http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054
--- Comment #2 from Evgeniy Dushistov ---
Yes, for C++ 2003 this is invalid code(page 212):
class A {
class B { };
friend class X;
};
class X : A::B { // ill-formed: A::B cannot be accessed
// in the base-clause for X
A::B mx; // OK: A::B used to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #14 from Bernd Edlinger ---
Martin,
Your patch is of course OK, but the MALLOC_ABI_ALIGNMENT is probably wrong too.
At least in targets with neon processor it should be raised to 64 bits.
If the malloc would really return 4 byte alig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58049
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|paolo.carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58044
--- Comment #1 from Jérôme Pouiller ---
AVX instructions seems to not been generated by assembler. Compiler directly
generate these instructions. Since -mavx2 is specified, compiler behaviour can
be considered correct. But, I don't see any case wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052
--- Comment #1 from Paolo Carlini ---
Not having spent a lot of time on this, I doubt it's a bug: the latest clang
and icc behave exactly like gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58049
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Bug ID: 58055
Summary: [meta-bug] RVO / NRVO improvements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58055
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58050
Paolo Carlini changed:
What|Removed |Added
Keywords||missed-optimization
Severity|no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051
Paolo Carlini changed:
What|Removed |Added
Keywords||missed-optimization
Severity|no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #3 from Marek Polacek ---
Note that with -O0:
d.c: In function ‘div3’:
d.c:102:3: error: inconsistent operand constraints in an ‘asm’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537
--- Comment #3 from fabien at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #1)
> Given the OK by Paolo, I retested the patch from:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01166.html
>
> It needed a small change to the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140
--- Comment #8 from fabien at gcc dot gnu.org ---
(In reply to Paolo Carlini from comment #7)
> Any news on this?
Sorry Paolo, no news. I will look into it after I resurrect some "stage one 1
material" patches on using decls (comming after c++/545
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056
Bug ID: 58056
Summary: ld segfaults when "-undefined dynamic_lookup" is set
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #4 from Uroš Bizjak ---
(In reply to Marek Polacek from comment #3)
> Note that with -O0:
> d.c: In function ‘div3’:
> d.c:102:3: error: inconsistent operand constraints in an ‘asm’
Just replace 32 with 32.0 as the asm operand.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #5 from Marek Polacek ---
Right, thanks, but then the ICE doesn't occur, so this makes it pretty much ICE
on invalid. Reduced nevertheless...
void
div3 (void)
{
double tmp1;
asm volatile ("fscale":"=t" (tmp1):"0" (0), "u" (0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #6 from Marek Polacek ---
...and -O is everything that's needed to trigger that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
fabien at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
Bug ID: 58057
Summary: gcc lexer cannot parse extern "\x43" void blah();
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
--- Comment #4 from Paolo Carlini ---
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58048
--- Comment #7 from Uroš Bizjak ---
Looking a bit into this problem:
A reload reg is inserted before "fscale" asm, but the chosen alternative can
move an immediate to memory directly.
Inserting insn reload before:
227: r184:SI=0x20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #4 from Vincent Lefèvre ---
I can see the same problem under Linux (gcc110.fsffrance.org).
According to the C standard (C99 and C11), the *_EPSILON values are "the
difference between 1 and the least value greater than 1 that is repres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #5 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #4)
> I can see the same problem under Linux (gcc110.fsffrance.org).
In case this wasn't clear, the architecture is also a PowerPC. The
double-double format comes f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010
Marek Polacek changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58008
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
--- Comment #1 from Paolo Carlini ---
Let's have this at hand, just c++98:
template
struct print_arg { };
struct const_holder {
static const int CONSTANT = 42;
};
template
struct identity {
typedef T type;
};
template
struct test_case :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
Paolo Carlini changed:
What|Removed |Added
CC||fabien at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58047
--- Comment #3 from Paolo Carlini ---
Seems closely related to PR37140.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Vincent Lefèvre ---
> (In reply to Vincent Lefèvre from comment #4)
>> I can see the same problem under Linux (gcc110.fsffrance.org).
>
> In case this wasn't clear,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|jason at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #7 from Vincent Lefèvre ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> Certainly not: IRIX isn't PowerPC but MIPS!
OK, that wasn't clear because the original but report mentioned:
"gcc.target/powerpc/rs6000-ldouble-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Vincent Lefèvre ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
>> Certainly not: IRIX isn't PowerPC but MIPS!
>
> OK, that wasn't clear because th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
schnoerr at mailzone dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
--- Comment #4 from Marek Polacek ---
Weird, even with -std=c++0x I still see no failures at all.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57987
--- Comment #5 from Martin Jambor ---
OK, so eventually I have posted the patch to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00074.html
Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
Bug ID: 58058
Summary: Memory leak with transfer function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #15 from Martin Jambor ---
I have submitted the patch to the mailing list for review:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00082.html
(In reply to Bernd Edlinger from comment #14)
> What I mean is, maybe the defautlt for MAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
schnoerr at mailzone dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolut
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
Paolo Carlini changed:
What|Removed |Added
CC|schnoerr at mailzone dot com |3dw4rd at verizon dot
net
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
--- Comment #8 from Paolo Carlini ---
Among the compilers I have at hand, only the latest Icc accepts this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58056
Andrew Pinski changed:
What|Removed |Added
Component|c++ |other
--- Comment #2 from Andrew Pinski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052
--- Comment #2 from Hubert Tong ---
(In reply to Paolo Carlini from comment #1)
> Not having spent a lot of time on this, I doubt it's a bug: the latest clang
> and icc behave exactly like gcc.
I had a vague recollection why I found the code weir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010
--- Comment #3 from Bill Schmidt ---
r189527 is probably a red herring. That just changed the cost model to be
turned on by default at -O3. Somebody who's actively working on the vectorizer
should probably have a look at this.
If you want to na
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #185 from Jan Hubicka ---
I merged in some patches intended to reduce memory of Firefox LTO and also
updated firefox tree. Some more involved patches are on the way, so it is
summary where we stand now.
WPA usage in TOP is 10GB now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059
Bug ID: 58059
Summary: gcc-4.7.2-r1 - g++: internal compiler error:
Segmentation fault (program cc1plus)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059
--- Comment #1 from Jacob McIntosh ---
Created attachment 30590
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30590&action=edit
preprocessed output
Generating this file crashed too:
$ gcc -v -save-temps -std=c++11 gcc_crash.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58059
--- Comment #2 from Jacob McIntosh ---
Oh, and of course, compilation yields nothing more than this:
$ g++ -std=c++11 gcc_crash.cc
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preproces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546
mib.bugzilla at gmail dot com changed:
What|Removed |Added
CC||mib.bugzilla at gmail dot c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57546
--- Comment #2 from mib.bugzilla at gmail dot com ---
I rerun this test today and the program segfaults.
Also get the same behavior (segfault) if the template is removed. I'll attach
the non-templated test case
g++ -v
Using built-in specs.
COLLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060
Bug ID: 58060
Summary: separate compilation of gnu multiversioning gives
undefined/multiple defined symbols at link time
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58060
--- Comment #1 from mib.bugzilla at gmail dot com ---
Created attachment 30593
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30593&action=edit
test case part 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
--- Comment #2 from janus at gcc dot gnu.org ---
I think the following should be enough to fix it:
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c(revi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57431
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #20 from Bill Schmidt ---
After thinking it over some more, I think you are right, Martin. We should go
ahead with the optimization with the corrected alignment attached to the type.
Please go ahead with your patch. I will run a rou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
--- Comment #9 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
I think I need to test for keyword in addition to testing for macro in
libcpp/lex.c
I'll look at this.
I'll also look at getting a better error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #23 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #22)
> We should be very wary of generating unaligned accesses during optimization
> for targets that define SLOW_UNALIGNED_ACCESS. And note that most
> architectures s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #21 from Bill Schmidt ---
My only comment on the patch would be to please add commentary indicating why
the change is being made, and referencing this PR. Something along the lines
of:
/* Ensure the memory reference carries the min
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58058
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58061
Bug ID: 58061
Summary: internal compiler error
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #186 from Jan Hubicka ---
oprofile of merging
6764713.0501 lto1 inflate_fast
38682 7.4624 lto1 compare_tree_sccs_1(tree_node*,
tree_node*, tree_node***)
32365 6.2437 lto1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548
--- Comment #2 from Paolo Carlini ---
What happened to the patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
Martin Jambor changed:
What|Removed |Added
Assignee|wschmidt at gcc dot gnu.org|jamborm at gcc dot
gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56014
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53756
Paolo Carlini changed:
What|Removed |Added
CC||jogojapan at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #25 from Bill Schmidt ---
Yep, that's terrific. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062
Bug ID: 58062
Summary: [C++11] bogus __func__ lookup in lambda body
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062
--- Comment #1 from Hubert Tong ---
Compiler invocation was:
g++ -std='c++11' main.cpp -Wall -Wextra -pedantic -c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
--- Comment #10 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
No, I remember now. This code *cannot* be right.
With the addition of user-defined literals in C++11 and DR1473
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548
--- Comment #3 from Sriraman Tallam ---
(In reply to Paolo Carlini from comment #2)
> What happened to the patch?
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00426.html
Patch has been submitted on Jun 7 in rev. 199842 to trunk. Sorry for not
upd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58057
--- Comment #11 from Paolo Carlini ---
Ed, your analysis matches my intuition, but the error message is still very
poor: to the user something like "... before STRING_USERDEF..." makes no sense
at all. Can we improve it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57548
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #26 from Bill Schmidt ---
Martin's patch bootstrapped on powerpc64-unknown-linux-gnu with no new
regressions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58054
--- Comment #3 from Evgeniy Dushistov ---
Here history of changes of C++ standard that related to this bug:
http://wg21.cmeerw.net/cwg/issue372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
Bug ID: 58063
Summary: default arguments evaluated twice per call
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #7 from François Dumont ---
I had a try and the result is not good. I attached the modified implementation
if you want to have a try even if it is not perfect cause there are some
exception safety issue.
With the current implementatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
François Dumont changed:
What|Removed |Added
CC||fdumont at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57840
--- Comment #2 from François Dumont ---
Created attachment 30596
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30596&action=edit
The modified hashtable implementation
To replace hashtable.h in include/bits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #8 from Paolo Carlini ---
Francois, you attached to the wrong bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58064
Bug ID: 58064
Summary: Cannot compile gcc-4.8.1 by gcc-3.4.6
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
Bug ID: 58065
Summary: ARM MALLOC_ABI_ALIGNMENT is wrong
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #1 from Bernd Edlinger ---
Created attachment 30598
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30598&action=edit
test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #2 from Bernd Edlinger ---
Created attachment 30599
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30599&action=edit
compiler output without this patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #3 from Bernd Edlinger ---
Created attachment 30600
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30600&action=edit
correct compiler output with patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
--- Comment #4 from Bernd Edlinger ---
Created attachment 30601
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30601&action=edit
Proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #16 from Bernd Edlinger ---
(In reply to Martin Jambor from comment #15)
> Anyway, the policy of GCC
> seems to be that the default of MALLOC_ABI_ALIGNMENT is ultra-safe and
> targets should override it. So I would suggest, again :-),
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
Bug ID: 58066
Summary: GCC mis-compiles access to TLS variable with -fPIC on
x86_64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #1 from Andrew Pinski
s with -fpic and -mcmodel=large
with GCC 4.8.0 up through the current trunk (20130802) I get an internal
compiler error. This looks rather similar to PR56797 but that particular bug
seems to have been only on ARM and this occurs on x86_64. So it may be that
PR56797 is more expansive than initially tho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
--- Comment #2 from Paul Pluzhnikov ---
(In reply to Andrew Pinski from comment #1)
> Which most Linux distro default to anyways ...
Ubuntu 12.04.1 LTS doesn't.
Configuring trunk GCC on it doesn't default to GNU2 TLS either.
What is the way to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58068
Bug ID: 58068
Summary: ICE in execute_strength_reduction at -O3 (both 32-bit
and 64-bit modes)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
1 - 100 of 103 matches
Mail list logo
