Re: gcc behavior of init priority of .ctors and .dtors section
> On May 17, 2024, at 2:26 AM, Konstantin Belousov wrote:
>
> On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote:
>> Hi,
>>
>> I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
>> that gcc behaves weirdly.
>>
>> A simple source file to demonstrate that.
>>
>> ```
>> # cat ctors.c
>>
>> #include
>>
>> __attribute__((constructor(101))) void init_101() { puts("init 1"); }
>> __attribute__((constructor(65535))) void init_65535() { puts("init 3"); }
>> __attribute__((constructor)) void init() { puts("init 4"); }
>> __attribute__((constructor(65535))) void init_65535_2() { puts("init 5"); }
>> __attribute__((constructor(65534))) void init_65534() { puts("init 2"); }
>>
>> int main() { puts("main"); }
>>
>> __attribute__((destructor(65534))) void fini_65534() { puts("fini 2"); }
>> __attribute__((destructor(65535))) void fini_65535() { puts("fini 3"); }
>> __attribute__((destructor)) void fini() { puts("fini 4"); }
>> __attribute__((destructor(65535))) void fini_65535_2() { puts("fini 5"); }
>> __attribute__((destructor(101))) void fini_101() { puts("fini 1"); }
>>
>> # clang ctors.c && ./a.out
>> init 1
>> init 2
>> init 3
>> init 4
>> init 5
>> main
>> fini 5
>> fini 4
>> fini 3
>> fini 2
>> fini 1
>> ```
>>
>> clang with the option -fno-use-init-array and run will produce the same
>> result, which
>> is what I expected.
> Why do you add that switch?
gcc13 in ports is not configured with option --enable-initfini-array then it
only produces .ctors / .dtors sections but
not .init_array / .fini_array sections. So I add that switch for clang to
produce `.ctors` sections instead as
a baseline ( .ctors produced by clang indeed works as expected, the same with
.init_array ).
>
>>
>> gcc13 from ports
>> ```
>> # gcc ctors.c && ./a.out
>> init 1
>> init 2
>> init 5
>> init 4
>> init 3
>> main
>> fini 3
>> fini 4
>> fini 5
>> fini 2
>> fini 1
>> ```
>>
>> The above order is not expected. I think clang's one is correct.
>>
>> Further hacking with readelf shows that clang produces the right order of
>> section .rela.ctors but gcc does not.
>>
>> ```
>> # clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep
>> 'Relocation section with addend (.rela.ctors)' -A5 > clang.txt
>> # gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with
>> addend (.rela.ctors)' -A5 > gcc.txt
>> # diff clang.txt gcc.txt
>> 3,5c3,5
>> < 00080001 R_X86_64_64 0060
>> init_65535_2 + 0
>> < 0008 00070001 R_X86_64_64 0040 init + 0
>> < 0010 00060001 R_X86_64_64 0020 init_65535
>> + 0
>> ---
>>> 00060001 R_X86_64_64 0011 init_65535 + >>> 0
>>> 0008 00070001 R_X86_64_64 0022 init + 0
>>> 0010 00080001 R_X86_64_64 0033 init_65535_2
>>> + 0
>> ```
>>
>> The above show clearly gcc produces the wrong order of section `.rela.ctors`.
>>
>> Is that expected behavior ?
>>
>> I have not tried Linux version of gcc.
> Note that init array vs. init function behavior is encoded by a note added
> by crt1.o. I suspect that the problem is that gcc port is built without
> --enable-initfini-array configure option.
Re: gcc behavior of init priority of .ctors and .dtors section
On Thu, May 16, 2024 at 08:05:57PM +, Lorenzo Salvadore wrote: > On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov > wrote: > > > gcc13 from ports > > > `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3 > > > fini 4 fini 5 fini 2 fini 1` > > > > > > The above order is not expected. I think clang's one is correct. > > > > > > Further hacking with readelf shows that clang produces the right order of > > > section .rela.ctors but gcc does not. > > > > > > ``` > > > # clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep > > > 'Relocation section with addend (.rela.ctors)' -A5 > clang.txt > > > # gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with > > > addend (.rela.ctors)' -A5 > gcc.txt > > > # diff clang.txt gcc.txt > > > 3,5c3,5 > > > < 00080001 R_X86_64_64 0060 init_65535_2 + 0 > > > < 0008 00070001 R_X86_64_64 0040 init + 0 > > > < 0010 00060001 R_X86_64_64 0020 init_65535 + 0 > > > --- > > > > > > > 00060001 R_X86_64_64 0011 init_65535 + 0 > > > > 0008 00070001 R_X86_64_64 0022 init + 0 > > > > 00000010 00080001 R_X86_64_64 0033 init_65535_2 + 0 > > > > ``` > > > > > > The above show clearly gcc produces the wrong order of section > > > `.rela.ctors`. > > > > > > Is that expected behavior ? > > > > > > I have not tried Linux version of gcc. > > > > Note that init array vs. init function behavior is encoded by a note added > > by crt1.o. I suspect that the problem is that gcc port is built without > > --enable-initfini-array configure option. > > Indeed, support for .init_array and .fini_array has been added to the GCC > ports > but is present in the *-devel ports only for now. I will > soon proceed to enable it for the GCC standard ports too. lang/gcc14 is soon > to be added to the ports tree and will have it since the beginning. It is not 'support', but a bug. For very long time, crt1.o instructs rtld to use initarray instead of initfunc. gcc generates broken binaries trying to use initfunc. > > If this is indeed the issue, switching to a -devel GCC port should fix it. > > Cheers, > > Lorenzo Salvadore
Re: gcc behavior of init priority of .ctors and .dtors section
On Thursday, May 16th, 2024 at 20:26, Konstantin Belousov wrote: > > gcc13 from ports > > `# gcc ctors.c && ./a.out init 1 init 2 init 5 init 4 init 3 main fini 3 > > fini 4 fini 5 fini 2 fini 1` > > > > The above order is not expected. I think clang's one is correct. > > > > Further hacking with readelf shows that clang produces the right order of > > section .rela.ctors but gcc does not. > > > > ``` > > # clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep > > 'Relocation section with addend (.rela.ctors)' -A5 > clang.txt > > # gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with > > addend (.rela.ctors)' -A5 > gcc.txt > > # diff clang.txt gcc.txt > > 3,5c3,5 > > < 00080001 R_X86_64_64 0060 init_65535_2 + 0 > > < 0008 00070001 R_X86_64_64 0040 init + 0 > > < 0010 00060001 R_X86_64_64 0020 init_65535 + 0 > > --- > > > > > 00060001 R_X86_64_64 0011 init_65535 + 0 > > > 00000008 00070001 R_X86_64_64 0022 init + 0 > > > 0010 00080001 R_X86_64_64 0033 init_65535_2 + 0 > > > ``` > > > > The above show clearly gcc produces the wrong order of section > > `.rela.ctors`. > > > > Is that expected behavior ? > > > > I have not tried Linux version of gcc. > > Note that init array vs. init function behavior is encoded by a note added > by crt1.o. I suspect that the problem is that gcc port is built without > --enable-initfini-array configure option. Indeed, support for .init_array and .fini_array has been added to the GCC ports but is present in the *-devel ports only for now. I will soon proceed to enable it for the GCC standard ports too. lang/gcc14 is soon to be added to the ports tree and will have it since the beginning. If this is indeed the issue, switching to a -devel GCC port should fix it. Cheers, Lorenzo Salvadore
Re: gcc behavior of init priority of .ctors and .dtors section
On Thu, May 16, 2024 at 08:06:46PM +0800, Zhenlei Huang wrote:
> Hi,
>
> I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
> that gcc behaves weirdly.
>
> A simple source file to demonstrate that.
>
> ```
> # cat ctors.c
>
> #include
>
> __attribute__((constructor(101))) void init_101() { puts("init 1"); }
> __attribute__((constructor(65535))) void init_65535() { puts("init 3"); }
> __attribute__((constructor)) void init() { puts("init 4"); }
> __attribute__((constructor(65535))) void init_65535_2() { puts("init 5"); }
> __attribute__((constructor(65534))) void init_65534() { puts("init 2"); }
>
> int main() { puts("main"); }
>
> __attribute__((destructor(65534))) void fini_65534() { puts("fini 2"); }
> __attribute__((destructor(65535))) void fini_65535() { puts("fini 3"); }
> __attribute__((destructor)) void fini() { puts("fini 4"); }
> __attribute__((destructor(65535))) void fini_65535_2() { puts("fini 5"); }
> __attribute__((destructor(101))) void fini_101() { puts("fini 1"); }
>
> # clang ctors.c && ./a.out
> init 1
> init 2
> init 3
> init 4
> init 5
> main
> fini 5
> fini 4
> fini 3
> fini 2
> fini 1
> ```
>
> clang with the option -fno-use-init-array and run will produce the same
> result, which
> is what I expected.
Why do you add that switch?
>
> gcc13 from ports
> ```
> # gcc ctors.c && ./a.out
> init 1
> init 2
> init 5
> init 4
> init 3
> main
> fini 3
> fini 4
> fini 5
> fini 2
> fini 1
> ```
>
> The above order is not expected. I think clang's one is correct.
>
> Further hacking with readelf shows that clang produces the right order of
> section .rela.ctors but gcc does not.
>
> ```
> # clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep
> 'Relocation section with addend (.rela.ctors)' -A5 > clang.txt
> # gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with addend
> (.rela.ctors)' -A5 > gcc.txt
> # diff clang.txt gcc.txt
> 3,5c3,5
> < 00080001 R_X86_64_64 0060 init_65535_2
> + 0
> < 0008 00070001 R_X86_64_64 0040 init + 0
> < 0010 00060001 R_X86_64_64 0020 init_65535 + > 0
> ---
> > 0000 00060001 R_X86_64_64 0011 init_65535 + > > 0
> > 0008 00070001 R_X86_64_64 0022 init + 0
> > 0010 00080001 R_X86_64_64 0033 init_65535_2
> > + 0
> ```
>
> The above show clearly gcc produces the wrong order of section `.rela.ctors`.
>
> Is that expected behavior ?
>
> I have not tried Linux version of gcc.
Note that init array vs. init function behavior is encoded by a note added
by crt1.o. I suspect that the problem is that gcc port is built without
--enable-initfini-array configure option.
gcc behavior of init priority of .ctors and .dtors section
Hi,
I'm recently working on https://reviews.freebsd.org/D45194 and got noticed
that gcc behaves weirdly.
A simple source file to demonstrate that.
```
# cat ctors.c
#include
__attribute__((constructor(101))) void init_101() { puts("init 1"); }
__attribute__((constructor(65535))) void init_65535() { puts("init 3"); }
__attribute__((constructor)) void init() { puts("init 4"); }
__attribute__((constructor(65535))) void init_65535_2() { puts("init 5"); }
__attribute__((constructor(65534))) void init_65534() { puts("init 2"); }
int main() { puts("main"); }
__attribute__((destructor(65534))) void fini_65534() { puts("fini 2"); }
__attribute__((destructor(65535))) void fini_65535() { puts("fini 3"); }
__attribute__((destructor)) void fini() { puts("fini 4"); }
__attribute__((destructor(65535))) void fini_65535_2() { puts("fini 5"); }
__attribute__((destructor(101))) void fini_101() { puts("fini 1"); }
# clang ctors.c && ./a.out
init 1
init 2
init 3
init 4
init 5
main
fini 5
fini 4
fini 3
fini 2
fini 1
```
clang with the option -fno-use-init-array and run will produce the same result,
which
is what I expected.
gcc13 from ports
```
# gcc ctors.c && ./a.out
init 1
init 2
init 5
init 4
init 3
main
fini 3
fini 4
fini 5
fini 2
fini 1
```
The above order is not expected. I think clang's one is correct.
Further hacking with readelf shows that clang produces the right order of
section .rela.ctors but gcc does not.
```
# clang -fno-use-init-array -c ctors.c && readelf -r ctors.o | grep 'Relocation
section with addend (.rela.ctors)' -A5 > clang.txt
# gcc -c ctors.c && readelf -r ctors.o | grep 'Relocation section with addend
(.rela.ctors)' -A5 > gcc.txt
# diff clang.txt gcc.txt
3,5c3,5
< 00080001 R_X86_64_64 0060 init_65535_2 + 0
< 0008 00070001 R_X86_64_64 0040 init + 0
< 0010 00060001 R_X86_64_64 0020 init_65535 + 0
---
> 00060001 R_X86_64_64 0011 init_65535 + 0
> 0008 00070001 R_X86_64_64 0022 init + 0
> 0010 00080001 R_X86_64_64 0033 init_65535_2 + > 0
```
The above show clearly gcc produces the wrong order of section `.rela.ctors`.
Is that expected behavior ?
I have not tried Linux version of gcc.
Best regards,
Zhenlei
Re: Buildworld fails with external GCC toolchain
From: Yasuhiro Kimura Subject: Re: Buildworld fails with external GCC toolchain Date: Tue, 15 Feb 2022 08:26:00 +0900 (JST) >> I have amd64 world + kernel building with GCC 9 and the only remaining >> open review not merged yet is https://reviews.freebsd.org/D34147. >> >> It is work to keep it working though and I hadn't worked on it again >> until recently. > > Thanks for letting me know. I tried patch of the review and confirmed > both buildworld and buildkernel succeed with GCC 9 and binutils 2.37. > So I reached start point now and can test binutils 2.38. I tried buildworld and buildkernel with binutils 2.38 and they completed successfully. Just FYI. --- Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
From: John Baldwin
Subject: Re: Buildworld fails with external GCC toolchain
Date: Mon, 14 Feb 2022 10:46:29 -0800
>>> Not really, the gcc 9 build has been broken for months, as far as I
>>> know.
>>>
>>> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>>>
>>> The last build(s) show a different error from yours, though:
>>>
>>> /workspace/src/tests/sys/netinet/libalias/util.c: In function
>>> 'set_udp':
>>> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error:
>>> converting a packed 'struct ip' pointer (alignment 2) to a 'uint32_t'
>>> {aka 'unsigned int'} pointer (alignment 4) may result in an unaligned
>>> pointer value [-Werror=address-of-packed-member]
>>>112 | uint32_t *up = (void *)p;
>>>| ^~~~
>>> In file included from
>>> /workspace/src/tests/sys/netinet/libalias/util.h:37,
>>> from /workspace/src/tests/sys/netinet/libalias/util.c:39:
>>> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>>> 51 | struct ip {
>>>|^~
>>>
>>> -Dimitry
>>>
>> Thanks for information. I went back the commit history of main branch
>> about every month and check if buildworld succeeds with GCC. But it
>> didn't succeed even if I went back about a year. And devel/binutils
>> port was update to 2.37 on last August. So I suspect external GCC
>> toolchain doesn't work well after binutils is updated to current
>> version.
>
> I have amd64 world + kernel building with GCC 9 and the only remaining
> open review not merged yet is https://reviews.freebsd.org/D34147.
>
> It is work to keep it working though and I hadn't worked on it again
> until recently.
Thanks for letting me know. I tried patch of the review and confirmed
both buildworld and buildkernel succeed with GCC 9 and binutils 2.37.
So I reached start point now and can test binutils 2.38.
---
Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
On 2/12/22 11:34 AM, Yasuhiro Kimura wrote:
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
Not really, the gcc 9 build has been broken for months, as far as I know.
See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
The last build(s) show a different error from yours, though:
/workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
/workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a
packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'}
pointer (alignment 4) may result in an unaligned pointer value
[-Werror=address-of-packed-member]
112 | uint32_t *up = (void *)p;
| ^~~~
In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
from /workspace/src/tests/sys/netinet/libalias/util.c:39:
/workspace/src/sys/netinet/ip.h:51:8: note: defined here
51 | struct ip {
|^~
-Dimitry
Thanks for information. I went back the commit history of main branch
about every month and check if buildworld succeeds with GCC. But it
didn't succeed even if I went back about a year. And devel/binutils
port was update to 2.37 on last August. So I suspect external GCC
toolchain doesn't work well after binutils is updated to current
version.
I have amd64 world + kernel building with GCC 9 and the only remaining
open review not merged yet is https://reviews.freebsd.org/D34147.
It is work to keep it working though and I hadn't worked on it again
until recently.
--
John Baldwin
Re: Buildworld fails with external GCC toolchain
From: Dimitry Andric
Subject: Re: Buildworld fails with external GCC toolchain
Date: Fri, 11 Feb 2022 22:53:44 +0100
> Not really, the gcc 9 build has been broken for months, as far as I know.
>
> See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
>
> The last build(s) show a different error from yours, though:
>
> /workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
> /workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a
> packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'}
> pointer (alignment 4) may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
> 112 | uint32_t *up = (void *)p;
> | ^~~~
> In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
> from /workspace/src/tests/sys/netinet/libalias/util.c:39:
> /workspace/src/sys/netinet/ip.h:51:8: note: defined here
>51 | struct ip {
> |^~
>
> -Dimitry
>
Thanks for information. I went back the commit history of main branch
about every month and check if buildworld succeeds with GCC. But it
didn't succeed even if I went back about a year. And devel/binutils
port was update to 2.37 on last August. So I suspect external GCC
toolchain doesn't work well after binutils is updated to current
version.
---
Yasuhiro Kimura
Re: Buildworld fails with external GCC toolchain
On 11 Feb 2022, at 21:07, Yasuhiro Kimura wrote:
>
> I'm tring to update devel/binutils port to 2.38. When it was updated
> to 2.37.1, there was a suggestion that it should also be checked if
> building base system with GCC succeeds as binutils is a part of
> external GCC toolchain. So I'd like to do it with binutils 2.38 before
> updating the port. And as a preparation for it, I tried building base
> system with current external GCC toolchain (that is, with binutils
> 2.37.1).
>
> At first I read following wiki pages.
>
> https://wiki.freebsd.org/ExternalToolchain
> https://wiki.freebsd.org/ExternalGCC
>
> Next I took following steps.
>
> 1. Make clean install of 14-CURRENT amd64 with the install image of
> 20220210 snapshot.
> 2. Checkout latest main of src repository (d4b0fa45dc1 at that time).
> 3. pkg install amd64-gcc9
> 4. cd /usr/src
> 5. make -j 4 CROSS_TOOLCHAIN=amd64-gcc9 buildworld buildkernel
>
> Then step 5 failed as following.
>
> --
> --- all_subdir_rescue ---
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld: nc.lo: in function `_$$hide$$
> nc.lo main':
> (.text.startup+0xd42): warning: warning: mktemp() possibly used unsafely;
> consider using mkstemp()
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_set_term.o):
> in function `_nc_setupscreen_sp':
> /usr/src/contrib/ncurses/ncurses/base/lib_set_term.c:415: undefined reference
> to `_nc_set_buffer_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_tstp.o): in
> function `handle_SIGTSTP':
> /usr/src/contrib/ncurses/ncurses/tty/lib_tstp.c:222: undefined reference to
> `flushinp_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getch.o): in
> function `check_mouse_activity':
> /usr/src/contrib/ncurses/ncurses/base/lib_getch.c:188: undefined reference to
> `_nc_timed_wait'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getstr.o): in
> function `wgetnstr':
> /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:106: undefined reference
> to `erasechar_sp'
> /usr/local/bin/x86_64-unknown-freebsd14.0-ld:
> /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:107: undefined reference
> to `killchar_sp'
> collect2: error: ld returned 1 exit status
> *** [rescue] Error code 1
>
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> --- all_subdir_stand ---
>
> make[2]: stopped in /usr/src
> --- all_subdir_share ---
>
> make[2]: stopped in /usr/src
> --- all_subdir_rescue ---
> 1 error
>
> make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue
> *** [rescue] Error code 2
>
> make[4]: stopped in /usr/src/rescue/rescue
> 1 error
>
> make[4]: stopped in /usr/src/rescue/rescue
>
> make[3]: stopped in /usr/src/rescue
>
> make[2]: stopped in /usr/src
> --- all_subdir_lib ---
>
> make[2]: stopped in /usr/src
> 167.49 real 492.07 user94.42 sys
>
> make[1]: stopped in /usr/src
>
> make: stopped in /usr/src
> --
>
> If I check commit messages of main branch over the last few months, I
> can find some commits that fix warning message displayed by GCC. So
> currently external GCC toolchain seems to work fine. Then what is the
> cause of my build failure? Did I do something wrong?
Not really, the gcc 9 build has been broken for months, as far as I know.
See also: https://ci.freebsd.org/job/FreeBSD-main-amd64-gcc9_build/
The last build(s) show a different error from yours, though:
/workspace/src/tests/sys/netinet/libalias/util.c: In function 'set_udp':
/workspace/src/tests/sys/netinet/libalias/util.c:112:2: error: converting a
packed 'struct ip' pointer (alignment 2) to a 'uint32_t' {aka 'unsigned int'}
pointer (alignment 4) may result in an unaligned pointer value
[-Werror=address-of-packed-member]
112 | uint32_t *up = (void *)p;
| ^~~~
In file included from /workspace/src/tests/sys/netinet/libalias/util.h:37,
from /workspace/src/tests/sys/netinet/libalias/util.c:39:
/workspace/src/sys/netinet/ip.h:51:8: note: defined here
51 | struct ip {
|^~
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Buildworld fails with external GCC toolchain
Hello, I'm tring to update devel/binutils port to 2.38. When it was updated to 2.37.1, there was a suggestion that it should also be checked if building base system with GCC succeeds as binutils is a part of external GCC toolchain. So I'd like to do it with binutils 2.38 before updating the port. And as a preparation for it, I tried building base system with current external GCC toolchain (that is, with binutils 2.37.1). At first I read following wiki pages. https://wiki.freebsd.org/ExternalToolchain https://wiki.freebsd.org/ExternalGCC Next I took following steps. 1. Make clean install of 14-CURRENT amd64 with the install image of 20220210 snapshot. 2. Checkout latest main of src repository (d4b0fa45dc1 at that time). 3. pkg install amd64-gcc9 4. cd /usr/src 5. make -j 4 CROSS_TOOLCHAIN=amd64-gcc9 buildworld buildkernel Then step 5 failed as following. -- --- all_subdir_rescue --- /usr/local/bin/x86_64-unknown-freebsd14.0-ld: nc.lo: in function `_$$hide$$ nc.lo main': (.text.startup+0xd42): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_set_term.o): in function `_nc_setupscreen_sp': /usr/src/contrib/ncurses/ncurses/base/lib_set_term.c:415: undefined reference to `_nc_set_buffer_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_tstp.o): in function `handle_SIGTSTP': /usr/src/contrib/ncurses/ncurses/tty/lib_tstp.c:222: undefined reference to `flushinp_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getch.o): in function `check_mouse_activity': /usr/src/contrib/ncurses/ncurses/base/lib_getch.c:188: undefined reference to `_nc_timed_wait' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libncursesw_real.a(lib_getstr.o): in function `wgetnstr': /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:106: undefined reference to `erasechar_sp' /usr/local/bin/x86_64-unknown-freebsd14.0-ld: /usr/src/contrib/ncurses/ncurses/base/lib_getstr.c:107: undefined reference to `killchar_sp' collect2: error: ld returned 1 exit status *** [rescue] Error code 1 make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue --- all_subdir_stand --- make[2]: stopped in /usr/src --- all_subdir_share --- make[2]: stopped in /usr/src --- all_subdir_rescue --- 1 error make[5]: stopped in /usr/obj/usr/src/amd64.amd64/rescue/rescue *** [rescue] Error code 2 make[4]: stopped in /usr/src/rescue/rescue 1 error make[4]: stopped in /usr/src/rescue/rescue make[3]: stopped in /usr/src/rescue make[2]: stopped in /usr/src --- all_subdir_lib --- make[2]: stopped in /usr/src 167.49 real 492.07 user94.42 sys make[1]: stopped in /usr/src make: stopped in /usr/src -- If I check commit messages of main branch over the last few months, I can find some commits that fix warning message displayed by GCC. So currently external GCC toolchain seems to work fine. Then what is the cause of my build failure? Did I do something wrong? Best Regards. --- Yasuhiro Kimura
gcc bootstrap or such outdated references in src.conf and make.conf for 13 and 14
QUOTE from man src.conf : To be able to build the system, either gcc or clang bootstrap must be enabled unless an alternate compiler is provided via XCC. END QUOTE QUOTE from man src.conf : The CCACHE_COMPILERCHECK option defaults to content when using the in-tree bootstrap compiler, and mtime when using an external compiler. The CCACHE_CPP2 option is used for Clang but not GCC. END QUOTE With clang/clang++ 11's change to what -O means, I'm not sure about the following from man make.conf : QUOTE from man make.conf CFLAGS(str) Controls the compiler setting when compiling C code. Optimization levels other than -O and -O2 are not supported. END QUOTE Same here: QUOTE from man make.conf COPTFLAGS (str) Controls the compiler settings when building the kernel. Optimization levels above [-O (-O2, ...)] are not guaranteed to work. END QUOTE Context man outputs are from: # ~/fbsd-based-on-what-freebsd-main.sh merge-base: 3f43ada98c89bce5ae416e203ba0e81595a5cd88 merge-base: CommitDate: 2021-01-29 19:46:24 + e124d7d5fc88 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. 3f43ada98c89 (freebsd/main, freebsd/HEAD, pure-src, main) Catch up with 6edfd179c86: mechanically rename IFCAP_NOMAP to IFCAP_MEXTPG. FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244523-e124d7d5fc88 GENERIC-NODBG amd64 amd64 143 143 === 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"
Re: gcc versus clang issue for 32-bit binaries
> On 10. Jun 2020, at 20:30, Damjan Jovanovic wrote:
>
> MAP_FIXED is generally bad news, as it overwrites any prior mappings within
> the range of addresses being mapped to.
>
> They should use MAP_FIXED | MAP_EXCL instead, which will fail if any mappings
> already exist in the range, and then maybe retry with another range if it
> fails. Linux and NetBSD have MAP_TRYFIXED instead, which does the retrying
> internally. Or at the very least, run mincore() on every page in the range to
> verify that nothing is mapped before using mmap() with MAP_FIXED.
It is used in syzkaller. Some go code generates C include files... So right now
I might want
to stick with a value.
>
> If there is no other way but to use a single hardcoded value, check
> /proc//map for a number of different processes, 32 and 64 bit, and find
> an address range that isn't used often.
Thanks for the hint. I tried to find one. Let's see how good this guess is.
Best regards
Michael
>
> Damjan
>
>
> On Wed, Jun 10, 2020 at 7:40 PM Michael Tuexen wrote:
> > On 10. Jun 2020, at 18:59, Mark Johnston wrote:
> >
> > On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
> >> Dear all,
> >>
> >> consider the following program test.c:
> >>
> >> #include
> >> #include
> >>
> >> int
> >> main(void)
> >> {
> >> void *p;
> >>
> >> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
> >> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> >> printf("p= %p\n", p);
> >> return (0);
> >> }
> >>
> >> On i386 the following happens:
> >> * when compiling it with cc and running it, it crashes.
> >> * when compiling it with gcc it runs fine.
> >>
> >> On amd64 the following happens:
> >> * when compiling it with cc -m64 it runs fine.
> >> * when compiling it with cc -m32 is crashes.
> >> * when compiling it with gcc -m64 it runs fine.
> >> * when compiling it with gcc -m32 it runs fine.
> >>
> >> So why does the above program crash when compiled for 32-bit when using
> >> clang, but runs fine when compiled with gcc.
> >
> > The difference is between ld.bfd and ld.lld, which emit executables with
> > different entry point addresses. cc -m32 -fuse-ld=bfd gives an
> > executable that does not crash.
> >
> > When linked with lld, libc and ld-elf get mapped into the region
> > [0x2000,0x2100], so the program crashes when the libc.so mapping
> > is overwritten with that created by the mmap() call and the program
> > calls printf().
> >
> >> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
> >>
> >> The reason I'm looking into it is that I want to get syzkaller working on
> >> 32-bit with clang.
> >
> > Do you know why SYZ_DATA_OFFSET is hard-coded the way it is? It looks
> > like it works more or less by accident, but at a glance I don't see why
> > it has to be a fixed mapping.
> I don't know, it comes from:
> https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L450
>
> Do you have a value which can be used on FreeBSD? Then we can just change
> it...
>
> Best regards
> Michael
>
> ___
> 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"
___
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"
Re: gcc versus clang issue for 32-bit binaries
> On 10. Jun 2020, at 18:59, Mark Johnston wrote:
>
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> consider the following program test.c:
>>
>> #include
>> #include
>>
>> int
>> main(void)
>> {
>> void *p;
>>
>> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
>> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
>> printf("p= %p\n", p);
>> return (0);
>> }
>>
>> On i386 the following happens:
>> * when compiling it with cc and running it, it crashes.
>> * when compiling it with gcc it runs fine.
>>
>> On amd64 the following happens:
>> * when compiling it with cc -m64 it runs fine.
>> * when compiling it with cc -m32 is crashes.
>> * when compiling it with gcc -m64 it runs fine.
>> * when compiling it with gcc -m32 it runs fine.
>>
>> So why does the above program crash when compiled for 32-bit when using
>> clang, but runs fine when compiled with gcc.
>
> The difference is between ld.bfd and ld.lld, which emit executables with
> different entry point addresses. cc -m32 -fuse-ld=bfd gives an
> executable that does not crash.
>
> When linked with lld, libc and ld-elf get mapped into the region
> [0x2000,0x2100], so the program crashes when the libc.so mapping
> is overwritten with that created by the mmap() call and the program
> calls printf().
>
>> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
>>
>> The reason I'm looking into it is that I want to get syzkaller working on
>> 32-bit with clang.
>
> Do you know why SYZ_DATA_OFFSET is hard-coded the way it is? It looks
> like it works more or less by accident, but at a glance I don't see why
> it has to be a fixed mapping.
It looks like 0x1000 works fine on my 32-bit VM.
I added you as a reviewer on https://github.com/google/syzkaller/pull/1809
Best regards
Michael
___
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"
Re: gcc versus clang issue for 32-bit binaries
MAP_FIXED is generally bad news, as it overwrites any prior mappings within
the range of addresses being mapped to.
They should use MAP_FIXED | MAP_EXCL instead, which will fail if any
mappings already exist in the range, and then maybe retry with another
range if it fails. Linux and NetBSD have MAP_TRYFIXED instead, which does
the retrying internally. Or at the very least, run mincore() on every page
in the range to verify that nothing is mapped before using mmap() with
MAP_FIXED.
If there is no other way but to use a single hardcoded value, check
/proc//map for a number of different processes, 32 and 64 bit, and
find an address range that isn't used often.
Damjan
On Wed, Jun 10, 2020 at 7:40 PM Michael Tuexen wrote:
> > On 10. Jun 2020, at 18:59, Mark Johnston wrote:
> >
> > On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
> >> Dear all,
> >>
> >> consider the following program test.c:
> >>
> >> #include
> >> #include
> >>
> >> int
> >> main(void)
> >> {
> >> void *p;
> >>
> >> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> >> printf("p= %p\n", p);
> >> return (0);
> >> }
> >>
> >> On i386 the following happens:
> >> * when compiling it with cc and running it, it crashes.
> >> * when compiling it with gcc it runs fine.
> >>
> >> On amd64 the following happens:
> >> * when compiling it with cc -m64 it runs fine.
> >> * when compiling it with cc -m32 is crashes.
> >> * when compiling it with gcc -m64 it runs fine.
> >> * when compiling it with gcc -m32 it runs fine.
> >>
> >> So why does the above program crash when compiled for 32-bit when using
> clang, but runs fine when compiled with gcc.
> >
> > The difference is between ld.bfd and ld.lld, which emit executables with
> > different entry point addresses. cc -m32 -fuse-ld=bfd gives an
> > executable that does not crash.
> >
> > When linked with lld, libc and ld-elf get mapped into the region
> > [0x2000,0x2100], so the program crashes when the libc.so mapping
> > is overwritten with that created by the mmap() call and the program
> > calls printf().
> >
> >> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
> >>
> >> The reason I'm looking into it is that I want to get syzkaller working
> on 32-bit with clang.
> >
> > Do you know why SYZ_DATA_OFFSET is hard-coded the way it is? It looks
> > like it works more or less by accident, but at a glance I don't see why
> > it has to be a fixed mapping.
> I don't know, it comes from:
> https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L450
>
> Do you have a value which can be used on FreeBSD? Then we can just change
> it...
>
> Best regards
> Michael
>
> ___
> 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"
>
___
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"
Re: gcc versus clang issue for 32-bit binaries
> On 10. Jun 2020, at 18:59, Mark Johnston wrote:
>
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>>
>> consider the following program test.c:
>>
>> #include
>> #include
>>
>> int
>> main(void)
>> {
>> void *p;
>>
>> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
>> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
>> printf("p= %p\n", p);
>> return (0);
>> }
>>
>> On i386 the following happens:
>> * when compiling it with cc and running it, it crashes.
>> * when compiling it with gcc it runs fine.
>>
>> On amd64 the following happens:
>> * when compiling it with cc -m64 it runs fine.
>> * when compiling it with cc -m32 is crashes.
>> * when compiling it with gcc -m64 it runs fine.
>> * when compiling it with gcc -m32 it runs fine.
>>
>> So why does the above program crash when compiled for 32-bit when using
>> clang, but runs fine when compiled with gcc.
>
> The difference is between ld.bfd and ld.lld, which emit executables with
> different entry point addresses. cc -m32 -fuse-ld=bfd gives an
> executable that does not crash.
>
> When linked with lld, libc and ld-elf get mapped into the region
> [0x2000,0x2100], so the program crashes when the libc.so mapping
> is overwritten with that created by the mmap() call and the program
> calls printf().
>
>> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
>>
>> The reason I'm looking into it is that I want to get syzkaller working on
>> 32-bit with clang.
>
> Do you know why SYZ_DATA_OFFSET is hard-coded the way it is? It looks
> like it works more or less by accident, but at a glance I don't see why
> it has to be a fixed mapping.
I don't know, it comes from:
https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L450
Do you have a value which can be used on FreeBSD? Then we can just change it...
Best regards
Michael
___
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"
Re: gcc versus clang issue for 32-bit binaries
On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
> Dear all,
>
> consider the following program test.c:
>
> #include
> #include
>
> int
> main(void)
> {
> void *p;
>
> p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> printf("p= %p\n", p);
> return (0);
> }
>
> On i386 the following happens:
> * when compiling it with cc and running it, it crashes.
> * when compiling it with gcc it runs fine.
>
> On amd64 the following happens:
> * when compiling it with cc -m64 it runs fine.
> * when compiling it with cc -m32 is crashes.
> * when compiling it with gcc -m64 it runs fine.
> * when compiling it with gcc -m32 it runs fine.
>
> So why does the above program crash when compiled for 32-bit when using
> clang, but runs fine when compiled with gcc.
The difference is between ld.bfd and ld.lld, which emit executables with
different entry point addresses. cc -m32 -fuse-ld=bfd gives an
executable that does not crash.
When linked with lld, libc and ld-elf get mapped into the region
[0x2000,0x2100], so the program crashes when the libc.so mapping
is overwritten with that created by the mmap() call and the program
calls printf().
> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
>
> The reason I'm looking into it is that I want to get syzkaller working on
> 32-bit with clang.
Do you know why SYZ_DATA_OFFSET is hard-coded the way it is? It looks
like it works more or less by accident, but at a glance I don't see why
it has to be a fixed mapping.
___
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"
gcc versus clang issue for 32-bit binaries
Dear all,
consider the following program test.c:
#include
#include
int
main(void)
{
void *p;
p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE |
PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
printf("p= %p\n", p);
return (0);
}
On i386 the following happens:
* when compiling it with cc and running it, it crashes.
* when compiling it with gcc it runs fine.
On amd64 the following happens:
* when compiling it with cc -m64 it runs fine.
* when compiling it with cc -m32 is crashes.
* when compiling it with gcc -m64 it runs fine.
* when compiling it with gcc -m32 it runs fine.
So why does the above program crash when compiled for 32-bit when using clang,
but runs fine when compiled with gcc.
I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
The reason I'm looking into it is that I want to get syzkaller working on
32-bit with clang.
Best regards
Michael
___
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"
GCC/gcc references in man src.conf output (as of head -r358510 anyway), more . . .
The following 2 references to GCC or gcc may not be intended
any more:
The
CCACHE_CPP2 option is used for Clang but not GCC.
To be able to build the system, either gcc
or clang bootstrap must be enabled unless an alternate compiler
is provided via XCC.
(That is it for GCC/gcc.)
The WITH_BINUTILS is interesting in that for:
arm/armv6, arm/armv7,
i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64,
mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf,
mips/mips64hf
the description would seem to imply the same result for
them as for WITHOUT_BINUTILS: as, objdump, and ld.bfd not
built and installed. Whatever the internal mechanism, I think
it would be clearer to list the above under WITHOUT_BINUTILS
for their default handling.
The text:
WITHOUT_ELFTOOLCHAIN_BOOTSTRAP
Set to not build ELF Tool Chain tools (addr2line, nm, size,
strings and strip) as part of the bootstrap process. An
alternate bootstrap tool chain must be provided.
gives no hint how to provide an alternate bootstrap tool chain
that has those programs.
The issue is somewhat wider in that only XCC and XLD are mentioned
anywhere. (For example, no XCXX, XCPP either.) Of course when the
C/C++ compiler command lines are used to run the linker the likes of
XLD do not help redirect what is attempted.
The text:
WITH_LLVM_TARGET_SPARC
Set to build LLVM target support for SPARC. The LLVM_TARGET_ALL
option should be used rather than this in most cases.
still is SPARC material.
As I remember, the text:
WITH_REPRODUCIBLE_BUILD
Set to exclude build metadata (such as the build time, user, or
host) from the kernel, boot loaders, and uname output, so that
builds produce bit-for-bit identical output.
suggests more control than the option actually gives
(most of the time).
The text:
WITHOUT_UNIFIED_OBJDIR
Set to use the historical object directory format for build(7)
targets. For native-builds and builds done directly in sub-
directories the format of ${MAKEOBJDIRPREFIX}/${.CURDIR} is used,
while for cross-builds
${MAKEOBJDIRPREFIX}/${TARGET}.${TARGET_ARCH}/${.CURDIR} is used.
This option is transitional and will be removed before the 12.0
release, at which time will be enabled permanently.
This must be set in the environment, make command line, or
/etc/src-env.conf, not /etc/src.conf.
mentions that the option was to be removed before 12.0 . (It also
says that the to-be-removed option will be enabled when removed.)
===
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"
Re: New external GCC toolchain ports/packages
On Fri, Dec 20, 2019 at 10:15 AM Konstantin Belousov wrote: > > On Fri, Dec 20, 2019 at 09:51:15AM -0800, Ryan Libby wrote: > > On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov > > wrote: > > > > > > On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > > > > On 12/19/19 12:06 PM, Ryan Libby wrote: > > > > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > > > >> > > > > >> In the interest of supporting newer versions of GCC for a base system > > > > >> toolchain, I've renamed the external GCC packages from -gcc > > > > >> to -gcc6. These are built as flavors of a new > > > > >> devel/freebsd-gcc6 > > > > >> port. The xtoolchain package is not used for these new packages, > > > > >> instead > > > > >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > > > > >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated > > > > >> this > > > > >> compiler to 6.5.0. > > > > >> > > > > >> I will leave the old ports/packages around for now to permit an easy > > > > >> transition, but going forward, the -gcc6 packages should be > > > > >> preferred > > > > >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and > > > > >> riscv64-xtoolchain-gcc > > > > >> are separate from the powerpc64-gcc set of packages). > > > > >> > > > > >> In addition, I've also just added a devel/freebsd-gcc9 package which > > > > >> builds -gcc9 packages. It adds powerpc and riscv flavors > > > > >> relative > > > > >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet > > > > >> to > > > > >> be able to finish a buildworld on any of the platforms I've tried > > > > >> (amd64, mips, sparc64), but the packages should permit other > > > > >> developers > > > > >> to get the tree building with GCC 9. To use these packages one > > > > >> would do > > > > >> something like: > > > > >> > > > > >> # pkg install amd64-gcc9 > > > > >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > > > > >> > > > > >> You can install both the gcc6 and gcc9 versions of a package at the > > > > >> same > > > > >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for > > > > >> major > > > > >> versions is similar to llvm and will also let us keep a known-good > > > > >> toolchain package for older releases while using newer major > > > > >> versions on > > > > >> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > > > > >> > > > > >> I do plan to switch the default toolchains for make > > > > >> universe/tinderbox > > > > >> for targets using -xtoolchain-gcc based on GCC 6 over to the > > > > >> freebsd-gcc6 variants in the next week or so. > > > > >> > > > > >> -- > > > > >> John Baldwin > > > > > > > > > > Awesome, thanks! I was able to get amd64 buildworld and buildkernel > > > > > to > > > > > succeed with just a few changes, and none to the port. I'll work on > > > > > getting the changes in. > > > > > > > > I have been able to get it building as well, mostly by muting a few > > > > warnings, adding libcompiler_rt to rtld's link for i386, disabling > > > I am curious about the rtld issue. Can you show me the pristine error > > > with > > > gcc, please ? > > > > For me, it's gcc generates __udivmoddi4 for the -m32 build but we used > > -nostdlib, and we get a link error. My hack right now is to explicitly > > link libgcc, but I don't think this is what we are intending to do > > because we seem to go through effort to reimplement other libgcc > > functions. > > > > Here's the text: > > --- ld-elf32.so.1.full --- > > /usr/local/bin/x86_64-unknown-freebsd13.0-ld: rtld_printf.o: in > > function `ksprintn': > > /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:115: undefined > > reference to `__udivmoddi4' > > /usr/local/bin/x86_64-unknown-freebsd13.0-ld: > > /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:117: undefined > > reference to `__udivmoddi4' > > collect2: error: ld returned 1 exit status > > *** [ld-elf32.so.1.full] Error code 1 > > > > You can see my hack at the link below. I'm not sure what the > > right solution is. > Does changing the base type from int to u_int help ? It does not; it fails in the same way. ___ 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"
Re: New external GCC toolchain ports/packages
On Fri, Dec 20, 2019 at 09:51:15AM -0800, Ryan Libby wrote: > On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov > wrote: > > > > On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > > > On 12/19/19 12:06 PM, Ryan Libby wrote: > > > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > > >> > > > >> In the interest of supporting newer versions of GCC for a base system > > > >> toolchain, I've renamed the external GCC packages from -gcc > > > >> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > > > >> port. The xtoolchain package is not used for these new packages, > > > >> instead > > > >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > > > >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated > > > >> this > > > >> compiler to 6.5.0. > > > >> > > > >> I will leave the old ports/packages around for now to permit an easy > > > >> transition, but going forward, the -gcc6 packages should be > > > >> preferred > > > >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and > > > >> riscv64-xtoolchain-gcc > > > >> are separate from the powerpc64-gcc set of packages). > > > >> > > > >> In addition, I've also just added a devel/freebsd-gcc9 package which > > > >> builds -gcc9 packages. It adds powerpc and riscv flavors > > > >> relative > > > >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to > > > >> be able to finish a buildworld on any of the platforms I've tried > > > >> (amd64, mips, sparc64), but the packages should permit other developers > > > >> to get the tree building with GCC 9. To use these packages one would > > > >> do > > > >> something like: > > > >> > > > >> # pkg install amd64-gcc9 > > > >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > > > >> > > > >> You can install both the gcc6 and gcc9 versions of a package at the > > > >> same > > > >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for > > > >> major > > > >> versions is similar to llvm and will also let us keep a known-good > > > >> toolchain package for older releases while using newer major versions > > > >> on > > > >> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > > > >> > > > >> I do plan to switch the default toolchains for make universe/tinderbox > > > >> for targets using -xtoolchain-gcc based on GCC 6 over to the > > > >> freebsd-gcc6 variants in the next week or so. > > > >> > > > >> -- > > > >> John Baldwin > > > > > > > > Awesome, thanks! I was able to get amd64 buildworld and buildkernel to > > > > succeed with just a few changes, and none to the port. I'll work on > > > > getting the changes in. > > > > > > I have been able to get it building as well, mostly by muting a few > > > warnings, adding libcompiler_rt to rtld's link for i386, disabling > > I am curious about the rtld issue. Can you show me the pristine error with > > gcc, please ? > > For me, it's gcc generates __udivmoddi4 for the -m32 build but we used > -nostdlib, and we get a link error. My hack right now is to explicitly > link libgcc, but I don't think this is what we are intending to do > because we seem to go through effort to reimplement other libgcc > functions. > > Here's the text: > --- ld-elf32.so.1.full --- > /usr/local/bin/x86_64-unknown-freebsd13.0-ld: rtld_printf.o: in > function `ksprintn': > /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:115: undefined > reference to `__udivmoddi4' > /usr/local/bin/x86_64-unknown-freebsd13.0-ld: > /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:117: undefined > reference to `__udivmoddi4' > collect2: error: ld returned 1 exit status > *** [ld-elf32.so.1.full] Error code 1 > > You can see my hack at the link below. I'm not sure what the > right solution is. Does changing the base type from int to u_int help ? > > > > > > googletest (needs an upstream patch to stop using signed wchar_t), > > > and a hack to jemalloc. I was able to build riscv as well with those > > > same changes and am working through builds of other platforms. > > > > > Actually, both those have upstream fixes. (For the jemalloc one, gcc is > technically right, but because of a literal signed char argument to a > macro.) > > > > I'm happy to compare notes. The jemalloc one is a bit weird. > > I pushed non-polished changes here. I'm working to get them reviewed. > Please feel free to comment on any/all. > https://github.com/rlibby/freebsd/commits/gcc9-fixes > > > > > > > -- > > > John Baldwin > > > ___ > > > freebsd-toolch...@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > > To unsubscribe, send any mail to > > > "freebsd-toolchain-unsubscr...@freebsd.org" ___ 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"
Re: New external GCC toolchain ports/packages
On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov wrote: > > On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > > On 12/19/19 12:06 PM, Ryan Libby wrote: > > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > >> > > >> In the interest of supporting newer versions of GCC for a base system > > >> toolchain, I've renamed the external GCC packages from -gcc > > >> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > > >> port. The xtoolchain package is not used for these new packages, instead > > >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > > >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this > > >> compiler to 6.5.0. > > >> > > >> I will leave the old ports/packages around for now to permit an easy > > >> transition, but going forward, the -gcc6 packages should be > > >> preferred > > >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and > > >> riscv64-xtoolchain-gcc > > >> are separate from the powerpc64-gcc set of packages). > > >> > > >> In addition, I've also just added a devel/freebsd-gcc9 package which > > >> builds -gcc9 packages. It adds powerpc and riscv flavors relative > > >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to > > >> be able to finish a buildworld on any of the platforms I've tried > > >> (amd64, mips, sparc64), but the packages should permit other developers > > >> to get the tree building with GCC 9. To use these packages one would do > > >> something like: > > >> > > >> # pkg install amd64-gcc9 > > >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > > >> > > >> You can install both the gcc6 and gcc9 versions of a package at the same > > >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for > > >> major > > >> versions is similar to llvm and will also let us keep a known-good > > >> toolchain package for older releases while using newer major versions on > > >> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > > >> > > >> I do plan to switch the default toolchains for make universe/tinderbox > > >> for targets using -xtoolchain-gcc based on GCC 6 over to the > > >> freebsd-gcc6 variants in the next week or so. > > >> > > >> -- > > >> John Baldwin > > > > > > Awesome, thanks! I was able to get amd64 buildworld and buildkernel to > > > succeed with just a few changes, and none to the port. I'll work on > > > getting the changes in. > > > > I have been able to get it building as well, mostly by muting a few > > warnings, adding libcompiler_rt to rtld's link for i386, disabling > I am curious about the rtld issue. Can you show me the pristine error with > gcc, please ? For me, it's gcc generates __udivmoddi4 for the -m32 build but we used -nostdlib, and we get a link error. My hack right now is to explicitly link libgcc, but I don't think this is what we are intending to do because we seem to go through effort to reimplement other libgcc functions. Here's the text: --- ld-elf32.so.1.full --- /usr/local/bin/x86_64-unknown-freebsd13.0-ld: rtld_printf.o: in function `ksprintn': /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:115: undefined reference to `__udivmoddi4' /usr/local/bin/x86_64-unknown-freebsd13.0-ld: /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:117: undefined reference to `__udivmoddi4' collect2: error: ld returned 1 exit status *** [ld-elf32.so.1.full] Error code 1 You can see my hack at the link below. I'm not sure what the right solution is. > > > googletest (needs an upstream patch to stop using signed wchar_t), > > and a hack to jemalloc. I was able to build riscv as well with those > > same changes and am working through builds of other platforms. > > Actually, both those have upstream fixes. (For the jemalloc one, gcc is technically right, but because of a literal signed char argument to a macro.) > > I'm happy to compare notes. The jemalloc one is a bit weird. I pushed non-polished changes here. I'm working to get them reviewed. Please feel free to comment on any/all. https://github.com/rlibby/freebsd/commits/gcc9-fixes > > > > -- > > John Baldwin > > ___ > > freebsd-toolch...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ 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"
Re: New external GCC toolchain ports/packages
On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote: > On 12/19/19 12:06 PM, Ryan Libby wrote: > > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > >> > >> In the interest of supporting newer versions of GCC for a base system > >> toolchain, I've renamed the external GCC packages from -gcc > >> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > >> port. The xtoolchain package is not used for these new packages, instead > >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this > >> compiler to 6.5.0. > >> > >> I will leave the old ports/packages around for now to permit an easy > >> transition, but going forward, the -gcc6 packages should be preferred > >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and > >> riscv64-xtoolchain-gcc > >> are separate from the powerpc64-gcc set of packages). > >> > >> In addition, I've also just added a devel/freebsd-gcc9 package which > >> builds -gcc9 packages. It adds powerpc and riscv flavors relative > >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to > >> be able to finish a buildworld on any of the platforms I've tried > >> (amd64, mips, sparc64), but the packages should permit other developers > >> to get the tree building with GCC 9. To use these packages one would do > >> something like: > >> > >> # pkg install amd64-gcc9 > >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > >> > >> You can install both the gcc6 and gcc9 versions of a package at the same > >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major > >> versions is similar to llvm and will also let us keep a known-good > >> toolchain package for older releases while using newer major versions on > >> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > >> > >> I do plan to switch the default toolchains for make universe/tinderbox > >> for targets using -xtoolchain-gcc based on GCC 6 over to the > >> freebsd-gcc6 variants in the next week or so. > >> > >> -- > >> John Baldwin > > > > Awesome, thanks! I was able to get amd64 buildworld and buildkernel to > > succeed with just a few changes, and none to the port. I'll work on > > getting the changes in. > > I have been able to get it building as well, mostly by muting a few > warnings, adding libcompiler_rt to rtld's link for i386, disabling I am curious about the rtld issue. Can you show me the pristine error with gcc, please ? > googletest (needs an upstream patch to stop using signed wchar_t), > and a hack to jemalloc. I was able to build riscv as well with those > same changes and am working through builds of other platforms. > > I'm happy to compare notes. The jemalloc one is a bit weird. > > -- > John Baldwin > ___ > freebsd-toolch...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ 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"
Re: New external GCC toolchain ports/packages
On 12/19/19 12:06 PM, Ryan Libby wrote: > On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: >> >> In the interest of supporting newer versions of GCC for a base system >> toolchain, I've renamed the external GCC packages from -gcc >> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 >> port. The xtoolchain package is not used for these new packages, instead >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this >> compiler to 6.5.0. >> >> I will leave the old ports/packages around for now to permit an easy >> transition, but going forward, the -gcc6 packages should be preferred >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and >> riscv64-xtoolchain-gcc >> are separate from the powerpc64-gcc set of packages). >> >> In addition, I've also just added a devel/freebsd-gcc9 package which >> builds -gcc9 packages. It adds powerpc and riscv flavors relative >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to >> be able to finish a buildworld on any of the platforms I've tried >> (amd64, mips, sparc64), but the packages should permit other developers >> to get the tree building with GCC 9. To use these packages one would do >> something like: >> >> # pkg install amd64-gcc9 >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 >> >> You can install both the gcc6 and gcc9 versions of a package at the same >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major >> versions is similar to llvm and will also let us keep a known-good >> toolchain package for older releases while using newer major versions on >> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). >> >> I do plan to switch the default toolchains for make universe/tinderbox >> for targets using -xtoolchain-gcc based on GCC 6 over to the >> freebsd-gcc6 variants in the next week or so. >> >> -- >> John Baldwin > > Awesome, thanks! I was able to get amd64 buildworld and buildkernel to > succeed with just a few changes, and none to the port. I'll work on > getting the changes in. I have been able to get it building as well, mostly by muting a few warnings, adding libcompiler_rt to rtld's link for i386, disabling googletest (needs an upstream patch to stop using signed wchar_t), and a hack to jemalloc. I was able to build riscv as well with those same changes and am working through builds of other platforms. I'm happy to compare notes. The jemalloc one is a bit weird. -- John Baldwin ___ 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"
Re: New external GCC toolchain ports/packages
On Wed, Dec 18, 2019 at 1:49 PM John Baldwin wrote: > > In the interest of supporting newer versions of GCC for a base system > toolchain, I've renamed the external GCC packages from -gcc > to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > port. The xtoolchain package is not used for these new packages, instead > one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this > compiler to 6.5.0. > > I will leave the old ports/packages around for now to permit an easy > transition, but going forward, the -gcc6 packages should be preferred > to -xtoolchain-gcc for all but riscv (riscv64-gcc and > riscv64-xtoolchain-gcc > are separate from the powerpc64-gcc set of packages). > > In addition, I've also just added a devel/freebsd-gcc9 package which > builds -gcc9 packages. It adds powerpc and riscv flavors relative > to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to > be able to finish a buildworld on any of the platforms I've tried > (amd64, mips, sparc64), but the packages should permit other developers > to get the tree building with GCC 9. To use these packages one would do > something like: > > # pkg install amd64-gcc9 > # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > > You can install both the gcc6 and gcc9 versions of a package at the same > time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major > versions is similar to llvm and will also let us keep a known-good > toolchain package for older releases while using newer major versions on > newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > > I do plan to switch the default toolchains for make universe/tinderbox > for targets using -xtoolchain-gcc based on GCC 6 over to the > freebsd-gcc6 variants in the next week or so. > > -- > John Baldwin Awesome, thanks! I was able to get amd64 buildworld and buildkernel to succeed with just a few changes, and none to the port. I'll work on getting the changes in. ___ 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"
Re: New external GCC toolchain ports/packages
On 12/18/19 4:16 PM, Mark Millard wrote: > > > On 2019-Dec-18, at 13:48, John Baldwin wrote: > >> In the interest of supporting newer versions of GCC for a base system >> toolchain, I've renamed the external GCC packages from -gcc >> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 >> port. The xtoolchain package is not used for these new packages, instead >> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and >> uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this >> compiler to 6.5.0. >> >> I will leave the old ports/packages around for now to permit an easy >> transition, but going forward, the -gcc6 packages should be preferred >> to -xtoolchain-gcc for all but riscv (riscv64-gcc and >> riscv64-xtoolchain-gcc >> are separate from the powerpc64-gcc set of packages). >> >> In addition, I've also just added a devel/freebsd-gcc9 package which >> builds -gcc9 packages. It adds powerpc and riscv flavors relative >> to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to >> be able to finish a buildworld on any of the platforms I've tried >> (amd64, mips, sparc64), but the packages should permit other developers >> to get the tree building with GCC 9. To use these packages one would do >> something like: >> >> # pkg install amd64-gcc9 >> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 >> >> You can install both the gcc6 and gcc9 versions of a package at the same >> time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major >> versions is similar to llvm and will also let us keep a known-good >> toolchain package for older releases while using newer major versions on >> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). >> >> I do plan to switch the default toolchains for make universe/tinderbox >> for targets using -xtoolchain-gcc based on GCC 6 over to the >> freebsd-gcc6 variants in the next week or so. >> > > How about base/binutils and base/gcc ? Is their (future?) status > changed by any of this activity? I plan to rename base/gcc to base/gcc6 (and update it to 6.5) and then add a base/gcc9 that would provide GCC 9 as /usr/bin/cc. -- John Baldwin ___ 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"
Re: New external GCC toolchain ports/packages
On 2019-Dec-18, at 13:48, John Baldwin wrote: > In the interest of supporting newer versions of GCC for a base system > toolchain, I've renamed the external GCC packages from -gcc > to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 > port. The xtoolchain package is not used for these new packages, instead > one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and > uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this > compiler to 6.5.0. > > I will leave the old ports/packages around for now to permit an easy > transition, but going forward, the -gcc6 packages should be preferred > to -xtoolchain-gcc for all but riscv (riscv64-gcc and > riscv64-xtoolchain-gcc > are separate from the powerpc64-gcc set of packages). > > In addition, I've also just added a devel/freebsd-gcc9 package which > builds -gcc9 packages. It adds powerpc and riscv flavors relative > to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to > be able to finish a buildworld on any of the platforms I've tried > (amd64, mips, sparc64), but the packages should permit other developers > to get the tree building with GCC 9. To use these packages one would do > something like: > > # pkg install amd64-gcc9 > # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 > > You can install both the gcc6 and gcc9 versions of a package at the same > time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major > versions is similar to llvm and will also let us keep a known-good > toolchain package for older releases while using newer major versions on > newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). > > I do plan to switch the default toolchains for make universe/tinderbox > for targets using -xtoolchain-gcc based on GCC 6 over to the > freebsd-gcc6 variants in the next week or so. > How about base/binutils and base/gcc ? Is their (future?) status changed by any of this activity? === 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"
New external GCC toolchain ports/packages
In the interest of supporting newer versions of GCC for a base system toolchain, I've renamed the external GCC packages from -gcc to -gcc6. These are built as flavors of a new devel/freebsd-gcc6 port. The xtoolchain package is not used for these new packages, instead one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and uses 'CROSS_TOOLCHAIN=mips-gcc6'. I've also gone ahead and updated this compiler to 6.5.0. I will leave the old ports/packages around for now to permit an easy transition, but going forward, the -gcc6 packages should be preferred to -xtoolchain-gcc for all but riscv (riscv64-gcc and riscv64-xtoolchain-gcc are separate from the powerpc64-gcc set of packages). In addition, I've also just added a devel/freebsd-gcc9 package which builds -gcc9 packages. It adds powerpc and riscv flavors relative to freebsd-gcc6 and uses GCC 9.2.0. To date in my testing I've yet to be able to finish a buildworld on any of the platforms I've tried (amd64, mips, sparc64), but the packages should permit other developers to get the tree building with GCC 9. To use these packages one would do something like: # pkg install amd64-gcc9 # make buildworld CROSS_TOOLCHAIN=amd64-gcc9 You can install both the gcc6 and gcc9 versions of a package at the same time, e.g. amd64-gcc6 and amd64-gcc9. Having different packages for major versions is similar to llvm and will also let us keep a known-good toolchain package for older releases while using newer major versions on newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x). I do plan to switch the default toolchains for make universe/tinderbox for targets using -xtoolchain-gcc based on GCC 6 over to the freebsd-gcc6 variants in the next week or so. -- John Baldwin ___ 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"
Re: [sw-dev] GCC 8.x or 9.x for FreeBSD rv64imafdc ??
On 11/26/19 10:18 AM, Bruce Hoult wrote: I think there are very few people who have experience with the intersection of FreeBSD and RISC-V. [warning] long rambling reply full of enthusiasm and hand waving :) Thank you for the reply and yes ! There are very few but it works I tell you it really does work and that is with a ZFS zpool. At least on QEMU for the moment and by Christmas time on the SiFive board. Maybe. Sort of waiting for a new board to pop up with SAS/SATA ports and more memory but Christmas may be here first. I simply can not go forwards with ZFS without memory and lots of it : root@callisto:~ # root@callisto:~ # uname -apKU FreeBSD callisto 13.0-CURRENT FreeBSD 13.0-CURRENT r350568 QEMU riscv riscv64 1300038 1300038 root@callisto:~ # zpool list ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) no pools available root@callisto:~ # Hopefully Ruslan will reply. Yes I have a compiler tarball from him that sort of works. When I say "sort of" I mean that I can compile some simple things and everything seems to work however I need to carefully specify where to find libgcc and even libc as there are some oddball paths stuck in his bootstrap result. Easy to work around. May even be enough to get a new bootstrap going of gcc 9.2.0 but I have not been able to get past libgmp. Yet. Maybe later today. Maybe tomorrow. :-\ For now I have been messing with r350568 with ZFS and a gcc from Ruslan but for anything after that I have nothing. I just drag around a tarball and hope for the best. However today I hear that I am slightly blind and that clang does exist in the rootfs : vesta# pwd /opt/rv64/rootfs vesta# ls -lap usr/bin/clang -r-xr-xr-x 3 root wheel 63383544 Nov 26 08:00 usr/bin/clang vesta# vesta# readelf -delV usr/bin/clang ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: RISC-V Version: 0x1 Entry point address: 0x6d48a Start of program headers: 64 (bytes into file) Start of section headers: 63381560 (bytes into file) Flags: 0x5, RVC, double-float ABI Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 31 Section header string table index: 30 Section Headers: . . . Dynamic section at offset 0x3c5ac08 contains 30 entries: TagType Name/Value 0x0001 (NEEDED) Shared library: [libz.so.6] 0x0001 (NEEDED) Shared library: [libexecinfo.so.1] 0x0001 (NEEDED) Shared library: [libncursesw.so.8] 0x0001 (NEEDED) Shared library: [libthr.so.3] 0x0001 (NEEDED) Shared library: [libc++.so.1] 0x0001 (NEEDED) Shared library: [libcxxrt.so.1] 0x0001 (NEEDED) Shared library: [libm.so.5] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.7] 0x000c (INIT) 0x16d40 0x000d (FINI) 0x2b7d086 0x0019 (INIT_ARRAY) 0x3c6b038 0x001b (INIT_ARRAYSZ) 2976 (bytes) . . . Not too sure how that is going to work with no RUNPATH or RPATH and it needs libgcc. However looking I do see libgcc_s.so.1 in /lib : vesta# ls -l lib/libgcc_s.so.1 -r--r--r-- 1 root wheel 94360 Nov 26 07:58 lib/libgcc_s.so.1 vesta# So this may actually work and be enough to bootstrap with. Maybe. I see the gcc in that project is pretty old, 6.1.0. I have no idea whether it would be easier to get 6.1.0 running natively inside freebsd-riscv and then use it to build a newer gcc, or maybe enough RISC-V improvements have been made to gcc in the last four years and 16856 commits that it's better to rebase Ruslan's changes to current gcc first. Well actually I do have 8.x of some flavour and only from Ruslan. Maybe Ruslan has a native compiler working. Or maybe not. I'm sorry I can't be more helpful but at least it's not a black hole. Not a black hole is a damn fine thing !! Better than I expected in fact. In truth I just need some tools to get off the ground and maybe figure out how pi became pretty much 2.000 thus :
Re: GCC 8.x or 9.x for FreeBSD rv64imafdc ??
On Tue, Nov 26, 2019 at 3:57 AM Dennis Clarke wrote: > > > > I will cross post this as there are very few options left. > > rv64imafdc folks : > > I will send this out to the only people and places that are likely to > not simply be a black hole from which nothing ever returns. However > most of my messages do just die on the mail lists with no reply from > anyone ever and that is very true for the gcc maillists for anything > RISC-V related. I wish I knew why. > > I am able to checkout and cross compile FreeBSD 13.0-CURRENT r354873 > however there is no compiler. I looked. The output destination rootfs > shows no signs of LLVM/Clang and certainly not gcc of any flavor. > > I do see wonderful things like : > > > https://github.com/freebsd-riscv/riscv-gcc/commit/be9abee2aaa919ad8530336569d17b5a60049717 > > > However nothing actually usable by any user out here in the more or less > real world that is not inside SiFive or similar. > > So is there any place at all that one may attain a compiler or am I left > to decipher the horrific mess that is known as the Canadian cross > compiler bootstrap which has never worked for me. > As of r354660, clang is built as part of buildworld. If you are using r354873 then you should have it as /usr/bin/clang, perhaps you just need to regenerate your rootfs. Cheers, Mitchell > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > GreyBeard and suspenders optional > ___ > 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" ___ 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"
GCC 8.x or 9.x for FreeBSD rv64imafdc ??
I will cross post this as there are very few options left. rv64imafdc folks : I will send this out to the only people and places that are likely to not simply be a black hole from which nothing ever returns. However most of my messages do just die on the mail lists with no reply from anyone ever and that is very true for the gcc maillists for anything RISC-V related. I wish I knew why. I am able to checkout and cross compile FreeBSD 13.0-CURRENT r354873 however there is no compiler. I looked. The output destination rootfs shows no signs of LLVM/Clang and certainly not gcc of any flavor. I do see wonderful things like : https://github.com/freebsd-riscv/riscv-gcc/commit/be9abee2aaa919ad8530336569d17b5a60049717 However nothing actually usable by any user out here in the more or less real world that is not inside SiFive or similar. So is there any place at all that one may attain a compiler or am I left to decipher the horrific mess that is known as the Canadian cross compiler bootstrap which has never worked for me. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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"
head r354975 and/or later broke ci.freebsd.org's FreeBSD-head-amd64-gcc builds in tests/sys/sys/bitstring_test.c 's atfu_bit_ffs_area_body
#12250 (of r355014) gots the likes of:
20:48:53
--- all_subdir_tests/sys/sys ---
20:48:53
/workspace/src/tests/sys/sys/bitstring_test.c: In function
'atfu_bit_ffc_area_body':
20:48:53
/workspace/src/sys/sys/bitstring.h:205:5: error: assuming signed overflow does
not occur when assuming that (X + c) < X is always false
[-Werror=strict-overflow]
20:48:53
if (_start >= _nbits) {
20:48:53
^
(I'll not list all the similar errors.)
The first breakage (later changed by lwhsu) was for #12238 (of r354977)
and was different:
21:21:52
--- all_subdir_tests/sys/sys ---
21:21:52
/workspace/src/tests/sys/sys/bitstring_test.c: In function
'atfu_bit_ffs_area_body':
21:21:52
/workspace/src/tests/sys/sys/bitstring_test.c:350:2: error: variable-sized
object may not be initialized
21:21:52
bitstr_t bit_decl(bitstr, nbits) = {};
21:21:52
^~~~
21:21:52
/workspace/src/tests/sys/sys/bitstring_test.c: In function
'atfu_bit_ffc_area_body':
21:21:52
/workspace/src/tests/sys/sys/bitstring_test.c:419:2: error: variable-sized
object may not be initialized
21:21:52
bitstr_t bit_decl(bitstr, nbits) = {};
21:21:52
^~~~
21:21:52
*** [bitstring_test.o] Error code 1
But, as of when I looked, none of the FreeBSD-head-amd64-gcc build attempts have
completed since then.
===
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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 23 September 2018 at 07:31, Michael Tuexen wrote: > Using this patch I was able to build/install world and kernel on an i386 > system. > However, after removing it, I can't build world then. When trying to compile a > kernel "the old way" I end up with: > > tuexen@head:~/head/sys/i386/conf % config -g TCP > WARNING: duplicate option `GEOM_PART_GPT' encountered. > Kernel build directory is ../compile/TCP > Don't forget to do ``make cleandepend && make depend'' > tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/ > tuexen@head:~/head/sys/i386/compile/TCP % make -j 6 > make: "../../../conf/../../../conf/kern.pre.mk" line 126: amd64/i386 kernel > requires linker ifunc support > > This is r338893. > > amd64 works without any problem. So this is i386 specific. Any idea how to > fix it? This safety belt is in place to ensure we don't build a non-functional kernel - now that the i386 kernel requires ifunc support using old GNU ld results in a kernel that doesn't boot. The workaround for the "old way" is to explicitly set LD=ld.lld in the environment - "LD=ld.lld make -j 6" should work. More details in this -arch thread, when amd64 encountered this hiccup: https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html The same issue now affects i386 as it has started using ifuncs, and will be resolved once we can switch i386's /usr/bin/ld to be lld, which is waiting on ports fixes in PR214864. ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
Resending from correct address...
> On 22. Sep 2018, at 05:57, Warner Losh wrote:
>
> Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
>
> They look good for me, but the only way you get this error is if they are
> wrong.
>
> Although from your typescript, I see:
>
> ===> lib/libc (cleandir)
> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
> amd64 libc requires linker ifunc support
>
> which tells me that we need to exclude all the non-build targets from this
> check This will use the HOST linker rather than the TARGET linker.
>
> So something like:
>
> diff --git a/lib/libc/Makefile b/lib/libc/Makefile
> index a1ce123c0f33..11575e1cabff 100644
> --- a/lib/libc/Makefile
> +++ b/lib/libc/Makefile
> @@ -21,10 +21,12 @@ LIBC_ARCH=${MACHINE_ARCH}
> LIBC_ARCH=${MACHINE_CPUARCH}
> .endif
>
> +.if build(all)
> .if (${LIBC_ARCH} == amd64 || ${LIBC_ARCH} == i386) && \
>defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
> .error ${LIBC_ARCH} libc requires linker ifunc support
> .endif
> +.endif
Using this patch I was able to build/install world and kernel on an i386 system.
However, after removing it, I can't build world then. When trying to compile a
kernel "the old way" I end up with:
tuexen@head:~/head/sys/i386/conf % config -g TCP
WARNING: duplicate option `GEOM_PART_GPT' encountered.
Kernel build directory is ../compile/TCP
Don't forget to do ``make cleandepend && make depend''
tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/
tuexen@head:~/head/sys/i386/compile/TCP % make -j 6
make: "../../../conf/../../../conf/kern.pre.mk" line 126: amd64/i386 kernel
requires linker ifunc support
This is r338893.
amd64 works without any problem. So this is i386 specific. Any idea how to fix
it?
Best regards
Michael
>
> # All library objects contain FreeBSD revision strings by default; they
> may be
> # excluded as a space-saving measure. To produce a library that does
>
> may be needed, but the problem may be related to caching these values from
> the host as well, even though we rebuild them...
>
> Warner
>
> On Fri, Sep 21, 2018 at 9:38 PM Rebecca Cran wrote:
>
>> On 9/21/18 9:35 PM, Warner Losh wrote:
>>>
>>> I meant to add, can you give a few lines before the error is spewed
>>> here in email? My IRC computer died before I could see any answers
>>> there...
>>>
>>> My 11.2-stable system has 6.0.1, so I can't test from there.
>>
>>
>> I've uploaded the full 'buildworld' output to
>> https://bluestop.org/files/typescript.txt .
>>
>>
>> --
>>
>> Rebecca
>>
>>
> ___
> 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"
___
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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 10:10 PM, Rebecca Cran wrote: > On 9/21/18 10:00 PM, Warner Losh wrote: > >> That may be the issue... Does the patch I included help? I'm building now >> on my stable system, but it's slow... > > It does seem to have got further this time, so a cautious yes. I can change that to a definite yes: >>> World build completed on Fri Sep 21 22:48:30 MDT 2018 -- Rebecca ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
One thing that may allow progress is explicitly passing the path to a new enough linker to make. In the past when some I encountered a similar problem (I use amd64-xtoolchain-gcc, amd64-gcc, and binutils for toolchain, and due to some miscommunication the wrong linker was selected automatically), I had good results passing an explicit linker LD like: LD=/usr/local/bin/ld make -sj4 buildkernel KERNCONF=foo CROSS_TOOLCHAIN=amd64-gcc Best, Conrad On Fri, Sep 21, 2018 at 9:10 PM, Rebecca Cran wrote: > On 9/21/18 10:00 PM, Warner Losh wrote: > >> That may be the issue... Does the patch I included help? I'm building now >> on my stable system, but it's slow... > > > It does seem to have got further this time, so a cautious yes. > > > -- > Rebecca > > ___ > 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" ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 10:00 PM, Warner Losh wrote: > That may be the issue... Does the patch I included help? I'm building now > on my stable system, but it's slow... It does seem to have got further this time, so a cautious yes. -- Rebecca ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 9:57 PM, Warner Losh wrote: > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say? > > They look good for me, but the only way you get this error is if they > are wrong. bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE bfd bcran@cube:~/workspace/freebsd % make -V LINKER_FEATURES Â filter -- Rebecca ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On Fri, Sep 21, 2018 at 9:59 PM Rebecca Cran wrote: > On 9/21/18 9:57 PM, Warner Losh wrote: > > > Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say? > > > > They look good for me, but the only way you get this error is if they > > are wrong. > > > bcran@cube:~/workspace/freebsd % make -V LINKER_TYPE > bfd > > bcran@cube:~/workspace/freebsd % make -V LINKER_FEATURES > filter > That may be the issue... Does the patch I included help? I'm building now on my stable system, but it's slow... Warner ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
They look good for me, but the only way you get this error is if they are
wrong.
Although from your typescript, I see:
===> lib/libc (cleandir)
make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
amd64 libc requires linker ifunc support
which tells me that we need to exclude all the non-build targets from this
check This will use the HOST linker rather than the TARGET linker.
So something like:
diff --git a/lib/libc/Makefile b/lib/libc/Makefile
index a1ce123c0f33..11575e1cabff 100644
--- a/lib/libc/Makefile
+++ b/lib/libc/Makefile
@@ -21,10 +21,12 @@ LIBC_ARCH=${MACHINE_ARCH}
LIBC_ARCH=${MACHINE_CPUARCH}
.endif
+.if build(all)
.if (${LIBC_ARCH} == amd64 || ${LIBC_ARCH} == i386) && \
defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
.error ${LIBC_ARCH} libc requires linker ifunc support
.endif
+.endif
# All library objects contain FreeBSD revision strings by default; they
may be
# excluded as a space-saving measure. To produce a library that does
may be needed, but the problem may be related to caching these values from
the host as well, even though we rebuild them...
Warner
On Fri, Sep 21, 2018 at 9:38 PM Rebecca Cran wrote:
> On 9/21/18 9:35 PM, Warner Losh wrote:
> >
> > I meant to add, can you give a few lines before the error is spewed
> > here in email? My IRC computer died before I could see any answers
> > there...
> >
> > My 11.2-stable system has 6.0.1, so I can't test from there.
>
>
> I've uploaded the full 'buildworld' output to
> https://bluestop.org/files/typescript.txt .
>
>
> --
>
> Rebecca
>
>
___
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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On Fri, Sep 21, 2018 at 9:34 PM Warner Losh wrote: > > > On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote: > >> On 9/21/18 9:09 PM, Warner Losh wrote: >> >> > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < >> > freebsd-toolch...@freebsd.org> wrote: >> > >> >> On 9/21/18 4:06 PM, Mark Johnston wrote: >> >>> https://reviews.freebsd.org/D17279 for anyone else that would like to >> >>> review. >> >> >> >> Is that possibly related to the error I'm getting trying to build >> >> -CURRENT on 11.2? >> >> >> >> >> >> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26: >> >> amd64 libc requires linker ifunc support >> >> >> > Yea, that should absolutely work. If it doesn't, that's a big big >> problem. >> >> >> I see, it was introduced earlier today in lib/libc/Makefile: >> >> >> commit ef8030831eccec4e481a1766fc1c67f7cadadac9 >> Author: emaste >> Date: Fri Sep 21 17:49:37 2018 + >> >> libc: require ifunc-capable linker for amd64/i386 >> >> We expect to introduce optimized libc routines in the near future, >> which requires use of a linker that supports ifuncs. >> >> Approved by:re (gjb, kib) >> Sponsored by: The FreeBSD Foundation >> >> >> And /usr/bin/ld -v on my 11.2 system says: >> >> >> GNU ld 2.17.50 [FreeBSD] 2007-07-03 >> > > What does ld.lld say? > > However, it shouldn't matter: we don't build libc until *AFTER* we build > ld.lld, so this error is bogusly triggering. I suspect that it needs to be > limited to only building targets, since tree traversal ones, as well as > install targets don't have this dependency. > I meant to add, can you give a few lines before the error is spewed here in email? My IRC computer died before I could see any answers there... My 11.2-stable system has 6.0.1, so I can't test from there. Warner ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 9:34 PM, Warner Losh wrote: > What does ld.lld say? > > However, it shouldn't matter: we don't build libc until *AFTER* we > build ld.lld, so this error is bogusly triggering. I suspect that it > needs to be limited to only building targets, since tree traversal > ones, as well as install targets don't have this dependency. LLD 6.0.0 (FreeBSD 326565-111) (compatible with GNU linkers) -- Rebecca ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 9:35 PM, Warner Losh wrote: > > I meant to add, can you give a few lines before the error is spewed > here in email? My IRC computer died before I could see any answers > there... > > My 11.2-stable system has 6.0.1, so I can't test from there. I've uploaded the full 'buildworld' output to https://bluestop.org/files/typescript.txt . -- Rebecca ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On Fri, Sep 21, 2018 at 9:30 PM Rebecca Cran wrote: > On 9/21/18 9:09 PM, Warner Losh wrote: > > > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < > > freebsd-toolch...@freebsd.org> wrote: > > > >> On 9/21/18 4:06 PM, Mark Johnston wrote: > >>> https://reviews.freebsd.org/D17279 for anyone else that would like to > >>> review. > >> > >> Is that possibly related to the error I'm getting trying to build > >> -CURRENT on 11.2? > >> > >> > >> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26: > >> amd64 libc requires linker ifunc support > >> > > Yea, that should absolutely work. If it doesn't, that's a big big > problem. > > > I see, it was introduced earlier today in lib/libc/Makefile: > > > commit ef8030831eccec4e481a1766fc1c67f7cadadac9 > Author: emaste > Date: Fri Sep 21 17:49:37 2018 + > > libc: require ifunc-capable linker for amd64/i386 > > We expect to introduce optimized libc routines in the near future, > which requires use of a linker that supports ifuncs. > > Approved by:re (gjb, kib) > Sponsored by: The FreeBSD Foundation > > > And /usr/bin/ld -v on my 11.2 system says: > > > GNU ld 2.17.50 [FreeBSD] 2007-07-03 > What does ld.lld say? However, it shouldn't matter: we don't build libc until *AFTER* we build ld.lld, so this error is bogusly triggering. I suspect that it needs to be limited to only building targets, since tree traversal ones, as well as install targets don't have this dependency. Warner ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 9:09 PM, Warner Losh wrote: > On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < > freebsd-toolch...@freebsd.org> wrote: > >> On 9/21/18 4:06 PM, Mark Johnston wrote: >>> https://reviews.freebsd.org/D17279 for anyone else that would like to >>> review. >> >> Is that possibly related to the error I'm getting trying to build >> -CURRENT on 11.2? >> >> >> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26: >> amd64 libc requires linker ifunc support >> > Yea, that should absolutely work. If it doesn't, that's a big big problem. I see, it was introduced earlier today in lib/libc/Makefile: commit ef8030831eccec4e481a1766fc1c67f7cadadac9 Author: emaste Date:Â Â Fri Sep 21 17:49:37 2018 + Â Â Â libc: require ifunc-capable linker for amd64/i386 Â Â Â Â Â Â We expect to introduce optimized libc routines in the near future, Â Â Â which requires use of a linker that supports ifuncs. Â Â Â Â Â Â Approved by:Â Â Â re (gjb, kib) Â Â Â Sponsored by:Â Â The FreeBSD Foundation And /usr/bin/ld -v on my 11.2 system says: GNU ld 2.17.50 [FreeBSD] 2007-07-03 -- Rebecca ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On Fri, Sep 21, 2018 at 9:02 PM Rebecca Cran via freebsd-toolchain < freebsd-toolch...@freebsd.org> wrote: > On 9/21/18 4:06 PM, Mark Johnston wrote: > > > > https://reviews.freebsd.org/D17279 for anyone else that would like to > > review. > > > Is that possibly related to the error I'm getting trying to build > -CURRENT on 11.2? > > > make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26: > amd64 libc requires linker ifunc support > Yea, that should absolutely work. If it doesn't, that's a big big problem. Warner ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 9/21/18 4:06 PM, Mark Johnston wrote: > > https://reviews.freebsd.org/D17279 for anyone else that would like to > review. Is that possibly related to the error I'm getting trying to build -CURRENT on 11.2? make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26: amd64 libc requires linker ifunc support -- Rebecca ___ 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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On Fri, Sep 21, 2018 at 04:37:08PM -0400, Ed Maste wrote:
> On 21 September 2018 at 15:31, Mark Johnston wrote:
> >
> > Perhaps the following? It's not quite right since it'll still use
> > -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> > figure out how to define a linker feature for only non-cross toolchains.
> > In any case, we're going to upstream the option soon.
>
> I wouldn't worry too much about out-of-tree since it will be upstream
> soon as you say, otherwise looks good.
>
> > +.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
> > +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
> > .error amd64/i386 kernel requires linker ifunc support
> > .endif
> > +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc-noplt} != ""
>
> Maybe roll && defined(LINKER_FEATURES) into the outer .if?
https://reviews.freebsd.org/D17279 for anyone else that would like to
review.
___
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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 21 September 2018 at 15:31, Mark Johnston wrote:
>
> Perhaps the following? It's not quite right since it'll still use
> -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> figure out how to define a linker feature for only non-cross toolchains.
> In any case, we're going to upstream the option soon.
I wouldn't worry too much about out-of-tree since it will be upstream
soon as you say, otherwise looks good.
> +.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
> +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
> .error amd64/i386 kernel requires linker ifunc support
> .endif
> +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc-noplt} != ""
Maybe roll && defined(LINKER_FEATURES) into the outer .if?
___
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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On Fri, Sep 21, 2018 at 02:54:04PM -0400, Ed Maste wrote:
> On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain
> wrote:
> > In looking into another report about using devel/amd64-gcc to buld
> > head I tried a build of -r338675 ( with WERROR= ). It got:
> >
> ...
> >
> > Question:
> >
> > Is ignoring "-z ifunc-noplt" a problem for using what
> > is built?
>
> This will have no functional impact, should just result in a missed
> optimization. (We ought to avoid passing it to non-lld linkers
> though.)
Perhaps the following? It's not quite right since it'll still use
-zifunc-noplt with an external LLVM toolchain, but I can't seem to
figure out how to define a linker feature for only non-cross toolchains.
In any case, we're going to upstream the option soon.
diff --git a/share/mk/bsd.linker.mk b/share/mk/bsd.linker.mk
index caf4fccbae0f..bee6a9e345dc 100644
--- a/share/mk/bsd.linker.mk
+++ b/share/mk/bsd.linker.mk
@@ -13,6 +13,9 @@
# linker support for that feature:
#
# - build-id: support for generating a Build-ID note
+# - filter:support for filter DSOs
+# - ifunc: support for GNU ifuncs
+# - ifunc-noplt: support for optimized ifunc calls
# - retpoline: support for generating PLT with retpoline speculative
# execution vulnerability mitigation
#
@@ -85,6 +88,7 @@ ${X_}LINKER_FEATURES+=filter
.endif
.if ${${X_}LINKER_TYPE} == "lld" && ${${X_}LINKER_VERSION} >= 6
${X_}LINKER_FEATURES+= retpoline
+${X_}LINKER_FEATURES+= ifunc-noplt
.endif
.endif
.else
diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index 523cea605afd..911f1accf1f6 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -121,12 +121,16 @@ CFLAGS+= ${CONF_CFLAGS}
LDFLAGS+= -Wl,--build-id=sha1
.endif
-.if (${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386") && \
-defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
+.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
+.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
.error amd64/i386 kernel requires linker ifunc support
.endif
+.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc-noplt} != ""
+LDFLAGS+= -Wl,-z -Wl,ifunc-noplt
+.endif
+.endif
.if ${MACHINE_CPUARCH} == "amd64"
-LDFLAGS+= -Wl,-z max-page-size=2097152 -Wl,-z common-page-size=4096
-Wl,-z -Wl,ifunc-noplt
+LDFLAGS+= -Wl,-z max-page-size=2097152 -Wl,-z common-page-size=4096
.endif
NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
___
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"
Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain wrote: > In looking into another report about using devel/amd64-gcc to buld > head I tried a build of -r338675 ( with WERROR= ). It got: > ... > > Question: > > Is ignoring "-z ifunc-noplt" a problem for using what > is built? This will have no functional impact, should just result in a missed optimization. (We ought to avoid passing it to non-lld linkers though.) ___ 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"
building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored
In looking into another report about using devel/amd64-gcc to buld head I tried a build of -r338675 ( with WERROR= ). It got: --- kernel.full --- linking kernel.full /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored. ctfmerge -L VERSION -g -o kernel.full ... textdata bss dec hex filename 23518632117710305673808 409634702710d8e kernel.full Building /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG/kernel.debug Building /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG/kernel -- >>> Kernel build for GENERIC-NODBG completed on Thu Sep 20 18:38:29 PDT 2018 -- Question: Is ignoring "-z ifunc-noplt" a problem for using what is built? === 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"
Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]
Hi,
this works now but now I am back to this:
Updating ./version.texi
--- ./m4.info ---
restore=: && backupdir=".am$$" && am__cwd=`pwd` &&
CDPATH="${ZSH_VERSION+.}:" && cd . && rm -rf $backupdir && mkdir
$backupdir && if (/usr/bin/makeinfo --no-split --version) >/dev/null
2>&1; then for f
2>in ./m4.info ./m4.info-[0-9] ./m4.info-[0-9][0-9] ./m4.i[0-9]
./m4.i[0-9][0-9];
2>do if test -f $f; then mv $f $backupdir; restore=mv; else :; fi;
2>done; else :; fi && cd "$am__cwd"; if /usr/bin/makeinfo
2>--no-split -I . -o ./m4.info ./m4.texi; then rc=0;
2>CDPATH="${ZSH_VERSION+.}:" && cd .; else rc=$?;
2>CDPATH="${ZSH_VERSION+.}:" && cd . && $restore $backupdir/* `echo
2>"././m4.info" | sed 's|[^/]*$||'`; fi; rm -rf $backupdir; exit $rc
2>Bad system call (core dumped) *** [./m4.info] Error code 140
make[4]: stopped in /usr/ports/devel/m4/work/m4-1.4.18/doc
Erich
On Sat, 04 Aug 2018 22:23:56 -0600
Brad Davis wrote:
> On Sat, Aug 4, 2018, at 9:48 PM, Brad Davis wrote:
> > On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote:
> > > > Author: brd
> > > > Date: Sat Aug 4 22:41:17 2018
> > > > New Revision: 337340
> > > > URL:
> > > > https://svnweb.freebsd.org/changeset/base/337340
> > > >
> > > >
> > > > Log:
> > > > Move autofs related configs to usr.sbin/autofs/
> > > >
> > > > This is prep for pkgbase to have config files tagged as such.
> > > >
> > > > Approved by: will (mentor)
> > > > Differential Revision:
> > > > https://reviews.freebsd.org/D16492
> > > . . .
> > >
> > > This broke all the ci.freebsd.org builds of freebsd-head-*-build .
> > >
> > > Using FreeBSD-head-powerpc64-build as an example:
> > > #6826 (for -r337399 ) worked but #6827 (for -r337400 )
> > > fails with:
> > >
> > > (cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null
> > > SRCCONF=/
> > > workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf
> > > etc- examples) cd /usr/src/etc; install -N /usr/src/etc -o root
> > > -g wheel -m 444 crontab devd.conf devfs.conf ddb.conf
> > > dhclient.conf disktab fbtab gettytab group hosts
> > > hosts.allow hosts.equiv libalias.conf libmap.conf
> > > login.access login.conf mac.conf motd netconfig networks
> > > newsyslog.conf nsswitch.conf phones profile protocols
> > > rc.bsdextended rc.firewall remote rpc services sysctl.conf
> > > syslog.conf termcap.small etc.powerpc/ttys amd.map auto_master
> > > ftpusers inetd.conf /usr/src/usr.bin/locate/locate/locate.rc
> > > hosts.lpd printcap / usr/src/usr.bin/mail/misc/mail.rc ntp.conf
> > > pf.os rc.sendmail csh.cshrc csh.login csh.logout regdomain.xml
> > > nsmb.conf opieaccess /usr/obj/usr/
> > > src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc
> > > install: auto_master: No such file or directory *** Error code 71
> > >
> > > Stop.
> > > make[8]: stopped in /usr/src/etc
> > > *** Error code 1
> > >
> > >
> > >
> > > Stop.
> > > make[7]: stopped in /usr/src/share/examples
> > > *** Error code 1
> > >
> > > Stop.
> > > make[6]: stopped in /usr/src/share/examples
> > > *** Error code 1
> > >
> > > Stop.
> > > make[5]: stopped in /usr/src/share
> > > *** Error code 1
> > >
> > > Stop.
> > > make[4]: stopped in /usr/src
> > > *** Error code 1
> > >
> > > Stop.
> > > make[3]: stopped in /usr/src
> > > *** Error code 1
> > >
> > > Stop.
> > > make[2]: stopped in /usr/src
> > > *** Error code 1
> > >
> > > Stop.
> > > make[1]: stopped in /usr/src
> > > *** Error code 1
> > >
> > > Stop.
> > > make: stopped in /usr/src/release
> >
> > Testing the fix..
>
> Fix committed in r337342. Sorry for the noise.
>
>
> Regards,
> Brad Davis
> ___
> 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"
___
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"
Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]
On Sat, Aug 04, 2018 at 10:23:56PM -0600, Brad Davis wrote: > On Sat, Aug 4, 2018, at 9:48 PM, Brad Davis wrote: > > On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote: > > > > Author: brd > > > > Date: Sat Aug 4 22:41:17 2018 > > > > New Revision: 337340 > > > > URL: > > > > https://svnweb.freebsd.org/changeset/base/337340 > > > > > > > > > > > > Log: > > > > Move autofs related configs to usr.sbin/autofs/ > > > > > > > > This is prep for pkgbase to have config files tagged as such. > > > > > > > > Approved by: will (mentor) > > > > Differential Revision: > > > > https://reviews.freebsd.org/D16492 > > > . . . > > > > > > This broke all the ci.freebsd.org builds of freebsd-head-*-build . > > > > > > Using FreeBSD-head-powerpc64-build as an example: > > > #6826 (for -r337399 ) worked but #6827 (for -r337400 ) > > > fails with: > > > > > > (cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null SRCCONF=/ > > > workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf etc- > > > examples) > > > cd /usr/src/etc; install -N /usr/src/etc -o root -g wheel -m 444 > > > crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab > > > gettytab group hosts hosts.allow hosts.equiv libalias.conf > > > libmap.conf login.access login.conf mac.conf motd netconfig > > > networks newsyslog.conf nsswitch.conf phones profile protocols > > > rc.bsdextended rc.firewall remote rpc services sysctl.conf > > > syslog.conf termcap.small etc.powerpc/ttys amd.map auto_master ftpusers > > > inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap / > > > usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc > > > csh.login csh.logout regdomain.xml nsmb.conf opieaccess /usr/obj/usr/ > > > src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc > > > install: auto_master: No such file or directory > > > *** Error code 71 > > > > > > Stop. > > > make[8]: stopped in /usr/src/etc > > > *** Error code 1 > > > > > > > > > > > > Stop. > > > make[7]: stopped in /usr/src/share/examples > > > *** Error code 1 > > > > > > Stop. > > > make[6]: stopped in /usr/src/share/examples > > > *** Error code 1 > > > > > > Stop. > > > make[5]: stopped in /usr/src/share > > > *** Error code 1 > > > > > > Stop. > > > make[4]: stopped in /usr/src > > > *** Error code 1 > > > > > > Stop. > > > make[3]: stopped in /usr/src > > > *** Error code 1 > > > > > > Stop. > > > make[2]: stopped in /usr/src > > > *** Error code 1 > > > > > > Stop. > > > make[1]: stopped in /usr/src > > > *** Error code 1 > > > > > > Stop. > > > make: stopped in /usr/src/release > > > > Testing the fix.. > > Fix committed in r337342. Sorry for the noise. > How was the original patch that caused the problem tested? -- Steve ___ 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"
Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]
On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote: > > Author: brd > > Date: Sat Aug 4 22:41:17 2018 > > New Revision: 337340 > > URL: > > https://svnweb.freebsd.org/changeset/base/337340 > > > > > > Log: > > Move autofs related configs to usr.sbin/autofs/ > > > > This is prep for pkgbase to have config files tagged as such. > > > > Approved by: will (mentor) > > Differential Revision: > > https://reviews.freebsd.org/D16492 > . . . > > This broke all the ci.freebsd.org builds of freebsd-head-*-build . > > Using FreeBSD-head-powerpc64-build as an example: > #6826 (for -r337399 ) worked but #6827 (for -r337400 ) > fails with: > > (cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null SRCCONF=/ > workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf etc- > examples) > cd /usr/src/etc; install -N /usr/src/etc -o root -g wheel -m 444 > crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab > gettytab group hosts hosts.allow hosts.equiv libalias.conf > libmap.conf login.access login.conf mac.conf motd netconfig > networks newsyslog.conf nsswitch.conf phones profile protocols > rc.bsdextended rc.firewall remote rpc services sysctl.conf > syslog.conf termcap.small etc.powerpc/ttys amd.map auto_master ftpusers > inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap / > usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc > csh.login csh.logout regdomain.xml nsmb.conf opieaccess /usr/obj/usr/ > src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc > install: auto_master: No such file or directory > *** Error code 71 > > Stop. > make[8]: stopped in /usr/src/etc > *** Error code 1 > > > > Stop. > make[7]: stopped in /usr/src/share/examples > *** Error code 1 > > Stop. > make[6]: stopped in /usr/src/share/examples > *** Error code 1 > > Stop. > make[5]: stopped in /usr/src/share > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src > *** Error code 1 > > Stop. > make[3]: stopped in /usr/src > *** Error code 1 > > Stop. > make[2]: stopped in /usr/src > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src/release Testing the fix.. Regards, Brad Davis ___ 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"
Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]
On Sat, Aug 4, 2018, at 9:48 PM, Brad Davis wrote: > On Sat, Aug 4, 2018, at 7:43 PM, Mark Millard wrote: > > > Author: brd > > > Date: Sat Aug 4 22:41:17 2018 > > > New Revision: 337340 > > > URL: > > > https://svnweb.freebsd.org/changeset/base/337340 > > > > > > > > > Log: > > > Move autofs related configs to usr.sbin/autofs/ > > > > > > This is prep for pkgbase to have config files tagged as such. > > > > > > Approved by:will (mentor) > > > Differential Revision: > > > https://reviews.freebsd.org/D16492 > > . . . > > > > This broke all the ci.freebsd.org builds of freebsd-head-*-build . > > > > Using FreeBSD-head-powerpc64-build as an example: > > #6826 (for -r337399 ) worked but #6827 (for -r337400 ) > > fails with: > > > > (cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null SRCCONF=/ > > workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf etc- > > examples) > > cd /usr/src/etc; install -N /usr/src/etc -o root -g wheel -m 444 > > crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab > > gettytab group hosts hosts.allow hosts.equiv libalias.conf > > libmap.conf login.access login.conf mac.conf motd netconfig > > networks newsyslog.conf nsswitch.conf phones profile protocols > > rc.bsdextended rc.firewall remote rpc services sysctl.conf > > syslog.conf termcap.small etc.powerpc/ttys amd.map auto_master ftpusers > > inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap / > > usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc > > csh.login csh.logout regdomain.xml nsmb.conf opieaccess /usr/obj/usr/ > > src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc > > install: auto_master: No such file or directory > > *** Error code 71 > > > > Stop. > > make[8]: stopped in /usr/src/etc > > *** Error code 1 > > > > > > > > Stop. > > make[7]: stopped in /usr/src/share/examples > > *** Error code 1 > > > > Stop. > > make[6]: stopped in /usr/src/share/examples > > *** Error code 1 > > > > Stop. > > make[5]: stopped in /usr/src/share > > *** Error code 1 > > > > Stop. > > make[4]: stopped in /usr/src > > *** Error code 1 > > > > Stop. > > make[3]: stopped in /usr/src > > *** Error code 1 > > > > Stop. > > make[2]: stopped in /usr/src > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/src > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/src/release > > Testing the fix.. Fix committed in r337342. Sorry for the noise. Regards, Brad Davis ___ 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"
Re: svn commit: r337340 - in head: [This broke all ci.freebsd.org 's FreeBSD-head-*-build 's, clang based and gcc 4.2.1 based]
> Author: brd > Date: Sat Aug 4 22:41:17 2018 > New Revision: 337340 > URL: > https://svnweb.freebsd.org/changeset/base/337340 > > > Log: > Move autofs related configs to usr.sbin/autofs/ > > This is prep for pkgbase to have config files tagged as such. > > Approved by:will (mentor) > Differential Revision: > https://reviews.freebsd.org/D16492 . . . This broke all the ci.freebsd.org builds of freebsd-head-*-build . Using FreeBSD-head-powerpc64-build as an example: #6826 (for -r337399 ) worked but #6827 (for -r337400 ) fails with: (cd /usr/src/etc; make -DDB_FROM_SRC __MAKE_CONF=/dev/null SRCCONF=/workspace/freebsd-ci/jobs/FreeBSD-head-powerpc64-build/src.conf etc-examples) cd /usr/src/etc; install -N /usr/src/etc -o root -g wheel -m 444 crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab gettytab group hosts hosts.allow hosts.equiv libalias.conf libmap.conf login.access login.conf mac.conf motd netconfig networks newsyslog.conf nsswitch.conf phones profile protocols rc.bsdextended rc.firewall remote rpc services sysctl.conf syslog.conf termcap.small etc.powerpc/ttys amd.map auto_master ftpusers inetd.conf /usr/src/usr.bin/locate/locate/locate.rc hosts.lpd printcap /usr/src/usr.bin/mail/misc/mail.rc ntp.conf pf.os rc.sendmail csh.cshrc csh.login csh.logout regdomain.xml nsmb.conf opieaccess /usr/obj/usr/src/powerpc.powerpc64/release/dist/base/usr/share/examples/etc install: auto_master: No such file or directory *** Error code 71 Stop. make[8]: stopped in /usr/src/etc *** Error code 1 Stop. make[7]: stopped in /usr/src/share/examples *** Error code 1 Stop. make[6]: stopped in /usr/src/share/examples *** Error code 1 Stop. make[5]: stopped in /usr/src/share *** Error code 1 Stop. make[4]: stopped in /usr/src *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src/release === 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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
I decided that it was better to fix our stdatomic.h, so I have a review to do that at https://reviews.freebsd.org/D16585 -- John Baldwin ___ 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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-27, at 8:52 AM, Mark Millard wrote:
> On 2018-Jul-27, at 12:12 AM, Mark Millard wrote:
>
> On 2018-Jul-26, at 11:29 PM, Mark Millard wrote:
>
>> . . .
>> I was looking too locally: the overall context has an outer #if
>> as well that skips the section:
>>
>> /*
>> * Keywords added in C11.
>> */
>>
>> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
>> . . .
>> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \
>> !__has_extension(cxx_atomic)
>> /*
>> * No native support for _Atomic(). Place object in structure to prevent
>> * most forms of direct non-atomic access.
>> */
>> #define _Atomic(T) struct { T volatile __val; }
>> #endif
>> . . .
>> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */
>>
>>
>>
>>
>> The build with gcc's float.h also removed did complete instead of
>> stopping early.
>>
>>
>>
>> As for what x86_64-unknown-freebsd12.0 .h files were used:
>> (some may do include_next back into FreeBSD headers)
>>
>>
>> # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R
>> .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; | sort -k 3 | uniq -f 2 | more
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/adxintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ammintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx2intrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512bwintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512cdintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512dqintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512erintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512fintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmaintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmavlintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512pfintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmiintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmivlintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlbwintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vldqintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avxintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmi2intrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmiintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clflushoptintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clwbintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clzerointrin.h
>> R 56022 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/cpuid.h
>> R 1222
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/emmintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/f16cintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fma4intrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fmaintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fxsrintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ia32intrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/immintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lwpintrin.h
>> R 1520
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lzcntintrin.h
>> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm3dnow.h
>> R 1222
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm_malloc.h
>> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mmintrin.h
>> R 1595
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/inc
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-27, at 12:12 AM, Mark Millard wrote:
On 2018-Jul-26, at 11:29 PM, Mark Millard wrote:
> . . .
> I was looking too locally: the overall context has an outer #if
> as well that skips the section:
>
> /*
> * Keywords added in C11.
> */
>
> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
> . . .
> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \
>!__has_extension(cxx_atomic)
> /*
> * No native support for _Atomic(). Place object in structure to prevent
> * most forms of direct non-atomic access.
> */
> #define _Atomic(T) struct { T volatile __val; }
> #endif
> . . .
> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */
>
>
>
>
> The build with gcc's float.h also removed did complete instead of
> stopping early.
>
>
>
> As for what x86_64-unknown-freebsd12.0 .h files were used:
> (some may do include_next back into FreeBSD headers)
>
>
> # find /usr/obj/amd64_xtoolchain-gcc/ -name "*.meta" -exec grep "^R
> .*/x86_64-unknown-freebsd12.0/.*\.h" {} \; | sort -k 3 | uniq -f 2 | more
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/adxintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ammintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx2intrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512bwintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512cdintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512dqintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512erintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512fintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmaintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512ifmavlintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512pfintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmiintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vbmivlintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlbwintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vldqintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avx512vlintrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/avxintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmi2intrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/bmiintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clflushoptintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clwbintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/clzerointrin.h
> R 56022 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/cpuid.h
> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/emmintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/f16cintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fma4intrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fmaintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/fxsrintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/ia32intrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/immintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lwpintrin.h
> R 1520
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/lzcntintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm3dnow.h
> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mm_malloc.h
> R 1222 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mmintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/mwaitxintrin.h
> R 1595 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pkuintrin.h
> R 1336 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/pmmintrin.h
> R 1485
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/popcntintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/prfchwintrin.h
> R 1595
> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/rdseedintrin.h
> R 1520 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/includ
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 7/27/18 12:12 AM, Mark Millard wrote:
> I was looking too locally: the overall context has an outer #if
> as well that skips the section:
>
> /*
> * Keywords added in C11.
> */
>
> #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
> . . .
> #if !defined(__cplusplus) && !__has_extension(c_atomic) && \
> !__has_extension(cxx_atomic)
> /*
> * No native support for _Atomic(). Place object in structure to prevent
> * most forms of direct non-atomic access.
> */
> #define _Atomic(T) struct { T volatile __val; }
> #endif
> . . .
> #endif /* __STDC_VERSION__ || __STDC_VERSION__ < 201112L */
Yes. It also means that if we didn't ship the compiler's stdatomic.h and
tried to build with -std=gnu11 or -std=c11 the compile would break.
Rather than requiring c11, another approach might be to fix sys/cdefs.h
and sys/stdatomic.h to actually work with modern GCC by having them not
use the struct for the _GCC_ATOMICS case, only for the _SYNC case.
I think that would fix all of the cases.
--
John Baldwin
___
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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-26, at 11:29 PM, Mark Millard wrote:
> On 2018-Jul-26, at 9:06 PM, Mark Millard wrote:
>
>> On 2018-Jul-26, at 6:14 PM, Mark Millard wrote:
>>
>>> On 2018-Jul-26, at 11:21 AM, John Baldwin wrote:
>>>
>>>> On 7/26/18 10:55 AM, Mark Millard wrote:
>>>>> . . .
>>>>
>>>> Yes, but the -E from above was when compiled with external GCC and it
>>>> didn't change
>>>> _Atomic(int). Here's part of the source of bar.c:
>>>>
>>>> #include
>>>> #include
>>>>
>>>> struct foo {
>>>> _Atomic(int) one;
>>>> _Atomic int two;
>>>> atomic_int three;
>>>> };
>>>>
>>>> And here is what that became after -E:
>>>>
>>>> # 4 "bar.c"
>>>> struct foo {
>>>> _Atomic(int) one;
>>>> _Atomic int two;
>>>> atomic_int three;
>>>> };
>>>>
>>>> So cdefs.h did not define _Atomic.
>>>>
>>>> Ah, if I add '-std=c99' then it does break. Code that wants to use
>>>> C11 atomics via should not be using -std=c99. Try this:
>>>>
>>>> Index: lib/ofed/librdmacm/Makefile
>>>> =======
>>>> --- lib/ofed/librdmacm/Makefile (revision 335896)
>>>> +++ lib/ofed/librdmacm/Makefile (working copy)
>>>> @@ -8,6 +8,7 @@
>>>> SHLIB_MAJOR= 1
>>>> MK_PROFILE=no
>>>> CFLAGS+= -I${_spath}
>>>> +CSTD= gnu11
>>>>
>>>> SRCS= \
>>>> acm.c \
>>>>
>>>> If this works then we should probably mark OFED as a BROKEN_OPTION when
>>>> building with ancient GCC for now as well.
>>>
>>> I've "unreverted" to set up a context for testing this.
>>>
>>> So far I'll I've done is to test that I can still reproduce the failure
>>> in my environment, same sort of error reports as ci.freebsd.org's
>>> FreeBSD-head-amd64-gcc . This is without your patch.
>>>
>>> But I've done this with gcc being given -v so that I've the exact commands
>>> and search order and the like. It does show: -std=gnu99 . I list the
>>> filemon data from the .meta as well, showing the exact mix of
>>> FreeBSD and gcc headers used. (I could also provide such for with
>>> the reverted Makefile.{inc1,libcompat} [so non-failing] build if you
>>> care.)
>>>
>>>
>>> For now I just report the failure *without your patch*:
>>> (I'll build again with your patch next.)
>>>
>>> . . .
>>> --- all_subdir_lib/ofed ---
>>> Building
>>> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/librdmacm/acm.o
>>> --- acm.o ---
>>> Using built-in specs.
>>> COLLECT_GCC=/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
>>> Target: x86_64-unknown-freebsd12.0
>>> Configured with:
>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure
>>> --target=x86_64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++
>>> --enable-gnu-indirect-function --without-headers --with-gmp=/usr/local
>>> --with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib
>>> --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/
>>> --with-as=/usr/local/bin/x86_64-unknown-freebsd12.0-as
>>> --with-ld=/usr/local/bin/x86_64-unknown-freebsd12.0-ld
>>> --enable-initfini-array --prefix=/usr/local --localstatedir=/var
>>> --mandir=/usr/local/man --infodir=/usr/local/info/
>>> --build=x86_64-unknown-freebsd12.0
>>> Thread model: posix
>>> gcc version 6.4.0 (FreeBSD Ports Collection for amd64)
>>> COLLECT_GCC_OPTIONS='-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2'
>>> '-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=gnu99'
>>> '-fstack-protector-strong' '-Wno-error=address' '-Wno-error=array-bounds'
>>> '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align'
>>> '-Wno-error=clobbered' '-Wno-error=enum-compare' '-Wno-error=extra'
>>> '-Wno-error=inline' '-Wno-error=logical-not-parentheses'
>>> '-Wno-error=strict-aliasing' '-Wno-error=uninitialized'
>>> '-Wno-error=unused-but-set-variable' '-Wno-error=unused-function'
>>> '-Wno-error=unused-value' '-Wno-error=misleading-indentation'
>>> '-Wno-error=nonnull-compare' '-Wn
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-26, at 9:06 PM, Mark Millard wrote:
> On 2018-Jul-26, at 6:14 PM, Mark Millard wrote:
>
>> On 2018-Jul-26, at 11:21 AM, John Baldwin wrote:
>>
>>> On 7/26/18 10:55 AM, Mark Millard wrote:
>>>> . . .
>>>
>>> Yes, but the -E from above was when compiled with external GCC and it
>>> didn't change
>>> _Atomic(int). Here's part of the source of bar.c:
>>>
>>> #include
>>> #include
>>>
>>> struct foo {
>>> _Atomic(int) one;
>>> _Atomic int two;
>>> atomic_int three;
>>> };
>>>
>>> And here is what that became after -E:
>>>
>>> # 4 "bar.c"
>>> struct foo {
>>> _Atomic(int) one;
>>> _Atomic int two;
>>> atomic_int three;
>>> };
>>>
>>> So cdefs.h did not define _Atomic.
>>>
>>> Ah, if I add '-std=c99' then it does break. Code that wants to use
>>> C11 atomics via should not be using -std=c99. Try this:
>>>
>>> Index: lib/ofed/librdmacm/Makefile
>>> ===
>>> --- lib/ofed/librdmacm/Makefile (revision 335896)
>>> +++ lib/ofed/librdmacm/Makefile (working copy)
>>> @@ -8,6 +8,7 @@
>>> SHLIB_MAJOR= 1
>>> MK_PROFILE=no
>>> CFLAGS+= -I${_spath}
>>> +CSTD= gnu11
>>>
>>> SRCS= \
>>> acm.c \
>>>
>>> If this works then we should probably mark OFED as a BROKEN_OPTION when
>>> building with ancient GCC for now as well.
>>
>> I've "unreverted" to set up a context for testing this.
>>
>> So far I'll I've done is to test that I can still reproduce the failure
>> in my environment, same sort of error reports as ci.freebsd.org's
>> FreeBSD-head-amd64-gcc . This is without your patch.
>>
>> But I've done this with gcc being given -v so that I've the exact commands
>> and search order and the like. It does show: -std=gnu99 . I list the
>> filemon data from the .meta as well, showing the exact mix of
>> FreeBSD and gcc headers used. (I could also provide such for with
>> the reverted Makefile.{inc1,libcompat} [so non-failing] build if you
>> care.)
>>
>>
>> For now I just report the failure *without your patch*:
>> (I'll build again with your patch next.)
>>
>> . . .
>> --- all_subdir_lib/ofed ---
>> Building
>> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/librdmacm/acm.o
>> --- acm.o ---
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
>> Target: x86_64-unknown-freebsd12.0
>> Configured with: /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure
>> --target=x86_64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++
>> --enable-gnu-indirect-function --without-headers --with-gmp=/usr/local
>> --with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib
>> --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/
>> --with-as=/usr/local/bin/x86_64-unknown-freebsd12.0-as
>> --with-ld=/usr/local/bin/x86_64-unknown-freebsd12.0-ld
>> --enable-initfini-array --prefix=/usr/local --localstatedir=/var
>> --mandir=/usr/local/man --infodir=/usr/local/info/
>> --build=x86_64-unknown-freebsd12.0
>> Thread model: posix
>> gcc version 6.4.0 (FreeBSD Ports Collection for amd64)
>> COLLECT_GCC_OPTIONS='-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2'
>> '-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=gnu99'
>> '-fstack-protector-strong' '-Wno-error=address' '-Wno-error=array-bounds'
>> '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align'
>> '-Wno-error=clobbered' '-Wno-error=enum-compare' '-Wno-error=extra'
>> '-Wno-error=inline' '-Wno-error=logical-not-parentheses'
>> '-Wno-error=strict-aliasing' '-Wno-error=uninitialized'
>> '-Wno-error=unused-but-set-variable' '-Wno-error=unused-function'
>> '-Wno-error=unused-value' '-Wno-error=misleading-indentation'
>> '-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value'
>> '-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-v'
>> '-c' '-o' 'acm.o' '-mtune=generic' '-march=x86-64'
>> /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v -I
>> /usr/src/contrib/ofed/librdmacm -isysroot
>> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp
>> /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c -mtune=gen
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-26, at 6:14 PM, Mark Millard wrote:
> On 2018-Jul-26, at 11:21 AM, John Baldwin wrote:
>
>> On 7/26/18 10:55 AM, Mark Millard wrote:
>>> . . .
>>
>> Yes, but the -E from above was when compiled with external GCC and it didn't
>> change
>> _Atomic(int). Here's part of the source of bar.c:
>>
>> #include
>> #include
>>
>> struct foo {
>> _Atomic(int) one;
>> _Atomic int two;
>> atomic_int three;
>> };
>>
>> And here is what that became after -E:
>>
>> # 4 "bar.c"
>> struct foo {
>> _Atomic(int) one;
>> _Atomic int two;
>> atomic_int three;
>> };
>>
>> So cdefs.h did not define _Atomic.
>>
>> Ah, if I add '-std=c99' then it does break. Code that wants to use
>> C11 atomics via should not be using -std=c99. Try this:
>>
>> Index: lib/ofed/librdmacm/Makefile
>> ===
>> --- lib/ofed/librdmacm/Makefile (revision 335896)
>> +++ lib/ofed/librdmacm/Makefile (working copy)
>> @@ -8,6 +8,7 @@
>> SHLIB_MAJOR= 1
>> MK_PROFILE=no
>> CFLAGS+= -I${_spath}
>> +CSTD= gnu11
>>
>> SRCS= \
>> acm.c \
>>
>> If this works then we should probably mark OFED as a BROKEN_OPTION when
>> building with ancient GCC for now as well.
>
> I've "unreverted" to set up a context for testing this.
>
> So far I'll I've done is to test that I can still reproduce the failure
> in my environment, same sort of error reports as ci.freebsd.org's
> FreeBSD-head-amd64-gcc . This is without your patch.
>
> But I've done this with gcc being given -v so that I've the exact commands
> and search order and the like. It does show: -std=gnu99 . I list the
> filemon data from the .meta as well, showing the exact mix of
> FreeBSD and gcc headers used. (I could also provide such for with
> the reverted Makefile.{inc1,libcompat} [so non-failing] build if you
> care.)
>
>
> For now I just report the failure *without your patch*:
> (I'll build again with your patch next.)
>
> . . .
> --- all_subdir_lib/ofed ---
> Building
> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/librdmacm/acm.o
> --- acm.o ---
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
> Target: x86_64-unknown-freebsd12.0
> Configured with: /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure
> --target=x86_64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++
> --enable-gnu-indirect-function --without-headers --with-gmp=/usr/local
> --with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib
> --with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/
> --with-as=/usr/local/bin/x86_64-unknown-freebsd12.0-as
> --with-ld=/usr/local/bin/x86_64-unknown-freebsd12.0-ld
> --enable-initfini-array --prefix=/usr/local --localstatedir=/var
> --mandir=/usr/local/man --infodir=/usr/local/info/
> --build=x86_64-unknown-freebsd12.0
> Thread model: posix
> gcc version 6.4.0 (FreeBSD Ports Collection for amd64)
> COLLECT_GCC_OPTIONS='-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2'
> '-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=gnu99'
> '-fstack-protector-strong' '-Wno-error=address' '-Wno-error=array-bounds'
> '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align'
> '-Wno-error=clobbered' '-Wno-error=enum-compare' '-Wno-error=extra'
> '-Wno-error=inline' '-Wno-error=logical-not-parentheses'
> '-Wno-error=strict-aliasing' '-Wno-error=uninitialized'
> '-Wno-error=unused-but-set-variable' '-Wno-error=unused-function'
> '-Wno-error=unused-value' '-Wno-error=misleading-indentation'
> '-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value'
> '-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-v'
> '-c' '-o' 'acm.o' '-mtune=generic' '-march=x86-64'
> /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v -I
> /usr/src/contrib/ofed/librdmacm -isysroot
> /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp
> /usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c -mtune=generic
> -march=x86-64 -auxbase-strip acm.o -g -O2 -Wno-error=address
> -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare
> -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare
> -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses
> -Wno-error=strict-aliasing -Wno-error=uninitialized
> -Wno-error=unused-but-set-variable -Wno-error=unused-function
> -Wno-error=unused-val
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-26, at 11:21 AM, John Baldwin wrote:
> On 7/26/18 10:55 AM, Mark Millard wrote:
>> . . .
>
> Yes, but the -E from above was when compiled with external GCC and it didn't
> change
> _Atomic(int). Here's part of the source of bar.c:
>
> #include
> #include
>
> struct foo {
>_Atomic(int) one;
>_Atomic int two;
>atomic_int three;
> };
>
> And here is what that became after -E:
>
> # 4 "bar.c"
> struct foo {
> _Atomic(int) one;
> _Atomic int two;
> atomic_int three;
> };
>
> So cdefs.h did not define _Atomic.
>
> Ah, if I add '-std=c99' then it does break. Code that wants to use
> C11 atomics via should not be using -std=c99. Try this:
>
> Index: lib/ofed/librdmacm/Makefile
> ===
> --- lib/ofed/librdmacm/Makefile (revision 335896)
> +++ lib/ofed/librdmacm/Makefile (working copy)
> @@ -8,6 +8,7 @@
> SHLIB_MAJOR= 1
> MK_PROFILE=no
> CFLAGS+= -I${_spath}
> +CSTD= gnu11
>
> SRCS= \
> acm.c \
>
> If this works then we should probably mark OFED as a BROKEN_OPTION when
> building with ancient GCC for now as well.
I've "unreverted" to set up a context for testing this.
So far I'll I've done is to test that I can still reproduce the failure
in my environment, same sort of error reports as ci.freebsd.org's
FreeBSD-head-amd64-gcc . This is without your patch.
But I've done this with gcc being given -v so that I've the exact commands
and search order and the like. It does show: -std=gnu99 . I list the
filemon data from the .meta as well, showing the exact mix of
FreeBSD and gcc headers used. (I could also provide such for with
the reverted Makefile.{inc1,libcompat} [so non-failing] build if you
care.)
For now I just report the failure *without your patch*:
(I'll build again with your patch next.)
. . .
--- all_subdir_lib/ofed ---
Building
/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/lib/ofed/librdmacm/acm.o
--- acm.o ---
Using built-in specs.
COLLECT_GCC=/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
Target: x86_64-unknown-freebsd12.0
Configured with: /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/configure
--target=x86_64-unknown-freebsd12.0 --disable-nls --enable-languages=c,c++
--enable-gnu-indirect-function --without-headers --with-gmp=/usr/local
--with-pkgversion='FreeBSD Ports Collection for amd64' --with-system-zlib
--with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/
--with-as=/usr/local/bin/x86_64-unknown-freebsd12.0-as
--with-ld=/usr/local/bin/x86_64-unknown-freebsd12.0-ld --enable-initfini-array
--prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/info/ --build=x86_64-unknown-freebsd12.0
Thread model: posix
gcc version 6.4.0 (FreeBSD Ports Collection for amd64)
COLLECT_GCC_OPTIONS='-B' '/usr/local/x86_64-unknown-freebsd12.0/bin/' '-O2'
'-pipe' '-I' '/usr/src/contrib/ofed/librdmacm' '-g' '-std=gnu99'
'-fstack-protector-strong' '-Wno-error=address' '-Wno-error=array-bounds'
'-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=cast-align'
'-Wno-error=clobbered' '-Wno-error=enum-compare' '-Wno-error=extra'
'-Wno-error=inline' '-Wno-error=logical-not-parentheses'
'-Wno-error=strict-aliasing' '-Wno-error=uninitialized'
'-Wno-error=unused-but-set-variable' '-Wno-error=unused-function'
'-Wno-error=unused-value' '-Wno-error=misleading-indentation'
'-Wno-error=nonnull-compare' '-Wno-error=shift-negative-value'
'-Wno-error=tautological-compare' '-Wno-error=unused-const-variable' '-v' '-c'
'-o' 'acm.o' '-mtune=generic' '-march=x86-64'
/usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 -quiet -v -I
/usr/src/contrib/ofed/librdmacm -isysroot
/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/tmp
/usr/src/contrib/ofed/librdmacm/acm.c -quiet -dumpbase acm.c -mtune=generic
-march=x86-64 -auxbase-strip acm.o -g -O2 -Wno-error=address
-Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare
-Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare
-Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses
-Wno-error=strict-aliasing -Wno-error=uninitialized
-Wno-error=unused-but-set-variable -Wno-error=unused-function
-Wno-error=unused-value -Wno-error=misleading-indentation
-Wno-error=nonnull-compare -Wno-error=shift-negative-value
-Wno-error=tautological-compare -Wno-error=unused-const-variable -std=gnu99
-version -fstack-protector-strong -o - |
/usr/local/bin/x86_64-unknown-freebsd12.0-as -v -I
/usr/src/contrib/ofed/librdmacm -o acm.o
GNU C99 (FreeBSD Ports Collection for amd64) version 6.4.0
(x86_64-unknown-freebsd12.0)
compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 6.0.0
(tags/RELEASE_600/final 326565), GMP version 6.1.2, MPFR version 4.0.1, MPC
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 7/16/18 11:27 PM, Mark Millard wrote:
> On 2018-Jul-1, at 6:34 AM, Mark Millard wrote:
>
>> My brain finally engaged for showing exactly what files are included
>> for the gcc builds: the .meta files include that information explicitly
>> (along with other files that are opened during the operation).
>>
>> amd64 is as I reported, just one header file from gcc: float.h .
>>
>> powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so
>> is not including . Building without __ALTIVEC__ might
>> be an error itself but would be a workaround for the altivec.h
>> file name aliasing vs. search-path problem.
>>
>> . . .
>
> Going in a different direction, what of the unchanged Makefile.inc1
> code block:
>
> .if ${WANT_COMPILER_TYPE} == gcc || \
> (defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
> # GCC requires -isystem and -L when using a cross-compiler. --sysroot
> # won't set header path and -L is used to ensure the base library path
> # is added before the port PREFIX library path.
> CD2CFLAGS+= -isystem ${XDDESTDIR}/usr/include -L${XDDESTDIR}/usr/lib
> # GCC requires -B to find /usr/lib/crti.o when using a cross-compiler
> # combined with --sysroot.
> CD2CFLAGS+= -B${XDDESTDIR}/usr/lib
> # Force using libc++ for external GCC.
> .if defined(X_COMPILER_TYPE) && \
> ${X_COMPILER_TYPE} == gcc && ${X_COMPILER_VERSION} >= 40800
> CD2CXXFLAGS+= -isystem ${XDDESTDIR}/usr/include/c++/v1 -std=c++11 \
> -nostdinc++
> .endif
> .endif
>
> Why is that pair of -isystem uses that gives the old search order
> okay? Or was the block just missed? (Similarly for other options
> listed above.)
Just missed. They should probably also be removed.
> Note: Locally I've reverted the -r335782 changes in order for my use
> of devel/*-gcc as cross compilers to work where they used to (hopefully:
> still building), restoring the historical search order for the
> directories for now.
I finally got the approval 2 days ago to remove float.h from amd64-gcc so
you shouldn't need this reverted anymore once the OFED thing is
straightened out.
--
John Baldwin
___
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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 7/26/18 10:55 AM, Mark Millard wrote: > > > On 2018-Jul-26, at 10:21 AM, John Baldwin wrote: > >> On 7/25/18 6:52 PM, Mark Millard wrote: >>> >>> >>> On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: >>> >>> >>> >>>> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: >>>> >>>>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >>>>> >>>>>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>>>>>> >>>>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>>>>> >>>>>>>> --- all_subdir_lib/ofed --- >>>>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>>>> 'fastlock_init': >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid >>>>>>>> initializer >>>>>>>> atomic_store(>cnt, 0); >>>>>>>> ^ >>>>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>>>> 'fastlock_acquire': >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type >>>>>>>> 'struct *' is incompatible with argument 1 of >>>>>>>> '__atomic_fetch_add' >>>>>>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>>>>>> ^~ >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>>>> 'fastlock_release': >>>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type >>>>>>>> 'struct *' is incompatible with argument 1 of >>>>>>>> '__atomic_fetch_sub' >>>>>>>> if (atomic_fetch_sub(>cnt, 1) > 1) >>>>>>>> ^~ >>>>>>>> . . . >>>>>>>> --- all_subdir_lib/ofed --- >>>>>>>> *** [acm.o] Error code 1 >>>>>>>> >>>>>>>> >>>>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( >>>>>>>> for >>>>>>>> -r336700 ) still shows this type of error. >>>>>>> >>>>>>> >>>>>>> [I should have a subject with "head -r336568 through -r336570 . . .".] >>>>>>> >>>>>>> From what I can tell looking around having something like: >>>>>>> >>>>>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>>>>> >>>>>>> involve a __atomic_fetch_add indicates that: >>>>>>> >>>>>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>>>>> >>>>>>> was in use instead of FreeBSD's stdatomic.h file. >>>>>>> >>>>>>> If this is right, then the issue may be tied to head -r335782 >>>>>>> implicitly changing the order of the include file directory >>>>>>> searching for builds via the devel/*-gcc . >>>>>>> >>>>>>> (I reverted -r335782 in my environment some time ago and have >>>>>>> not run into this problem in my context so far.) >>>>>> >>>>>> C11 atomics should work fine with compiler-provided headers since they >>>>>> are a part of the language (and the system stdatomic.h simply attempts >>>>>> to mimic the compiler-provided header in case it is missing). >>>>>> >>>>>> Simple standalone tests of _Atomic(int) with GCC don't trigger those >>>>>> failures when using its stdatomic.h, so there is probably something else >>>>>> going on with kernel includes being used while building the library, >>>>>> etc. The last time we had this issue with stdarg.h it was because a >>>>>> header shared between the
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-26, at 10:21 AM, John Baldwin wrote: > On 7/25/18 6:52 PM, Mark Millard wrote: >> >> >> On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: >> >> >> >>> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: >>> >>>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >>>> >>>>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>>>>> >>>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>>>> >>>>>>> --- all_subdir_lib/ofed --- >>>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>>> 'fastlock_init': >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid >>>>>>> initializer >>>>>>> atomic_store(>cnt, 0); >>>>>>> ^ >>>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>>> 'fastlock_acquire': >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type >>>>>>> 'struct *' is incompatible with argument 1 of >>>>>>> '__atomic_fetch_add' >>>>>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>>>>> ^~ >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>>> 'fastlock_release': >>>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type >>>>>>> 'struct *' is incompatible with argument 1 of >>>>>>> '__atomic_fetch_sub' >>>>>>> if (atomic_fetch_sub(>cnt, 1) > 1) >>>>>>> ^~ >>>>>>> . . . >>>>>>> --- all_subdir_lib/ofed --- >>>>>>> *** [acm.o] Error code 1 >>>>>>> >>>>>>> >>>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >>>>>>> -r336700 ) still shows this type of error. >>>>>> >>>>>> >>>>>> [I should have a subject with "head -r336568 through -r336570 . . .".] >>>>>> >>>>>> From what I can tell looking around having something like: >>>>>> >>>>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>>>> >>>>>> involve a __atomic_fetch_add indicates that: >>>>>> >>>>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>>>> >>>>>> was in use instead of FreeBSD's stdatomic.h file. >>>>>> >>>>>> If this is right, then the issue may be tied to head -r335782 >>>>>> implicitly changing the order of the include file directory >>>>>> searching for builds via the devel/*-gcc . >>>>>> >>>>>> (I reverted -r335782 in my environment some time ago and have >>>>>> not run into this problem in my context so far.) >>>>> >>>>> C11 atomics should work fine with compiler-provided headers since they >>>>> are a part of the language (and the system stdatomic.h simply attempts >>>>> to mimic the compiler-provided header in case it is missing). >>>>> >>>>> Simple standalone tests of _Atomic(int) with GCC don't trigger those >>>>> failures when using its stdatomic.h, so there is probably something else >>>>> going on with kernel includes being used while building the library, >>>>> etc. The last time we had this issue with stdarg.h it was because a >>>>> header shared between the kernel and userland always used >>>>> '' >>>>> which is correct for the kernel but not for userland. >>>> >>>> I did misread the headers. FreeBSD has the likes of: >>>> >>>> #if defined(__CLANG_ATOMICS) >>>> . . . >>>> #defineatomic_fetch_add_explicit(object, operand, order)
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 7/25/18 6:52 PM, Mark Millard wrote: > > > On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: > > > >> On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: >> >>> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >>> >>>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>>>> >>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>>> >>>>>> --- all_subdir_lib/ofed --- >>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid >>>>>> initializer >>>>>> atomic_store(>cnt, 0); >>>>>> ^ >>>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>> 'fastlock_acquire': >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type >>>>>> 'struct *' is incompatible with argument 1 of >>>>>> '__atomic_fetch_add' >>>>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>>>> ^~ >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>>> 'fastlock_release': >>>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type >>>>>> 'struct *' is incompatible with argument 1 of >>>>>> '__atomic_fetch_sub' >>>>>> if (atomic_fetch_sub(>cnt, 1) > 1) >>>>>> ^~ >>>>>> . . . >>>>>> --- all_subdir_lib/ofed --- >>>>>> *** [acm.o] Error code 1 >>>>>> >>>>>> >>>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >>>>>> -r336700 ) still shows this type of error. >>>>> >>>>> >>>>> [I should have a subject with "head -r336568 through -r336570 . . .".] >>>>> >>>>> From what I can tell looking around having something like: >>>>> >>>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>>> >>>>> involve a __atomic_fetch_add indicates that: >>>>> >>>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>>> >>>>> was in use instead of FreeBSD's stdatomic.h file. >>>>> >>>>> If this is right, then the issue may be tied to head -r335782 >>>>> implicitly changing the order of the include file directory >>>>> searching for builds via the devel/*-gcc . >>>>> >>>>> (I reverted -r335782 in my environment some time ago and have >>>>> not run into this problem in my context so far.) >>>> >>>> C11 atomics should work fine with compiler-provided headers since they >>>> are a part of the language (and the system stdatomic.h simply attempts >>>> to mimic the compiler-provided header in case it is missing). >>>> >>>> Simple standalone tests of _Atomic(int) with GCC don't trigger those >>>> failures when using its stdatomic.h, so there is probably something else >>>> going on with kernel includes being used while building the library, >>>> etc. The last time we had this issue with stdarg.h it was because a >>>> header shared between the kernel and userland always used >>>> '' >>>> which is correct for the kernel but not for userland. >>> >>> I did misread the headers. FreeBSD has the likes of: >>> >>> #if defined(__CLANG_ATOMICS) >>> . . . >>> #define atomic_fetch_add_explicit(object, operand, order) >>> \ >>> __c11_atomic_fetch_add(object, operand, order) >>> . . . >>> #elif defined(__GNUC_ATOMICS) >>> . . . >>> #define atomic_fetch_add_explicit(object, operand, order) >>> \ >>> __atomic_fetch_add(&(object)->__val, operand, order) >>> . . . >>> #endif >>> . . . >>> #define
Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.
On 25/7/18 12:40 am, Julian Elischer wrote: On 22/7/18 4:32 am, Dimitry Andric wrote: On 21 Jul 2018, at 21:11, Yuri Pankov wrote: Yuri Pankov wrote: Julian Elischer wrote: ... anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? In later GCC versions the cpp's -lang-asm seems to be deprecated in favor of -x assembler-with-cpp as it conflicts with -l option. Could you try changing the -Wp,-E,-lang-asm to -Wp,-E,-xassembler-with-cpp? I did this but if failed.. I had to reread this email a few times to think of replacing the whole -Wp,-E,-lang-asm with just -xassembler-with-cpp! Just tried it myself, and if you indeed mean the third_party/aesni-intel/aesni-intel_asm.c, the following seems to work for me: clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c Yes, that is exactly what I suggested to Julian on IRC. The point is that the ".c" extension is misleading, it should more likely be a ".S" extension. But maybe this source file is used for multiple purposes. Note that -x assembler-with-cpp should also work fine for gcc. Ah.. the trick is to remove the -Wp,-E as well... -Dimitry thanks I tried that but the version of the file we have has several lines that caused problems... a lot of the assembler has assembler comments (starting with '#') which clang complained about and died.. it also had #.align 4 which I HOPE is just a commented out line.. ___ 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" ___ 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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-25, at 2:10 PM, Mark Millard wrote: > On 2018-Jul-25, at 10:09 AM, Mark Millard wrote: > >> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote: >> >>> On 7/24/18 11:39 PM, Mark Millard wrote: >>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: >>>> >>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >>>>> (head -r336573 after the prior 6596's -r336565 ): >>>>> >>>>> --- all_subdir_lib/ofed --- >>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid >>>>> initializer >>>>> atomic_store(>cnt, 0); >>>>> ^ >>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>> 'fastlock_acquire': >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type >>>>> 'struct *' is incompatible with argument 1 of >>>>> '__atomic_fetch_add' >>>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>>> ^~ >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function >>>>> 'fastlock_release': >>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type >>>>> 'struct *' is incompatible with argument 1 of >>>>> '__atomic_fetch_sub' >>>>> if (atomic_fetch_sub(>cnt, 1) > 1) >>>>> ^~ >>>>> . . . >>>>> --- all_subdir_lib/ofed --- >>>>> *** [acm.o] Error code 1 >>>>> >>>>> >>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >>>>> -r336700 ) still shows this type of error. >>>> >>>> >>>> [I should have a subject with "head -r336568 through -r336570 . . .".] >>>> >>>> From what I can tell looking around having something like: >>>> >>>> if (atomic_fetch_add(>cnt, 1) > 0) >>>> >>>> involve a __atomic_fetch_add indicates that: >>>> >>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h >>>> >>>> was in use instead of FreeBSD's stdatomic.h file. >>>> >>>> If this is right, then the issue may be tied to head -r335782 >>>> implicitly changing the order of the include file directory >>>> searching for builds via the devel/*-gcc . >>>> >>>> (I reverted -r335782 in my environment some time ago and have >>>> not run into this problem in my context so far.) >>> >>> C11 atomics should work fine with compiler-provided headers since they >>> are a part of the language (and the system stdatomic.h simply attempts >>> to mimic the compiler-provided header in case it is missing). >>> >>> Simple standalone tests of _Atomic(int) with GCC don't trigger those >>> failures when using its stdatomic.h, so there is probably something else >>> going on with kernel includes being used while building the library, >>> etc. The last time we had this issue with stdarg.h it was because a >>> header shared between the kernel and userland always used >>> '' >>> which is correct for the kernel but not for userland. >> >> I did misread the headers. FreeBSD has the likes of: >> >> #if defined(__CLANG_ATOMICS) >> . . . >> #define atomic_fetch_add_explicit(object, operand, order) >> \ >> __c11_atomic_fetch_add(object, operand, order) >> . . . >> #elif defined(__GNUC_ATOMICS) >> . . . >> #define atomic_fetch_add_explicit(object, operand, order) >> \ >> __atomic_fetch_add(&(object)->__val, operand, order) >> . . . >> #endif >> . . . >> #define atomic_fetch_add(object, operand) >> \ >> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst) >> >> so __atomic_fetch_add would occur. >> >> But so far I do not see the problem with -r335782 reverted. I last built >> -r336693 last night via devel/amd64-gcc (via xtoolchain). >> >> From what I can tel
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-25, at 10:09 AM, Mark Millard wrote:
> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>
>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>>
>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>>>> (head -r336573 after the prior 6596's -r336565 ):
>>>>
>>>> --- all_subdir_lib/ofed ---
>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
>>>> from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init':
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid
>>>> initializer
>>>> atomic_store(>cnt, 0);
>>>> ^
>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0:
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function
>>>> 'fastlock_acquire':
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type
>>>> 'struct *' is incompatible with argument 1 of
>>>> '__atomic_fetch_add'
>>>> if (atomic_fetch_add(>cnt, 1) > 0)
>>>> ^~
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function
>>>> 'fastlock_release':
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type
>>>> 'struct *' is incompatible with argument 1 of
>>>> '__atomic_fetch_sub'
>>>> if (atomic_fetch_sub(>cnt, 1) > 1)
>>>> ^~
>>>> . . .
>>>> --- all_subdir_lib/ofed ---
>>>> *** [acm.o] Error code 1
>>>>
>>>>
>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for
>>>> -r336700 ) still shows this type of error.
>>>
>>>
>>> [I should have a subject with "head -r336568 through -r336570 . . .".]
>>>
>>> From what I can tell looking around having something like:
>>>
>>> if (atomic_fetch_add(>cnt, 1) > 0)
>>>
>>> involve a __atomic_fetch_add indicates that:
>>>
>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
>>>
>>> was in use instead of FreeBSD's stdatomic.h file.
>>>
>>> If this is right, then the issue may be tied to head -r335782
>>> implicitly changing the order of the include file directory
>>> searching for builds via the devel/*-gcc .
>>>
>>> (I reverted -r335782 in my environment some time ago and have
>>> not run into this problem in my context so far.)
>>
>> C11 atomics should work fine with compiler-provided headers since they
>> are a part of the language (and the system stdatomic.h simply attempts
>> to mimic the compiler-provided header in case it is missing).
>>
>> Simple standalone tests of _Atomic(int) with GCC don't trigger those
>> failures when using its stdatomic.h, so there is probably something else
>> going on with kernel includes being used while building the library,
>> etc. The last time we had this issue with stdarg.h it was because a
>> header shared between the kernel and userland always used
>> ''
>> which is correct for the kernel but not for userland.
>
> I did misread the headers. FreeBSD has the likes of:
>
> #if defined(__CLANG_ATOMICS)
> . . .
> #define atomic_fetch_add_explicit(object, operand, order)
> \
> __c11_atomic_fetch_add(object, operand, order)
> . . .
> #elif defined(__GNUC_ATOMICS)
> . . .
> #define atomic_fetch_add_explicit(object, operand, order)
> \
> __atomic_fetch_add(&(object)->__val, operand, order)
> . . .
> #endif
> . . .
> #define atomic_fetch_add(object, operand)
> \
> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst)
>
> so __atomic_fetch_add would occur.
>
> But so far I do not see the problem with -r335782 reverted. I last built
> -r336693 last night via devel/amd64-gcc (via xtoolchain).
>
> From what I can tell FreeBSD defines:
>
> #if !defined(__CLANG_ATOMICS)
> #define _Atomic(T) struct { volatile T __val; }
> #endif
>
> and that struct is being used in &(object)->__val is what the
> error reports are about. So that would be, for example,
>
> &(>cnt)->__val
>
> This would appear to suggest that __val itself had a type meeting:
>
> operand type struct
>
>
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 7/25/18 10:09 AM, Mark Millard wrote:
>
>
> On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
>
>> On 7/24/18 11:39 PM, Mark Millard wrote:
>>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>>
>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>>>> (head -r336573 after the prior 6596's -r336565 ):
>>>>
>>>> --- all_subdir_lib/ofed ---
>>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
>>>>from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init':
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid
>>>> initializer
>>>> atomic_store(>cnt, 0);
>>>> ^
>>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0:
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function
>>>> 'fastlock_acquire':
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type
>>>> 'struct *' is incompatible with argument 1 of
>>>> '__atomic_fetch_add'
>>>> if (atomic_fetch_add(>cnt, 1) > 0)
>>>> ^~
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function
>>>> 'fastlock_release':
>>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type
>>>> 'struct *' is incompatible with argument 1 of
>>>> '__atomic_fetch_sub'
>>>> if (atomic_fetch_sub(>cnt, 1) > 1)
>>>> ^~
>>>> . . .
>>>> --- all_subdir_lib/ofed ---
>>>> *** [acm.o] Error code 1
>>>>
>>>>
>>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for
>>>> -r336700 ) still shows this type of error.
>>>
>>>
>>> [I should have a subject with "head -r336568 through -r336570 . . .".]
>>>
>>> From what I can tell looking around having something like:
>>>
>>> if (atomic_fetch_add(>cnt, 1) > 0)
>>>
>>> involve a __atomic_fetch_add indicates that:
>>>
>>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
>>>
>>> was in use instead of FreeBSD's stdatomic.h file.
>>>
>>> If this is right, then the issue may be tied to head -r335782
>>> implicitly changing the order of the include file directory
>>> searching for builds via the devel/*-gcc .
>>>
>>> (I reverted -r335782 in my environment some time ago and have
>>> not run into this problem in my context so far.)
>>
>> C11 atomics should work fine with compiler-provided headers since they
>> are a part of the language (and the system stdatomic.h simply attempts
>> to mimic the compiler-provided header in case it is missing).
>>
>> Simple standalone tests of _Atomic(int) with GCC don't trigger those
>> failures when using its stdatomic.h, so there is probably something else
>> going on with kernel includes being used while building the library,
>> etc. The last time we had this issue with stdarg.h it was because a
>> header shared between the kernel and userland always used
>> ''
>> which is correct for the kernel but not for userland.
>
> I did misread the headers. FreeBSD has the likes of:
>
> #if defined(__CLANG_ATOMICS)
> . . .
> #define atomic_fetch_add_explicit(object, operand, order)
> \
> __c11_atomic_fetch_add(object, operand, order)
> . . .
> #elif defined(__GNUC_ATOMICS)
> . . .
> #define atomic_fetch_add_explicit(object, operand, order)
> \
> __atomic_fetch_add(&(object)->__val, operand, order)
> . . .
> #endif
> . . .
> #define atomic_fetch_add(object, operand)
> \
> atomic_fetch_add_explicit(object, operand, memory_order_seq_cst)
>
> so __atomic_fetch_add would occur.
>
> But so far I do not see the problem with -r335782 reverted. I last built
> -r336693 last night via devel/amd64-gcc (via xtoolchain).
>
> From what I can tell FreeBSD defines:
>
> #if !defined(__CLANG_ATOMICS)
> #define _Atomic(T) struct { volatile T __val; }
> #endif
This looks wrong for modern GCC supporting C11 atomics. What is happening is
that this is probably overriding the compiler's builtin _Atomic and then the
compiler's stdatomic.h which doesn't look for __val but expects 'object' to
be a plain int is then failing to compile. Just including sys/cdefs.h in
my test program doesn't trigger the failure though.
--
John Baldwin
___
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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-25, at 8:39 AM, John Baldwin wrote:
> On 7/24/18 11:39 PM, Mark Millard wrote:
>> On 2018-Jul-24, at 10:32 PM, Mark Millard wrote:
>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText
>>> (head -r336573 after the prior 6596's -r336565 ):
>>>
>>> --- all_subdir_lib/ofed ---
>>> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0,
>>>from /workspace/src/contrib/ofed/librdmacm/acm.c:42:
>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init':
>>> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer
>>> atomic_store(>cnt, 0);
>>> ^
>>> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0:
>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire':
>>> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type
>>> 'struct *' is incompatible with argument 1 of
>>> '__atomic_fetch_add'
>>> if (atomic_fetch_add(>cnt, 1) > 0)
>>> ^~
>>> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release':
>>> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type
>>> 'struct *' is incompatible with argument 1 of
>>> '__atomic_fetch_sub'
>>> if (atomic_fetch_sub(>cnt, 1) > 1)
>>> ^~
>>> . . .
>>> --- all_subdir_lib/ofed ---
>>> *** [acm.o] Error code 1
>>>
>>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for
>>> -r336700 ) still shows this type of error.
>>
>>
>> [I should have a subject with "head -r336568 through -r336570 . . .".]
>>
>> From what I can tell looking around having something like:
>>
>> if (atomic_fetch_add(>cnt, 1) > 0)
>>
>> involve a __atomic_fetch_add indicates that:
>>
>> /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h
>>
>> was in use instead of FreeBSD's stdatomic.h file.
>>
>> If this is right, then the issue may be tied to head -r335782
>> implicitly changing the order of the include file directory
>> searching for builds via the devel/*-gcc .
>>
>> (I reverted -r335782 in my environment some time ago and have
>> not run into this problem in my context so far.)
>
> C11 atomics should work fine with compiler-provided headers since they
> are a part of the language (and the system stdatomic.h simply attempts
> to mimic the compiler-provided header in case it is missing).
>
> Simple standalone tests of _Atomic(int) with GCC don't trigger those
> failures when using its stdatomic.h, so there is probably something else
> going on with kernel includes being used while building the library,
> etc. The last time we had this issue with stdarg.h it was because a
> header shared between the kernel and userland always used ''
> which is correct for the kernel but not for userland.
I did misread the headers. FreeBSD has the likes of:
#if defined(__CLANG_ATOMICS)
. . .
#define atomic_fetch_add_explicit(object, operand, order) \
__c11_atomic_fetch_add(object, operand, order)
. . .
#elif defined(__GNUC_ATOMICS)
. . .
#define atomic_fetch_add_explicit(object, operand, order) \
__atomic_fetch_add(&(object)->__val, operand, order)
. . .
#endif
. . .
#define atomic_fetch_add(object, operand) \
atomic_fetch_add_explicit(object, operand, memory_order_seq_cst)
so __atomic_fetch_add would occur.
But so far I do not see the problem with -r335782 reverted. I last built
-r336693 last night via devel/amd64-gcc (via xtoolchain).
>From what I can tell FreeBSD defines:
#if !defined(__CLANG_ATOMICS)
#define _Atomic(T) struct { volatile T __val; }
#endif
and that struct is being used in &(object)->__val is what the
error reports are about. So that would be, for example,
&(>cnt)->__val
This would appear to suggest that __val itself had a type meeting:
operand type struct
for T in _Atomic(T) .
(This is independent of just what the issue traces back to: just
the net result on ci.freebsd.org . No claim that you are right
or wrong here. I'll not be looking any more until this afternoon
or night.)
===
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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 7/24/18 11:39 PM, Mark Millard wrote: > On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: > >> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText >> (head -r336573 after the prior 6596's -r336565 ): >> >> --- all_subdir_lib/ofed --- >> In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, >> from /workspace/src/contrib/ofed/librdmacm/acm.c:42: >> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': >> /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer >> atomic_store(>cnt, 0); >> ^ >> In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: >> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': >> /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type >> 'struct *' is incompatible with argument 1 of >> '__atomic_fetch_add' >> if (atomic_fetch_add(>cnt, 1) > 0) >> ^~ >> /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': >> /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type >> 'struct *' is incompatible with argument 1 of >> '__atomic_fetch_sub' >> if (atomic_fetch_sub(>cnt, 1) > 1) >> ^~ >> . . . >> --- all_subdir_lib/ofed --- >> *** [acm.o] Error code 1 >> >> >> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for >> -r336700 ) still shows this type of error. > > > [I should have a subject with "head -r336568 through -r336570 . . .".] > > From what I can tell looking around having something like: > > if (atomic_fetch_add(>cnt, 1) > 0) > > involve a __atomic_fetch_add indicates that: > > /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h > > was in use instead of FreeBSD's stdatomic.h file. > > If this is right, then the issue may be tied to head -r335782 > implicitly changing the order of the include file directory > searching for builds via the devel/*-gcc . > > (I reverted -r335782 in my environment some time ago and have > not run into this problem in my context so far.) C11 atomics should work fine with compiler-provided headers since they are a part of the language (and the system stdatomic.h simply attempts to mimic the compiler-provided header in case it is missing). Simple standalone tests of _Atomic(int) with GCC don't trigger those failures when using its stdatomic.h, so there is probably something else going on with kernel includes being used while building the library, etc. The last time we had this issue with stdarg.h it was because a header shared between the kernel and userland always used '' which is correct for the kernel but not for userland. -- John Baldwin ___ 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"
Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.
On 22/7/18 3:11 am, Yuri Pankov wrote: Yuri Pankov wrote: Julian Elischer wrote: I would really like ot get some pointers as to who are our tools committers at the moment, in particular who might know about these issues. The main issue for me at the moment is the ability to compile the aesni code in Samba from clang.. Julian On 20/7/18 7:32 pm, Julian Elischer wrote: compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour when lld became the linker I think.. 1/ linking needed some directories added to some of the build scripts because previously apparently it looked in $SYSROOT/usr/lib by default and now it doesn't. 2/ compiling our samba produces a libtdb.so that has various symbols in it, (according to nm(1) ), but when we try link against it we get complaints about those symbols not being defined. 3/ an attempt to switch to using clang to compile everything leads to: "--aes-accel=intelaesni selected and compiler rejects -Wp,-E,-lang-asm. One wonders whether there is a clang equivalent of "-Wp,-E,-lang-asm" The AES acceleration is a configure option for the samba package. Apparently turning it on requires -Wp,-E,-lang-asm. which apparently gcc 4.2.1 has, but clang doesn't have.    FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based    on LLVM 6.0.1)    Target: x86_64-unknown-freebsd12.0    Thread model: posix    InstalledDir: /usr/bin anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? In later GCC versions the cpp's -lang-asm seems to be deprecated in favor of -x assembler-with-cpp as it conflicts with -l option. Could you try changing the -Wp,-E,-lang-asm to -Wp,-E,-xassembler-with-cpp? Just tried it myself, and if you indeed mean the third_party/aesni-intel/aesni-intel_asm.c, the following seems to work for me: clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c when I try it I get lots of errors due to hte fact that there are assembled comments that start with # and they are all cited as errors by clang. I had to put '//' before about 80 lines line that. possible work arrounds include: 1/ Get gcc/lld to produce a library from which lld can find the symbols 2/ find a way to compile this with clang but everything else with gcc? 3/ find a way to allow clang to use -Wp,-E,-lang-asm whatever that means Thoughts from any tools people? ___ 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"
Re: head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of
On 2018-Jul-24, at 10:32 PM, Mark Millard wrote: > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText > (head -r336573 after the prior 6596's -r336565 ): > > --- all_subdir_lib/ofed --- > In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, > from /workspace/src/contrib/ofed/librdmacm/acm.c:42: > /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': > /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer > atomic_store(>cnt, 0); > ^ > In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: > /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': > /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct > *' is incompatible with argument 1 of '__atomic_fetch_add' > if (atomic_fetch_add(>cnt, 1) > 0) > ^~ > /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': > /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct > *' is incompatible with argument 1 of '__atomic_fetch_sub' > if (atomic_fetch_sub(>cnt, 1) > 1) > ^~ > . . . > --- all_subdir_lib/ofed --- > *** [acm.o] Error code 1 > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for > -r336700 ) still shows this type of error. [I should have a subject with "head -r336568 through -r336570 . . .".] >From what I can tell looking around having something like: if (atomic_fetch_add(>cnt, 1) > 0) involve a __atomic_fetch_add indicates that: /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/stdatomic.h was in use instead of FreeBSD's stdatomic.h file. If this is right, then the issue may be tied to head -r335782 implicitly changing the order of the include file directory searching for builds via the devel/*-gcc . (I reverted -r335782 in my environment some time ago and have not run into this problem in my context so far.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) === 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"
head -r336568 and -r336570 appears to have made ci.freebsg.org's FreeBSD-head-amd64-gcc fail either than it had been (error: operand type 'struct *' is incompatible with argument 1 of '__a
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6597/consoleText (head -r336573 after the prior 6596's -r336565 ): --- all_subdir_lib/ofed --- In file included from /workspace/src/contrib/ofed/librdmacm/cma.h:43:0, from /workspace/src/contrib/ofed/librdmacm/acm.c:42: /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_init': /workspace/src/contrib/ofed/librdmacm/cma.h:60:2: error: invalid initializer atomic_store(>cnt, 0); ^ In file included from /workspace/src/contrib/ofed/librdmacm/acm.c:42:0: /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_acquire': /workspace/src/contrib/ofed/librdmacm/cma.h:68:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_add' if (atomic_fetch_add(>cnt, 1) > 0) ^~ /workspace/src/contrib/ofed/librdmacm/cma.h: In function 'fastlock_release': /workspace/src/contrib/ofed/librdmacm/cma.h:73:2: error: operand type 'struct *' is incompatible with argument 1 of '__atomic_fetch_sub' if (atomic_fetch_sub(>cnt, 1) > 1) ^~ . . . --- all_subdir_lib/ofed --- *** [acm.o] Error code 1 https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6621/consoleText ( for -r336700 ) still shows this type of error. === 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"
Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.
On 22/7/18 4:32 am, Dimitry Andric wrote: On 21 Jul 2018, at 21:11, Yuri Pankov wrote: Yuri Pankov wrote: Julian Elischer wrote: ... anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? In later GCC versions the cpp's -lang-asm seems to be deprecated in favor of -x assembler-with-cpp as it conflicts with -l option. Could you try changing the -Wp,-E,-lang-asm to -Wp,-E,-xassembler-with-cpp? Just tried it myself, and if you indeed mean the third_party/aesni-intel/aesni-intel_asm.c, the following seems to work for me: clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c Yes, that is exactly what I suggested to Julian on IRC. The point is that the ".c" extension is misleading, it should more likely be a ".S" extension. But maybe this source file is used for multiple purposes. Note that -x assembler-with-cpp should also work fine for gcc. -Dimitry thanks I tried that but the version of the file we have has several lines that caused problems... a lot of the assembler has assembler comments (starting with '#') which clang complained about and died.. it also had #.align 4 which I HOPE is just a commented out line.. ___ 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"
Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.
On 21 Jul 2018, at 21:11, Yuri Pankov wrote: > > Yuri Pankov wrote: >> Julian Elischer wrote: ... >>>> anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? >> In later GCC versions the cpp's -lang-asm seems to be deprecated in >> favor of -x assembler-with-cpp as it conflicts with -l option. >> Could you try changing the -Wp,-E,-lang-asm to -Wp,-E,-xassembler-with-cpp? > > Just tried it myself, and if you indeed mean the > third_party/aesni-intel/aesni-intel_asm.c, the following seems to work for me: > > clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c Yes, that is exactly what I suggested to Julian on IRC. The point is that the ".c" extension is misleading, it should more likely be a ".S" extension. But maybe this source file is used for multiple purposes. Note that -x assembler-with-cpp should also work fine for gcc. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.
Yuri Pankov wrote: Julian Elischer wrote: I would really like ot get some pointers as to who are our tools committers at the moment, in particular who might know about these issues. The main issue for me at the moment is the ability to compile the aesni code in Samba from clang.. Julian On 20/7/18 7:32 pm, Julian Elischer wrote: compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour when lld became the linker I think.. 1/ linking needed some directories added to some of the build scripts because previously apparently it looked in $SYSROOT/usr/lib by default and now it doesn't. 2/ compiling our samba produces a libtdb.so that has various symbols in it, (according to nm(1) ), but when we try link against it we get complaints about those symbols not being defined. 3/ an attempt to switch to using clang to compile everything leads to: "--aes-accel=intelaesni selected and compiler rejects -Wp,-E,-lang-asm. One wonders whether there is a clang equivalent of "-Wp,-E,-lang-asm" The AES acceleration is a configure option for the samba package. Apparently turning it on requires -Wp,-E,-lang-asm. which apparently gcc 4.2.1 has, but clang doesn't have.   FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based   on LLVM 6.0.1)   Target: x86_64-unknown-freebsd12.0   Thread model: posix   InstalledDir: /usr/bin anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? In later GCC versions the cpp's -lang-asm seems to be deprecated in favor of -x assembler-with-cpp as it conflicts with -l option. Could you try changing the -Wp,-E,-lang-asm to -Wp,-E,-xassembler-with-cpp? Just tried it myself, and if you indeed mean the third_party/aesni-intel/aesni-intel_asm.c, the following seems to work for me: clang -xassembler-with-cpp -c third_party/aesni-intel/aesni-intel_asm.c possible work arrounds include: 1/ Get gcc/lld to produce a library from which lld can find the symbols 2/ find a way to compile this with clang but everything else with gcc? 3/ find a way to allow clang to use -Wp,-E,-lang-asm whatever that means Thoughts from any tools people? ___ 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"
Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.
Julian Elischer wrote: I would really like ot get some pointers as to who are our tools committers at the moment, in particular who might know about these issues. The main issue for me at the moment is the ability to compile the aesni code in Samba from clang.. Julian On 20/7/18 7:32 pm, Julian Elischer wrote: compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour when lld became the linker I think.. 1/ linking needed some directories added to some of the build scripts because previously apparently it looked in $SYSROOT/usr/lib by default and now it doesn't. 2/ compiling our samba produces a libtdb.so that has various symbols in it, (according to nm(1) ), but when we try link against it we get complaints about those symbols not being defined. 3/ an attempt to switch to using clang to compile everything leads to: "--aes-accel=intelaesni selected and compiler rejects -Wp,-E,-lang-asm. One wonders whether there is a clang equivalent of "-Wp,-E,-lang-asm" The AES acceleration is a configure option for the samba package. Apparently turning it on requires -Wp,-E,-lang-asm. which apparently gcc 4.2.1 has, but clang doesn't have.   FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based   on LLVM 6.0.1)   Target: x86_64-unknown-freebsd12.0   Thread model: posix   InstalledDir: /usr/bin anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? In later GCC versions the cpp's -lang-asm seems to be deprecated in favor of -x assembler-with-cpp as it conflicts with -l option. Could you try changing the -Wp,-E,-lang-asm to -Wp,-E,-xassembler-with-cpp? possible work arrounds include: 1/ Get gcc/lld to produce a library from which lld can find the symbols 2/ find a way to compile this with clang but everything else with gcc? 3/ find a way to allow clang to use -Wp,-E,-lang-asm whatever that means Thoughts from any tools people? ___ 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"
Re: gcc/clang interoperability problem with a custom "samba" build in recent -current.
I would really like ot get some pointers as to who are our tools committers at the moment, in particular who might know about these issues. The main issue for me at the moment is the ability to compile the aesni code in Samba from clang.. Julian On 20/7/18 7:32 pm, Julian Elischer wrote: compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour when lld became the linker I think.. 1/ linking needed some directories added to some of the build scripts because previously apparently it looked in $SYSROOT/usr/lib by default and now it doesn't. 2/ compiling our samba produces a libtdb.so that has various symbols in it, (according to nm(1) ), but when we try link against it we get complaints about those symbols not being defined. 3/ an attempt to switch to using clang to compile everything leads to: "--aes-accel=intelaesni selected and compiler rejects -Wp,-E,-lang-asm. One wonders whether there is a clang equivalent of "-Wp,-E,-lang-asm" The AES acceleration is a configure option for the samba package. Apparently turning it on requires -Wp,-E,-lang-asm. which apparently gcc 4.2.1 has, but clang doesn't have.   FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based   on LLVM 6.0.1)   Target: x86_64-unknown-freebsd12.0   Thread model: posix   InstalledDir: /usr/bin anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? possible work arrounds include: 1/ Get gcc/lld to produce a library from which lld can find the symbols 2/ find a way to compile this with clang but everything else with gcc? 3/ find a way to allow clang to use -Wp,-E,-lang-asm whatever that means Thoughts from any tools people? Julian ___ 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" ___ 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"
gcc/clang interoperability problem with a custom "samba" build in recent -current.
compiling our samba with gcc 4.2.1 in 12 gave us some off behaviour when lld became the linker I think.. 1/ linking needed some directories added to some of the build scripts because previously apparently it looked in $SYSROOT/usr/lib by default and now it doesn't. 2/ compiling our samba produces a libtdb.so that has various symbols in it, (according to nm(1) ), but when we try link against it we get complaints about those symbols not being defined. 3/ an attempt to switch to using clang to compile everything leads to: "--aes-accel=intelaesni selected and compiler rejects -Wp,-E,-lang-asm. One wonders whether there is a clang equivalent of "-Wp,-E,-lang-asm" The AES acceleration is a configure option for the samba package. Apparently turning it on requires -Wp,-E,-lang-asm. which apparently gcc 4.2.1 has, but clang doesn't have. FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin anyone know if there is a clang equivalent of -Wp, -E,-lang-asm? possible work arrounds include: 1/ Get gcc/lld to produce a library from which lld can find the symbols 2/ find a way to compile this with clang but everything else with gcc? 3/ find a way to allow clang to use -Wp,-E,-lang-asm whatever that means Thoughts from any tools people? Julian ___ 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jul-1, at 6:34 AM, Mark Millard wrote:
> My brain finally engaged for showing exactly what files are included
> for the gcc builds: the .meta files include that information explicitly
> (along with other files that are opened during the operation).
>
> amd64 is as I reported, just one header file from gcc: float.h .
>
> powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so
> is not including . Building without __ALTIVEC__ might
> be an error itself but would be a workaround for the altivec.h
> file name aliasing vs. search-path problem.
>
> . . .
Going in a different direction, what of the unchanged Makefile.inc1
code block:
.if ${WANT_COMPILER_TYPE} == gcc || \
(defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
# GCC requires -isystem and -L when using a cross-compiler. --sysroot
# won't set header path and -L is used to ensure the base library path
# is added before the port PREFIX library path.
CD2CFLAGS+= -isystem ${XDDESTDIR}/usr/include -L${XDDESTDIR}/usr/lib
# GCC requires -B to find /usr/lib/crti.o when using a cross-compiler
# combined with --sysroot.
CD2CFLAGS+= -B${XDDESTDIR}/usr/lib
# Force using libc++ for external GCC.
.if defined(X_COMPILER_TYPE) && \
${X_COMPILER_TYPE} == gcc && ${X_COMPILER_VERSION} >= 40800
CD2CXXFLAGS+= -isystem ${XDDESTDIR}/usr/include/c++/v1 -std=c++11 \
-nostdinc++
.endif
.endif
Why is that pair of -isystem uses that gives the old search order
okay? Or was the block just missed? (Similarly for other options
listed above.)
Note: Locally I've reverted the -r335782 changes in order for my use
of devel/*-gcc as cross compilers to work where they used to (hopefully:
still building), restoring the historical search order for the
directories for now.
===
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"
aarch64-none-elf-gcc and related programs will not install
Hi, context: 12.0-CURRENT #0 r336037 amd64 / ports r474140 I get the following when installing aarch64-none-elf-gcc and related programs from ports. It will build fine, just errors on install. my /etc/make.conf looks like this: > less /etc/make.conf WRKDIRPREFIX=/buildports MAKE_JOBS_NUMBER=36 WITH_CCACHE_BUILD=YES CCACHE_DIR=/ccache WITH_MANCOMPRESS=YES WITHOUT_DEBUG=YES OPTIONS_SET+=OPTIMIZED_CFLAGS OPTIONS_SET+=ICONV CPUTYPE?=sandybridge It doesn't matter if /etc/make.conf is moved out of the way. these also fail in a similar way: devel/arm-none-eabi-gcc sysutils/u-boot-rpi2 sysutils/u-boot-rpi3 output when trying to install: root@REDACTED:/usr/ports/devel/aarch64-none-elf-gcc # make distclean && make clean && make ===> Cleaning for aarch64-none-elf-gcc-6.4.0 ===> Deleting distfiles for aarch64-none-elf-gcc-6.4.0 ===> Cleaning for aarch64-none-elf-gcc-6.4.0 ===> License GPLv3 GPLv3RLE accepted by the user ===> aarch64-none-elf-gcc-6.4.0 depends on file: /usr/local/sbin/pkg - found => gcc-6.4.0.tar.xz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://mirrors.kernel.org/sourceware/gcc/releases/gcc-6.4.0/gcc-6.4.0.tar.xz [...] /bin/sh /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/gcc-6.4.0/libgcc/../mkinstalldirs /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include install -m 0644 unwind.h /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include gmake[4]: Leaving directory '/buildports/usr/ports/devel/aarch64-none-elf-gcc/work/.build/aarch64-none-elf/ilp32/libgcc' gmake[3]: Leaving directory '/buildports/usr/ports/devel/aarch64-none-elf-gcc/work/.build/aarch64-none-elf/libgcc' gmake[2]: Leaving directory '/buildports/usr/ports/devel/aarch64-none-elf-gcc/work/.build/aarch64-none-elf/libgcc' gmake[1]: Leaving directory '/buildports/usr/ports/devel/aarch64-none-elf-gcc/work/.build' > Compressing man pages (compress-man) root@REDACTED:/usr/ports/devel/aarch64-none-elf-gcc # root@REDACTED:/usr/ports/devel/aarch64-none-elf-gcc # make deinstall reinstall ===> Deinstalling for aarch64-none-elf-gcc ===> aarch64-none-elf-gcc not installed, skipping ===> Installing for aarch64-none-elf-gcc-6.4.0 ===> Registering installation for aarch64-none-elf-gcc-6.4.0 pkg-static: Unable to access file /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include-fixed/netinet/ip_fil.h:No such file or directory pkg-static: Unable to access file /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include-fixed/netinet/ip_lookup.h:No such file or directory pkg-static: Unable to access file /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include-fixed/netinet/ip_nat.h:No such file or directory pkg-static: Unable to access file /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include-fixed/netinet/ip_proxy.h:No such file or directory pkg-static: Unable to access file /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include-fixed/netinet/ip_scan.h:No such file or directory pkg-static: Unable to access file /buildports/usr/ports/devel/aarch64-none-elf-gcc/work/stage/usr/local/lib/gcc/aarch64-none-elf/6.4.0/include-fixed/netinet/ip_state.h:No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/devel/aarch64-none-elf-gcc *** Error code 1 Stop. make: stopped in /usr/ports/devel/aarch64-none-elf-gcc root@REDACTED:/usr/ports/devel/aarch64-none-elf-gcc # How can I fix? thanks, -- J. ___ 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
My brain finally engaged for showing exactly what files are included for the gcc builds: the .meta files include that information explicitly (along with other files that are opened during the operation). amd64 is as I reported, just one header file from gcc: float.h . powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so is not including . Building without __ALTIVEC__ might be an error itself but would be a workaround for the altivec.h file name aliasing vs. search-path problem. The details from the .meta files for the amd64 float.h failure and the powerpc64 altivec.h issue follow. For the -r335782+ amd64 context: E 73559 /bin/sh R 73559 /etc/libmap.conf R 73559 /var/run/ld-elf.so.hints R 73559 /lib/libedit.so.7 R 73559 /lib/libc.so.7 R 73559 /lib/libncursesw.so.8 F 73559 73560 E 73560 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc R 73560 /etc/libmap.conf R 73560 /var/run/ld-elf.so.hints R 73560 /usr/lib/libc++.so.1 R 73560 /lib/libcxxrt.so.1 R 73560 /lib/libm.so.5 R 73560 /lib/libc.so.7 R 73560 /lib/libgcc_s.so.1 F 73560 73561 E 73561 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 R 73561 /etc/libmap.conf R 73561 /var/run/ld-elf.so.hints R 73561 /usr/local/lib/libmpc.so.3 R 73561 /usr/local/lib/libmpfr.so.6 R 73561 /usr/local/lib/libgmp.so.10 R 73561 /lib/libz.so.6 R 73561 /usr/lib/libc++.so.1 R 73561 /lib/libcxxrt.so.1 R 73561 /lib/libm.so.5 R 73561 /lib/libc.so.7 R 73561 /lib/libgcc_s.so.1 R 73561 /dev/urandom R 73561 /usr/src/lib/msun/src/catrigl.c F 73560 73562 E 73562 /usr/local/bin/x86_64-unknown-freebsd12.0-as R 73562 /etc/libmap.conf R 73562 /var/run/ld-elf.so.hints R 73562 /lib/libc.so.7 R 73562 catrigl.o W 73562 catrigl.o R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/cdefs.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/complex.h R 73561 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/float.h R 73561 /usr/src/lib/msun/ld80/invtrig.h R 73561 /usr/src/lib/libc/include/fpmath.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/endian.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/_types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/x86/_types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/_limits.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/x86/_limits.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/endian.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/x86/endian.h R 73561 /usr/src/lib/libc/i386/_fpmath.h R 73561 /usr/src/lib/msun/src/math.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/_limits.h R 73561 /usr/src/lib/msun/src/math_private.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/endian.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_pthreadtypes.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_stdint.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/select.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_sigset.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_timeval.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/timespec.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_timespec.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/endian.h R 73561 /usr/src/lib/msun/src/catrigl.c X 73562 0 0 X 73561 1 0 D 73560 catrigl.o X 73560 1 0 X 73559 1 0 Note that only one one file (float.h) comes from gcc. It would have to not be a file of a related set of files (very independent) for such to be coherent. As for my pre-existing powerpc64 build under -r335782+: It did not include altivec.h at all according to its Lex_Lexer.o.meta file. Apparently __ALTIVEC__ is not defined, as the code for the #include in Lex/Lexer.cpp is: #ifdef __SSE2__ #include #elif __ALTIVEC__ #include #undef bool #endif It did open the 3 files with /gcc/ in the path (2 being headers): /usr/local/libexec/gcc/powerpc64-unknown
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 11:53 AM, John Baldwin wrote: > On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: >>>> On 2018-Jun-30, at 7:51 AM, John Baldwin 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 instead of >>> 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 >>> 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.hstddef.hstdint.h > varargs.h > float.h iso646.hppu_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 , > etc. headers used for SSE on x86 that are always provided by the compiler. > However, this header is '' not '' 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 > probably plays a similar role in providing the vendor-specified C > bindings for altivec instructions.) [This is based on a -r335812
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: >>>> On 2018-Jun-30, at 7:51 AM, John Baldwin 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 instead of >>> 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 >>> 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.hstddef.hstdint.h > varargs.h > float.h iso646.hppu_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 , etc. headers used for SSE on x86 that are always provided by the compiler. However, this header is '' not '' 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 probably plays a similar role in providing the vendor-specified C bindings for altivec instructions.) -- John Baldwin ___ 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: > >> On 6/30/18 9:17 AM, Mark Millard wrote: >>> On 2018-Jun-30, at 7:51 AM, John Baldwin 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 instead of >> 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 >> 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.hstddef.hstdint.h varargs.h float.h iso646.hppu_intrinsics.h spu2vmx.h stdatomic.h stdfix.h stdnoreturn.h vec_types.h htmintrin.h paired.hsi2vmx.h stdalign.h stdbool.h stdint-gcc.htgmath.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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: > On 6/30/18 9:17 AM, Mark Millard wrote: >> On 2018-Jun-30, at 7:51 AM, John Baldwin 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 instead of > 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 > 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.) === 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/30/18 9:17 AM, Mark Millard wrote: > On 2018-Jun-30, at 7:51 AM, John Baldwin 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 instead of 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 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. -- John Baldwin ___ 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 7:51 AM, John Baldwin 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: head -r335812 uses the gcc headers (and fails): ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include End of search list. head -r335245 uses the FreeBSD headers and works: ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-unknown-freebsd12.0/include" ignoring duplicate directory "/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include End of search list. Might this reversal have other effects even for architectures for which the code does compile via devel/*-gcc ? === 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
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. -- John Baldwin ___ 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
[Re-sending from my subscription address, sorry for the spam] On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> >>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>>> breaking-change was the following but I've not tried personal >>>> builds to confirm. >>>> ] > > So this is a bit complicated and I'm not sure what the correct fix is. > > What is happening is that the shipped with GCC is now being used > after this change instead of sys/x86/include/float.h. A sledgehammer approach > would be to remove float.h from the GCC package (we currently don't install > the float.h for the base system clang either). However, looking at this > in more detail, it seems that x86/include/float.h is also busted in some > ways. > > First, the #error I don't understand how it is happening. The GCC float.h > defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just > like the x86 float.h: > > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP > #define __LDBL_MAX_EXP__ 16384 > > I even hacked catrigl.c to add the following lines before the #error > check: > > LDBL_MAX_EXP_ = LDBL_MAX_EXP > LDBL_MANT_DIG_ = LDBL_MANT_DIG > > #if LDBL_MAX_EXP != 0x4000 > #error "Unsupported long double format" > #endif > > And the -E output is: > > DBL_MAX_EXP_ = 16384 > LDBL_MANT_DIG_ = 53 > > # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error > "U > nsupported long double format" > #error "Unsupported long double format" > ^ > > Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which > it must be since the x86 float.h uses '16384' not '0x4000' as the value). > Isn't this just the unsupported LDBL_MANT_DIG you're hitting here? Note line 93. I reused the same error message for LDBL_MAX_EXP :/ > However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the > initial FPU control word in sys/amd64/include/fpu.h that reads thus: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in > __LDBL_MANT_DIG__ being set to 53 instead of 64: > > /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the >compiler get the contents of and std::numeric_limits correct. */ > #undef TARGET_96_ROUND_53_LONG_DOUBLE > #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) > > clang seems unaware of this as it reports all the same values for > LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 > but not i386): > > # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep > 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.1897314953572316e+4932L > #define __LDBL_MIN__ 3.3621031431120935e-4932L > > The x86/include/float.h header though reports the MIN/MAX values somewhere > in between the two ranges for both amd64 and i386 while reporting an > LDBL_MANT_DIG of 64: > > #define LDBL_M
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-29, at 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 .] > > On 2018-Jun-29, at 10:38 AM, John Baldwin wrote: > >> On 6/28/18 7:54 PM, Mark Millard wrote: >>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >>> >>>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>>> >>>> . . . >>>> Later below expand the failing and previoly good commands, one >>>> option per line. The summary of the distinction in content is >>>> a one line difference, the working example ( -r335773 )had the >>>> option: >>>> >>>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>>> >>>> but the failing one did not. Working ( -r335773 ) is shown first. >>>> >>>> --- catrigl.o --- >>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>>> -DCOMPAT_32BIT >>>> -march=i686 >>>> -mmmx >>>> -msse >>>> -msse2 >>>> -m32 >>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>>> -O2 >>>> -pipe >>>> -I/workspace/src/lib/msun/x86 >>>> -I/workspace/src/lib/msun/ld80 >>>> -I/workspace/src/lib/msun/i387 >>>> -I/workspace/src/lib/msun/src >>>> -I/workspace/src/lib/libc/include >>>> -I/workspace/src/lib/libc/i386 >>>> . . . >>>> >>>> --- catrigl.o --- >>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>>> -DCOMPAT_32BIT >>>> -march=i686 >>>> -mmmx >>>> -msse >>>> -msse2 >>>> -m32 >>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>>> -O2 >>>> -pipe >>>> -I/workspace/src/lib/msun/x86 >>>> -I/workspace/src/lib/msun/ld80 >>>> -I/workspace/src/lib/msun/i387 >>>> -I/workspace/src/lib/msun/src >>>> -I/workspace/src/lib/libc/include >>>> -I/workspace/src/lib/libc/i386 >>>> . . . >>> >>> >>> For the report: >>> >>>> The xtoolchain GCC packages have not required these flags since ports >>>> commits r465416 and r466701 >>> >>> Looking at >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText >>> there is: >>> >>>> Updating FreeBSD repository catalogue... >>>> FreeBSD repository is up to date. >>>> All repositories are up to date. >>>> The following 6 package(s) will be affected (of 0 checked): >>>> >>>> New packages to be INSTALLED: >>>>amd64-xtoolchain-gcc: 0.4_1 >>>>amd64-gcc: 6.4.0 >>>>mpfr: 4.0.1 >>>>gmp: 6.1.2 >>>>mpc: 1.1.0_1 >>>>amd64-binutils: 2.30_3,1 >>> >>> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 >>> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). >>> >>> This indicates that -r465416 and -r466701 did not cause: >>> >>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> >>> to lead to include files being looked up in: >>> >>> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> >>> Thus there appears to still be a need for: >>> >>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> >>> unless more is done to the devel/*-gcc to make them look >>> in that additional place automatically (based on --sysroot). >> >> --sysroot does work, and you can verify it by doing the following: >> >> % touch empty.c >> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c >> Using built-in specs. >> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc >> Target: x86_64-unknown-freebsd11.2 >> ... >> ignoring
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> >>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>>> breaking-change was the following but I've not tried personal >>>> builds to confirm. >>>> ] > > So this is a bit complicated and I'm not sure what the correct fix is. > > What is happening is that the shipped with GCC is now being used > after this change instead of sys/x86/include/float.h. A sledgehammer approach > would be to remove float.h from the GCC package (we currently don't install > the float.h for the base system clang either). However, looking at this > in more detail, it seems that x86/include/float.h is also busted in some > ways. > > First, the #error I don't understand how it is happening. The GCC float.h > defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just > like the x86 float.h: > > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP > #define __LDBL_MAX_EXP__ 16384 > > I even hacked catrigl.c to add the following lines before the #error > check: > > LDBL_MAX_EXP_ = LDBL_MAX_EXP > LDBL_MANT_DIG_ = LDBL_MANT_DIG > > #if LDBL_MAX_EXP != 0x4000 > #error "Unsupported long double format" > #endif > > And the -E output is: > > DBL_MAX_EXP_ = 16384 > LDBL_MANT_DIG_ = 53 > > # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error > "U > nsupported long double format" > #error "Unsupported long double format" > ^ > > Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which > it must be since the x86 float.h uses '16384' not '0x4000' as the value). > Isn't this just the unsupported LDBL_MANT_DIG you're hitting here? Note line 93. I reused the same error message for LDBL_MAX_EXP :/ > However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the > initial FPU control word in sys/amd64/include/fpu.h that reads thus: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in > __LDBL_MANT_DIG__ being set to 53 instead of 64: > > /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the >compiler get the contents of and std::numeric_limits correct. */ > #undef TARGET_96_ROUND_53_LONG_DOUBLE > #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) > > clang seems unaware of this as it reports all the same values for > LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 > but not i386): > > # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep > 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.1897314953572316e+4932L > #define __LDBL_MIN__ 3.3621031431120935e-4932L > > The x86/include/float.h header though reports the MIN/MAX values somewhere > in between the two ranges for both amd64 and i386 while reporting an > LDBL_MANT_DIG of 64: > > #define LDBL_MANT_DIG 64 > #defi
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
[I expect this is more than just amd64-gcc related but that is all that ci.freebsd.org normally builds via a devel/*-gcc .] On 2018-Jun-29, at 10:38 AM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> >>> . . . >>> Later below expand the failing and previoly good commands, one >>> option per line. The summary of the distinction in content is >>> a one line difference, the working example ( -r335773 )had the >>> option: >>> >>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> >>> but the failing one did not. Working ( -r335773 ) is shown first. >>> >>> --- catrigl.o --- >>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>> -DCOMPAT_32BIT >>> -march=i686 >>> -mmmx >>> -msse >>> -msse2 >>> -m32 >>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> -O2 >>> -pipe >>> -I/workspace/src/lib/msun/x86 >>> -I/workspace/src/lib/msun/ld80 >>> -I/workspace/src/lib/msun/i387 >>> -I/workspace/src/lib/msun/src >>> -I/workspace/src/lib/libc/include >>> -I/workspace/src/lib/libc/i386 >>> . . . >>> >>> --- catrigl.o --- >>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc >>> -DCOMPAT_32BIT >>> -march=i686 >>> -mmmx >>> -msse >>> -msse2 >>> -m32 >>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> -O2 >>> -pipe >>> -I/workspace/src/lib/msun/x86 >>> -I/workspace/src/lib/msun/ld80 >>> -I/workspace/src/lib/msun/i387 >>> -I/workspace/src/lib/msun/src >>> -I/workspace/src/lib/libc/include >>> -I/workspace/src/lib/libc/i386 >>> . . . >> >> >> For the report: >> >>> The xtoolchain GCC packages have not required these flags since ports >>> commits r465416 and r466701 >> >> Looking at https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText >> there is: >> >>> Updating FreeBSD repository catalogue... >>> FreeBSD repository is up to date. >>> All repositories are up to date. >>> The following 6 package(s) will be affected (of 0 checked): >>> >>> New packages to be INSTALLED: >>> amd64-xtoolchain-gcc: 0.4_1 >>> amd64-gcc: 6.4.0 >>> mpfr: 4.0.1 >>> gmp: 6.1.2 >>> mpc: 1.1.0_1 >>> amd64-binutils: 2.30_3,1 >> >> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 >> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). >> >> This indicates that -r465416 and -r466701 did not cause: >> >> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >> >> to lead to include files being looked up in: >> >> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >> >> Thus there appears to still be a need for: >> >> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >> >> unless more is done to the devel/*-gcc to make them look >> in that additional place automatically (based on --sysroot). > > --sysroot does work, and you can verify it by doing the following: > > % touch empty.c > % x86_64-unknown-freebsd11.2-gcc -c -v empty.c > Using built-in specs. > COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc > Target: x86_64-unknown-freebsd11.2 > ... > ignoring nonexistent directory > "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" > ignoring nonexistent directory > "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include > /usr/include > End of search list. > ... > % x86_64-unknown-freebsd11.2-gcc -c -v
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/28/18 7:54 PM, Mark Millard wrote: > On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: > >> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >> >>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>> breaking-change was the following but I've not tried personal >>> builds to confirm. >>> ] So this is a bit complicated and I'm not sure what the correct fix is. What is happening is that the shipped with GCC is now being used after this change instead of sys/x86/include/float.h. A sledgehammer approach would be to remove float.h from the GCC package (we currently don't install the float.h for the base system clang either). However, looking at this in more detail, it seems that x86/include/float.h is also busted in some ways. First, the #error I don't understand how it is happening. The GCC float.h defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just like the x86 float.h: # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP #define __LDBL_MAX_EXP__ 16384 I even hacked catrigl.c to add the following lines before the #error check: LDBL_MAX_EXP_ = LDBL_MAX_EXP LDBL_MANT_DIG_ = LDBL_MANT_DIG #if LDBL_MAX_EXP != 0x4000 #error "Unsupported long double format" #endif And the -E output is: DBL_MAX_EXP_ = 16384 LDBL_MANT_DIG_ = 53 # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error "U nsupported long double format" #error "Unsupported long double format" ^ Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which it must be since the x86 float.h uses '16384' not '0x4000' as the value). However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the initial FPU control word in sys/amd64/include/fpu.h that reads thus: /* * The hardware default control word for i387's and later coprocessors is * 0x37F, giving: * * round to nearest * 64-bit precision * all exceptions masked. * * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc * because of the difference between memory and fpu register stack arguments. * If its using an intermediate fpu register, it has 80/64 bits to work * with. If it uses memory, it has 64/53 bits to work with. However, * gcc is aware of this and goes to a fair bit of trouble to make the * best use of it. * * This is mostly academic for AMD64, because the ABI prefers the use * SSE2 based math. For FreeBSD/amd64, we go with the default settings. */ #define __INITIAL_FPUCW__ 0x037F #define __INITIAL_FPUCW_I386__ 0x127F #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ #define __INITIAL_MXCSR__ 0x1F80 #define __INITIAL_MXCSR_MASK__ 0xFFBF GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in __LDBL_MANT_DIG__ being set to 53 instead of 64: /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the compiler get the contents of and std::numeric_limits correct. */ #undef TARGET_96_ROUND_53_LONG_DOUBLE #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) clang seems unaware of this as it reports all the same values for LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 but not i386): # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.1897314953572316e+4932L #define __LDBL_MIN__ 3.3621031431120935e-4932L The x86/include/float.h header though reports the MIN/MAX values somewhere in between the two ranges for both amd64 and i386 while reporting an LDBL_MANT_DIG of 64: #define LDBL_MANT_DIG 64 #define LDBL_MIN3.3621031431120935063E-4932L #define LDBL_MAX1.1897314953572317650E+4932L I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we should really be fixing our tree to work with compiler-provided language headers when at all possible. It's not clear to me if amd64 should be using the compiler provided values of things like LDBL_MIN/MAX either btw. -- John Baldwin ___ 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"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/28/18 7:54 PM, Mark Millard wrote: > On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: > >> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >> >>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>> breaking-change was the following but I've not tried personal >>> builds to confirm. >>> ] >>> >>> It looks to me that: >>> >>>> Author: jhb >>>> Date: Thu Jun 28 21:26:14 2018 >>>> New Revision: 335782 >>>> URL: >>>> https://svnweb.freebsd.org/changeset/base/335782 >>>> >>>> >>>> Log: >>>> Remove the various build flag hacks for GCC cross-compile. >>>> >>>> The xtoolchain GCC packages have not required these flags since ports >>>> commits r465416 and r466701. The in-tree GCC 4.2.1 has also been patched >>>> in r335716 and r335717 to correctly honor --sysroot when looking for >>>> includes and libraries. >>>> >>>> Reviewed by: bdrewery >>>> Sponsored by: DARPA / AFRL >>>> Differential Revision: >>>> https://reviews.freebsd.org/D16055 >>> . . . >>> >>> broke ci.freebsd.org's FreeBSD-head-amd64-gcc build. >>> >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText shows: >>> >>> --- catrigl.o --- >>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT -march=i686 >>> -mmmx -msse -msse2 -m32 >>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 >>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ >>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 -O2 >>> -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 >>> -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src >>> -I/workspace/src/lib/libc/include -I/workspace/src/lib/libc/i386 -g -MD >>> -MF.depend.catrigl.o -MTcatrigl.o -std=gnu99 -fstack-protector-strong >>> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-error=address >>> -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare >>> -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare >>> -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses >>> -Wno-error=strict-aliasing -Wno-error=uninitialized >>> -Wno-error=unused-but-set-variable -Wno-error=unuse d-function -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-unknown-pragmas -c /workspace/src/lib/msun/src/catrigl.c -o catrigl.o >>> /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long >>> double format" >>> #error "Unsupported long double format" >>> ^ >>> /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl': >>> /workspace/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared >>> (first use in this function) >>> w = clog_for_large_values(z) + m_ln2; >>> ^ >>> /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared >>> identifier is reported only once for each function it appears in >>> /workspace/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON' >>> undeclared (first use in this function) >>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) >>> ^~ >>> /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl': >>> /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared >>> (first use in this function) >>> ry = creall(w) + m_ln2; >>> ^ >>> /workspace/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON' >>> undeclared (first use in this function) >>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4) >>> ^~ >>> In file included from /workspace/src/lib/msun/src/catrigl.c:45:0: >>> /workspace/src/lib/msun/src/catrigl.c: In function 'clog_for_large_values': >>> /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared >>> (first use in this function) >>> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1, >>> ^ >
