Re: head -r335782 (?) broke's FreeBSD-head-amd64-gcc build (lib32 part of build)

From: John Baldwin <>
Date: Sat, 30 Jun 2018 11:53:48 -0700
On 6/30/18 10:19 AM, Mark Millard wrote:
> On 2018-Jun-30, at 10:04 AM, Mark Millard <marklmi at> wrote:
>> On 2018-Jun-30, at 9:29 AM, John Baldwin <jhb at> wrote:
>>> On 6/30/18 9:17 AM, Mark Millard wrote:
>>>> On 2018-Jun-30, at 7:51 AM, John Baldwin <jhb at> wrote:
>>>>> On 6/29/18 2:37 PM, Mark Millard wrote:
>>>>>> [I expect this is more than just amd64-gcc related but that is all
>>>>>> that normally builds via a devel/*-gcc .]
>>>>> As indicated by my other mail, this is i386 and amd64 specific as it
>>>>> only matters for float.h on i386 due to the disagreement on
>>>> I was correct about the search order for include files being
>>>> different before -r335782 vs. -r335782 and later:
>>> Yes, but this is kind of a feature, not a bug, and the issue there is that
>>> as much as possible we should allow FreeBSD to work with the standard headers
>>> that are supposed to be part of the language (and thus provided by the
>>> toolchain).  Right now we don't ship any of the 'std*.h' headers clang
>>> provides for example in our base system clang, though a few months ago I
>>> fixed the one place that was using <machine/stdarg.h> instead of
>>> <stdarg.h> in userland that was breaking the use of the toolchain-provided
>>> stdarg.h (both GCC and clang).
>>>> Might this reversal have other effects even for
>>>> architectures for which the code does compile
>>>> via devel/*-gcc ?
>>> It depends on the header.  This particular failure is due to a quirk of
>>> <float.h> on FreeBSD/i386.  I have built other platforms with external
>>> GCC just fine.  To the extent that we encounter any other issues we
>>> should try to make our source more conformant with C and only fall back to
>>> axeing the toolchain-provided language headers as a last resort.
>> It is too bad that the review did not
>> catch the change in what headers are used by buildworld and buildkernel.
>> I'd view such switching of long established header bindings as a
>> fairly big deal, possibly even warranting being explicitly proposed and
>> debated.
>> I'm not claiming my opinion on which search order that I have is
>> actually relevant. I'm just now nervous about my powerpc64-gcc based
>> builds having unexpected differences, for example. [I sometimes explore
>> the status of powerpc family builds via more modern toolchains.]
>> (But lib32 for powerpc64 via modern gcc's is messed up anyway,
>> generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly.
>> has more about
>> that.)
> Looks like my being nervous is justified: there is a conflicting altivec.h
> that has nothing to do with C/C++ language standards:
> # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/
> altivec.h		htmxlintrin.h		ppc-asm.h		spe.h			stdarg.h		stddef.h		stdint.h		varargs.h
> float.h			iso646.h		ppu_intrinsics.h	spu2vmx.h		stdatomic.h		stdfix.h		stdnoreturn.h		vec_types.h
> htmintrin.h		paired.h		si2vmx.h		stdalign.h		stdbool.h		stdint-gcc.h		tgmath.h
> I've not checked for other name conflicts vs. FreeBSD. I just happen
> to recognize altivec.h . There is:
> /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h
> /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h
> /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h

Actually, that is a compiler intrinsincs header similar to the <emmintrin.h>,
etc. headers used for SSE on x86 that are always provided by the compiler.
However, this header is '<altivec.h>' not '<machine/altivec.h>' so it won't conflict.

(On x86, these headers provide the _mm_* functions documented in Intel's
SDM as the official C bindings for vector extensions, and <altivec.h>
probably plays a similar role in providing the vendor-specified C
bindings for altivec instructions.)

John Baldwin
Received on Sat Jun 30 2018 - 16:53:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC