On 2018-Jun-30, at 11:53 AM, John Baldwin <jhb at freebsd.org> wrote:
> On 6/30/18 10:19 AM, Mark Millard wrote:
>
>
> 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
>
> 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.)
[This is based on a -r335812 build still.]
If I have a modern gcc build a system that includes building the system
clang, I do not expect it is that simple. There is:
/usr/src/contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:#include <altivec.h>
and altivec.h files around:
/usr/lib/clang/6.0.0/include/altivec.h
/usr/src/contrib/llvm/tools/clang/lib/Headers/altivec.h
/usr/src/contrib/gcc/config/rs6000/altivec.h
/usr/src/sys/powerpc/include/altivec.h
/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/altivec.h
/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
If I read the below right the gcc altivec.h will be found by
the above #include when building system clang via a modern gcc.
The Lex_Lexer.o.meta shows (note the lack of include in some of the paths
compared to the above places where altivec.h files actually are --and other
path mismatches):
ignoring nonexistent directory
"/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/c++/v1//powerpc64-unknown-freebsd12.0"
ignoring nonexistent directory
"/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/c++/v1//backward"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/../../../../powerpc64-unknown-freebsd12.0/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/libclang
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/lib/clang/libllvm
/usr/src/contrib/llvm/tools/clang/lib/Basic
/usr/src/contrib/llvm/tools/clang/lib/Driver
/usr/src/contrib/llvm/tools/clang/include
/usr/src/lib/clang/include
/usr/src/contrib/llvm/include
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/c++/v1/
/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include
End of search list.
But the old order would have found the FreeBSD one, not the clang one,
for its different order if I understand right. So it is not clear
that before -r335782 was right either. But is is now different from
what I can tell. What the consequences might be I do not (yet) know.
Just for completeness . . .
There are also uses of machine/altivec.h :
/usr/src/sys/powerpc/aim/aim_machdep.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/booke/spe.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/powermac/platform_powermac.c:#include <machine/altivec.h>
/* For save_vec() */
/usr/src/sys/powerpc/powerpc/altivec.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/powerpc/elf32_machdep.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/powerpc/elf64_machdep.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/powerpc/exec_machdep.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/powerpc/machdep.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/powerpc/ptrace_machdep.c:#include <machine/altivec.h>
/usr/src/sys/powerpc/powerpc/trap.c:#include <machine/altivec.h>
I'd wish that the file names for the 3 contexts had been made distinct to
avoid all potential aliasing problems.
===
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"
