Re: How to insist on only clang, for world/kernel?

2016-03-13 Thread Chris H 
On Sun, 13 Mar 2016 17:32:55 -0600 Warner Losh  wrote

> 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.

2016-03-13 Thread Steve Kargl 
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.

2016-03-13 Thread Steve Kargl 
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.

2016-03-13 Thread Dimitry Andric 
On 13 Mar 2016, at 21:10, Steve Kargl  wrote:
> 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?

2016-03-13 Thread Warner Losh 
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 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
>
> --
>
>
>
___
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.

2016-03-13 Thread Steve Kargl 
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.

2016-03-13 Thread Steve Kargl 
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)

2016-03-13 Thread bugzilla-noreply 
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)

2016-03-13 Thread bugzilla-noreply 
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)

2016-03-13 Thread bugzilla-noreply 
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)

2016-03-13 Thread bugzilla-noreply 
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)

2016-03-13 Thread bugzilla-noreply 
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)

2016-03-13 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207837

Jan Beich  changed:

   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)

2016-03-13 Thread bugzilla-noreply 
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"