[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I don't see anything strange on it, -Wmaybe-uninitialized is a middle-end warning and as such very much depends on the optimizations, there is no guarantee you get the same warnings between different optimization levels, whether something is found as potentially uninitialized depends heavily e.g. on inlining, tail recursion etc. In this case at -O3 the function is first inlined into itself a small amount of times. I don't see anything wrong to warn here, given that the variable indeed is not initialized in some code paths (if fn2 returns zero).
[Bug middle-end/59737] [4.9 Regression] ice from optimize_inline_calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59737 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed.
[Bug libgcc/60166] ARM default NAN encoding violates EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60166 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Isn't this a dup of PR59833.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- Well, the code paths in question do not necessarily exist (you could say the same thing with -O2, where the function is not inlined: there may be some code paths for which fn1() doesn't initialize c). Actually the number of maybe-uninitialized warnings should decrease when the optimization level increases, because of additional knowledge, not the opposite.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Vincent Lefèvre from comment #2) Well, the code paths in question do not necessarily exist (you could say the same thing with -O2, where the function is not inlined: there may be some code paths for which fn1() doesn't initialize c). The code path exists in the code, the fact that perhaps in your program such code path is never taken doesn't mean it is undesirable to warn about it. GCC has two kinds of warnings, the is uninitialized one where particular code, if executed, will always use uninitialized value, and maybe uninitialized, where it will use uninitialized value only conditionally. That is the case here. Actually the number of maybe-uninitialized warnings should decrease when the optimization level increases, because of additional knowledge, not the opposite. No, usually with more inlining it increases and should. When fn1 is not inlined, GCC intentionally does not warn that c might be uninitialized because maybe the function call could use the value or not set it unconditionally, that would lead to so huge amount of false positives for the warning that nobody would be willing to use the warning.
[Bug c++/60167] [4.8/4.9 regression] Bogus error: conflicting declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60167 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-13 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.8.3 Summary|[4.9 regression] Bogus |[4.8/4.9 regression] Bogus |error: conflicting |error: conflicting |declaration |declaration Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r207167 and in r207189 has been introduced on the 4.8 branch as well.
[Bug gcov-profile/60171] New: SEGFAULT when compiling with --coverage on travis-ci
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60171 Bug ID: 60171 Summary: SEGFAULT when compiling with --coverage on travis-ci Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: lomato at gmail dot com I'm experiencing a bug when compiling and running a code on travis-ci. In 2 different projects, when added --coverage, they both crash. Travis-ci is an automated platform that doesn't allow me to have an interactive shell, but I can run gdb scripts on it. I've filed a bug on their github account, and they suggested me to open one here, to have help/suggestions from you too. Here you can find the bug opened on travis https://github.com/travis-ci/travis-ci/issues/1966 where you can watch the runs with the segfaults and the gdb runs. The strangest thing is that when backtracing on gdb, it returns me a meaningless line (the last one of the source file, a line with } ).
[Bug target/60169] [4.8/4.9 Regression] ICE ARM thumb1 handles far jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60169 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.3 Summary|ICE ARM thumb1 handles far |[4.8/4.9 Regression] ICE |jump|ARM thumb1 handles far jump
[Bug libgcc/60166] ARM default NAN encoding violates EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60166 --- Comment #2 from Joey Ye joey.ye at arm dot com --- (In reply to Ramana Radhakrishnan from comment #1) Isn't this a dup of PR59833. It isn't. This one is only impacts QNAN.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) (In reply to Vincent Lefèvre from comment #2) Well, the code paths in question do not necessarily exist (you could say the same thing with -O2, where the function is not inlined: there may be some code paths for which fn1() doesn't initialize c). The code path exists in the code, the fact that perhaps in your program such code path is never taken doesn't mean it is undesirable to warn about it. GCC has two kinds of warnings, the is uninitialized one where particular code, if executed, will always use uninitialized value, and maybe uninitialized, where it will use uninitialized value only conditionally. That is the case here. Where it of course still only assumes that the function is entered at all.
[Bug rtl-optimization/60162] [4.9 Regression][lra] mlra appears to be using the FP registers for integer values and then moving on to GPR registers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60162 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|[4.9 lra regression] mlra |[4.9 Regression][lra] mlra |appears to be using the FP |appears to be using the FP |registers for integer |registers for integer |values and then moving on |values and then moving on |to GPR registers. |to GPR registers.
[Bug tree-optimization/60172] New: ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 Bug ID: 60172 Summary: ARM performance regression from trunk@207239 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: joey.ye at arm dot com Dhrystone on Cortex-M4 drops by 1.5% with this patch: 2014-01-29 Richard Biener rguent...@suse.de PR tree-optimization/58742 * tree-ssa-forwprop.c (associate_pointerplus): Rename to associate_pointerplus_align. (associate_pointerplus_diff): New function. (associate_pointerplus): Likewise. Call associate_pointerplus_align and associate_pointerplus_diff. * gcc.dg/pr58742-1.c: New testcase. * gcc.dg/pr58742-2.c: Likewise. * gcc.dg/pr58742-3.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207239 Options used: -O2 -fno-inline -fno-common
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #5 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Jakub Jelinek from comment #3) The code path exists in the code, It exists *only* if fn2() can return 0. But the fact is that in the reality, this can never happen (with the original non-reduced code, this can even be proved). the fact that perhaps in your program such code path is never taken doesn't mean it is undesirable to warn about it. GCC has two kinds of warnings, the is uninitialized one where particular code, if executed, will always use uninitialized value, and maybe uninitialized, where it will use uninitialized value only conditionally. That is the case here. But in this case, the warning is missing with -O2. No, usually with more inlining it increases and should. When fn1 is not inlined, GCC intentionally does not warn that c might be uninitialized because maybe the function call could use the value or not set it unconditionally, that would lead to so huge amount of false positives for the warning that nobody would be willing to use the warning. This is the same problem with -O3: there is a false positive here. So, you have to choose whether you want to avoid false positives or not.
[Bug gcov-profile/60171] SEGFAULT when compiling with --coverage on travis-ci
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60171 --- Comment #1 from Dario Lombardo lomato at gmail dot com --- On my local platform (ubuntu 12.04, with same version of gcc as travis), I don't have the problem.
[Bug regression/60173] New: [4.9 Regression]: gcc.dg/binop-xor1.c scan-tree-dump-times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60173 Bug ID: 60173 Summary: [4.9 Regression]: gcc.dg/binop-xor1.c scan-tree-dump-times Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: ro at techfak dot uni-bielefeld.de Host: x86_64-unknown-linux-gnu Target: cris-axis-elf This test previously passed, now it fails. A patch in the revision range (last_known_working:first_known_failing) 207658:207668 exposed or caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/dg.exp ... FAIL: gcc.dg/binop-xor1.c scan-tree-dump-times optimized \\^ 1 This test also fails for at least the following targets (revision, link to gcc-testresults@) powerpc64-unknown-linux-gnu (207741 http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00830.html), m68k-unknown-linux-gnu (unknown, http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00849.html), s390x-ibm-linux-gnu (207735, http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00828.html), powerpc-ibm-aix7.1.0.0 (207693, http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00752.html), (The failure is not universal, it seems to not fail for at least as many other targets.) Author of the single suspect patch CC:ed.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
How can the compiler know that fn2 never returns 0, without inlining (not in
this case), some attribute (not provided, gcc right now has returns_nonnull
attribute but that is only for pointers) or some interprocedural analysis)?
Of course, if you want zero false positives, the uninitialized warnings could
not exist, even if you do:
int
foo (void)
{
int c;
return c;
}
you could say that warning here is a false positive, because you might actually
never call that function.
For -O2 we don't warn, because then the compiler does see an opaque call that
might be initializing what the arguments points to, might not, but warning in
that case would just mean too many false positives as I've said before.
While for -O3, when it is inlined a few times, the compiler clearly sees code
paths where the value is uninitialized, and has nothing that would hint such
code paths are impossible.
Of course, if fn2 is guaranteed to return non-NULL, why do you even write if
(fn2 (a, 0)) *p1 = b; rather than just
fn2 (a, 0); *p1 = b; ?
[Bug rtl-optimization/60162] [4.9 Regression][lra] mlra appears to be using the FP registers for integer values and then moving on to GPR registers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60162 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Created attachment 32120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32120action=edit Reduced from gzip. Command line options. -march=armv7-a -mfpu=neon -mfloat-abi=hard -mthumb -O3 -mlra
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #7 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Jakub Jelinek from comment #6) How can the compiler know that fn2 never returns 0, without inlining (not in this case), some attribute (not provided, gcc right now has returns_nonnull attribute but that is only for pointers) or some interprocedural analysis)? It doesn't know with -O3, but it doesn't know either with -O2 as well. That's my point (see below). For -O2 we don't warn, because then the compiler does see an opaque call that might be initializing what the arguments points to, might not, but warning in that case would just mean too many false positives as I've said before. I think it should. Or you should avoid the false positives with -O3 too. Of course, if fn2 is guaranteed to return non-NULL, why do you even write if (fn2 (a, 0)) *p1 = b; rather than just fn2 (a, 0); *p1 = b; ? That's because of creduce. But it seems that I've managed to make the warning disappear with both -O2 and -O3 even when it is clear that the value is not initialized. More later...
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-13 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please check the rev. after 2014-01-30 Richard Biener rguent...@suse.de PR tree-optimization/59993 * tree-ssa-forwprop.c (associate_pointerplus): Check we can propagate form the earlier stmt and avoid the transform when the intermediate result is needed. which avoids a case where extra expresions could have been introduced. Also ... can you attach the Dhrystone variant you are using? Also I can double the benchmark score on my machine when using -O3 -fwhole-program.
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #10 from PaX Team pageexec at gmail dot com --- please reopen, this bug is not fixed yet.
[Bug rtl-optimization/60162] [4.9 Regression][lra] mlra appears to be using the FP registers for integer values and then moving on to GPR registers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60162 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-13 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from ktkachov at gcc dot gnu.org --- I remember noticing weird loads to VFP regs when investigating PR59913 and looking at the assembly output of genattrtab. That was at least as far back as r206958. pinskia: Playing with the TARGET_REGISTER_MOVE_COST hook in arm did not make a difference, even when I set the move between GPR and VFP regs to ridiculously high numbers
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
Vincent Lefèvre vincent-gcc at vinc17 dot net changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #8 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Vincent Lefèvre from comment #5)
It exists *only* if fn2() can return 0. But the fact is that in the reality,
this can never happen (with the original non-reduced code, this can even be
proved).
After an analysis of the MPFR code, it actually seems to be a bug in MPFR. So,
the problem is the missing warning with -O2.
The -Wmaybe-uninitialized rule given in the gcc man page is (for GCC 4.8):
-Wmaybe-uninitialized
For an automatic variable, if there exists a path from the function
entry to a use of the variable that is initialized, but there exist
some other paths for which the variable is not initialized, the
compiler emits a warning if it cannot prove the uninitialized paths
are not executed at run time. [...]
This rule does *not* depend on the optimization level, except for the if it
cannot prove the uninitialized paths are not executed at run time part.
Indeed, the fact that a path exists or not is not something that depends on the
optimizations.
Concerning the if it cannot prove the uninitialized paths are not executed at
run time part, GCC should be able to prove more things with -O3 than with -O2,
meaning that -Wmaybe-uninitialized warnings could disappear with -O3 compared
to -O2, but generally not the opposite.
In the original example, GCC cannot prove anything about run time, so that
according to the gcc man page, one should get a warning whatever the
optimization level.
I've another example (similar to the MPFR code):
int fn3 (void);
void fn2 (int *p)
{
if (fn3 ())
*p = 0;
}
int fn1 (void)
{
int c;
fn2 (c);
return c;
}
GCC doesn't give any may be used uninitialized warning (whether -O2 or -O3 is
used). This is incorrect according to the above rule. BTW, for -O3, this is
surprising because it is similar to the original example.
I'm reopening the bug because the GCC behavior doesn't match the documentation.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Vincent Lefèvre from comment #8)
The -Wmaybe-uninitialized rule given in the gcc man page is (for GCC 4.8):
-Wmaybe-uninitialized
For an automatic variable, if there exists a path from the function
entry to a use of the variable that is initialized, but there exist
some other paths for which the variable is not initialized, the
compiler emits a warning if it cannot prove the uninitialized paths
are not executed at run time. [...]
This rule does *not* depend on the optimization level, except for the if it
cannot prove the uninitialized paths are not executed at run time part.
Indeed, the fact that a path exists or not is not something that depends on
the optimizations.
The definition of a function changes with inlining ;-)
Concerning the if it cannot prove the uninitialized paths are not executed
at run time part, GCC should be able to prove more things with -O3 than
with -O2, meaning that -Wmaybe-uninitialized warnings could disappear with
-O3 compared to -O2, but generally not the opposite.
In the original example, GCC cannot prove anything about run time, so that
according to the gcc man page, one should get a warning whatever the
optimization level.
f(i) is considered as an initialization of i. This heuristic is necessary,
otherwise the number of false positives would make the warning useless.
I've another example (similar to the MPFR code):
int fn3 (void);
void fn2 (int *p)
{
if (fn3 ())
*p = 0;
}
int fn1 (void)
{
int c;
fn2 (c);
return c;
}
GCC doesn't give any may be used uninitialized warning (whether -O2 or -O3
is used). This is incorrect according to the above rule. BTW, for -O3, this
is surprising because it is similar to the original example.
A different optimization pass (CCP) seems to notice that the value returned is
either 0 or something uninitialized and thus must be 0. Maybe there is an
opportunity for a warning there (though again we need to make sure it won't
cause too many false positives).
I don't know why you think warnings should be so well defined. They have always
been a heuristic compromise.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Vincent Lefèvre from comment #8)
Concerning the if it cannot prove the uninitialized paths are not executed
at run time part, GCC should be able to prove more things with -O3 than
with -O2, meaning that -Wmaybe-uninitialized warnings could disappear with
-O3 compared to -O2, but generally not the opposite.
Your assumption is mistaken because you don't seem to realize something that
Jakub has said repeatedly. GCC doesn't warn *on purpose* for very common code
such as
{
int c;
f(c);
return c;
}
if GCC doesn't know what is going on within f(), because that will trigger a
lot of false positives (although it is easy to build testcases where warning
would have been warranted). At -O3, that code may be converted to
{
int c;
if (g())
c = 3
return c;
}
and then, even though g() may never return false, if GCC cannot prove that,
then GCC will warn, because not warning will case a lot of false negatives.
Such design decisions are based on experience.
Now, I agree that ideally, GCC should warn for your last testcase. But I guess
in that case inlining either doesn't happen or it happens too late, so GCC only
sees the first case. The analysis that GCC performs are predicated on the
transformations leading to better code, otherwise they are not performed. A
tool for static analysis will surely inline as much as it could, not matter if
the code is slower or larger, but this is not how GCC works because GCC is not
a tool for static analysis.
On the other hand, GCC has bugs (missed optimizations, PR24639), and it would
be nice if more people worked on those, but this PR doesn't look like one.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marc Glisse from comment #9) A different optimization pass (CCP) seems to notice that the value returned is either 0 or something uninitialized and thus must be 0. Maybe there is an opportunity for a warning there (though again we need to make sure it won't cause too many false positives). Actually this missed warning is the infamous PR18501.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Only in your reading of the documentation. You clearly don't know what you are asking for, even the very common case of pthread_t th; if (pthread_create (th, NULL, tf, NULL)) goto fail; pthread_join (th, NULL); case would need to be warned about, even when there is nothing wrong about it. In your testcase, if fn1 isn't inlined, it is the same thing for GCC, a function call as a black box which could do anything to the memory pointed to by the escaped pointer (unless the function is say pure or const, at which point it couldn't store to it). If it is inlined, the compiler sees it, sees that a variable is used and in certain path has uninitialized value and in others initialized, and correctly warns.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #13 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #10) Now, I agree that ideally, GCC should warn for your last testcase. But I guess in that case inlining either doesn't happen or it happens too late, so GCC only sees the first case. Actually it is the reverse, inlining happens earlier in this new testcase (the first example was recursive, which makes the inliner more conservative). The analysis that GCC performs are predicated on the transformations leading to better code, otherwise they are not performed. A tool for static analysis will surely inline as much as it could, not matter if the code is slower or larger, but this is not how GCC works because GCC is not a tool for static analysis. Maybe we could have a wiki page explaining what options to tweak (inlining parameters, etc) for a compilation where you are only interested in warnings? (I had vaguely mentioned creating -Ow at some point, but that didn't seem such a good idea)
[Bug ada/60174] New: ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 Bug ID: 60174 Summary: ICE on ACATS cc3305a Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de BUILD cc3305a.adb gnatmake --GCC=/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ -gnatws -O2 -gnat95 -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/ada/acats/support cc3305a.adb -largs --GCC=/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/xgcc -c -B/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ -gnatws -O2 -gnat95 -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/ada/acats/support cc3305a.adb Unable to coalesce ssa_names 34 and 399 which are marked as MUST COALESCE. i_34(ab) and i_399(ab) +===GNAT BUG DETECTED==+ | 4.9.0 20140209 (experimental) (armv7l-unknown-linux-gnueabihf) GCC error:| | SSA corruption | | Error detected around cc3305a.adb:35:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/system.ads cc3305a.adb /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/testsuite/ada/acats/support/report.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-soflin.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/ada.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/a-except.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-parame.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stalib.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/a-unccon.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-traent.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stache.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stoele.ads /home/ed/gnu/gcc-build-arm-linux-gnueabihf/gcc/ada/rts/s-stoele.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:432 gnatmake: cc3305a.adb compilation error FAIL: cc3305a cat LAST_UPDATED Obtained from SVN: trunk revision 207646
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Can you check from the -fdump-tree-all dumps where i_34(ab) and i_399(ab) start to have overlapping life-ranges?
[Bug middle-end/60175] New: ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 Bug ID: 60175 Summary: ICE on gcc.dg/asan/nosanitize-and-inline.c Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de /home/ed/gnu/gcc-4.9-20140209/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c: In function 'main':^M /home/ed/gnu/gcc-4.9-20140209/gcc/testsuite/gcc.dg/asan/nosanitize-and-inline.c:57:1: internal compiler error: in check_probability, at basic-block.h:950^M 0xc561f check_probability^M ../../gcc-4.9-20140209/gcc/basic-block.h:950^M 0x23aaab check_probability^M ../../gcc-4.9-20140209/gcc/cfgloopmanip.c:1332^M 0x23aaab combine_probabilities^M ../../gcc-4.9-20140209/gcc/basic-block.h:959^M 0x23aaab duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vecedge_def*, va_heap, vl_ptr*, int)^M ../../gcc-4.9-20140209/gcc/cfgloopmanip.c:1264^M 0x473d8f peel_loop_completely^M ../../gcc-4.9-20140209/gcc/loop-unroll.c:609^M 0x473d8f peel_loops_completely^M ../../gcc-4.9-20140209/gcc/loop-unroll.c:370^M 0x473d8f unroll_and_peel_loops(int)^M ../../gcc-4.9-20140209/gcc/loop-unroll.c:275^M 0x465e33 rtl_unroll_and_peel_loops^M ../../gcc-4.9-20140209/gcc/loop-init.c:598^M 0x465e33 execute^M ../../gcc-4.9-20140209/gcc/loop-init.c:629^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See http://gcc.gnu.org/bugs.html for instructions.^M cat LAST_UPDATED Obtained from SVN: trunk revision 207646
[Bug target/43546] [4.7/4.8/4.9 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 13 13:20:06 2014 New Revision: 207757 URL: http://gcc.gnu.org/viewcvs?rev=207757root=gccview=rev Log: PR target/43546 * expr.c (compress_float_constant): If x is a hard register, extend into a pseudo and then move to x. * gcc.target/i386/pr43546.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr43546.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug target/43546] [4.7/4.8 Regression] ICE: in assign_stack_local_1, at function.c:353 with -mpreferred-stack-boundary=2 -msseregparm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43546 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] ICE: |ICE: in |in assign_stack_local_1, at |assign_stack_local_1, at|function.c:353 with |function.c:353 with |-mpreferred-stack-boundary= |-mpreferred-stack-boundary= |2 -msseregparm |2 -msseregparm | Known to fail||4.8.2 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #2 from Mikael Pettersson mikpelinux at gmail dot com --- I got the exact same error on armv5tel-linux-gnueabi with 4.9-20140209 aka r207646. The previous weekly snapshot, 4.9-20140202 aka r207409, was Ok.
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165 --- Comment #14 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Marc Glisse from comment #9) The definition of a function changes with inlining ;-) It shouldn't: what happens at run time isn't changed by inlining. f(i) is considered as an initialization of i. This heuristic is necessary, otherwise the number of false positives would make the warning useless. Perhaps, but this isn't documented. I don't know why you think warnings should be so well defined. According to the gcc man page, it is well-defined: the rule is given explicitly. (In reply to Jakub Jelinek from comment #12) In your testcase, if fn1 isn't inlined, it is the same thing for GCC, a function call as a black box which could do anything to the memory pointed to by the escaped pointer (unless the function is say pure or const, at which point it couldn't store to it). Here you assume that the function can do anything, while Marc said that GCC assumes that i is initialized. There's a contradiction. Moreover in the case of MPFR, the called function is in the same preprocessed source file, so that it is not obvious for the user that GCC will see it as a black box (when not inlined).
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Feb 13 13:35:10 2014 New Revision: 207758 URL: http://gcc.gnu.org/viewcvs?rev=207758root=gccview=rev Log: 2014-02-13 Richard Biener rguent...@suse.de PR bootstrap/59878 * doc/install.texi (ISL): Update recommended version to 0.12.2, mention the possibility of an in-tree build. (CLooG): Update recommended version to 0.18.1, mention the possibility of an in-tree build and clarify that the ISL bundled with CLooG does not work. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||grosser at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed. (or invalid, just depends how you interpret it ;)) - make the cloog folks have the bundled ISL produce a sensible isl_version () output would be a better fix, of course ;) Tobias? (not sure, maybe cloog 0.18.1 is fixed in this regard, 0.18.0 definitely wasn't)
[Bug tree-optimization/60165] may be used uninitialized warning with -O3 but not with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60165
--- Comment #15 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Manuel López-Ibáñez from comment #10)
Now, I agree that ideally, GCC should warn for your last testcase. But I
guess in that case inlining either doesn't happen or it happens too late, so
GCC only sees the first case. The analysis that GCC performs are predicated
on the transformations leading to better code, otherwise they are not
performed. A tool for static analysis will surely inline as much as it
could, not matter if the code is slower or larger, but this is not how GCC
works because GCC is not a tool for static analysis.
Well, detecting uninitialized variables is equivalent to generating better
code. See the following functions. If you want to be able to remove the i == 0
test in the first one (making generated code better), you'll solve the warning
problem in the second one.
int f(void)
{
int i = 0;
/* some code that sets i to a nonzero value, but difficult to prove */
if (i == 0)
abort();
return i;
}
int f(void)
{
int i;
/* some code that sets i to a nonzero value, but difficult to prove */
return i;
}
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174
--- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #1)
Can you check from the -fdump-tree-all dumps where i_34(ab) and i_399(ab)
start to have overlapping life-ranges?
OK, i used grep 'i_\(34\|399\)(ab)' cc3305a.adb.*
i_399(ab) is first mentioned in cc3305a.adb.078t.dom1:
cc3305a.adb.078t.dom1:i_399(ab) - { i_36(ab) }
cc3305a.adb.078t.dom1: # i_34(ab) = PHI i_168(D)(ab)(2), i_168(D)(ab)(3),
i_168(D)(ab)(4), i_398(ab)(8), i_398(ab)(9), i_398(ab)(11), i_398(ab)(12),
i_398(ab)(13), i_35(ab)(14), i_35(ab)(15), i_35(ab)(16), i_35(ab)(17),
i_208(ab)(20), i_208(ab)(21), i_208(ab)(22), i_399(ab)(25), i_399(ab)(26),
i_399(ab)(28), i_399(ab)(30), i_399(ab)(31), i_36(ab)(32), i_36(ab)(34),
i_36(ab)(36), i_36(ab)(38), i_400(ab)(39), i_37(ab)(41), i_37(ab)(42),
i_37(ab)(43), i_38(ab)(46), i_38(ab)(47), i_38(ab)(48), i_401(ab)(51),
i_401(ab)(52), i_401(ab)(54), i_401(ab)(56), i_401(ab)(57), i_39(ab)(58),
i_39(ab)(60), i_43(ab)(90), i_402(ab)(61), i_40(ab)(63), i_40(ab)(64),
i_40(ab)(65), i_41(ab)(68), i_41(ab)(69), i_41(ab)(70), i_403(ab)(73),
i_403(ab)(74), i_403(ab)(76), i_403(ab)(78), i_403(ab)(79), i_42(ab)(80),
i_42(ab)(82), i_42(ab)(84), i_42(ab)(86), i_404(ab)(87), i_43(ab)(89)
cc3305a.adb.078t.dom1: # i_399(ab) = PHI i_36(ab)(24), i_333(93)
cc3305a.adb.078t.dom1: _188 = i_399(ab) != 0;
cc3305a.adb.078t.dom1: _189 = i_399(ab) != 4;
cc3305a.adb.078t.dom1: # i_400(ab) = PHI i_399(ab)(29), i_36(ab)(37),
i_36(ab)(38), i_399(ab)(30)
cc3305a.adb.078t.dom1: # i_305 = PHI i_34(ab)(5)
cc3305a.adb.078t.dom1: # i_333 = PHI i_34(ab)(23)
cc3305a.adb.078t.dom1: # i_350 = PHI i_34(ab)(49)
cc3305a.adb.078t.dom1: # i_365 = PHI i_34(ab)(71)
is this already overlapping?
[Bug libstdc++/60176] New: [C++11] void return value in std::list::insert() c++1 should be an iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60176
Bug ID: 60176
Summary: [C++11] void return value in std::list::insert()
c++1 should be an iterator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fasbjx at free dot fr
Created attachment 32121
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32121action=edit
Test case
/usr/bin/g++-4.8 -std=c++11 --version
g++-4.8 (Debian 4.8.2-14) 4.8.2
/usr/bin/g++-4.8 -std=c++11 /tmp/insert_error.cpp
/tmp/insert_error.cpp: In function ‘int main()’:
/tmp/insert_error.cpp:8:62: error: conversion from ‘void’ to non-scalar type
‘std::listint::iterator {aka std::_List_iteratorint}’ requested
std::listint::iterator it = v2.insert( v2.end(), v1, v1+5 );
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 32122 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32122action=edit output from -fdump-tree-all
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Looks like so. Can you attach -fdump-tree-dom1-details?
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 32123 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32123action=edit output from -fdump-tree-dom1-details (In reply to Richard Biener from comment #5) Looks like so. Can you attach -fdump-tree-dom1-details? sure, here you are.
[Bug c++/60177] New: Unable to deduce template base of derived class in function template accepting a simple-template-id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60177
Bug ID: 60177
Summary: Unable to deduce template base of derived class in
function template accepting a simple-template-id
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
templateclass struct Base { };
struct Derived : Basevoid { };
templatetemplatetypename class TT, typename T
void func (TTT) { }
int main () {
func (Derived { });
}
- - - - - - - - - - - - - - - - - - - - - - - - - -
main.cpp: In function 'int main()':
main.cpp:9:20: error: no matching function for call to 'func(Derived)'
func (Derived { });
^
main.cpp:9:20: note: candidate is:
main.cpp:6:6: note: templatetemplateclass class TT, class T void
func(TTT)
void func (TTT) { }
^
main.cpp:6:6: note: template argument deduction/substitution failed:
main.cpp:9:20: note: can't deduce a template for 'TTT' from non-template
type 'Derived'
func (Derived { });
- - - - - - - - - - - - - - - - - - - - - - - - - -
gcc rejects the snippet which is a violation of [temp.deduct.call]/4 (`clang`
and `msvc` accepts the code).
`TTT` is a `simple-template-id` and the standard says that if a derived type
is passed to such context it should be deduced to a suitable base of that
passed type.
Correct behavior is that the deduced template parameters for `func (Derived
{})` should be `TT = Base, T = void`.
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Ok, I believe this is caused by some jump-threading threading over a copy of an SSA name used in abnormal context. You can try verifying if -fno-tree-dominator-opts fixes this (maybe you also need -fno-tree-vrp, not sure)
[Bug ada/60174] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Richard Biener from comment #7) Ok, I believe this is caused by some jump-threading threading over a copy of an SSA name used in abnormal context. You can try verifying if -fno-tree-dominator-opts fixes this (maybe you also need -fno-tree-vrp, not sure) Yes, if I add -fno-tree-dominator-opts (_before_ -largs) to the gnatmake command line, the ICE is gone, and the test case PASSES.
[Bug c++/60178] New: std::mutex::try_lock failing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60178
Bug ID: 60178
Summary: std::mutex::try_lock failing
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: meme02 at eaku dot net
Created attachment 32124
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32124action=edit
Output from g++ -save-temps command above.
Problem summary:
The very simple standard example code for std::mutex usage here:
http://en.cppreference.com/w/cpp/thread/shared_mutex/unlock
---
#include iostream
#include mutex
int main()
{
std::mutex test;
if (test.try_lock()) {
std::cout first try_lock successful\n;
} else {
std::cout first try_lock NOT successful\n;
return 0;
}
test.unlock();
test.lock();
if (test.try_lock()) {
std::cout second try_lock successful\n;
} else {
std::cout second try_lock NOT successful\n;
}
test.lock(); // trying to lock an already-locked std::mutex will
// block program execution, so we'll hang here
}
---
... does not perform as it should. On my system:
---
[bash]$ rm -f test; /usr/local/bin/g++ -save-temps -Wall -Wextra -std=c++0x
test.cpp -o test; ./test
first try_lock successful
second try_lock successful
[bash]$
---
Obviously, the second try_lock should fail and the program should then hang,
but this does not occur.
I'm running the latest gcc stable tarball, 4.82, updated today, no flags given
at build time. I was previously using 4.62 and the problem was there too (I
upgraded to see if that would fix it). /proc/version says Linux version
2.6.18-194.el5PAE (mockbu...@x86-007.build.bos.redhat.com) (gcc version 4.1.2
20080704 (Red Hat 4.1.2-48)) #1 SMP Tue Mar 16 22:00:21 EDT 2010.
[Bug target/60179] New: [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 Bug ID: 60179 Summary: [4.9 Regression] target optimization attribute streaming is broken Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target: x86_64-*-*, i?86-*-* Since somewhen recently the i386 target started to put pointers to strings in struct cl_target_option (TargetSaves in i386.opt). This breaks LTO streaming of TS_TARGET_OPTION which streams the contents of cl_target_option byte-for-byte. For me this results in a LTO bootstrap comparison failure when comparing stage2/libccp/lex.o and stage3/libcpp/lex.o. And it obviously will make the backend crash if anybody would ever inspect one of those streamed string pointers (well, or they'll point somewhere random and not so useful).
[Bug target/60179] [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||tmsriram at google dot com --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- CCing offender.
[Bug target/60179] [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Known to work||4.8.3 Target Milestone|--- |4.9.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- i386 is the only port TargetSaveing strings, nios2 saves arrays (not sure how they end up in cl_target_option). rs6000 is saving ints. It was suggested to change streaming to not stream TS_TARGET_OPTION but re-generate them from the attributes (we stream those if they are present and preserved).
[Bug target/60179] [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32125 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32125action=edit untested patch
[Bug target/60179] [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #32125|0 |1 is obsolete|| --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32126 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32126action=edit non-working patch
[Bug target/60179] [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-13 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32127 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32127action=edit patch
[Bug c++/60180] New: internal compiler error: in use_thunk, at cp/method.c:338
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60180 Bug ID: 60180 Summary: internal compiler error: in use_thunk, at cp/method.c:338 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ignoreddropbox at gmail dot com gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7) Building file: ../verification_tests.cpp Invoking: GCC C++ Compiler g++ -D__GXX_EXPERIMENTAL_CXX0X__ -I/home/eran/FakeIt/tests/../include -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP -MFverification_tests.d -MTverification_tests.d -o verification_tests.o ../verification_tests.cpp In file included from /home/eran/FakeIt/tests/../include/fakeit/Mock.h:8:0, from /home/eran/FakeIt/tests/../include/fakeit.h:4, from ../verification_tests.cpp:7: /home/eran/FakeIt/tests/../include/fakeit/StubbingImpl.h:38:10: internal compiler error: in use_thunk, at cp/method.c:338 virtual ~FunctionStubbingProgress() override = default; ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccqU9q2o.out file, please attach this to your bugreport. make: *** [verification_tests.o] Error 1
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs after recent modification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Thu Feb 13 16:18:13 2014 New Revision: 207763 URL: http://gcc.gnu.org/viewcvs?rev=207763root=gccview=rev Log: PR libffi/60073 * src/sparc/ffitarget.h (FFI_TARGET_SPECIFIC_VARIADIC): Define. (FFI_EXTRA_CIF_FIELDS): Likewise. (FFI_NATIVE_RAW_API): Move around. * src/sparc/ffi.c (ffi_prep_cif_machdep_core): New function from... (ffi_prep_cif_machdep): ...here. Call ffi_prep_cif_machdep_core. (ffi_prep_cif_machdep_var): New function. (ffi_closure_sparc_inner_v9): Do not pass anonymous FP arguments in FP registers. * doc/libffi.texi (Introduction): Fix inaccuracy. Modified: trunk/libffi/ChangeLog trunk/libffi/doc/libffi.texi trunk/libffi/src/sparc/ffi.c trunk/libffi/src/sparc/ffitarget.h
[Bug target/60181] New: constant folding of complex number incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181
Bug ID: 60181
Summary: constant folding of complex number incorrect
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
The following testcase fails on s390x and Power. Constant folding and runtime
execution of a division of complex numbers produce different results.
The testcase works fine on x86 so it looks like S/390 and Power do something
different here.
It looks somewhat like:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
#include complex.h
#include stdio.h
#include stdlib.h
_Complex float __attribute__ ((noinline))
calc (_Complex float a, _Complex float b)
{
return a / b;
}
int
main (int argc, char **argv)
{
_Complex float a = calc (10 + 6 * I, 5 + 12 * I);
_Complex float b = (10 + 6 * I) / (5 + 12 * I);
printf (%ap + %ap * i\n, creal (a), cimag (a));
printf (%ap + %ap * i\n, creal (b), cimag (b));
if (a != b)
abort ();
return 0;
}
gcc -O0 t.c -o f
./f
0x1.719c08p-1p + -0x1.10a9a8p-1p * i
0x1.719c06p-1p + -0x1.10a9a8p-1p * i
Aborted
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs after recent modification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks for reporting the problem.
[Bug c++/60180] internal compiler error: in use_thunk, at cp/method.c:338
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60180 --- Comment #1 from EP ignoreddropbox at gmail dot com --- Created attachment 32128 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32128action=edit dump created by gcc
[Bug tree-optimization/60174] [4.9 regression] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-13 Component|ada |tree-optimization CC||ebotcazou at gcc dot gnu.org Assignee|law at redhat dot com |unassigned at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE on ACATS cc3305a|[4.9 regression] ICE on ||ACATS cc3305a Target Milestone|--- |4.9.0 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Probably a missing SSA_NAME_OCCURS_IN_ABNORMAL_PHI check somewhere.
[Bug tree-optimization/60174] [4.9 regression] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174 --- Comment #10 from Jeffrey A. Law law at redhat dot com --- That was my thought as well. I've got some unexpected family stuff to deal with over the next couple days, but I don't see any reason why this can't be nailed down early next week.
[Bug tree-optimization/60174] [4.9 regression] ICE on ACATS cc3305a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60174
--- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Reproducible on x86{-64}/Linux with the following procedure:
- copy $srcdir/gcc/testsuite/ada/acats/support/repbody.ada to $buildir
- gnatchop repbody.ada
- copy $srcdir/gcc/testsuite/ada/acats/support/repspec.ada to $buildir
- gnatchop repspec.ada
- copy $builddir/gcc/ada/rts/system.ads to $buildir
- edit system.ads and change ZCX_By_Default to False
- compile
eric@polaris:~/build/gcc/native gcc/xgcc -Bgcc -S cc3305a.adb -O2
Unable to coalesce ssa_names 34 and 399 which are marked as MUST COALESCE.
i_34(ab) and i_399(ab)
+===GNAT BUG DETECTED==+
| 4.9.0 20140213 (experimental) [trunk revision 207749] (x86_64-suse-linux) GCC
error:|
| SSA corruption |
| Error detected around cc3305a.adb:35:1 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
[Bug c++/60182] New: g++ segfault within template expansion using using aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60182 Bug ID: 60182 Summary: g++ segfault within template expansion using using aliasing Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: xgue...@tower-research.com Created attachment 32129 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32129action=edit Code producing the issue G++ segfault while passing a class member that has been declared using a using alias to a templates function that uses templated type reduction. [g++48 -std=c++11 -o test test.cpp] test.cpp: In constructor ‘A::A(const string)’: test.cpp:28:25: internal compiler error: Segmentation fault doSomething(m_elements); 0x90661f crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x58bedc unify ../../gcc-4.8.2/gcc/cp/pt.c:16580 0x58e9e1 unify_one_argument ../../gcc-4.8.2/gcc/cp/pt.c:15470 0x588dca type_unification_real ../../gcc-4.8.2/gcc/cp/pt.c:15542 0x58faf9 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, bool) ../../gcc-4.8.2/gcc/cp/pt.c:15124 0x5516b1 add_template_candidate_real ../../gcc-4.8.2/gcc/cp/call.c:2925 0x54f0a1 add_template_candidate ../../gcc-4.8.2/gcc/cp/call.c:3022 0x54f0a1 add_candidates ../../gcc-4.8.2/gcc/cp/call.c:5023 0x5537fd perform_overload_resolution ../../gcc-4.8.2/gcc/cp/call.c:3817 0x55727a build_new_function_call(tree_node*, vectree_node*, va_gc, vl_embed**, bool, int) ../../gcc-4.8.2/gcc/cp/call.c:3894 0x606911 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool, bool, int) ../../gcc-4.8.2/gcc/cp/semantics.c:2231 0x5c4d5a cp_parser_postfix_expression ../../gcc-4.8.2/gcc/cp/parser.c:5862 0x5c6edd cp_parser_unary_expression ../../gcc-4.8.2/gcc/cp/parser.c:6736 0x5c7a0f cp_parser_binary_expression ../../gcc-4.8.2/gcc/cp/parser.c:7428 0x5c7ebf cp_parser_assignment_expression ../../gcc-4.8.2/gcc/cp/parser.c:7664 0x5c9ab3 cp_parser_expression ../../gcc-4.8.2/gcc/cp/parser.c:7826 0x5ca21c cp_parser_expression ../../gcc-4.8.2/gcc/cp/parser.c:7865 0x5ca21c cp_parser_expression_statement ../../gcc-4.8.2/gcc/cp/parser.c:9127 0x5c13c7 cp_parser_statement ../../gcc-4.8.2/gcc/cp/parser.c:8979 0x5c259e cp_parser_statement_seq_opt ../../gcc-4.8.2/gcc/cp/parser.c:9245 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/60183] New: [4.7/4.8/4.9 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183
Bug ID: 60183
Summary: [4.7/4.8/4.9 Regression] phiprop creates invalid code
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
On:
unsigned long c[32] = { 1 };
static void
foo (unsigned long *x, unsigned long *y)
{
int i;
unsigned long w = x[0];
for (i = 0; i 8; i++)
{
w ^= *y++;
w += *y++;
w ^= *y++;
w += *y++;
}
x[1] = w;
}
__attribute__((noinline, noclone)) void
bar (unsigned long *x)
{
foo (x, c);
}
int
main ()
{
unsigned long a[2] = { 0, -1UL };
asm volatile ( : : r (c) : memory);
c[0] = 0;
bar (a);
if (a[1] != 0)
__builtin_abort ();
return 0;
}
at -O1 or higher phiprop causes invalid code to be generated, where the loop
body reads the next *y value into a SSA_NAME and in loop preheader it reads
c[0] into a SSA_NAME which is then used in a PHI on the loop header and the
result of the PHI is used instead of the first *y read. In this particular
case, I don't even see any advantages of doing that, but more importantly it
can read one past the end of the array. With -O{1,2,3} -fsanitize=address
this fails loudly, otherwise if you are unlucky enough and the variable is at
the end of some mmapped area, you could get a crash as well.
[Bug rtl-optimization/60141] ICE in i386.c distance_non_agu_define_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60141
--- Comment #1 from Teresa Johnson tejohnson at google dot com ---
This appears to have been exposed, not caused, by the change to the
pass ordering. It is in fact a duplicate of PR middle-end/43631, which
was fixed on trunk by r197994 on 4/15/13. I will backport the fix to
google-4_8.
Teresa
On Mon, Feb 10, 2014 at 4:49 PM, shenhan at google dot com
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60141
Bug ID: 60141
Summary: ICE in i386.c distance_non_agu_define_in_bb
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shenhan at google dot com
CC: llozano at google dot com, tejohnson at google dot com
This only fails for google/gcc-4_8
To reproduce -
configure:
~/gcc.git/configure --disable-bootstrap --enable-languages='c,c++'
--disable-multilib --disable-libatomic --disable-libmudflap
--disable-libssp --enable-libgomp --enable-__cxa_atexit
--enable-checking=release --disable-libquadmath --disable-libitm
--enable-esp --with-arch=atom --with-tune=atom --enable-frame-pointer
Build -
make -j40
Compile a testcase -
./gcc/xgcc -B./gcc -g -O2 -fpic -c -m32 ~/SROA.pp.cpp
Output -
SROA.cpp: In member function ‘void
{anonymous}::AllocaPartitioning::UseBuilder::operator()()’:
SROA.cpp:873:3: internal compiler error: Segmentation fault
0x8d0baf crash_signal
../../../gcc.git/gcc/toplev.c:346
0xa798c8 distance_non_agu_define_in_bb
../../../gcc.git/gcc/config/i386/i386.c:17506
0xa79cad distance_non_agu_define
../../../gcc.git/gcc/config/i386/i386.c:17564
0xa79cad ix86_lea_outperforms
../../../gcc.git/gcc/config/i386/i386.c:17730
0xb8e6ca output_89
../../../gcc.git/gcc/config/i386/i386.md:2152
0x72a5c3 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../../gcc.git/gcc/final.c:2895
0x72ae84 final(rtx_def*, _IO_FILE*, int)
../../../gcc.git/gcc/final.c:1986
0x72b46d rest_of_handle_final
../../../gcc.git/gcc/final.c:4432
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Debugging shows that in distance_non_agu_define_in_bb (i386.c),
BLOCK_FOR_INSN(start) returns zero, which caused this ICE.
A preliminary bisecting in google/gcc-4_8 shows that the follow CL introduces
this ICE. (So I cc'ed Teresa Johnson)
commit 907fca49eae2da51a328eb192c691cc24f69e6af
Author: tejohnson tejohnson@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Dec 2 18:28:19 2013 +
Backport the last few fixes for -freorder-blocks-and-partition from
trunk to google/4_8: r204985, r205057 and r205243
r204985 | tejohnson | 2013-11-18 14:38:51 -0800 (Mon, 18 Nov 2013) |
15
lines
This patch fixes an lto profiledbootstrap failure with
-freorder-blocks-and-partition enabled. Currently compgotos
is the only pass that goes into cfglayout mode after bb reordering,
which is undesireable (and in the case of
-freorder-blocks-and-partition
can cause illegal partitioning) because of the optimizations performed
on the cfg when going into cfglayout mode. Moved compgoto before
bb reordering to avoid these problems.
2013-11-18 Teresa Johnson tejohn...@google.com
* gcc/cfgrtl.c (cfg_layout_initialize): Assert if we
try to go into cfglayout after bb reordering.
* gcc/passes.def: Move compgotos before bb reordering
since it goes into cfglayout.
r205057 | tmsriram | 2013-11-19 14:12:21 -0800 (Tue, 19 Nov 2013) | 7
lines
Emit a label for the split cold function part. Label name is formed
by
suffixing the original function name with cold.
Patch tested for bootstrap on all default languages on x86_64 and
regression testsuite checked for parity with RUNTESTFLAGS -m32 and
m64.
2013-11-19 Sriraman Tallam tmsri...@google.com
* final.c (final_scan_insn): Emit a label for the split
cold function part. Label name is formed by suffixing
the original function name with cold.
2013-11-19 Sriraman Tallam tmsri...@google.com
* gcc.dg/tree-prof/cold_partition_label.c: New testcase.
[Bug libstdc++/60176] [C++11] void return value in std::list::insert() c++1 should be an iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60176 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Our std::list needs work to conform to C++11
[Bug libstdc++/60178] std::mutex::try_lock failing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60178 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution|--- |WORKSFORME --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- You need to use -pthread The program has undefined behaviour anyway due to locking the same mutex twice in a single thread.
[Bug target/57936] ICE in rs6000_secondary_reload_inner:15144, type = load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936 Orion Poplawski orion at cora dot nwra.com changed: What|Removed |Added CC||orion at cora dot nwra.com --- Comment #4 from Orion Poplawski orion at cora dot nwra.com --- Created attachment 32130 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32130action=edit ccf2q412.out.gz I think I may be encountering the same or similar while compiling the eigen3 test cases. This is on RHEL7 ppc64 with gcc-4.8.2-3.el7. [ 13%] Building CXX object test/CMakeFiles/product_extra_3.dir/product_extra.cpp.o cd /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/ppc64-redhat-linux-gnu/test /usr/bin/c++ -DEIGEN_CHOLMOD_SUPPORT -DEIGEN_SPQR_SUPPORT -DEIGEN_SUPERLU_SUPPORT -DEIGEN_UMFPACK_SUPPORT -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mcpu=power7 -mtune=power7 -fexceptions -pedantic -Wall -Wextra -Wundef -Wcast-align -Wchar-subscripts -Wnon-virtual-dtor -Wunused-local-typedefs -Wpointer-arith -Wwrite-strings -Wformat-security -Wno-psabi -Wno-variadic-macros -Wno-long-long -fno-check-new -fno-common -fstrict-aliasing -ansi -g2 -g0 -O2 -fno-inline-functions -I/builddir/build/BUILD/eigen-eigen-ffa86ffb5570/ppc64-redhat-linux-gnu/test -I/builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test -I/builddir/build/BUILD/eigen-eigen-ffa86ffb5570 -I/builddir/build/BUILD/eigen-eigen-ffa86ffb5570/ppc64-redhat-linux-gnu -I/usr/include/suitesparse -I/usr/include/SuperLU -isystem /usr/include/QtGui -isystem /usr/include/QtCore -DEIGEN_TEST_MAX_SIZE=320 -DEIGEN_TEST_FUNC=product_extra -DEIGEN_TEST_PART_3=1 -o CMakeFiles/product_extra_3.dir/product_extra.cpp.o -c /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/product_extra.cpp rs6000_secondary_reload_inner:15249, type = load (parallel [ (set (reg:V4SI 77 0) (reg:V4SI 32 0)) (clobber (reg:DI 3 3)) ]) /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/product_extra.cpp: In function 'void product_extra(const MatrixType) [with MatrixType = Eigen::Matrixstd::complexfloat, -1, -1]': /builddir/build/BUILD/eigen-eigen-ffa86ffb5570/test/product_extra.cpp:101:1: internal compiler error: in rs6000_secondary_reload_fail, at config/rs6000/rs6000.c:15222 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccf2q412.out file, please attach this to your bugreport.
[Bug rtl-optimization/60141] ICE in i386.c distance_non_agu_define_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60141 Han Shen shenhanc at gmail dot com changed: What|Removed |Added CC||shenhanc at gmail dot com --- Comment #2 from Han Shen shenhanc at gmail dot com --- Thanks, Teresa!
[Bug c++/60182] g++ segfault within template expansion using using aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60182
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-13
CC||trippels at gcc dot gnu.org
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
Known to fail||4.7.3, 4.8.3, 4.9.0
Severity|major |normal
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
class B {};
template typename using __allocator_base = B;
template typename class F : __allocator_baseint {};
class C {};
template typename, typename = Fint class G : C {};
template typename class D;
class A {
using Container = GDchar;
A();
A(Dchar const );
Container m_elements;
};
template template class, class class C, class A = FDint
void doSomething(CDchar, A );
A::A(Dchar const ) : A() { doSomething(m_elements); }
[Bug target/60181] constant folding of complex number incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- There are no specified accuracy requirements for complex multiplication / division, even under Annex G (parts of which - imaginary types in particular - are not implemented in GCC at present), beyond certain requirements for special cases and avoiding certain cases of overflow from the simplest formulas. Constant folding is correctly rounding, runtime complex multiplication / division isn't (and given complaints about slowness at present, I don't think users would want it to be even slower, though there may well be a case for defining a standard library interface for correctly rounding complex multiplication / division). x86 probably benefits from excess precision being used implicitly by GCC when compiling the implementations of complex multiplication and division.
[Bug tree-optimization/60183] [4.7/4.8/4.9 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug c++/60184] New: g++ does not allow static members of named unions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60184
Bug ID: 60184
Summary: g++ does not allow static members of named unions
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: d0sboots at gmail dot com
cat test.cc EOF
union Test {
static constexpr int kConstant = 10;
};
EOF
g++ --std=c++0x -c -o test.o test.cc
produces:
test.cc:2:36: error: 'Test::kConstant' may not be static because it is a member
of a union
However, this is correct according to my reading of the standard, as well as
the folks here:
http://stackoverflow.com/questions/15996333/does-c11-allow-non-anonymous-unions-to-contain-static-data-members
It is also allowed by clang.
9/5 : A union is a class defined with the class-key union; it holds only one
data member at a time
Section 9.4, in general, describes static members. It places no restrictions on
static members in union-type classes.
9.5/1: In a union, at most one of the non-static data members can be active at
any time, that is, the value of at most one of the non-static data members can
be stored in a union at any time.
There is no reason to specifically call out non-static data members unless
static data members can exist.
9.5/5: The member-specification of an anonymous union shall only define
non-static data members.
This only applies to anonymous unions. That this is specifically called out for
anonymous unions implies that it *is* allowed in general.
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 --- Comment #26 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Thu Feb 13 21:15:06 2014 New Revision: 207766 URL: http://gcc.gnu.org/viewcvs?rev=207766root=gccview=rev Log: 2014-02-13 Teresa Johnson tejohn...@google.com For Google b/12971524, backport r197994 to fix PR60141. 2013-04-16 Steven Bosscher ste...@gcc.gnu.org PR middle-end/43631 * emit-rtl.c (make_note_raw): New function. (link_insn_into_chain): New static inline function. (add_insn): Use it. (add_insn_before, add_insn_after): Factor insn chain linking code... (add_insn_before_nobb, add_insn_after_nobb): ...here, new functions using link_insn_into_chain. (note_outside_basic_block_p): New helper function for emit_note_after and emit_note_before. (emit_note_after): Use nobb variant of add_insn_after if the note should not be contained in a basic block. (emit_note_before): Use nobb variant of add_insn_before if the note should not be contained in a basic block. (emit_note_copy): Use make_note_raw. (emit_note): Likewise. * bb-reorder.c (insert_section_boundary_note): Remove hack to set BLOCK_FOR_INSN to NULL manually for NOTE_INSN_SWITCH_TEXT_SECTIONS. * jump.c (cleanup_barriers): Use reorder_insns_nobb to avoid making the moved barrier the tail of the basic block it follows. * var-tracking.c (pass_variable_tracking): Add TODO_verify_flow. Modified: branches/google/gcc-4_8/gcc/bb-reorder.c branches/google/gcc-4_8/gcc/emit-rtl.c branches/google/gcc-4_8/gcc/jump.c branches/google/gcc-4_8/gcc/var-tracking.c
[Bug rtl-optimization/60141] ICE in i386.c distance_non_agu_define_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60141
--- Comment #3 from Teresa Johnson tejohnson at google dot com ---
On Thu, Feb 13, 2014 at 9:22 AM, Teresa Johnson tejohn...@google.com wrote:
This appears to have been exposed, not caused, by the change to the
pass ordering. It is in fact a duplicate of PR middle-end/43631, which
was fixed on trunk by r197994 on 4/15/13. I will backport the fix to
google-4_8.
Backported fix as r207766:
2014-02-13 Teresa Johnson tejohn...@google.com
For Google b/12971524, backport r197994 to fix PR60141.
2013-04-16 Steven Bosscher ste...@gcc.gnu.org
PR middle-end/43631
* emit-rtl.c (make_note_raw): New function.
(link_insn_into_chain): New static inline function.
(add_insn): Use it.
(add_insn_before, add_insn_after): Factor insn chain linking code...
(add_insn_before_nobb, add_insn_after_nobb): ...here, new functions
using link_insn_into_chain.
(note_outside_basic_block_p): New helper function for emit_note_after
and emit_note_before.
(emit_note_after): Use nobb variant of add_insn_after if the note
should not be contained in a basic block.
(emit_note_before): Use nobb variant of add_insn_before if the note
should not be contained in a basic block.
(emit_note_copy): Use make_note_raw.
(emit_note): Likewise.
* bb-reorder.c (insert_section_boundary_note): Remove hack to set
BLOCK_FOR_INSN to NULL manually for NOTE_INSN_SWITCH_TEXT_SECTIONS.
* jump.c (cleanup_barriers): Use reorder_insns_nobb to avoid making
the moved barrier the tail of the basic block it follows.
* var-tracking.c (pass_variable_tracking): Add TODO_verify_flow.
Teresa
Teresa
On Mon, Feb 10, 2014 at 4:49 PM, shenhan at google dot com
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60141
Bug ID: 60141
Summary: ICE in i386.c distance_non_agu_define_in_bb
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shenhan at google dot com
CC: llozano at google dot com, tejohnson at google dot com
This only fails for google/gcc-4_8
To reproduce -
configure:
~/gcc.git/configure --disable-bootstrap --enable-languages='c,c++'
--disable-multilib --disable-libatomic --disable-libmudflap
--disable-libssp --enable-libgomp --enable-__cxa_atexit
--enable-checking=release --disable-libquadmath --disable-libitm
--enable-esp --with-arch=atom --with-tune=atom --enable-frame-pointer
Build -
make -j40
Compile a testcase -
./gcc/xgcc -B./gcc -g -O2 -fpic -c -m32 ~/SROA.pp.cpp
Output -
SROA.cpp: In member function ‘void
{anonymous}::AllocaPartitioning::UseBuilder::operator()()’:
SROA.cpp:873:3: internal compiler error: Segmentation fault
0x8d0baf crash_signal
../../../gcc.git/gcc/toplev.c:346
0xa798c8 distance_non_agu_define_in_bb
../../../gcc.git/gcc/config/i386/i386.c:17506
0xa79cad distance_non_agu_define
../../../gcc.git/gcc/config/i386/i386.c:17564
0xa79cad ix86_lea_outperforms
../../../gcc.git/gcc/config/i386/i386.c:17730
0xb8e6ca output_89
../../../gcc.git/gcc/config/i386/i386.md:2152
0x72a5c3 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../../gcc.git/gcc/final.c:2895
0x72ae84 final(rtx_def*, _IO_FILE*, int)
../../../gcc.git/gcc/final.c:1986
0x72b46d rest_of_handle_final
../../../gcc.git/gcc/final.c:4432
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
Debugging shows that in distance_non_agu_define_in_bb (i386.c),
BLOCK_FOR_INSN(start) returns zero, which caused this ICE.
A preliminary bisecting in google/gcc-4_8 shows that the follow CL introduces
this ICE. (So I cc'ed Teresa Johnson)
commit 907fca49eae2da51a328eb192c691cc24f69e6af
Author: tejohnson tejohnson@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Dec 2 18:28:19 2013 +
Backport the last few fixes for -freorder-blocks-and-partition from
trunk to google/4_8: r204985, r205057 and r205243
r204985 | tejohnson | 2013-11-18 14:38:51 -0800 (Mon, 18 Nov 2013) |
15
lines
This patch fixes an lto profiledbootstrap failure with
-freorder-blocks-and-partition enabled. Currently compgotos
is the only pass that goes into cfglayout mode after bb reordering,
which is undesireable (and in the case of
-freorder-blocks-and-partition
can cause illegal partitioning) because of the optimizations
[Bug c++/60185] [4.9 Regression] ICE with invalid default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60185 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.7.0, 4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/60185] New: [4.9 Regression] ICE with invalid default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60185
Bug ID: 60185
Summary: [4.9 Regression] ICE with invalid default parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet triggers an ICE on trunk:
templateint struct A
{
int i;
A() { void foo(int=i); }
};
A0 a;
bug.cc: In instantiation of 'Aanonymous ::A() [with int anonymous = 0]':
bug.cc:7:6: required from here
bug.cc:4:14: internal compiler error: in tsubst_copy, at cp/pt.c:12375
A() { void foo(int=i); }
^
0x62bfa5 tsubst_copy
../../gcc/gcc/cp/pt.c:12375
0x60687b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14974
0x607dcb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14035
0x60895b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14018
0x608054 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14764
0x6115c6 tsubst_expr
../../gcc/gcc/cp/pt.c:13812
0x61862c tsubst_default_argument(tree_node*, tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:10094
0x631760 tsubst_default_arguments
../../gcc/gcc/cp/pt.c:10143
0x631760 tsubst_decl
../../gcc/gcc/cp/pt.c:10521
0x61be9f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11357
0x6127fb tsubst_expr
../../gcc/gcc/cp/pt.c:13276
0x61208c tsubst_expr
../../gcc/gcc/cp/pt.c:13424
0x611093 tsubst_expr
../../gcc/gcc/cp/pt.c:13219
0x61208c tsubst_expr
../../gcc/gcc/cp/pt.c:13424
0x60f2a9 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19690
0x64d8c7 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19806
0x688bed cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4148
Please submit a full bug report, [etc.]
This is a recent regression, introduced between 2014-01-28 and 2014-02-01.
The bug is related to PR39055. It is actually the original testcase
of this PR (which never made it into the testsuite). Only a non-template
version of this testcase was added as
gcc/testsuite/g++.dg/overload/defarg5.C
[Bug c++/60186] New: [4.9 Regression] [c++11] ICE with invalid value in constexpr array initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60186
Bug ID: 60186
Summary: [4.9 Regression] [c++11] ICE with invalid value in
constexpr array initializer
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11)
triggers an ICE on trunk:
=
templatetypename void foo(int i)
{
constexpr int a[] = { i };
}
=
bug.cc: In function 'void foo(int)':
bug.cc:3:27: internal compiler error: unexpected expression 'i' of kind
implicit_conv_expr
constexpr int a[] = { i };
^
0x73e03f cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:9787
0x741085 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:9807
0x743d1b maybe_constant_value(tree_node*)
../../gcc/gcc/cp/semantics.c:9917
0x7499a8 maybe_constant_init(tree_node*)
../../gcc/gcc/cp/semantics.c:9934
0x6506d4 process_init_constructor_array
../../gcc/gcc/cp/typeck2.c:1195
0x6506d4 process_init_constructor
../../gcc/gcc/cp/typeck2.c:1476
0x6506d4 digest_init_r
../../gcc/gcc/cp/typeck2.c:1053
0x651f2a digest_init_flags
../../gcc/gcc/cp/typeck2.c:1098
0x651f2a store_init_value(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, int)
../../gcc/gcc/cp/typeck2.c:786
0x5c7195 check_initializer
../../gcc/gcc/cp/decl.c:5777
0x5d9ef0 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6293
0x6c816d cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16815
0x6c9929 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6acc13 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6add31 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10733
0x6ae37b cp_parser_statement
../../gcc/gcc/cp/parser.c:9467
0x6af169 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9745
0x6af2d6 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9699
0x6c34ab cp_parser_function_body
../../gcc/gcc/cp/parser.c:18641
0x6c34ab cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18677
Please submit a full bug report, [etc.]
The regression was introduced between 2014-01-14 and 2014-01-21.
[Bug c++/60186] [4.9 Regression] [c++11] ICE with invalid value in constexpr array initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60186 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.7.0, 4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug debug/60152] [4.9 Regression] multiple AT_calling_convention attributes generated after r205679
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60152 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 13 22:42:44 2014 New Revision: 207770 URL: http://gcc.gnu.org/viewcvs?rev=207770root=gccview=rev Log: PR debug/60152 * dwarf2out.c (gen_subprogram_die): Don't call add_calling_convention_attribute if subr_die is old_die. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/60152] [4.9 Regression] multiple AT_calling_convention attributes generated after r205679
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60152 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/60187] New: [4.7/4.8/4.9 Regression] [c++11] ICE with parameter pack as underlying type for enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60187
Bug ID: 60187
Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with parameter
pack as underlying type for enum
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11)
triggers an ICE since GCC 4.6.0:
==
templatetypename... T struct A
{
enum E : T {};
};
Aint a;
==
bug.cc: In instantiation of 'struct Aint':
bug.cc:6:8: required from here
bug.cc:3:8: internal compiler error: in dependent_type_p, at cp/pt.c:20283
enum E : T {};
^
0x5ff408 dependent_type_p(tree_node*)
../../gcc/gcc/cp/pt.c:20283
0x5d1e29 start_enum(tree_node*, tree_node*, tree_node*, bool, bool*)
../../gcc/gcc/cp/decl.c:12604
0x624e54 lookup_template_class_1
../../gcc/gcc/cp/pt.c:7518
0x624e54 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:7725
0x629673 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10031
0x61b9f1 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11436
0x62e0d3 tsubst_decl
../../gcc/gcc/cp/pt.c:10824
0x61be9f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11357
0x64a34a instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9010
0x64a34a instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9274
0x6db973 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:134
0x5c4f38 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4719
0x5ede67 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4682
0x6c7e9e cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16680
0x6c9929 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6acc13 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d3ec2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d2bb8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d445a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d445a c_parse_file()
../../gcc/gcc/cp/parser.c:31536
Please submit a full bug report, [etc.]
The code was correctly rejected by GCC 4.4.0
and wrongly accepted by GCC 4.4.1-4.5.3.
[Bug c++/60188] New: [c++11] ICE with parameter pack in default template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60188
Bug ID: 60188
Summary: [c++11] ICE with parameter pack in default template
parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11)
triggers an ICE since GCC 4.3.0:
===
struct A
{
int i;
};
templatetypename... T, int A::* = T::i void foo() {}
template void fooA();
===
bug.cc: In substitution of 'templateclass ... T, int A::* anonymous void
foo() [with T = {A}; int A::* anonymous = missing]':
bug.cc:8:22: required from here
bug.cc:6:36: internal compiler error: in dependent_type_p, at cp/pt.c:20283
templatetypename... T, int A::* = T::i void foo() {}
^
0x5ff408 dependent_type_p(tree_node*)
../../gcc/gcc/cp/pt.c:20283
0x5ffbc0 dependent_scope_p(tree_node*)
../../gcc/gcc/cp/pt.c:20314
0x6321b4 tsubst_qualified_id
../../gcc/gcc/cp/pt.c:12263
0x609c4c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14134
0x6115c6 tsubst_expr
../../gcc/gcc/cp/pt.c:13812
0x61e39c tsubst_template_arg
../../gcc/gcc/cp/pt.c:9293
0x639b80 type_unification_real
../../gcc/gcc/cp/pt.c:16326
0x64260a fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:15671
0x6432ca get_bindings
../../gcc/gcc/cp/pt.c:18402
0x643dfe determine_specialization
../../gcc/gcc/cp/pt.c:1968
0x644f31 check_explicit_specialization(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/pt.c:2636
0x5516f1 grokfndecl
../../gcc/gcc/cp/decl.c:7724
0x5ebfc4 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:10798
0x6c9d5a cp_parser_explicit_instantiation
../../gcc/gcc/cp/parser.c:14111
0x6d3fef cp_parser_declaration
../../gcc/gcc/cp/parser.c:10956
0x6d2bb8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d445a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d445a c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f37c3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60189] New: ICE with invalid use of _Cilk_sync
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60189
Bug ID: 60189
Summary: ICE with invalid use of _Cilk_sync
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -fcilkplus)
triggers an ICE on trunk:
===
void foo()
{
_Cilk_sync return;
}
===
bug.cc: In function 'void foo()':
bug.cc:5:3: internal compiler error: Segmentation fault
_Cilk_sync return;
^
0xba523f crash_signal
../../gcc/gcc/toplev.c:337
0x6b9008 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9635
0x6ae398 cp_parser_statement
../../gcc/gcc/cp/parser.c:9473
0x6af169 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9745
0x6af2d6 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9699
0x6c34ab cp_parser_function_body
../../gcc/gcc/cp/parser.c:18641
0x6c34ab cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18677
0x6c77f2 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22792
0x6c8691 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22704
0x6c8691 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16585
0x6c9929 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6acc13 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d3ec2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d2bb8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d445a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d445a c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f37c3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60189] ICE with invalid use of _Cilk_sync
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60189 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||bviyer at gcc dot gnu.org Known to fail||4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Balaji, this looks like your domain, would you mind having a look?
[Bug c++/60190] New: [c++1y] ICE with invalid return type of template lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60190
Bug ID: 60190
Summary: [c++1y] ICE with invalid return type of template
lambda
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid line of code (compiled with -std=c++1y) triggers
an ICE on trunk:
==
auto f = []int() - int() {};
==
bug.cc:1:27: error: 'operator()' declared as function returning a function
auto f = []int() - int() {};
^
bug.cc:1:29: internal compiler error: in poplevel_class, at
cp/name-lookup.c:2951
auto f = []int() - int() {};
^
0x77d247 poplevel_class()
../../gcc/gcc/cp/name-lookup.c:2951
0x6626b8 popclass()
../../gcc/gcc/cp/class.c:7127
0x67756d finish_struct(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:6808
0x6b08a7 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:8768
0x6b08a7 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4305
0x6b20ed cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:5971
0x6b50c6 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7170
0x6b5def cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7874
0x6b62e1 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8112
0x6b67a5 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8162
0x6b67a5 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8372
0x6c82ce cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16758
0x6c9929 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6acc13 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d3ec2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d2bb8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d445a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d445a c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f37c3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 Gregory R. Warnes gcc-bugs at warnes dot net changed: What|Removed |Added CC||gcc-bugs at warnes dot net --- Comment #3 from Gregory R. Warnes gcc-bugs at warnes dot net --- +1 I've just spent several days tracking down the cause of the mysterious hangs in processes forked by R (http://www.r-project.org). A resolution of this issue would be very helpful.
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Joey Ye joey.ye at arm dot com --- Reopen per-requested.
[Bug c++/60187] [4.7/4.8/4.9 Regression] [c++11] ICE with parameter pack as underlying type for enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60187 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-14 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- ICE started with r165935.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- I can reproduce this with trunk version. Build options are `-O2 -funroll-loops -fsanitize=address'.
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
Bernd Edlinger bernd.edlinger at hotmail dot de changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
The test case fails on current trunk:
longfunc:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mulr3, r0, r3
push{r4, r5}
umullr4, r5, r0, r2
mlar1, r2, r1, r3
movr0, r4
addr5, r5, r1
movr1, r5
pop{r4, r5}
bxlr
.sizelongfunc, .-longfunc
.identGCC: (GNU) 4.9.0 20140209 (experimental)
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575 --- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de --- $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-4.9-20140209/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard Thread model: posix gcc version 4.9.0 20140209 (experimental) (GCC)
[Bug c++/60186] [4.9 Regression] [c++11] ICE with invalid value in constexpr array initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60186 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-14 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r206639, and eventhough that change has been partly reverted in r207051, the ICE continues to trigger.
