[Bug c++/58568] [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-30 CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r196742.
[Bug c/58564] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-09-30 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- Sorry, missed that outer condition is 0 ... boolean-typed-expr. Can confirm this issue. Btw this condition has to be always false for unsigned 1-bit precision typed integrals.
[Bug c++/58567] [4.8/4.9 Regression] ICE with invalid loop variable in template using openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58567 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-30 CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r188939.
[Bug rtl-optimization/55190] [SH] ivopts causes loop setup bloat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190 bin.cheng amker.cheng at gmail dot com changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #3 from bin.cheng amker.cheng at gmail dot com --- ARM can benefit from doloop structure too, but it is implemented in different way. ARM backend defines special addsi_compare pattern and let combine pass combine decrement and comparison instruction, thus saving the comparison instruction. IVOPT can be improved to select two iv candidates for the example loop, with auto-increment one for the memory access and decrement one for loop exit check. This is especially good for target supports both doloop and auto-increment instructions like ARM and SH. BUT most hand-written loops have incremental basic iv, so IVOPT depends on previous pass ivcanon to rewrite it into decremental iv, like below: for (i = 0; i 100; i++) //loop body for (i = 100; i 0; i--) //modified loop body Unfortunately, ivcanon pass only do such loop transformation for loop which iterates constant number times. It seems difficult for RTL loop passes to revert decision made by IVOPT, so I think it should be done in GIMPLE IVOPT. I will give it a try. Thanks.
[Bug rtl-optimization/58577] New: Capacita regresses with 202619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58577 Bug ID: 58577 Summary: Capacita regresses with 202619 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Ganesh.Gopalasubramanian at amd dot com CC: rguenther at suse dot de capactia from pb11 (polyhedron) regresses with revision 202619. The opensuse polyhedron runs shows this. (REF:http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt) 130916.99962 7.01 15.45 74.94 40.86 8.82 16.19 4.89 99.45 130917.86399 7.76 15.45 44.48 -1.00 9.09 16.16 4.97 10805.10 Execution log shows a string of NaNs snip before commit Calculating G Transforming G Starting Bi-CGSTAB, for accuracy 1e-6, N= 1048576 |r|/|y| = 9.09707323E-02 |r|/|y| = 9.78626590E-03 |r|/|y| = 7.68897077E-03 |r|/|y| = 1.48448779E-03 |r|/|y| = 2.01700241E-04 /snip Capacita run built with GCC49 trunk gives out the following output. snip after commit Calculating G Transforming G Starting Bi-CGSTAB, for accuracy 1e-6, N= 1048576 |r|/|y| = NaN |r|/|y| = NaN |r|/|y| = NaN |r|/|y| = NaN |r|/|y| = NaN /snip
[Bug c++/58563] [4.9 Regression] [c++11] ICE calling invalid destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58563 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-30 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|[c++11] ICE calling invalid |[4.9 Regression] [c++11] |destructor |ICE calling invalid ||destructor Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Does not ICE for me with 4.7/4.8, but with trunk it does.
[Bug libstdc++/58576] std::regex_match() reports mismatched braces on a valid regex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58576 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- [:alnum:] only matches the six characters :almnu. If you want to match any letter or digit you have to write [[:alnum:]].
[Bug tree-optimization/58532] [4.9 Regression] bootstrap failure with BOOT_CFLAGS=-g -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58532 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Sep 30 07:44:46 2013 New Revision: 203024 URL: http://gcc.gnu.org/viewcvs?rev=203024root=gccview=rev Log: 2013-09-30 Richard Biener rguent...@suse.de PR middle-end/58532 * tree-cfg.c (make_abnormal_goto_edges): Skip debug statements before looking for setjmp-like calls. * g++.dg/torture/pr58552.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr58552.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug tree-optimization/58532] [4.9 Regression] bootstrap failure with BOOT_CFLAGS=-g -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58532 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58552] [4.9 Regression] -fcompare-debug failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58552 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58553] New fail in PASS-FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-30 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Jeff, the niter code returns the number of latch executions, so adding one is correct if the memset happens before the latch (the code doesn't try to distinguish both cases but it now has to, after I removed the restriction of distributing only exactly loops with a single basic block). I'll fix it.
[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug c++/58561] [4.8/4.9 Regression] [c++11] ICE using declaration of function with auto in return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58561 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-30 CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Summary|[c++11] ICE using |[4.8/4.9 Regression] |declaration of function |[c++11] ICE using |with auto in return type|declaration of function ||with auto in return type Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r185768.
[Bug c++/58560] [4.9 Regression] [c++11] ICE with auto in typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58560 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-30 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.9 Regression] [c++11] |[c++11] ICE with auto in|ICE with auto in typedef |typedef | Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- This doesn't ICE for me with latest 4.7/4.8. But trunk ICEs.
[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|c |middle-end Target Milestone|--- |4.7.4 Summary|possible wrong code bug at |[4.7/4.8/4.9 Regression] |-O0 |possible wrong code bug at ||-O0 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- I think the bug is in the /* A 0 ? sign bit of A : 0 is simply (A sign bit of A). */ if (TREE_CODE (arg0) == LT_EXPR integer_zerop (TREE_OPERAND (arg0, 1)) integer_zerop (op2) (tem = sign_bit_p (TREE_OPERAND (arg0, 0), arg1))) ... transformation in fold_ternary_loc or sign_bit_p or combination thereof. We get here with arg0 ((int) (d == c a != 1)) 0, arg1 1U and arg2 0U, sign_bit_p (surprisingly) looks through zero extensions (of bool to int) and returns (d == c a != 1) and we incorrectly fold it as (d == c a != 1) 1.
[Bug c++/58560] [4.7/4.8/4.9 Regression] [c++11] ICE with auto in typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58560 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9 Regression] [c++11]|[4.7/4.8/4.9 Regression] |ICE with auto in typedef|[c++11] ICE with auto in ||typedef --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Oops, sorry, --enable-checking=release crept in.
[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507 --- Comment #3 from Nick Clifton nickc at redhat dot com --- Hi Ilya, I have now checked my patches in. If you use the latest (development) FSF sources for GCC and the binutils you should see that correct parsing of the -mmcu command line option and the correct display of the MSP430 architecture variant. Cheers Nick
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
bin.cheng amker.cheng at gmail dot com changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #15 from bin.cheng amker.cheng at gmail dot com ---
There must be another scenario for the example, and in this case example:
int test_0 (char* p, int c)
{
int r = 0;
r += *p++;
r += *p++;
r += *p++;
return r;
}
should be translated into sth like:
//...
ldrb [rx]
ldrb [rx+1]
ldrb [rx+2]
add rx, rx, #3
//...
This way all loads are independent and can be issued on super scalar machine.
Actuall for targets like arm which supports post-increment constant (other than
size of memory access), it can be further changed into:
//...
ldrb [rx], #3
ldrb [rx-2]
ldrb [rx-1]
//...
For now auto-increment pass can't do this optimization. I once have a patch
for this but benchmark shows the case is not common.
This case is common especially after loop unrolling and rtl passes deliberately
break down long dependence of RX, which I think is right.
[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30932 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30932action=edit gcc49-pr58564.patch Untested fix. Note, this patch doesn't attempt to fold the zero extension of something 0 into 0 resp. side-effects of something, 0, because I think we are generally trying to move away from adding further new stuff to fold-const.c, and rather should improve GIMPLE optimizations.
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||galens at capaccess dot org --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 58576 has been marked as a duplicate of this bug. ***
[Bug libstdc++/58576] std::regex_match() reports mismatched braces on a valid regex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58576 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- regex doesn't work in GCC 4.8 Your test works with the GCC trunk, where the work to implement regex is being done. *** This bug has been marked as a duplicate of bug 53631 ***
[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30933 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30933action=edit gcc49-pr58564-nonnegative.patch Actually, teaching fold that it should fold that 0 into 0 is easy, just needs making some checks less strict (they were considering only INTEGER_TYPE, forgetting about BOOLEAN_TYPE or ENUMERAL_TYPE which IMHO can be handled the same). This latter patch I'm obviously not going to propose for the older branches.
[Bug tree-optimization/58577] [4.9 Regression] Capacita regresses with 202619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58577 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-30 Component|rtl-optimization|tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|Capacita regresses with |[4.9 Regression] Capacita |202619 |regresses with 202619 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug bootstrap/58572] [4.9 regression] make install uses -Wno-narrowing with system compiler which does not know about it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug sanitizer/58543] Invalid unpoisoning of stack redzones on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
--- Comment #4 from dodji at seketeli dot org dodji at seketeli dot org ---
Thank you for reporting this bug.
Please find my comments below,
y.gribov at samsung dot com gcc-bugzi...@gcc.gnu.org a écrit:
Prologue seems to poison words at frame_shadow_base + { 0, 4, 8, 12, 16, 24,
28}:
Right.
add r4, r3, #536870912
ldr r3, .L3+8
str r3, [r4]
ldr r3, .L3+12
str r3, [r4, #4]
ldr r3, .L3+16
str r3, [r4, #8]
ldr r3, .L3+20
str r3, [r4, #12]
ldr r3, .L3+16
str r3, [r4, #16]
ldr r3, .L3+20
str r3, [r4, #24]
ldr r3, .L3+24
str r3, [r4, #28]
Whereas epilogue poisons frame_shadow_base + { 0, 4, 8, 12, 16, 40, 44}:
I guess you mean *un*poison here.
add r3, r4, #20
.L1:
mov r2, #0
str r2, [r4]
add r4, r4, #4
cmp r4, r3
bcc .L1
My understanding is that in the loop above, we are setting the memory
pointed to by frame_shadow_base + { 0, 4, 8, 12, 16} to zero.
And in the code below, we are preparing to set the memory pointed to by
frame_shadow_base + {24, 28} to zero.
add r3, r4, #24 ; r3 gets invalid value here
Why is r3 invalid? It's being set to #24, so that the strb r2, [r3]
below writes a zero byte to [r4,#24].
Or what am I missing?
mov r2, #0
strb r2, [r3]
add r3, r3, #1
mov r2, #0
strb r2, [r3]
add r3, r3, #1
mov r2, #0
strb r2, [r3]
add r3, r3, #1
mov r2, #0
strb r2, [r3]
add r3, r3, #1
mov r2, #0
strb r2, [r3]
add r3, r3, #1
mov r2, #0
strb r2, [r3]
add r3, r3, #1
mov r2, #0
strb r2, [r3]
add r3, r3, #1
mov r2, #0
strb r2, [r3]
This causes some shadow bytes to remain set after function returns. Those may
trigger incorrect Asan errors later.
I am guessing that you have a short and self contained example of an
asan error that is caused by a wrong epilogue. Would it be possible
that you file it so that I can understand better what is going on?
Thanks.
[Bug c++/58567] [4.8/4.9 Regression] ICE with invalid loop variable in template using openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58567 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug c++/58568] [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug tree-optimization/58570] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|wrong code at -Os and above |[4.9 Regression] wrong code |on x86_64-linux-gnu (both |at -Os and above on |32-bit and 64-bit modes)|x86_64-linux-gnu (both ||32-bit and 64-bit modes)
[Bug tree-optimization/58556] [4.9 Regression] gen-vect-26.c / gen-vect-28.c regression merging from r202839 to r202981
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58556 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-30 CC||xinliangli at gmail dot com Target Milestone|--- |4.9.0 Summary|gen-vect-26.c / |[4.9 Regression] |gen-vect-28.c regression|gen-vect-26.c / |merging from r202839 to |gen-vect-28.c regression |r202981 |merging from r202839 to ||r202981 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The test uses -O2 -ftree-vectorize which has changed allowed peeling.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c++ |middle-end Target Milestone|--- |4.9.0 Summary|Floating point exception in |[4.9 Regression] Floating |want_inline_self_recursive_ |point exception in |call_p |want_inline_self_recursive_ ||call_p
[Bug sanitizer/58543] Invalid unpoisoning of stack redzones on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543
--- Comment #5 from Yury Gribov y.gribov at samsung dot com ---
I guess you mean *un*poison here.
Right you are!
My understanding is that in the loop above, we are setting the memory
pointed to by frame_shadow_base + { 0, 4, 8, 12, 16} to zero.
And in the code below, we are preparing to set the memory pointed to by
frame_shadow_base + {24, 28} to zero.
Exactly.
add r3, r4, #24 ; r3 gets invalid value here
Why is r3 invalid? It's being set to #24,
so that the strb r2, [r3] below writes a zero byte to [r4,#24].
Not really - it's set to #40 because r4 was changed to #16 inside the loop
Would it be possible that you file it
so that I can understand better what is going on?
Sure - simply compile the attached repro with `-O0 -fsanitize-address'. But
note that you need to use ARM target because x86 does not trigger this bug
(most probably because it uses different code path in asan_clear_shadow).
-Y
[Bug tree-optimization/58556] [4.9 Regression] gen-vect-26.c / gen-vect-28.c regression merging from r202839 to r202981
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58556 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|arc-elf32 |arc-elf32, arm-none-eabi CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Also appears on arm.
[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Ok, this one shows that pattern detection does not consider conditionally executed stores properly. I have a fix.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-30 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Thus confirmed.
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I'd say the bug is in s390_chunkify_start: if (GET_CODE (pat) == PARALLEL XVECLEN (pat, 0) 2) pat = XVECEXP (pat, 0, 0); Dunno what exactly the 2 condition has been added for, JUMP_INSNs with PARALLEL with XVECLEN (pat, 0) == 2 are: 1) casesi_jump 2) *cmp_and_br_signed_mode, *cmp_and_br_unsigned_mode, *icmp_and_br_signed_mode, *icmp_and_br_unsigned_mode 3) *ccraw_to_int I can understand why you wouldn't want to handle 1) in there, and supposedly 3) should be split before machine reorg or worst case at the start of it. But 2), this case, it looks wrong not to do anything here. Note that similar condition is in s390_split_branches, no idea what do you want to do there. But perhaps TARGET_Z10 implies TARGET_ZARCH and thus s390_split_branches would be never called.
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30934 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30934action=edit Possible fix Possible fix.
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30935 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30935action=edit Alternate fix Another possibility. If the check is there really just to prevent handling tablejumps, I wonder why we can't do the tablejump handling first and only if it didn't do anything, handle all other jumps.
[Bug tree-optimization/58553] New fail in PASS-FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Testcase that also fails on x86_64:
#define MAX_LENGTH 96
#define SEQUENCE_LENGTH 31
static struct {
char buf[MAX_LENGTH + 1];
} u1, u2;
extern void abort (void);
int main ()
{
int i;
char c;
u1.buf[0] = '\0';
for (i = 0, c = 'A'; i MAX_LENGTH; i++, c++)
{
u1.buf[i] = 'a';
if (c = 'A' + SEQUENCE_LENGTH)
c = 'A';
u2.buf[i] = c;
}
if (u1.buf[MAX_LENGTH] != '\0')
abort ();
return 0;
}
jump threading rotates the loop in interesting ways.
[Bug tree-optimization/57608] [4.8/4.9 Regression] wrong code for expression at -O3 on x86_64-linux-gnu with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57608 Mikael Pettersson mikpelinux at gmail dot com changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com --- This wrong-code stopped occurring on trunk with r201251, and on 4.8 branch with r202388 (PR57521). The latter is a backport of trunk's r202019 (PR57521), and applying that to trunk @ r201250 also fixes the wrong-code.
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org --- Thanks for tracking this down! (In reply to Jakub Jelinek from comment #2) I'd say the bug is in s390_chunkify_start: if (GET_CODE (pat) == PARALLEL XVECLEN (pat, 0) 2) pat = XVECEXP (pat, 0, 0); Dunno what exactly the 2 condition has been added for, JUMP_INSNs with The more complex loop jumps might have more than 2 I think. PARALLEL with XVECLEN (pat, 0) == 2 are: 1) casesi_jump 2) *cmp_and_br_signed_mode, *cmp_and_br_unsigned_mode, *icmp_and_br_signed_mode, *icmp_and_br_unsigned_mode 3) *ccraw_to_int I can understand why you wouldn't want to handle 1) in there, and supposedly 3) should be split before machine reorg or worst case at the start of it. But 2), this case, it looks wrong not to do anything here. Note that similar condition is in s390_split_branches, no idea what do you want to do there. But perhaps TARGET_Z10 implies TARGET_ZARCH and thus s390_split_branches would be never called. Exactly.
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #6 from Andreas Krebbel krebbel at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) Created attachment 30935 [details] Alternate fix Another possibility. If the check is there really just to prevent handling tablejumps, I wonder why we can't do the tablejump handling first and only if it didn't do anything, handle all other jumps. I agree with that patch. Since tablejump_p is available it is easier to read the other way around. Thanks!
[Bug other/58578] New: mpfr tasinh test doesn't terminate when built with trunk for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58578 Bug ID: 58578 Summary: mpfr tasinh test doesn't terminate when built with trunk for ARM Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: kuganv at linaro dot org Created attachment 30936 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30936action=edit preprocessed testcase mpfr tasinh 3.1.1. does not produce correct code for optimization level -O1 and above. Preprocessed ouput for a reduced testcase is attached. For the reduced testcase, if-condition at line 45 (original source) is evaluated true whereas it is not when compiled with -O1 and run. This can be easily verified with gdb. gcc version 4.9.0 20130922 (experimental)
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati jjcogliati-r1 at yahoo dot com changed: What|Removed |Added Attachment #30913|0 |1 is obsolete|| --- Comment #20 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- Created attachment 30937 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30937action=edit Patch to add -Wfloat-conversion option against trunk Added one more changed needed to get it to compile (which only occured if I did an rm -Rf in the build directry, the make bootstrap didn't catch the libcpp warning found.) The only thing I have left is to possibly modify the test scripts (to use -Wfloat-conversion instead of -Wconversion for the relevant tests) and recompile against the current trunk.
[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Sep 30 12:22:00 2013 New Revision: 203031 URL: http://gcc.gnu.org/viewcvs?rev=203031root=gccview=rev Log: 2013-09-30 Richard Biener rguent...@suse.de PR tree-optimization/58554 * tree-loop-distribution.c (classify_partition): Require unconditionally executed stores for memcpy and memset recognition. (tree_loop_distribution): Calculate dominance info. * gcc.dg/torture/pr58554.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58554.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58553] New fail in PASS-FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553 Bug 58553 depends on bug 58554, which changed state. Bug 58554 Summary: [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/58577] [4.9 Regression] Capacita regresses with 202619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58577 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Let's see if it is fixed by the fixes for PR58553 and PR58554.
[Bug tree-optimization/58554] [4.9 Regression] Revision 202619 causes runtime failure in CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||Ganesh.Gopalasubramanian@am ||d.com --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 58577 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/58577] [4.9 Regression] Capacita regresses with 202619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58577 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- It is. *** This bug has been marked as a duplicate of bug 58554 ***
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #7 from Andreas Krebbel krebbel at gcc dot gnu.org --- Created attachment 30938 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30938action=edit Alternate fix - v2 Since tablejump_p is checking for JUMP_P anyway we could move the check even outside the jump insn check. I've also changed s390_split_branches to exit early for table jumps. Untested so far.
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30939 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30939action=edit gcc48-pr58574.patch Yeah, perhaps. I'm attaching 4.8 version of the patch, which wasn't using tablejump_p at all. The patch also contains a testcase (which should be added to the 4.9 version of the patch too).
[Bug target/58574] [4.8/4.9 Regression] Wrong code due to s390x machine reorg pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58574 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Note that I can't test this easily on the trunk, the partition I have access to has just 2 CPUs and 1GB of RAM, bootstrap/regtest would be very slow if it worked at all, but am testing the 4.8 version of the patch (via a build system scratch build).
[Bug fortran/58579] New: Memory allocation fails when calling character-valued function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58579 Bug ID: 58579 Summary: Memory allocation fails when calling character-valued function Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: apbartok at gmail dot com This is a problem I found with gfortran 4.6.3, 4.7.3, 4.8.0 on $ uname -a Linux 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux $ gfortran -v Using built-in specs. COLLECT_GCC=/usr/bin/gfortran-4.8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.0-3ubuntu3~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64 --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.8.0 (Ubuntu/Linaro 4.8.0-3ubuntu3~12.04) and gfortran 4.7.3 on $ uname -a Darwin 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.3/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.7.3/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.7 --with-libiconv-prefix=/opt/local --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.7 --with-gxx-include-dir=/opt/local/include/gcc47/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-ppl-version-check --with-pkgversion='MacPorts gcc47 4.7.3_1' Thread model: posix gcc version 4.7.3 (MacPorts gcc47 4.7.3_1) I don't think this is a simple stack issue: $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 128297 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 128297 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited The following test case runs fine $ echo 33554431 | ./a.out but this one fails $ echo 33554432 | ./a.out Operating system error: Cannot allocate memory Memory allocation failed compilation: $ gfortran -g -Wall -Wextra -fno-strict-aliasing -fwrapv -fcheck=all -fdump-core -fbacktrace test_char_array.f95 (without the -f options the code simply returns a segmentation fault.) code: $ cat test_char_array.f95 program test_char implicit none integer :: i read*, i print*, trim(test(i)) contains function test(i) integer, intent(in) :: i character(len=i) :: test test(1:1) = A endfunction test endprogram test_char Many thanks in advance. Albert
[Bug preprocessor/58580] New: preprocessor goes OOM with warning for zero literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580 Bug ID: 58580 Summary: preprocessor goes OOM with warning for zero literals Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Created attachment 30940 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30940action=edit testcase g++-4.8 -E test.cpp # 1 test.cpp # 1 command-line # 1 test.cpp test.cpp:1:1: warning: null character(s) preserved in literal [enabled by default] ^ test.cpp:2:1: warning: null character(s) preserved in literal [enabled by default] test.cpp:3:1: warning: null character(s) preserved in literal [enabled by default] test.cpp:4:1: warning: null character(s) preserved in literal [enabled by default] cc1plus: out of memory allocating 1677721600 bytes after a total of 405504 bytes use a suitable ulimit -v to force the error.
[Bug preprocessor/58580] [4.8/4.9 Regression] preprocessor goes OOM with warning for zero literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58580 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2 Summary|preprocessor goes OOM with |[4.8/4.9 Regression] |warning for zero literals |preprocessor goes OOM with ||warning for zero literals --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Works with 4.7.
[Bug other/58578] [4.9 Regression] mpfr tasinh test doesn't terminate when built with trunk for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58578 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-30 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Please can you add the output of gcc -v that was used when compiling this test.
[Bug other/58578] [4.9 Regression] mpfr tasinh test doesn't terminate when built with trunk for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58578 --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- I suspect this was introduced with r197527
[Bug rtl-optimization/58322] similar simple code produces different (and non-optimal) result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58322
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-09-30
Known to work||4.6.2
Ever confirmed|0 |1
Known to fail||4.7.2, 4.8.1
--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org ---
Confirmed.
test1 should use direct addressing.
With addresses 0x60 that can use IN/OUT everything is fine; the indirect
addressing starts with adresses = 0x60:
== Code ==
#define UCSR0B (*(volatile unsigned char*) 0x60)
void test1 (void)
{
UCSR0B |= 1;
}
void test2 (char flag)
{
if (flag)
UCSR0B |= 1;
}
== Command Line ==
$ avr-gcc bug.c -S -Os -mmcu=atmega8 -v
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.8 --enable-languages=c,c++ --disable-nls
--disable-shared --with-dwarf2
Thread model: single
gcc version 4.8.0 20130306 (experimental) (GCC)
[Bug tree-optimization/58553] New fail in PASS-FAIL: gcc.c-torture/execute/memcpy-2.c execution on arm and aarch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553 --- Comment #8 from Jeffrey A. Law law at redhat dot com --- Yes, threading is rotating the loop in interesting ways -- I was going to look at that independently of the correctness issue. One of the things I've noticed as I've been laying down some infrastructure for the FSA optimization is much of the work Zdenek did to prevent threading through loop headers and such isn't working as well as we'd like.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #27 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 30 17:42:31 2013 New Revision: 203035 URL: http://gcc.gnu.org/viewcvs?rev=203035root=gccview=rev Log: 2013-09-30 Chris Jefferson ch...@bubblescope.net PR libstdc++/58437 * include/bits/stl_algo.h (__move_median_first): Rename to __move_median_to_first, change to take an addition argument. (__unguarded_partition_pivot): Adjust. * testsuite/performance/25_algorithms/sort.cc: New. * testsuite/performance/25_algorithms/sort_heap.cc: Likewise. * testsuite/performance/25_algorithms/stable_sort.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/performance/25_algorithms/sort.cc trunk/libstdc++-v3/testsuite/performance/25_algorithms/sort_heap.cc trunk/libstdc++-v3/testsuite/performance/25_algorithms/stable_sort.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_algo.h
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #28 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 30 17:42:52 2013 New Revision: 203036 URL: http://gcc.gnu.org/viewcvs?rev=203036root=gccview=rev Log: 2013-09-30 Chris Jefferson ch...@bubblescope.net PR libstdc++/58437 * include/bits/stl_algo.h (__move_median_first): Rename to __move_median_to_first, change to take an addition argument. (__unguarded_partition_pivot): Adjust. * testsuite/performance/25_algorithms/sort.cc: New. * testsuite/performance/25_algorithms/sort_heap.cc: Likewise. * testsuite/performance/25_algorithms/stable_sort.cc: Likewise. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort.cc branches/gcc-4_8-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort_heap.cc branches/gcc-4_8-branch/libstdc++-v3/testsuite/performance/25_algorithms/stable_sort.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/stl_algo.h
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #29 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 30 17:43:05 2013 New Revision: 203037 URL: http://gcc.gnu.org/viewcvs?rev=203037root=gccview=rev Log: 2013-09-30 Chris Jefferson ch...@bubblescope.net PR libstdc++/58437 * include/bits/stl_algo.h (__move_median_first): Rename to __move_median_to_first, change to take an addition argument. (__unguarded_partition_pivot): Adjust. * testsuite/performance/25_algorithms/sort.cc: New. * testsuite/performance/25_algorithms/sort_heap.cc: Likewise. * testsuite/performance/25_algorithms/stable_sort.cc: Likewise. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/performance/25_algorithms/sort_heap.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/performance/25_algorithms/stable_sort.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/stl_algo.h
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #30 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.7.4/4.8.2/4.9.0.
[Bug c++/58563] [4.9 Regression] [c++11] ICE calling invalid destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58563 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Seems easy.
[Bug c++/58563] [4.9 Regression] [c++11] ICE calling invalid destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58563 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marek Polacek from comment #2) Does not ICE for me with 4.7/4.8, but with trunk it does. I guess this does not apply, please ignore. Should be reproducible even with 4.7/4.8.
[Bug c++/58581] New: [4.7/4.8/4.9 Regression] [c++11] ICE with no-throw specification in deleted function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58581 Bug ID: 58581 Summary: [4.7/4.8/4.9 Regression] [c++11] ICE with no-throw specification in deleted function 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++0x) triggers an ICE since GCC 4.7.0: === templatetypename T int foo(T) noexcept(T()) = delete; int i = foo(0); === bug.cc:3:14: error: use of deleted function 'int foo(T) [with T = int]' int i = foo(0); ^ bug.cc:1:26: note: declared here templatetypename T int foo(T) noexcept(T()) = delete; ^ bug.cc:3:14: internal compiler error: in nothrow_spec_p, at cp/except.c:1265 int i = foo(0); ^ 0x68b5fa nothrow_spec_p(tree_node const*) ../../gcc/gcc/cp/except.c:1265 0x534afb set_flags_from_callee(tree_node*) ../../gcc/gcc/cp/call.c:327 0x534c79 build_call_a(tree_node*, int, tree_node**) ../../gcc/gcc/cp/call.c:359 0x536856 build_cxx_call(tree_node*, int, tree_node**, int) ../../gcc/gcc/cp/call.c:7168 0x548739 build_over_call ../../gcc/gcc/cp/call.c:7152 0x54a371 build_new_function_call(tree_node*, vectree_node*, va_gc, vl_embed**, bool, int) ../../gcc/gcc/cp/call.c:3917 0x6b6c3e finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool, bool, int) ../../gcc/gcc/cp/semantics.c:2257 0x643626 cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:6009 0x645f6d cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7009 0x646b4f cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:7701 0x64700f cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:7937 0x647466 cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:7987 0x647466 cp_parser_constant_expression ../../gcc/gcc/cp/parser.c:8197 0x65313e cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:16520 0x65377f cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:10986 0x6555e0 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:10867 0x65e5ee cp_parser_declaration ../../gcc/gcc/cp/parser.c:10764 0x65d35a cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10650 0x65ec36 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:3939 0x65ec36 c_parse_file() ../../gcc/gcc/cp/parser.c:28898 Please submit a full bug report, [etc.]
[Bug c++/58582] New: [c++11] ICE defining and instantiating deleted template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58582
Bug ID: 58582
Summary: [c++11] ICE defining and instantiating deleted
template function
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++0x) triggers an ICE
since GCC 4.4.0 (when deleted functions were introduced):
struct A
{
templateint void foo() = delete;
};
templateint void A::foo() { int i; }
template void A::foo0();
bug.cc:6:20: error: redefinition of 'void A::foo()'
templateint void A::foo() { int i; }
^
bug.cc:3:22: note: 'void A::foo()' previously declared here
templateint void foo() = delete;
^
bug.cc: In instantiation of 'void A::foo() [with int anonymous = 0]':
bug.cc:8:25: required from here
bug.cc:6:36: internal compiler error: in add_stmt, at cp/semantics.c:386
templateint void A::foo() { int i; }
^
0x6ae530 add_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:386
0x5a43ac tsubst_expr
../../gcc/gcc/cp/pt.c:13289
0x5a1cdf instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19391
0x5de5ff instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19492
0x619766 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4060
Please submit a full bug report, [etc.]
A slightly modified example (just leave out int i;) crashes in a different
place:
struct A
{
templateint void foo() = delete;
};
templateint void A::foo() {}
template void A::foo0();
bug.cc:6:20: error: redefinition of 'void A::foo()'
templateint void A::foo() {}
^
bug.cc:3:22: note: 'void A::foo()' previously declared here
templateint void foo() = delete;
^
bug.cc: In instantiation of 'void A::foo() [with int anonymous = 0]':
bug.cc:8:25: required from here
bug.cc:6:30: internal compiler error: in finish_function, at cp/decl.c:13810
templateint void A::foo() {}
^
0x56ab15 finish_function(int)
../../gcc/gcc/cp/decl.c:13810
0x5a1d18 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19402
0x5de5ff instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19492
0x619766 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4060
Please submit a full bug report, [etc.]
[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Sep 30 20:15:20 2013 New Revision: 203042 URL: http://gcc.gnu.org/viewcvs?rev=203042root=gccview=rev Log: PR middle-end/58564 * fold-const.c (fold_ternary_loc): For A 0 : sign bit of A : 0 optimization, punt if sign_bit_p looked through any zero extension. * gcc.c-torture/execute/pr58564.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr58564.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Sep 30 20:16:14 2013 New Revision: 203043 URL: http://gcc.gnu.org/viewcvs?rev=203043root=gccview=rev Log: PR middle-end/58564 * fold-const.c (fold_ternary_loc): For A 0 : sign bit of A : 0 optimization, punt if sign_bit_p looked through any zero extension. * gcc.c-torture/execute/pr58564.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58564.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/fold-const.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/58564] [4.7/4.8/4.9 Regression] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Sep 30 20:17:07 2013 New Revision: 203044 URL: http://gcc.gnu.org/viewcvs?rev=203044root=gccview=rev Log: PR middle-end/58564 * fold-const.c (tree_unary_nonnegative_warnv_p): Use INTEGRAL_TYPE_P (t) instead of TREE_CODE (t) == INTEGER_TYPE. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug c++/58583] New: [c++11] ICE with invalid non-static data member initialization in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583
Bug ID: 58583
Summary: [c++11] ICE with invalid non-static data member
initialization in template
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++0x) is wrongly
accepted since GCC 4.7.0 (when non-static data member initializers were
introduced):
==
templateint N struct A
{
A* p = new AN;
};
==
Even instantiating A0 doesn't produce an error.
However, without template the code is rejected correctly.
A slightly modified code snippet triggers an ICE:
==
struct B
{
templateint N struct A
{
A* p = new A0;
};
};
==
bug.cc: In constructor 'constexpr B::A0::A()':
bug.cc:3:26: internal compiler error: in tsubst_copy, at cp/pt.c:12810
templateint N struct A
^
0x5bbd53 tsubst_copy
../../gcc/gcc/cp/pt.c:12810
0x59aa12 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14855
0x69636c perform_member_init
../../gcc/gcc/cp/init.c:538
0x69636c emit_mem_initializers(tree_node*)
../../gcc/gcc/cp/init.c:1093
0x6a0a2e synthesize_method(tree_node*)
../../gcc/gcc/cp/method.c:796
0x617659 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4714
0x54889b build_over_call
../../gcc/gcc/cp/call.c:7116
0x54477e build_new_method_call_1
../../gcc/gcc/cp/call.c:7813
0x54477e build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7883
0x5456f2 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7440
0x699086 build_new_1
../../gcc/gcc/cp/init.c:2761
0x699086 build_new(vectree_node*, va_gc, vl_embed**, tree_node*, tree_node*,
vectree_node*, va_gc, vl_embed**, int, int)
../../gcc/gcc/cp/init.c:3001
0x645ad2 cp_parser_new_expression
../../gcc/gcc/cp/parser.c:7139
0x646097 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:6910
0x646b4f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7701
0x64700f cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7937
0x647466 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:7987
0x647466 cp_parser_constant_expression
../../gcc/gcc/cp/parser.c:8197
0x648a36 cp_parser_late_parse_one_default_arg
../../gcc/gcc/cp/parser.c:23055
0x637c35 cp_parser_late_parsing_nsdmi
../../gcc/gcc/cp/parser.c:23109
Please submit a full bug report, [etc.]
[Bug middle-end/58564] [4.7 Regression] possible wrong code bug at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] possible |possible wrong code bug at |wrong code bug at -O0 |-O0 | --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed for 4.8.2+ so far.
[Bug c++/58584] New: [c++11] ICE with invalid argument for alignas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58584
Bug ID: 58584
Summary: [c++11] ICE with invalid argument for alignas
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++0x) triggers an ICE
since GCC 4.8.0 (when alignas was introduced):
struct A
{
int i alignas(this);
};
bug.cc:3:17: error: invalid use of 'this' at top level
int i alignas(this);
^
bug.cc:3:17: internal compiler error: tree check: expected tree_list, have
error_mark in cp_check_const_attributes, at cp/decl2.c:1325
0xcd8a0a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9176
0x6110cb tree_check
../../gcc/gcc/tree.h:2609
0x6110cb cp_check_const_attributes
../../gcc/gcc/cp/decl2.c:1325
0x6110cb cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1351
0x6161b7 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:989
0x636a92 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20084
0x6376ce cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19630
0x6376ce cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18885
0x63a070 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19101
0x63a070 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14080
0x64f549 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11328
0x6535d9 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10918
0x6555e0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x65e5ee cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x65d35a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65ec36 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ec36 c_parse_file()
../../gcc/gcc/cp/parser.c:28898
0x772143 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]
A template version of the code crashes in a different place:
templateint struct A
{
int i alignas(this);
};
neu50B.cc:3:17: error: invalid use of 'this' at top level
int i alignas(this);
^
neu50B.cc:3:17: internal compiler error: tree check: expected tree_list, have
error_mark in get_attribute_name, at attribs.c:659
0xcd8a0a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9176
0x72a595 tree_check
../../gcc/gcc/tree.h:2819
0x72a595 get_attribute_name(tree_node const*)
../../gcc/gcc/attribs.c:659
0x610d23 is_late_template_attribute
../../gcc/gcc/cp/decl2.c:1120
0x610d23 splice_template_attributes
../../gcc/gcc/cp/decl2.c:1200
0x610d23 save_template_attributes
../../gcc/gcc/cp/decl2.c:1221
0x610d23 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/gcc/cp/decl2.c:1348
0x6161b7 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:989
0x636a92 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20084
0x6376ce cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19630
0x6376ce cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18885
0x63a070 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19101
0x63a070 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14080
0x64f549 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11328
0x653bb3 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:22578
0x656990 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22454
0x65e789 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10728
0x65d35a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x65ec36 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65ec36 c_parse_file()
../../gcc/gcc/cp/parser.c:28898
Please submit a full bug report, [etc.]
[Bug fortran/58579] Memory allocation fails when calling character-valued function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58579 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org Known to fail||4.8.1, 4.9.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- The generated code (-fdump-tree-original) looks odd: D.1887 = i; D.1888 = *D.1887; D.1890 = MAX_EXPR D.1888, 0 * 64; D.1891 = (void * restrict) __builtin_malloc (MAX_EXPR (unsigned long) D.1890, 1); Why is there the multiplication by 64? We have a kind=1 character, i.e. one should have multiplied by 1 (byte). Random guess: That's the bit size of a pointer. (That it fails with that multiplication is clear: gfortran uses a (signed) 32bit variable for the string length - and 33554432 * 64 == 2**31 - but (2**31-1) is the largest positive 32bit integer.)
[Bug fortran/58579] Memory allocation fails when calling character-valued function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58579
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
Completely untested draft patch
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2355,11 +2355,13 @@ gfc_conv_string_tmp (gfc_se * se, tree type, tree len)
{
/* Allocate a temporary to hold the result. */
var = gfc_create_var (type, pstr);
+ tmp = TYPE_SIZE_UNIT (get_element_type (type));
+ tmp = fold_build2_loc (input_location, MULT_EXPR, size_type_node,
+ fold_convert (size_type_node, len),
+ fold_convert (size_type_node, tmp));
tmp = gfc_call_malloc (se-pre, type,
fold_build2_loc (input_location, MULT_EXPR,
- TREE_TYPE (len), len,
- fold_convert (TREE_TYPE (len),
- TYPE_SIZE
(type;
+ size_type_node, len, tmp);
gfc_add_modify (se-pre, var, tmp);
/* Free the temporary afterwards. */
[Bug c++/58584] [c++11] ICE with invalid argument for alignas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58584 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Please don't use anymore -std=c++0x, it's legacy, supported only for backward compatibility.
[Bug middle-end/58585] New: [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Bug ID: 58585
Summary: [4.9 Regression] ICE in ipa with virtual inheritance
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid code snippet triggers an ICE on trunk when compiled with
-O2 -fPIC:
struct A
{
virtual void foo() {}
void bar();
};
void A::bar() { foo(); }
struct B : virtual A
{
virtual void foo() {}
char c;
};
struct C : virtual B
{
C();
};
C::C() { bar(); }
bug.cc:18:17: internal compiler error: in ipa_get_indirect_edge_target_1, at
ipa-cp.c:1570
C::C() { bar(); }
^
0xf46f8d ipa_get_indirect_edge_target_1
../../gcc/gcc/ipa-cp.c:1569
0x9958fe estimate_edge_devirt_benefit
../../gcc/gcc/ipa-inline-analysis.c:2783
0x9958fe estimate_edge_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:2815
0x9958fe estimate_calls_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:2868
0x996a72 estimate_node_size_and_time
../../gcc/gcc/ipa-inline-analysis.c:2955
0x999046 do_estimate_edge_size(cgraph_edge*)
../../gcc/gcc/ipa-inline-analysis.c:3498
0x99918c estimate_edge_size
../../gcc/gcc/ipa-inline.h:275
0x99918c estimate_edge_growth
../../gcc/gcc/ipa-inline.h:287
0x99918c do_estimate_growth_1
../../gcc/gcc/ipa-inline-analysis.c:3609
0x8004de cgraph_for_node_and_aliases(cgraph_node*, bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc/gcc/cgraph.c:2156
0x999617 do_estimate_growth(cgraph_node*)
../../gcc/gcc/ipa-inline-analysis.c:3623
0xf5513d estimate_growth
../../gcc/gcc/ipa-inline.h:262
0xf5513d inline_small_functions
../../gcc/gcc/ipa-inline.c:1549
0xf5513d ipa_inline
../../gcc/gcc/ipa-inline.c:2009
0xf5513d execute
../../gcc/gcc/ipa-inline.c:2379
Please submit a full bug report, [etc.]
The regression appeared between 4.9.0-20130922 and 4.9.0-20130926.
[Bug fortran/58586] New: ICE with derived type with a polymorphic allocatable component passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58586 Bug ID: 58586 Summary: ICE with derived type with a polymorphic allocatable component passed by value Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com gfortran -c ice3.f90 ice3.f90: In function ‘sub’: ice3.f90:29:0: internal compiler error: Segmentation fault call add(b()) ^ 0x87dfdf crash_signal ../../gcc-4.8-20130425/gcc/toplev.c:332 0x5b19b0 structure_alloc_comps ../../gcc-4.8-20130425/gcc/fortran/trans-array.c:7440 0x5c97ca gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) ../../gcc-4.8-20130425/gcc/fortran/trans-expr.c:4621 0x5ede84 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc-4.8-20130425/gcc/fortran/trans-stmt.c:406 0x5a7761 trans_code ../../gcc-4.8-20130425/gcc/fortran/trans.c:1500 0x5c4a02 gfc_generate_function_code(gfc_namespace*) ../../gcc-4.8-20130425/gcc/fortran/trans-decl.c:5397 0x568770 translate_all_program_units ../../gcc-4.8-20130425/gcc/fortran/parse.c:4474 0x568770 gfc_parse_file() ../../gcc-4.8-20130425/gcc/fortran/parse.c:4688 0x5a3a85 gfc_be_parse_file ../../gcc-4.8-20130425/gcc/fortran/f95-lang.c:189 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. module mod type,abstract :: a end type type :: b class(a),allocatable :: a end type interface b module procedure b_init end interface contains subroutine add(c) type(b),value :: c end subroutine function b_init() result(res) type(b) :: res end function end module mod subroutine sub use mod call add(b()) end subroutine sub
[Bug target/58587] New: Bootstrap error with ada with -mcpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58587
Bug ID: 58587
Summary: Bootstrap error with ada with -mcpu=power7
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: meissner at gcc dot gnu.org
Trying to bootstrap gcc (4.8-RH, but reproduced also with the trunk) with
a ppc64 compiler configured --with-cpu=power7 ICEs during stage1 while par.adb
is being compiled at -O0.
Reproduced even with a cross-compiler from x86_64-linux, will attach a tarball
with all the required files.
../gnat1 -I. -gnatwa -quiet -nostdinc -m64 -gnatpg -gnatwns -mtune=power7
-mcpu=power7 par.adb -o /tmp/par.s
par.adb: In function ‘Par’:
par.adb:1604:5: error: insn does not satisfy its constraints:
(insn 1505 719 1504 (set (reg:TI 77 0)
(const_double -16 [0xfff0] 7 [0x7] 0 [0] 0 [0]))
par.adb:1509 721 {*vsx_movti_64bit}
(nil))
+===GNAT BUG DETECTED==+
| 4.9.0 20130927 (experimental) (powerpc64-linux) GCC error: |
| in extract_constrain_insn_cached, at recog.c:2076|
| Error detected around par.adb:1604:5 |
| 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 target/58587] Bootstrap error with ada with -mcpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58587
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 30941
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30941action=edit
pr58587.tar.bz2
I've tried to create a C small reproducer from scratch, but just using TImode
seems to work, reload decides to put the extra large constant into memory, and
similarly say:
typedef int TI __attribute__((mode (TI)));
void
foo (void)
{
asm volatile ( : : v (((TI) 0x7fffUL) 4));
}
[Bug c/58588] New: internal compiler error: Segmentation fault from aligned attribute with undefined token for size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58588 Bug ID: 58588 Summary: internal compiler error: Segmentation fault from aligned attribute with undefined token for size Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dbruening at acm dot org Host: Fedora 17 Target: x86_64-redhat-linux Build: gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) Created attachment 30942 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30942action=edit Preprocessed source stored into /tmp/ccmaOY7z.out file, please attach this to your bugreport. This one-line file reproduces the problem: int __attribute__ ((aligned (UNDEFINED_VALUE))) foo; It results in internal compiler error: Segmentation fault as shown below: % gcc -v -save-temps -c gcc-crash.c Using built-in specs. COLLECT_GCC=gcc Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -E -quiet -v gcc-crash.c -mtune=generic -march=x86-64 -fpch-preprocess -o gcc-crash.i ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include-fixed ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../x86_64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-redhat-linux/4.7.2/include /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -fpreprocessed gcc-crash.i -quiet -dumpbase gcc-crash.c -mtune=generic -march=x86-64 -auxbase gcc-crash -version -o gcc-crash.s GNU C (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux) compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.7.2 20120921 (Red Hat 4.7.2-2) (x86_64-redhat-linux) compiled by GNU C version 4.7.2 20120921 (Red Hat 4.7.2-2), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 1ddc7c1a4fba2159f711c3e228ac3970 gcc-crash.c:1:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. Preprocessed source stored into /tmp/ccmaOY7z.out file, please attach this to your bugreport. % cat /tmp/ccmaOY7z.out // /usr/libexec/gcc/x86_64-redhat-linux/4.7.2/cc1 -fpreprocessed gcc-crash.i -quiet -dumpbase gcc-crash.c -mtune=generic -march=x86-64 -auxbase gcc-crash -version -o - -frandom-seed=0 # 1 gcc-crash.c # 1 command-line # 1 gcc-crash.c int __attribute__ ((aligned (UNDEFINED_VALUE))) foo; % cat gcc-crash.i # 1 gcc-crash.c # 1 command-line # 1 gcc-crash.c int __attribute__ ((aligned (UNDEFINED_VALUE))) foo; I do not have access to a more recent gcc so I'm not sure whether this has been fixed since 4.7.2.
[Bug c/58588] internal compiler error: Segmentation fault from aligned attribute with undefined token for size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58588 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- A dup of bug 55570. *** This bug has been marked as a duplicate of bug 55570 ***
[Bug c/55570] [4.7/4.8 regression] Undefined variable in alignment compiler directive causes compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55570 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||dbruening at acm dot org --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 58588 has been marked as a duplicate of this bug. ***
[Bug c++/33911] attribute deprecated vs. templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911 Easwaran Raman eraman at google dot com changed: What|Removed |Added CC||eraman at google dot com --- Comment #10 from Easwaran Raman eraman at google dot com --- For template member functions, is concatenating the parsed attributes to prefix_attributes and passing them to grokfield a valid fix? This patch works for a small test case I have and I wonder if this is correct: Index: gcc/cp/parser.c === --- gcc/cp/parser.c(revision 202261) +++ gcc/cp/parser.c(working copy) @@ -16489,7 +16489,7 @@ cp_parser_init_declarator (cp_parser* parser, decl = grokfield (declarator, decl_specifiers, initializer, !is_non_constant_init, /*asmspec=*/NULL_TREE, -prefix_attributes); +chainon (prefix_attributes, attributes)); if (decl TREE_CODE (decl) == FUNCTION_DECL) cp_parser_save_default_args (parser, decl); }
[Bug target/58587] Bootstrap error with ada with -mcpu=power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58587 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
