On 2018-Jun-30, at 10:04 AM, Mark Millard <marklmi at yahoo.com> wrote:
> On 2018-Jun-30, at 9:29 AM, John Baldwin <jhb at FreeBSD.org> wrote:
>
>> On 6/30/18 9:17 AM, Mark Millard wrote:
>>> On 2018-Jun-30, at 7:51 AM, John Baldwin <jhb at FreeBSD.org> 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 ci.freebsd.org 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
>>>> LDBL_MANT_DIG.
>>>
>>> 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 https://reviews.freebsd.org/D16055 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.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 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
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
