Re: How to insist on only clang, for world/kernel?
On Sun, 13 Mar 2016 17:32:55 -0600 Warner Loshwrote > Then you may be able to do make buildworld CC=clang (or whatever clang is > compiled as. > No guarantee, sine I've not played with 9.x in a while. > > Warner Apologies. Appears my response wasn't clear. I had no difficulties getting clang (and only clang) by placing your suggestions in src.conf(5). Whereas prior to those, I got gcc as cc. Thanks again, Warner. > > > On Fri, Mar 11, 2016 at 8:20 AM, Chris H wrote: > > > On Thu, 10 Mar 2016 21:49:01 -0700 Warner Losh wrote > > > > > make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y > > > WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t > > > make buildkernel > > > > > > But that's mostly default these days, so really most people get what you > > > want by doing > > > > > > make buildworld buildkernel > > > > > > Warner > > Thanks for the quick reply, Warner! > > This is on RELENG_9, so I *don't* get that by default. ;) > > But true. Everything else I run in on -CURRENT, and indeed gets > > the options you indicate above out-of-the-box. > > > > Thanks again, Warner. > > > > > > On Thu, Mar 10, 2016 at 9:23 PM, Chris H wrote: > > > > > > > Greetings, > > > > A recent build/install world/kernel on a fresh 9-STABLE. > > > > I was surprised to see that, while clang was also built, > > > > gcc was used to perform the build for at least world. > > > > I performed some research to definitively determine the > > > > magic incantation for at least src.conf(5). However, I > > > > found too many possibilities to be sure. So I'm here > > > > to beg for the answer. > > > > > > > > The most likely candidates I have so far > > > > > > > > FAVORITE_COMPILER=clang > > > > MAKE_COMPILER_TYPE=clang > > > > WITH_CLANG=true > > > > CC=clang > > > > CXX=clang++ > > > > CPP=clang-cpp > > > > > > > > Thanks you. > > > > > > > > --Chris > > > > -- > > > > > > --Chris -- ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang gets numerical underflow wrong, please fix.
On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote: > > $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 1024 iterations > $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 16384 iterations > Change the program to #include #include int main(void) { int i; float x = 1.f; i = 0; feclearexcept(FE_ALL_EXCEPT); do { x *= 2; i++; printf("%d %e\n", i, x); } while(!fetestexcept(FE_OVERFLOW)); if (fetestexcept(FE_OVERFLOW)) printf("FE_UNDERFLOW: "); printf("x = %e after %d iterations\n", x, i); return 0; } You'll get a bunch of invalid output before the OVERFLOW. % cc -O -o z b.c -lm && ./z | tail 1016 7.022239e+305 <-- not a valid float 1017 1.404448e+306 <-- not a valid float 1018 2.808896e+306 <-- not a valid float 1019 5.617791e+306 <-- not a valid float 1020 1.123558e+307 <-- not a valid float 1021 2.247116e+307 <-- not a valid float 1022 4.494233e+307 <-- not a valid float 1023 8.988466e+307 <-- not a valid float 1024 inf FE_UNDERFLOW: x = inf after 1024 iterations Clang is broken with or without #pragma FENV_ACCESS "on". -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang gets numerical underflow wrong, please fix.
On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote: > On 13 Mar 2016, at 21:10, Steve Kargl> wrote: > > Thanks for the quick reply. But, it must be using an 80-bit > > extended double instead of a double for storage. This variation > > > > #include > > #include > > > > int > > main(void) > > { > > int i; > > // float x = 1.f; > > double x = 1.; > > i = 0; > > feclearexcept(FE_ALL_EXCEPT); > > do { > > x /= 2; > > i++; > > } while(!fetestexcept(FE_UNDERFLOW)); > > if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); > > printf("x = %e after %d iterations\n", x, i); > > > > return 0; > > } > > > > yields > > > > % cc -O -o z b.c -lm && ./z > > FE_UNDERFLOW: x = 0.00e+00 after 16435 iterations > > > > It should be 1075 iterations. > > > > Note, there is a similar issue with OVERFLOW. The upshot is > > that clang on current is probably miscompiling libm. > > With this example, I also get different results from gcc (4.8.5), > depending on the optimization level: > > $ gcc -O underflow-iter.c -o underflow-iter-gcc -lm > $ ./underflow-iter-gcc > FE_UNDERFLOW: x = 0.00e+00 after 1075 iterations > $ gcc -O2 underflow-iter.c -o underflow-iter-gcc -lm > $ ./underflow-iter-gcc > FE_UNDERFLOW: x = 0.00e+00 after 16435 iterations > > Similar for the overflow case: > > $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 1024 iterations > $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 16384 iterations > > Are we depending on some sort of subtle undefined behavior here? I don't know. From n1256.pdf, 6.5.5, I can find The result of the binary * operator is the product of the operands. I can't find what happens when one operand is DBL_MAX and the other is greater than 1. The result is clearly an overflow condition. Annex F is normative text, which defers to IEC 60559. F.3 states -- The +, -, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations. Annex F contains alot of text about "#pragma STDC FENV_ACCESS ON", but of course neither gcc nor clang implement this pragma. In particular, in F.8.1 one has Floating-point arithmetic operations ... may entail side effects which optimization shall honor, at least where the state of the FENV_ACCESS pragma is ``on''. The flags ... in the floating-point environment may be regarded as global variables; floating-point operations (+, *, etc.) implicitly ... write the flags. However, F.7.1 has F.7.1 Environment management IEC 60559 requires that floating-point operations implicitly raise floating-point exception status flags, ... When the state for the FENV_ACCESS pragma (defined in ) is ``on'', these changes to the floating-point state are treated as side effects which respect sequence points.313) 313) If the state for the FENV_ACCESS pragma is ``off'', the implementation is free to assume the floating-point control modes will be the default ones and the floating-point status flags will not be tested, which allows certain optimizations (see F.8). So, I'm guessing clang/llvm developers aer going to claim that the lack of implementation of the FENV_ACCESS pragme means "off". So, clang is unsuitable for real floating-point development. -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang gets numerical underflow wrong, please fix.
On 13 Mar 2016, at 21:10, Steve Karglwrote: > On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote: ... >> So it's storing the intermediate result in a double, for some reason. >> The fnstsw will then result in zero, since there was no underflow at >> that point. >> >> I will submit a bug for this upstream, thanks for the report. Submitted upstream as: https://llvm.org/bugs/show_bug.cgi?id=26931 > Thanks for the quick reply. But, it must be using an 80-bit > extended double instead of a double for storage. This variation > > #include > #include > > int > main(void) > { > int i; > // float x = 1.f; > double x = 1.; > i = 0; > feclearexcept(FE_ALL_EXCEPT); > do { > x /= 2; > i++; > } while(!fetestexcept(FE_UNDERFLOW)); > if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); > printf("x = %e after %d iterations\n", x, i); > > return 0; > } > > yields > > % cc -O -o z b.c -lm && ./z > FE_UNDERFLOW: x = 0.00e+00 after 16435 iterations > > It should be 1075 iterations. > > Note, there is a similar issue with OVERFLOW. The upshot is > that clang on current is probably miscompiling libm. With this example, I also get different results from gcc (4.8.5), depending on the optimization level: $ gcc -O underflow-iter.c -o underflow-iter-gcc -lm $ ./underflow-iter-gcc FE_UNDERFLOW: x = 0.00e+00 after 1075 iterations $ gcc -O2 underflow-iter.c -o underflow-iter-gcc -lm $ ./underflow-iter-gcc FE_UNDERFLOW: x = 0.00e+00 after 16435 iterations Similar for the overflow case: $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm $ ./overflow-iter-gcc FE_OVERFLOW: x = inf after 1024 iterations $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm $ ./overflow-iter-gcc FE_OVERFLOW: x = inf after 16384 iterations Are we depending on some sort of subtle undefined behavior here? With -O, the 'main loop' becomes: .L3: fld1 fstpl 24(%esp) movl$0, %ebx .L8: fldl24(%esp) fld %st(0) faddp %st, %st(1) fstpl 24(%esp) addl$1, %ebx fnstsw %ax movl%eax, %esi movl__has_sse, %eax testl %eax, %eax je .L4 cmpl$2, %eax jne .L5 call__test_sse testl %eax, %eax je .L5 .L4: stmxcsr 44(%esp) jmp .L6 .L5: movl$0, 44(%esp) .L6: orl 44(%esp), %esi testl $8, %esi je .L8 With -O2, it becomes: .L3: fld1 xorl%ebx, %ebx .L12: fadd%st(0), %st addl$1, %ebx fnstsw %ax testl %edx, %edx movl%eax, %esi je .L10 cmpl$2, %edx je .L27 .L9: xorl%eax, %eax .L8: orl %eax, %esi andl$8, %esi je .L12 So it switches from using faddp and fstpl to direct fadd of %st(0) and %st. I assume that uses the internal 80 bit precision? Gcc also manages to move the __has_sse stuff out to further down in the function, but it does not really affect the result. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: How to insist on only clang, for world/kernel?
Then you may be able to do make buildworld CC=clang (or whatever clang is compiled as. No guarantee, sine I've not played with 9.x in a while. Warner On Fri, Mar 11, 2016 at 8:20 AM, Chris Hwrote: > On Thu, 10 Mar 2016 21:49:01 -0700 Warner Losh wrote > > > make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y > > WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t > > make buildkernel > > > > But that's mostly default these days, so really most people get what you > > want by doing > > > > make buildworld buildkernel > > > > Warner > Thanks for the quick reply, Warner! > This is on RELENG_9, so I *don't* get that by default. ;) > But true. Everything else I run in on -CURRENT, and indeed gets > the options you indicate above out-of-the-box. > > Thanks again, Warner. > > > > On Thu, Mar 10, 2016 at 9:23 PM, Chris H wrote: > > > > > Greetings, > > > A recent build/install world/kernel on a fresh 9-STABLE. > > > I was surprised to see that, while clang was also built, > > > gcc was used to perform the build for at least world. > > > I performed some research to definitively determine the > > > magic incantation for at least src.conf(5). However, I > > > found too many possibilities to be sure. So I'm here > > > to beg for the answer. > > > > > > The most likely candidates I have so far > > > > > > FAVORITE_COMPILER=clang > > > MAKE_COMPILER_TYPE=clang > > > WITH_CLANG=true > > > CC=clang > > > CXX=clang++ > > > CPP=clang-cpp > > > > > > Thanks you. > > > > > --Chris > > -- > > > ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang gets numerical underflow wrong, please fix.
On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote: > On 13 Mar 2016, at 19:25, Steve Kargl> wrote: > > > > Consider this small piece of code: > > > > #include > > #include > > > > float > > foo() > > { > > static const volatile float tiny = 1.e-30f; > > return (tiny * tiny); > > } > > > > int > > main(void) > > { > > float x; > > feclearexcept(FE_ALL_EXCEPT); > > x = foo(); > > if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); > > printf("x = %e\n", x); > > return 0; > > } > > > > clang seems to get the underflow condition wrong. > > > > % cc -o z a.c -lm && ./z > > FE_UNDERFLOW: x = 0.00e+00 > > > > % cc -O -o z a.c -lm && ./z > > x = 1.00e-60 <--- This is not a possible value! > > > > % gcc -o z a.c -lm && ./z > > FE_UNDERFLOW: x = 0.00e+00 > > > > % gcc -O -o z a.c -lm && ./z > > FE_UNDERFLOW: x = 0.00e+00 > > Hmm, this is an interesting one. On amd64, it works as expected with > clang, but there it always uses SSE, obviously: > > $ ./underflow-amd64 > FE_UNDERFLOW: x = 0.00e+00 > > The problem seems to be caused by the intermediate result being stored > using fstpl instead of fstps, e.g. simplifying the sample program (to > get rid of all the SSE stuff the fexxx() macros insert): > > int main(void) > { > float x; > __uint16_t status; > __fnclex(); > x = foo(); > __fnstsw(); > printf("status: %#x\n", (unsigned)status); > printf("x = %e\n", x); > return 0; > } > > With gcc, the assembly becomes: > > foo: > fldstiny.1853 > fldstiny.1853 > fmulp %st, %st(1) > ret > [...] > main: > [...] > fnclex > callfoo > fstps 12(%esp) > fnstsw %ax > > In this case, fmulp does not generate an underflow, but the fstps will. > With clang, the assembly becomes: > > foo: > fldsfoo.tiny > fmuls foo.tiny > retl > [...] > main: > subl$24, %esp > fnclex > calll foo > fstpl 12(%esp)# 8-byte Folded Spill > fnstsw 22(%esp) > > So it's storing the intermediate result in a double, for some reason. > The fnstsw will then result in zero, since there was no underflow at > that point. > > I will submit a bug for this upstream, thanks for the report. > Thanks for the quick reply. But, it must be using an 80-bit extended double instead of a double for storage. This variation #include #include int main(void) { int i; // float x = 1.f; double x = 1.; i = 0; feclearexcept(FE_ALL_EXCEPT); do { x /= 2; i++; } while(!fetestexcept(FE_UNDERFLOW)); if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); printf("x = %e after %d iterations\n", x, i); return 0; } yields % cc -O -o z b.c -lm && ./z FE_UNDERFLOW: x = 0.00e+00 after 16435 iterations It should be 1075 iterations. Note, there is a similar issue with OVERFLOW. The upshot is that clang on current is probably miscompiling libm. -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
clang gets numerical underflow wrong, please fix.
Consider this small piece of code: #include #include float foo() { static const volatile float tiny = 1.e-30f; return (tiny * tiny); } int main(void) { float x; feclearexcept(FE_ALL_EXCEPT); x = foo(); if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); printf("x = %e\n", x); return 0; } clang seems to get the underflow condition wrong. % cc -o z a.c -lm && ./z FE_UNDERFLOW: x = 0.00e+00 % cc -O -o z a.c -lm && ./z x = 1.00e-60 <--- This is not a possible value! % gcc -o z a.c -lm && ./z FE_UNDERFLOW: x = 0.00e+00 % gcc -O -o z a.c -lm && ./z FE_UNDERFLOW: x = 0.00e+00 % uname -a FreeBSD laptop-kargl 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296724: Sun Mar 13 09:12:38 PDT 2016 % cc --version FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) % gcc --version gcc (FreeBSD Ports Collection) 4.8.5 -- Steve ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #16 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sun Mar 13 18:32:18 UTC 2016 New revision: 296801 URL: https://svnweb.freebsd.org/changeset/base/296801 Log: Pull in r219512 from upstream llvm trunk (by Hal Finkel): [MiSched] Fix a logic error in tryPressure() Fixes a logic error in the MachineScheduler found by Steve Montgomery (and confirmed by Andy). This has gone unfixed for months because the fix has been found to introduce some small performance regressions. However, Andy has recommended that, at this point, we fix this to avoid further dependence on the incorrect behavior (and then follow-up separately on any regressions), and I agree. Fixes PR18883. This fixes a possible "ran out of registers" error when compiling www/firefox 45.0 on i386. Direct commit to stable/9, because head already has this fix since the llvm/clang 3.6.0 import. PR: 207837 Changes: stable/9/contrib/llvm/lib/CodeGen/MachineScheduler.cpp -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #14 from Jan Beich--- (In reply to Dimitry Andric from comment #13) OPTIMIZED_CFLAGS is enabled by default. It doesn't pass just -O3 but also --enable-optimize which lets vendor decide whether to pass -fomit-frame-pointer and (in later versions) rust -O. https://dxr.mozilla.org/mozilla-central/search?q=MOZ_OPTIMIZE -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #12 from Dimitry Andric--- Strangely, I tried building www/firefox on stable/10, from before r410973 was applied, and it builds just fine for me, even the problematic Unified_cpp_protocol_websocket0.cpp file. I'm unsure what is different in my environment from the original submitter, though. This is on pretty plain stable/10 r294049, as of 2016-01-21. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #10 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Mar 13 15:17:03 UTC 2016 New revision: 410995 URL: https://svnweb.freebsd.org/changeset/ports/410995 Log: MFH: r410973 www/firefox: work around Clang 3.4 crash with OPTIMIZED_CFLAGS=off Pretend we want C++14 to pull more modern version of Clang on 10.x i386. PR: 207837 Approved by: ports-secteam (junovitch) Changes: _U branches/2016Q1/ branches/2016Q1/Mk/bsd.gecko.mk -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #9 from commit-h...@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Mar 13 14:42:59 UTC 2016 New revision: 410973 URL: https://svnweb.freebsd.org/changeset/ports/410973 Log: www/firefox: work around Clang 3.4 crash with OPTIMIZED_CFLAGS=off Pretend we want C++14 to pull more modern version of Clang on 10.x i386. PR: 207837 MFH: 2016Q1 Changes: head/Mk/bsd.gecko.mk -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 Jan Beichchanged: What|Removed |Added CC||jbe...@freebsd.org --- Comment #8 from Jan Beich --- (In reply to Vikash Badal from comment #7) > ---Begin OPTIONS List--- > [...] > OPTIMIZED_CFLAGS=off: Use extra compiler optimizations $ make config -C /usr/ports/www/firefox I'll add a workaround later via USES=compiler:c++14-lang. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837 --- Comment #7 from Vikash Badal--- (In reply to Jan Beich from comment #3) I tried adding OPTIMIZED_CFLAGS=on to the make.conf for the poudriere jail ---Begin make.conf--- MACHINE=i386 MACHINE_ARCH=i386 ARCH=${MACHINE_ARCH} USE_PACKAGE_DEPENDS=yes BATCH=yes WRKDIRPREFIX=/wrkdirs PORTSDIR=/usr/ports PACKAGES=/packages DISTDIR=/distfiles /usr/local/etc/poudriere.d/RELENG_10_2_i386-make.conf WITH_PKGNG=yes WITH_GALLIUM="yes" DEFAULT_VERSIONS=apache=2.2 php=5.6 OPTIMIZED_CFLAGS=on still fails full log: http://anger.where-ever.za.net/~vikashb/firefox-45.0_3,1-OPTIMIZED_CFLAGS_off.log not sure if i missed the plot here -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"