http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
chrbr at gcc dot gnu.org changed:
What|Removed |Added
CC||chrbr at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646
--- Comment #5 from Janne Blomqvist 2012-04-18 08:31:47
UTC ---
Another build problem at
http://stackoverflow.com/questions/10202966/android-ndk-fortran-build-of-lapack-problems-with-unresolved-sincos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027
Bug #: 53027
Summary: pointer_traits<>::rebind is private
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53027
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
--- Comment #21 from Manfred Schwarb 2012-04-18
09:01:46 UTC ---
This new version does fix it, timings are around 0.2s for the
above test-case (exactly as fast as the user-optimized len_trim
variant). Thanks a lot!
However, I don't see why this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52108
--- Comment #2 from Petr Ovtchenkov
2012-04-18 09:09:04 UTC ---
There are opinion, that this is not a bug:
http://llvm.org/bugs/show_bug.cgi?id=12583
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
Bug #: 53028
Summary: add dg-pedantic
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53026
--- Comment #2 from mattipee at yahoo dot co.uk 2012-04-18 09:32:16 UTC ---
The code was many hundreds of lines long, but I've stripped it down to fewer
than 40 lines with which I can reliably reproduce the ICE.
user@host:~$ g++ -v --save-temps -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #8 from Paolo Carlini 2012-04-18
09:34:16 UTC ---
Ok, let's not touch the branch for the time being. If you can figure out other
fixes on top of the first one, please let us know (preferably, on the mailing
list).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53026
Paolo Carlini changed:
What|Removed |Added
Status|WAITING |NEW
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024
Richard Guenther changed:
What|Removed |Added
Keywords||documentation
Status|UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53022
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52422
--- Comment #3 from paolo at gcc dot gnu.org
2012-04-18 10:21:52 UTC ---
Author: paolo
Date: Wed Apr 18 10:21:43 2012
New Revision: 186565
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186565
Log:
/cp
2012-04-18 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53021
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #9 from chrbr at gcc dot gnu.org 2012-04-18 10:23:57 UTC ---
Created attachment 27181
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27181
test ?
For the record, here is the modified version of the test I'm playing with.
compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52422
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52108
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50478
--- Comment #5 from Paolo Carlini 2012-04-18
10:35:59 UTC ---
Seems fixed in mainline.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976
Richard Guenther changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688
--- Comment #8 from Richard Guenther 2012-04-18
11:34:01 UTC ---
Author: rguenth
Date: Wed Apr 18 11:33:51 2012
New Revision: 186566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186566
Log:
2012-04-18 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
Paolo Carlini changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #11 from Paolo Carlini 2012-04-18
12:01:27 UTC ---
Of course I meant it doesn't *link*. I guess I have never noticed this error
before:
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #12 from Iain Sandoe 2012-04-18 12:08:55
UTC ---
(In reply to comment #11)
> Of course I meant it doesn't *link*. I guess I have never noticed this error
> before:
>
> /usr/bin/ld: cannot find -lm
> /usr/bin/ld: cannot find -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #14 from Paolo Carlini 2012-04-18
12:19:04 UTC ---
But anyway -static-libstdc++ works on Linux too to avoid the link-time problem.
Still (on x86_64-linux) the testcase runs Ok for me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30006
Marty changed:
What|Removed |Added
CC||vadmium+gc at gmail dot com
--- Comment #3 from M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976
--- Comment #16 from William J. Schmidt
2012-04-18 12:25:30 UTC ---
Author: wschmidt
Date: Wed Apr 18 12:25:17 2012
New Revision: 186567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186567
Log:
gcc:
2012-04-18 Bill Schmidt
PR t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #15 from Iain Sandoe 2012-04-18 12:31:06
UTC ---
(In reply to comment #14)
> But anyway -static-libstdc++ works on Linux too to avoid the link-time
> problem.
> Still (on x86_64-linux) the testcase runs Ok for me.
OK.
Just for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #16 from chrbr at gcc dot gnu.org 2012-04-18 12:37:47 UTC ---
(In reply to comment #14)
> But anyway -static-libstdc++ works on Linux too to avoid the link-time
> problem.
> Still (on x86_64-linux) the testcase runs Ok for me.
Interes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
--- Comment #8 from Michal Hlavinka 2012-04-18
12:22:34 UTC ---
Created attachment 27182
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27182
pre-processed reproducer (avr)
(In reply to comment #7)
> Would you please post a complete test ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976
--- Comment #17 from William J. Schmidt
2012-04-18 12:29:39 UTC ---
Author: wschmidt
Date: Wed Apr 18 12:29:23 2012
New Revision: 186568
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186568
Log:
gcc:
2012-04-18 Bill Schmidt
PR t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
--- Comment #3 from Paolo Carlini 2012-04-18
12:52:04 UTC ---
Interestingly, removing the const from the move assignment avoids the issue
with -pedantic.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029
Bug #: 53029
Summary: missed optimization in internal read (without
implied-do-loop)
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446
Marty changed:
What|Removed |Added
CC||vadmium+gc at gmail dot com
--- Comment #3 from M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47772
Marty changed:
What|Removed |Added
CC||vadmium+gc at gmail dot com
--- Comment #3 from M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51646
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52693
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #17 from Jonathan Wakely 2012-04-18
12:43:00 UTC ---
does it help if you link to libpthread using --whole-archive ?
g++ deallocate_global_thread-1.cc -static -Wl,--whole-archive -lpthread
-Wl,--no-whole-archive -lrt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47772
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
--- Comment #4 from Paolo Carlini 2012-04-18
13:01:37 UTC ---
And this is enough to see the inconsistency vs -pedantic:
#include
#include
struct proxy
{
void operator=(int const&);
void operator=(int &&) const;
};
int main()
{
assert(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #18 from Jonathan Wakely 2012-04-18
12:57:15 UTC ---
(In reply to comment #16)
> by the way, (not the bug), I'm wondering if there is another way than
> using pthread_key_create to hold the thread's freelist ? like using TLS in the
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446
Manuel López-Ibáñez changed:
What|Removed |Added
CC||darren at kulp dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #20 from chrbr at gcc dot gnu.org 2012-04-18 13:32:31 UTC ---
(In reply to comment #17)
> does it help if you link to libpthread using --whole-archive ?
>
> g++ deallocate_global_thread-1.cc -static -Wl,--whole-archive -lpthread
> -Wl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30006
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36446
Manuel López-Ibáñez changed:
What|Removed |Added
CC||darren at kulp dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681
--- Comment #5 from Matt Kline 2012-04-18 14:04:37
UTC ---
That, if feasible, would be perfect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
Paolo Carlini changed:
What|Removed |Added
CC||daniel.kruegler at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #21 from Jonathan Wakely 2012-04-18
14:02:37 UTC ---
(In reply to comment #20)
> now it worked for Paolo without it :-(
Some distros rebuild libpthread.a to make it work automatically.
http://lists.opensuse.org/opensuse-bugs/2010-07
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
--- Comment #5 from Paolo Carlini 2012-04-18
13:29:10 UTC ---
Oh, and isn't really a run-time issue:
#include
struct proxy
{
void operator=(int const&);
void operator=(int &&) const;
};
static_assert( std::is_assignable::value, "" );
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #19 from Paolo Carlini 2012-04-18
13:10:59 UTC ---
At the moment I'm using an x86_64-linux machine using glibc 2.14.1, not a RH,
really no problem with this specific testcase, no Seg fault, no valgrind
errors, with 4.7.1 too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #22 from Paolo Carlini 2012-04-18
14:14:37 UTC ---
To be clear: for some reason, on my Linux machine, I badly need
-static-libstdc++, what suggested by Jon in Comment #17 doesn't change much. If
code compiles and links then runs fine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47762
--- Comment #23 from Paolo Carlini 2012-04-18
14:24:47 UTC ---
Ah, thanks Jon, that may indeed explain it!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52681
--- Comment #6 from Jonathan Wakely 2012-04-18
14:16:20 UTC ---
Entirely feasible, and probably safe enough for the 4.6 and 4.7 branches too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53016
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53030
Bug #: 53030
Summary: [4.8 Regression] LTO bootstrap failed with
bootstrap-profiled
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
--- Comment #8 from Daniel Krügler
2012-04-18 14:41:38 UTC ---
(In reply to comment #7)
> Daniel, can you have a look to snippet in Comment #5? Should it compile or
> not?
It needed a while until I recognized that the second operator= overload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53031
Bug #: 53031
Summary: [4.8 Regression] gcc.dg/tree-ssa/vrp54.c
scan-tree-dump-not vrp1 "link_error"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53032
Bug #: 53032
Summary: [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to
build
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
--- Comment #9 from Paolo Carlini 2012-04-18
14:59:02 UTC ---
Ah, thanks Daniel. Therefore the situation is becoming more clear.
Then - assuming this interpretation is correct - I'm not sure what we want to
do from a practical point of view: sho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
--- Comment #10 from Jason Merrill 2012-04-18
15:14:58 UTC ---
std::is_assignable uses SFINAE, so it should always act pedantic, and the
assert should fail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52363
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|paolo.carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015
--- Comment #3 from brainschrat at gmx dot de 2012-04-18 15:22:01 UTC ---
Maybe this is related to using both -I and -J to the same directory.
As I wanted to use delta, I tried to simplify my folder layout for the test
case:
project
- src
- lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43833
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29467
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32960
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33443
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33715
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Target|i686-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878
--- Comment #5 from Mikael Pettersson 2012-04-18
16:38:18 UTC ---
Created attachment 27183
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27183
combined patch
I've combined HJ's two patches to one and verified that it restores bootstrap
on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34455
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44600
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42689
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33715
--- Comment #3 from Jonathan Wakely 2012-04-18
16:53:37 UTC ---
(In reply to comment #0)
> I would like to have a warning in C++ that warns about local variables
> assigned
> via operator new or operator new[], but then are not freed in an excep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
--- Comment #5 from Jonathan Wakely 2012-04-18
17:01:23 UTC ---
(In reply to comment #3)
> First, I think the C++ standard forbids a function from having a null
> address:
But GCC extensions allow it, see the weakref attribute:
http://gcc.gnu.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925
--- Comment #6 from Jonathan Wakely 2012-04-18
17:04:25 UTC ---
... That's not an argument against improving the warning though. GCC's uses
occur in system headers so warnings are suppressed, and could be worked around
anyway with further extens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878
--- Comment #6 from Eric Botcazou 2012-04-18
17:23:24 UTC ---
> I've combined HJ's two patches to one and verified that it restores bootstrap
> on sparc64-linux.
But it probably breaks SPARC/Solaris, as TARGET_LONG_DOUBLE_128 must be
non-zero fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52878
--- Comment #7 from H.J. Lu 2012-04-18 17:32:38
UTC ---
If someone can provide a description of what TARGET_LONG_DOUBLE_128
should be in all cases, I can try to come up with a patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #2 from Mike Stump 2012-04-18
17:35:23 UTC ---
I don't see much value in this. The primary idea of the gcc testsuite is as a
regression suite. For a regression, there is just one bit of code that you're
testing, with one set of opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53008
--- Comment #1 from Dave Boutcher 2012-04-18
17:46:17 UTC ---
The problem seems to be that functions referenced only by function pointers are
not put in the tmclone table. I can work around the problem by making a bogus
call to the function anyw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52985
--- Comment #2 from Will Benfold 2012-04-18 18:08:16
UTC ---
Another test case; this one doesn't need any headers and also cuts out the
loop. The exit status should always be 1, but in fact it's 0 if no
command-line args are supplied and 1 other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #3 from Manuel López-Ibáñez 2012-04-18
18:25:46 UTC ---
(In reply to comment #2)
> I don't see much value in this. The primary idea of the gcc testsuite is as a
> regression suite. For a regression, there is just one bit of code tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
--- Comment #3 from janus at gcc dot gnu.org 2012-04-18 19:38:10 UTC ---
To implement this, we'll presumably need to modify 'gfc_compare_interfaces' in
interface.c (for the case of generic_flag=1 and strict_flag=0). Possibly the
changes should go d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53033
Bug #: 53033
Summary: [avr]: Wrong register number for 3-byte loads via X
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53033
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
--- Comment #9 from Georg-Johann Lay 2012-04-18
20:00:17 UTC ---
(In reply to comment #6)
> We can see this bug on avr target too.
Thanks for the test case.
It's a bug, but completely unrelated to this one. See PR53033.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53028
--- Comment #4 from Mike Stump 2012-04-18
20:01:23 UTC ---
You explained yourself properly. Just because there are hundreds that do this,
doesn't mean that I necessarily agree with them. Personally, I'd rip out all
but one of them that either t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53033
--- Comment #2 from Georg-Johann Lay 2012-04-18
20:07:43 UTC ---
Until the issue is fixed you can use the command option -mstrict-X as a
work-around.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53034
Bug #: 53034
Summary: [4.5/4.6/4.7/4.8 Regression] tree-switch-conversion is
too aggressive
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53034
--- Comment #1 from Steven Bosscher 2012-04-18
20:25:45 UTC ---
The gimple switch conversion pass is much too aggressive, worse code is
generated for the examples that were used to introduce the implementation of
switch statements with bit tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53034
Steven Bosscher changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53034
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
1 - 100 of 118 matches
Mail list logo
