[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #10 from Markus Trippelsdorf --- And even with !IA32_EMULATION the kernel build uses -m16 a few times on x86_64. Please note that we're talking about -ffreestanding target here.
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #9 from Markus Trippelsdorf --- (In reply to Alan Modra from comment #7) > On x86_64-linux you can run 32-bit binaries. On powerpc64le-linux you > can't. It's that simple. -m32 support in powerpc64le gcc, by default, > doesn't make sense until we have > - supported and tested compat layer in the kernel > - supported and tested gcc, binutils and glibc Only if IA32_EMULATION is set in the kernel config. I have disabled this option for years now. So the situation is exactly the same.
[Bug rtl-optimization/60851] [4.9/5 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851 --- Comment #11 from uros at gcc dot gnu.org --- Author: uros Date: Fri Mar 20 06:07:30 2015 New Revision: 221529 URL: https://gcc.gnu.org/viewcvs?rev=221529&root=gcc&view=rev Log: PR rtl-optimization/60851 * recog.c (constrain_operands): Accept a pseudo register before reload for LRA enabled targets. testsuite/ChangeLog: PR rtl-optimization/60851 * gcc.target/i386/pr60851.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr60851.c Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c trunk/gcc/testsuite/ChangeLog
[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #3 from Jan Hubicka ---
The following should help:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 221528)
+++ ipa-devirt.c(working copy)
@@ -1412,9 +1412,18 @@ add_type_duplicate (odr_type val, tree t
if (!val->types_set)
val->types_set = new hash_set;
+ /* Chose polymorphic type as leader (this happens only in case of ODR
+ violations. */
+ if ((TREE_CODE (type) == RECORD_TYPE && TYPE_BINFO (type)
+ && polymorphic_type_binfo_p (TYPE_BINFO (type)))
+ && (TREE_CODE (val->type) != RECORD_TYPE || !TYPE_BINFO (val->type)
+ || !polymorphic_type_binfo_p (TYPE_BINFO (val->type
+{
+ prevail = true;
+ build_bases = true;
+}
/* Always prefer complete type to be the leader. */
-
- if (!COMPLETE_TYPE_P (val->type) && COMPLETE_TYPE_P (type))
+ else if (!COMPLETE_TYPE_P (val->type) && COMPLETE_TYPE_P (type))
{
prevail = true;
build_bases = TYPE_BINFO (type);
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #22 from Jeffrey A. Law --- Let's try to stay focused. Killing copyrename seems like a fine thing to do as long as the resulting debug info is good. But that's independent of this BZ. I still find myself wondering if leaving the "0" instead of "_10" in that PHI node is a reasonable approach. Certainly if I hack uncprop to leave things in that state, I get the code we want. And ISTM that uncprop ought to leave the constant alone if the SSA_NAME holding the constant conflicts with any of the other SSA_NAMEs in the PHI node that may potentially coalesce with the PHI result. That captures pretty well the case where the constant is better than an SSA_NAME. In this particular case, we have: # _28 = PHI <0(2), _29(3), _29(7), _10(8), _29(6)> When _28 and _10 coalesce, the result then conflicts with _29 during IRA/LRA because of the extended lifetime of _10). Thus the annoying copies created by out-of-ssa can't be eliminated. WIth the proposed change, we'd instead have: # _28 = PHI <0(2), _29(3), _29(7), 0(8), _29(6)> While we won't coalesce _28/_29 during out-of-ssa, LRA will see the copies and note that the associated pseudos don't conflict and ultimately assign them to the same hard register and the annoying copies are gone.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #39 from Jerry DeLisle --- Fixed on trunk. Thanks all for testing and suggestions.
[Bug ipa/65483] bzip2 bsR/bsW should be auto-inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483 Jan Hubicka changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #2 from Jan Hubicka --- The difference between 4.9 and 5.0 seems to be unrolling of the decoder loop and increased register pressure 4.9 does: 00406d60 : 406d60: 8b 35 32 14 01 00 mov0x11432(%rip),%esi# 418198 406d66: 53 push %rbx 406d67: 8b 05 27 14 01 00 mov0x11427(%rip),%eax# 418194 406d6d: 39 f7 cmp%esi,%edi 406d6f: 0f 8e f3 00 00 00 jle406e68 406d75: 48 63 05 20 14 01 00movslq 0x11420(%rip),%rax# 41819c 406d7c: 83 f8 03cmp$0x3,%eax 406d7f: 0f 8f 03 01 00 00 jg 406e88 406d85: 4c 8d 0c 40 lea(%rax,%rax,2),%r9 406d89: 49 c1 e1 03 shl$0x3,%r9 406d8d: 49 8d 91 c0 81 41 00lea0x4181c0(%r9),%rdx 406d94: 8b 4a 08mov0x8(%rdx),%ecx 406d97: 39 4a 04cmp%ecx,0x4(%rdx) 406d9a: 0f 8e c0 00 00 00 jle406e60 406da0: 44 8d 56 08 lea0x8(%rsi),%r10d 406da4: 89 fe mov%edi,%esi 406da6: 48 63 d9movslq %ecx,%rbx 406da9: 48 03 5a 10 add0x10(%rdx),%rbx 406dad: 8b 05 e1 13 01 00 mov0x113e1(%rip),%eax# 418194 406db3: 44 8d 59 01 lea0x1(%rcx),%r11d 406db7: 44 29 d6sub%r10d,%esi 406dba: 83 c6 07add$0x7,%esi 406dbd: 83 e6 08and$0x8,%esi 406dc0: 74 3e je 406e00 406dc2: 45 89 d8mov%r11d,%r8d 406dc5: 44 89 5a 08 mov%r11d,0x8(%rdx) 406dc9: 44 0f b6 1b movzbl (%rbx),%r11d 406dcd: c1 e0 08shl$0x8,%eax 406dd0: 44 89 d6mov%r10d,%esi 406dd3: 44 89 15 be 13 01 00mov%r10d,0x113be(%rip)# 418198 406dda: 44 09 d8or %r11d,%eax 406ddd: 44 39 d7cmp%r10d,%edi 406de0: 89 05 ae 13 01 00 mov%eax,0x113ae(%rip)# 418194 406de6: 0f 8e 7c 00 00 00 jle406e68 406dec: 41 83 c2 08 add$0x8,%r10d 406df0: 48 83 c3 01 add$0x1,%rbx 406df4: 44 39 42 04 cmp%r8d,0x4(%rdx) 406df8: 44 8d 59 02 lea0x2(%rcx),%r11d 406dfc: 7e 62 jle406e60 406dfe: 66 90 xchg %ax,%ax 406e00: 49 8d 91 c0 81 41 00lea0x4181c0(%r9),%rdx 406e07: c1 e0 08shl$0x8,%eax 406e0a: 44 89 d6mov%r10d,%esi 406e0d: 44 89 5a 08 mov%r11d,0x8(%rdx) 406e11: 0f b6 0bmovzbl (%rbx),%ecx 406e14: 44 89 15 7d 13 01 00mov%r10d,0x1137d(%rip)# 418198 406e1b: 09 c8 or %ecx,%eax 406e1d: 44 39 d7cmp%r10d,%edi 406e20: 89 05 6e 13 01 00 mov%eax,0x1136e(%rip)# 418194 406e26: 7e 40 jle406e68 406e28: 44 39 5a 04 cmp%r11d,0x4(%rdx) 406e2c: 45 8d 42 08 lea0x8(%r10),%r8d 406e30: 41 8d 73 01 lea0x1(%r11),%esi 406e34: 7e 2a jle406e60 406e36: 89 72 08mov%esi,0x8(%rdx) 406e39: 0f b6 4b 01 movzbl 0x1(%rbx),%ecx 406e3d: c1 e0 08shl$0x8,%eax 406e40: 41 83 c2 10 add$0x10,%r10d 406e44: 41 83 c3 02 add$0x2,%r11d 406e48: 48 83 c3 02 add$0x2,%rbx 406e4c: 44 89 05 45 13 01 00mov%r8d,0x11345(%rip)# 418198 406e53: 09 c8 or %ecx,%eax 406e55: 39 72 04cmp%esi,0x4(%rdx) 406e58: 89 05 36 13 01 00 mov%eax,0x11336(%rip)# 418194 406e5e: 7f a0 jg 406e00 406e60: e8 3b 28 00 00 callq 4096a0 406e65: 0f 1f 00nopl (%rax) 406e68: 89 f1 mov%esi,%ecx 406e6a: 41 b9 01 00 00 00 mov$0x1,%r9d 406e70: 29 f9 sub%edi,%ecx 406e72: d3 e8 shr%cl,%eax 406e74: 89 0d 1e 13 01 00 mov%ecx,0x1131e(%rip)# 418198 406e7a: 89 f9 mov%edi,%ecx
[Bug ipa/65483] bzip2 bsR/bsW should be auto-inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483 --- Comment #1 from Jan Hubicka --- Benchmarking build with -O3 -flto -Ofast -funroll-loops For mainline I get (running on input.graphic) real0m35.673s user0m35.556s sys 0m0.133s and setting early-inlining-insns=80 to get bsR/bsW inlined before we get LTO real0m31.975s user0m31.867s sys 0m0.124s -fno-ipa-cp: real0m34.232s user0m34.132s sys 0m0.117s For GCC 4.9 I get. real0m32.719s user0m32.615s sys 0m0.124s Oddly enought GCC 4.9 does not inlie bsR/bsW either.
[Bug testsuite/65484] New: FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 Bug ID: 65484 Summary: FAIL: g++.dg/vect/pr36648.cc on powerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org The g++.dg/vect/pr36648.cc (a P1 4.3/4.4 regression) test fails on powerpc64: FAIL: g++.dg/vect/pr36648.cc -std=c++98 scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: g++.dg/vect/pr36648.cc -std=c++98 scan-tree-dump-times vect "vectorizing stmts using SLP" 1 ... The verbose runtest output shows the test is being compiled with the undocumented -mno-allow-movmisalign option (see pr65482): Executing on host: /build/gcc-5.0/gcc/testsuite/g++/../../xg++ -B/build/gcc-5.0/gcc/testsuite/g++/../../ /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc ... -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mvsx -mno-allow-movmisalign -fdump-tree-vect-details ... -o ./pr36648.exe(timeout = 300) The .vect dump shows gcc decides not to vectorize the code because of an (apparently) unsupported unaligned store: $ grep -e vectorized -e vectorizing pr36648.cc.126t.vect /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc:9:8: note: === vect_mark_stmts_to_be_vectorized === /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc:9:8: note: not vectorized: unsupported unaligned store._14->x /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc:18:14: note: vectorized 0 loops in function. The -mno-allow-movmisalign option likely gets added to the command line in check_vect_support_and_set_flags in lib/target-supports.exp. Since the pr36648 regression was about GCC generating incorrect code with -O3 (that led to the program crashing at runtime) and not about it necessarily being able to vectorize it, the use of the option seems questionable. It should be sufficient to verify that the test compiles and runs successfully to completion.
[Bug ipa/65483] New: bzip2 bsR/bsW should be auto-inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
Bug ID: 65483
Summary: bzip2 bsR/bsW should be auto-inlined
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
bzip2 contains:
INLINE UInt32 bsR ( Int32 n )
{
UInt32 v;
bsNEEDR ( n );
v = (bsBuff >> (bsLive-n)) & ((1 << n)-1);
bsLive -= n;
return v;
}
and
INLNE void bsW ( Int32 n, UInt32 v )
{
bsNEEDW ( n );
bsBuff |= (v << (32 - bsLive - n));
bsLive += n;
}
which should be inlined. INLINE is however defined to nothing for SPEC.
The catch is that we instead inline fgetc/fputc into the functions here:
#define bsNEEDR(nz) \
{ \
while (bsLive < nz) { \
Int32 zzi = fgetc ( bsStream ); \
if (zzi == EOF) compressedStreamEOF(); \
bsBuff = (bsBuff << 8) | (zzi & 0xffL); \
bsLive += 8;\
} \
}
/*-*/
#define bsNEEDW(nz) \
{ \
while (bsLive >= 8) { \
fputc ( (UChar)(bsBuff >> 24), \
bsStream );\
bsBuff <<= 8; \
bsLive -= 8;\
bytesOut++; \
} \
}
Considering spec_getc/285 with 33 size
to be inlined into bsR/98 in unknown:-1
Estimated badness is -21.814074, frequency 21.04.
Badness calculation for bsR/98 -> spec_getc/285
size growth 27, time 22 inline hints: cross_module big_speedup
-10.907037: guessed profile. frequency 21.035000, count 0 caller count 0
time w/o inlining 1063.840001, time w inlining 769.35 overall growth 0
(current) 0 (original)
Adjusted by hints -21.814074
Accounting size:20.00, time:304.69 on predicate:(true)
...
Inlined into bsR which now has time 767 and size 55,net change of +27.
which makes it to reach inline-insns-auto limit.
bsR is estimated as:
Inline summary for bsR/98 inlinable
self time: 559
global time: 0
self size: 28
global size: 0
min size: 0
self stack: 0
global stack:0
size:21.00, time:304.328000, predicate:(true)
size:3.00, time:1.982000, predicate:(not inlined)
calls:
compressedStreamEOF/143 function not considered for inlining
loop depth: 0 freq: 8 size: 1 time: 10 callee size:12 stack: 0
spec_getc/153 function body not available
loop depth: 1 freq:21035 size: 3 time: 12 callee size: 0 stack: 0
The spec_getc is implemented as:
int spec_getc (int fd) {
int rc = 0;
debug1(4,"spec_getc: %d = ", fd);
if (fd > MAX_SPEC_FD) {
fprintf(stderr, "spec_read: fd=%d, > MAX_SPEC_FD!\n", fd);
exit (1);
}
if (spec_fd[fd].pos >= spec_fd[fd].len) {
debug(4,"EOF\n");
return EOF;
}
rc = spec_fd[fd].buf[spec_fd[fd].pos++];
debug1(4,"%d\n", rc);
return rc;
}
we however split out the error handling into spec_getc.part and get:
Inline summary for spec_getc/38 inlinable
self time: 24
global time: 0
self size: 33
global size: 0
min size: 0
self stack: 0
global stack:0
size:20.00, time:14.485000, predicate:(true)
size:3.00, time:1.998000, predicate:(not inlined)
which makes it quite good inline candidate especially because the call appears
within what we consider an internal loop of bsR.
Apparently clang gets lucky here because it inlines more at copmile time and
spec_getc is housed in different translation unit.
[Bug middle-end/65449] -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449 --- Comment #4 from ma.jiang at zte dot com.cn --- Hi Bernd, Thanks for your apply. (In reply to Bernd Edlinger from comment #3) > Yes, but that is not the fault of the strict volatile code path any more. // Sure,I agree with you. The redundant read is another problem. In fact, it should be named as "volatile pointer dereference produce redundant read". > For bit-fields this redundant read is exactly what AAPCS demands: > // Yes.I know that volatile bitfiled need the redundant read. That is why I thought there were connections between the redundant read and -fstrict-volatile-bitfields originally. > IMO, the problem is this: > > In store_fixed_bit_field_1 we do not know if the access is on a > packed structure member where the extra read is not necessary, > or if we have a bit-field where the extra read would be mandatory, > even if the complete container is overwritten. // I agree that the problem is caused by the store_fixed_bit_field_1.But,I disgree with you about three things.First,the redundant read should not appear if -fstrict-volatile-bitfields was off. Second, in store_fixed_bit_field_1 we can distinguish pointer dereference from structure member access(e.g.,MEM_EXPR(op0) will tell us whether op0 is a componet_ref or not, if MEM_P(op0) is true). Third, as gcc manual said "-fstrict-volatile-bitfields :This option should be used if accesses to volatile bit-fields (or other structure fields, although the compiler usually honors those types anyway) should use a single access of the width of the field’s type, aligned to a natural alignment if possible.", store_fixed_bit_field_1 does not need to distinguish bitfields from normal structure member. > > BTW: What happens in your example if you use -O0? Isn't there still an > unaligned stw access? That's because you example is in a way invalid C. > You can't set an int* to an unaligned address, it must be at least > aligned to the GET_MODE_ALIGNMENT(SImode). //Yes, I know what you mean. Split access is a auxiliary fuction provided by compiler with the help of data analysis.As -O0 turn off all analysis , an unaligned stw is acceptable. And ,BTW, the C standard said nothing about unaligned access as I know. Could you show me something about it?
[Bug driver/65482] New: -mno-allow-movmisalign undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482 Bug ID: 65482 Summary: -mno-allow-movmisalign undocumented Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Some of the vectorization tests make use of the -mno-allow-movmisalign option (for example g++.dg/vect/slp-pr50819.cc). The option is not documented, either in the output of gcc -help -v or in the gcc manual, making it difficult to understand its effects on such tests.
[Bug preprocessor/65481] _Pragma GCC dependency broken on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65481 --- Comment #1 from Andrew Pinski --- contrib/gcc_update --touch is usually used to fix this problem.
[Bug c/65466] Unnecessary source line output for "note: each undeclared identifier is reported only once"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 --- Comment #4 from joseph at codesourcery dot com --- On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 > > --- Comment #3 from Manuel López-Ibáñez --- > (In reply to jos...@codesourcery.com from comment #2) > > On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > > > > > (If I was re-doing that patch again, I will try to overload inform(), > > > because > > > inform_with_flags is just too much typing). > > > > Note that diagnostic functions cannot be overloaded in a way that means > > different functions with the same name have the msgid argument in > > different positions, as that breaks exgettext. > > Ah, yes, I forgot about this. We had this problem already in the Fortran FE. > Can exgettext be fixed to handle overloads eventually? Perhaps someone could > reimplement it as a GCC plugin. That would be a nice GSoC! exgettext (which essentially just computes arguments to pass to xgettext from GNU gettext) needs to handle sources that are not part of the current configuration, including inside disabled #if conditionals. That is, the sources parsed by the compiler compiling any particular build of GCC are not the full set of sources that need to be handled to generate gcc.pot.
[Bug preprocessor/65481] New: _Pragma GCC dependency broken on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65481 Bug ID: 65481 Summary: _Pragma GCC dependency broken on powerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org The gcc.dg/cpp/_Pragma3.c test is failing on powerpc64 but passes on powerpc64le. The following test case demonstrates the same problem that causes the test failure. It looks like the timestamp computation is broken on this target. GCC 4.8.3 has the same problem. $ cat t.c && touch t.h && stat t.c t.h && /build/gcc-5.0/gcc/xgcc -B/build/gcc-5.0/gcc -ansi -pedantic-errors -E -o/dev/null t.c #define GCC_PRAGMA(x) _Pragma (#x) GCC_PRAGMA(GCC dependency "t.h") File: ‘t.c’ Size: 68Blocks: 8 IO Block: 65536 regular file Device: fd00h/64768dInode: 69928678Links: 1 Access: (0664/-rw-rw-r--) Uid: (25066/ msebor) Gid: (25066/ msebor) Context: unconfined_u:object_r:default_t:s0 Access: 2015-03-19 19:55:32.668667450 -0400 Modify: 2015-03-19 19:54:40.448639710 -0400 Change: 2015-03-19 19:54:40.468639721 -0400 Birth: - File: ‘t.h’ Size: 0 Blocks: 0 IO Block: 65536 regular empty file Device: fd00h/64768dInode: 69928674Links: 1 Access: (0664/-rw-rw-r--) Uid: (25066/ msebor) Gid: (25066/ msebor) Context: unconfined_u:object_r:default_t:s0 Access: 2015-03-19 19:56:02.508682213 -0400 Modify: 2015-03-19 19:56:02.508682213 -0400 Change: 2015-03-19 19:56:02.508682213 -0400 Birth: - t.c:2:16: warning: current file is older than t.h GCC_PRAGMA(GCC dependency "t.h") ^
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka changed:
What|Removed |Added
Component|tree-optimization |ipa
Summary|crafty performance |[5 regression] crafty
|regression |performance regression
--- Comment #2 from Jan Hubicka ---
Martin: Looking into it, the parameter 4(ply)=2 and donull=true seems to be
used in calls starting the recursion:
/*
--
| |
| now call Search to produce a value for this move. |
| |
--
*/
begin_root_nodes=nodes_searched;
if (first_move) {
value=-ABSearch(-beta,-alpha,ChangeSide(wtm),
depth+extensions,2,DO_NULL);
if (abort_search) {
UnMakeMove(1,current_move[1],wtm);
return(alpha);
}
first_move=0;
}
else {
value=-ABSearch(-alpha-1,-alpha,ChangeSide(wtm),
depth+extensions,2,DO_NULL);
if (abort_search) {
UnMakeMove(1,current_move[1],wtm);
return(alpha);
}
if ((value > alpha) && (value < beta)) {
value=-ABSearch(-beta,-alpha,ChangeSide(wtm),
depth+extensions,2,DO_NULL);
if (abort_search) {
UnMakeMove(1,current_move[1],wtm);
return(alpha);
}
}
}
While it recursively call itself with alternating players and sometimes drops
to !DO_NULL.
Intuitively, clonning the function specializing for first iteration of
recursion is like loop peeling and that is already done (not particularly well)
by recursive inlining.
I would suggest we may disable/add negative hint for cloning in the case where
the specialized function will end up calling unspecialized version of itself
with non-cold edge.
We also may consider adding bit of negative hints for cases where cloning would
turn function called once (by noncold edge) to a function called twice.
The same may be done with inliner, but that would even more reduce changes that
ipa-split produced split functions will actually get partially inlined.
Function is inlined by 4.9:
Considering NextMove/2405 with 284 size
to be inlined into Search.constprop/4352 in unknown:-1
Estimated badness is -128, frequency 0.69.
Badness calculation for Search.constprop/4352 -> NextMove/2405
size growth 273, time 174 inline hints: cross_module array_index
-128: guessed profile. frequency 0.694000, benefit 1.771337%, time w/o
inlining 621, time w inlining 610 overall growth 266 (current) 266 (original)
Accounting size:228.00, time:104.18 on predicate:(op4 <= 62)
Accounting size:4.00, time:4.13 on predicate:(op2 changed) &&
(op4 <= 62)
Accounting size:2.00, time:1.03 on predicate:(op2 == 0) && (op4
<= 62)
Accounting size:2.00, time:1.03 on predicate:(op2 != 0) && (op4
<= 62)
I am marking it as a regression thus and changing component to IPA.
[Bug c/65466] Unnecessary source line output for "note: each undeclared identifier is reported only once"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 --- Comment #3 from Manuel López-Ibáñez --- (In reply to jos...@codesourcery.com from comment #2) > On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > > > (If I was re-doing that patch again, I will try to overload inform(), > > because > > inform_with_flags is just too much typing). > > Note that diagnostic functions cannot be overloaded in a way that means > different functions with the same name have the msgid argument in > different positions, as that breaks exgettext. Ah, yes, I forgot about this. We had this problem already in the Fortran FE. Can exgettext be fixed to handle overloads eventually? Perhaps someone could reimplement it as a GCC plugin. That would be a nice GSoC!
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 --- Comment #1 from Martin Sebor --- The same problem is causing failures in the following tests on these targets: c-c++-common/asan/misalign-2.c c-c++-common/asan/null-deref-1.c
[Bug c/65466] Unnecessary source line output for "note: each undeclared identifier is reported only once"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 --- Comment #2 from joseph at codesourcery dot com --- On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: > (If I was re-doing that patch again, I will try to overload inform(), because > inform_with_flags is just too much typing). Note that diagnostic functions cannot be overloaded in a way that means different functions with the same name have the msgid argument in different positions, as that breaks exgettext.
[Bug libstdc++/65480] New: libstdc++-prettyprinters/libfundts.cc test failures on powepc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65480
Bug ID: 65480
Summary: libstdc++-prettyprinters/libfundts.cc test failures on
powepc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
The libstdc++-prettyprinters/libfundts.cc test fails the following assertions
on powerpc64 (all assertions pass on powerpc64le).
FAIL: libstdc++-prettyprinters/libfundts.cc print ab
got =>{_M_manager = @0x10020668: 0x100029b0
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr =
0x10029200, _M_buffer = {__data = "\000\000\000\000\020\002\222", __align =
{<=
expected =>std::experimental::any containing bool = {[contained value] =
false}<=
FAIL: libstdc++-prettyprinters/libfundts.cc print ai
got =>{_M_manager = @0x10020698: 0x10002b0c
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr =
0x61578, _M_buffer = {__data = "\000\000\000\006\020\000\005x", __align =
{<=
expected =>std::experimental::any containing int = {[contained value] = 6}<=
FAIL: libstdc++-prettyprinters/libfundts.cc print ap
got =>{_M_manager = @0x100206c8: 0x10002c68
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr = 0x0,
_M_buffer = {__data = "\000\000\000\000\000\000\000", __align = {<=
expected =>std::experimental::any containing void * = {[contained value] =
0x0}<=
FAIL: libstdc++-prettyprinters/libfundts.cc print as
got =>{_M_manager = @0x10020710: 0x10002df4
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr =
0x10041cf8, _M_buffer = {__data = "\000\000\000\000\020\004\034\370", __align =
{<=
expected =>std::experimental::any containing std::string = {[contained value] =
"stringy"}<=
FAIL: libstdc++-prettyprinters/libfundts.cc print as2
got =>{_M_manager = @0x10020740: 0x10002fe4
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr =
0x100065a0, _M_buffer = {__data = "\000\000\000\000\020\000e\240", __align =
{<=
expected =>std::experimental::any containing const char \* = {\[contained
value\] = 0x[[:xdigit:]]+ "stringiest"}<=
FAIL: libstdc++-prettyprinters/libfundts.cc print am
got =>{_M_manager = @0x10020770: 0x1000313c
, std::allocator > >
>::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*)>, _M_storage = {_M_ptr =
0x10041d10, _M_buffer = {__data = "\000\000\000\000\020\004\035\020", __align =
{<=
expected =>std::experimental::any containing std::map with 3 elements = {[1] =
2, [3] = 4, [5] = 6}<=
[Bug libgomp/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #2 from joseph at codesourcery dot com --- The issue is that someone needs to go through all the parsing for OpenMP constructs, and figure out exactly where to add calls to convert_lvalue_to_rvalue (if an OpenMP construct reads the value of an object, reading the value of an _Atomic object must be an atomic load) and what other special handling might be needed (if an OpenMP construct writes to an object, it must be an atomic store; if it both reads and writes, some form of compare-and-exchange may be needed).
[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443 --- Comment #6 from vries at gcc dot gnu.org --- After looking into it a bit further, I think what we're trying to get is: ... : goto ; : i_17 = (int) ivtmp_y; _7 = (long unsigned int) i_17; _8 = _7 * 4; _9 = pretmp_24 + _8; _10 = *_9; sum_11 = _10 + sum_y; i_12 = i_17 + 1; i.1_3 = (unsigned int) i_12; goto ; : ivtmp_6 = ivtmp_y + 1; goto ; : # sum_y = PHI <1(x), sum_11(6)> # ivtmp_y = PHI <0(x), ivtmp_6(6)> if (ivtmp_y < _20 + 1) goto ; else goto ; : # sum_21 = PHI goto ; ...
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #8 from Matthias Klose --- Alan told me that you can work around it by configuring with --enable-targets=powerpcle-linux --disable-multilib to still have the -m32 option recognized.
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #8 from David --- (In reply to Kai Tietz from comment #7) The first code block in comment #6 is what is in the code now. As you can see, it already has the #define you are describing. I don't understand what you mean by "change it to" this, since it is already there. Are you suggesting we delete the entire #ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES block and replace it with the single #define? I would be ok with that. Using the #error (the second code block in comment #6) seemed like a more backward-compatible way to do this, since it would tell people what has happened and what to do to fix it rather than (silently) assuming we know what they want to do. But I am ok with either of these two solutions.
[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #6 from Zoltan Hidvegi ---
gcc collect2 links the programs twice, first it links just all the object and
archive files passed, then it parses the output and if necessary creates a
source file that contains information about static constructors and destructors
and some tables for exception unwinding, and compiles and relinks with that
additional object file. The problem is that the AIX linker by default does
garbage collection, and removes stuff that is unreachable. In the example b.cc
which contains main has no reference at all to anything in a.cc, so the garbage
collector thinks it can throw it away. If I use -bkeepfile:a.o for the first ld
call from collect2, then garbage collection is skipped for a.o, and this allows
the correct generation of frame_table and the example works. Unfortunately,
using -bnogc does not work, it leads to lots of undefined symbols. However
using -bexpfull for the first link does work (without keepfile), maybe that's a
proper fix? The only problem with that is that gcc does not call the second
link if it's not necessary, however keeping the executable created with
-bexpfull is not a good idea, so gcc would always have to relink.
Btw. a workaround is to refer to any symbol from a.cc from b.cc, e.g. adding a
dummy void bar() {} to a.cc and void junk() { bar(); } into b.cc would make the
example work.
[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Michael Meissner --- Problem is believed to be fixed in subversion id 221524.
[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 --- Comment #15 from Michael Meissner --- Author: meissner Date: Thu Mar 19 22:37:33 2015 New Revision: 221524 URL: https://gcc.gnu.org/viewcvs?rev=221524&root=gcc&view=rev Log: [gcc] 2015-03-19 Michael Meissner PR target/65240 * config/rs6000/predicates.md (easy_fp_constant): Remove special -ffast-math handling that kept non-0 constants live in the RTL until reload. Remove logic testing the number of instructions it took to create a constant in a GPR that was never used, due to a test for soft-float earlier. (memory_fp_constant): Delete, no longer used. * config/rs6000/rs6000.md (mov_hardfloat): Remove alternatives for loading non-0 constants into GPRs for hard floating point that is no longer needed due to changes in easy_fp_constant. Add support for loading 0.0 into GPRs. (mov_hardfloat32): Likewise. (mov_hardfloat64): Likewise. (mov_64bit_dm): Likewise. (movtd_64bit_nodm): Likewise. (pre-reload move FP constant define_split): Delete define_split, since it is no longer used. (extenddftf2_internal): Remove GHF constraints that are not valid for extenddftf2. [gcc/testsuite] 2015-03-19 Michael Meissner PR target/65240 * gcc/testsuite/g++.dg/pr65240.h: Add tests for PR 65240. * gcc/testsuite/g++.dg/pr65240-1.C: Likewise. * gcc/testsuite/g++.dg/pr65240-2.C: Likewise. * gcc/testsuite/g++.dg/pr65240-3.C: Likewise. * gcc/testsuite/g++.dg/pr65240-4.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/pr65240-1.C trunk/gcc/testsuite/g++.dg/pr65240-2.C trunk/gcc/testsuite/g++.dg/pr65240-3.C trunk/gcc/testsuite/g++.dg/pr65240-4.C trunk/gcc/testsuite/g++.dg/pr65240.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/65479] New: sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 Bug ID: 65479 Summary: sanitizer stack trace missing frames past #0 on powerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org On both powerpc64 and powerpc64le, the c-c++-common/asan/misalign-1.c shows 6 failures, all in the output pattern test. The failures are due to to the stack trace missing stack frame #1 (it only includes frame #0). It looks like the backtrace on powerpc doesn't work correctly. = ==87868==ERROR: AddressSanitizer: unknown-crash on address 0x3fffc231eb2f at pc 0x1ce8 bp 0x3fffc231e9f0 sp 0x3fffc231ea10 READ of size 4 at 0x3fffc231eb2f thread T0 #0 0x1ce4 in foo /src/gcc-5.0-git/gcc/testsuite/c-c++-common/asan/misalign-1.c:11 Address 0x3fffc231eb2f is located in stack of thread T0 at offset 175 in frame #0 0x186c in main /src/gcc-5.0-git/gcc/testsuite/c-c++-common/asan/misalign-1.c:28 This frame has 3 object(s): [32, 36) 'v' [96, 100) 'w' [160, 176) 't' <== Memory access at offset 175 partially overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: unknown-crash /src/gcc-5.0-git/gcc/testsuite/c-c++-common/asan/misalign-1.c:11 foo Shadow bytes around the buggy address: 0x09fff8463d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d50: f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 =>0x09fff8463d60: f2 f2 f2 f2 00[00]f4 f4 f3 f3 f3 f3 00 00 00 00 0x09fff8463d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==87868==ABORTING
[Bug target/65474] sub-optimal code for __builtin_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474 --- Comment #3 from wmi at google dot com --- Thanks. You are right. I wrote a microbenchmark (attached), and tested it on different intel microarchitectures. westmere: 1.gcc.out:19.42 1.llvm.out: 19.32 sandybridge: 1.gcc.out:18.61 1.llvm.out: 19.16 ivybridge: 1.gcc.out:15.79 1.llvm.out: 15.87 On sandybridge, llvm's version was slower. On other microarchitectures, they were close to each other. So gcc's choose makes sense.
[Bug target/65474] sub-optimal code for __builtin_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474 --- Comment #2 from wmi at google dot com --- Created attachment 35069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35069&action=edit microbench
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #7 from Anton Blanchard --- Thanks Martin. Bill: the swaps pass isn't catching our vectorised copy, I guess because of the adds in the loop: lxvd2x 0,9,4 addi 28,1,-48 add 6,9,10 xxpermdi 12,0,0,2 xxpermdi 12,12,12,2 stxvd2x 12,0,28
[Bug tree-optimization/65478] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 Jan Hubicka changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #1 from Jan Hubicka --- Martin, can you take a look on ipa-cp's decision sanity?
[Bug tree-optimization/65478] New: crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 Bug ID: 65478 Summary: crafty performance regression Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org As reported to me privately by Igor, crafty SPEC2k benchmark is slower since r219863 which decreased inline-unit-growth. I looked into the reason and it is the fact that we do not inline NextMove function. The function itself is big: Inline summary for NextMove/18 inlinable self time: 177 global time: 0 self size: 284 global size: 0 min size: 0 self stack: 0 global stack:0 size:228.00, time:150.114000, predicate:(true) size:3.00, time:2.00, predicate:(not inlined) size:4.00, time:0.649000, predicate:(op0 changed) size:4.00, time:5.946000, predicate:(op1 changed) size:2.00, time:1.486000, predicate:(op1 == 0) size:2.00, time:1.486000, predicate:(op1 != 0) One quite wrong estiamte I see is the following: switch (_45) , case 1: , case 2: , case 3: , case 4: , case 5: , case 6: , case 8: , case 9: , case 10: > freq:1.00 size: 20 time: 6 Accounting size:20.00, time:6.00 on predicate:(true) This assumes jump tree implementation of switch. We should discover dense switch statements and estimate the jumptable. The function overall is estimated as relatively uncool for inlining Considering NextMove/2405 with 284 size to be inlined into Search.constprop/4352 in unknown:-1 Estimated badness is -0.081348, frequency 0.69. Badness calculation for Search.constprop/4352 -> NextMove/2405 size growth 273, time 174 inline hints: cross_module array_index -0.040674: guessed profile. frequency 0.694000, count 0 caller count 0 time w/o inlining 397.838000, time w inlining 386.734000 overall growth 277 (current) 0 (original) Adjusted by hints -0.081348 not inlinable: Search.constprop/4352 -> NextMove/2405, --param inline-unit-growth limit reached I am not 100% sure what makes it interesting, though it sounds natural as it is part of the innermost loop. The function is called once, but because ipa-cp decides to clone Search function we turn it into function called twice: Estimating effects for Search/3356, base_time: 245. Estimating body: Search/3356 Known to be false: size:725 time:245 - estimates for value -32768 for param #0: time_benefit: 1, size: 725 Estimating body: Search/3356 Known to be false: op4 > 62, op4 changed size:707 time:242 - estimates for value 2 for param #4: time_benefit: 52, size: 707 Estimating body: Search/3356 Known to be false: size:725 time:245 - estimates for value 0 for param #5: time_benefit: 1, size: 725 Estimating body: Search/3356 Known to be false: size:725 time:245 - estimates for value 1 for param #5: time_benefit: 1, size: 725 Evaluating opportunities for Search/3356. - considering value 2 for param #4 (caller_count: 3) good_cloning_opportunity_p (time: 52, size: 707, freq_sum: 11298) -> evaluation: 830, threshold: 500 Creating a specialized node of Search/3356. ad
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #7 from Alan Modra --- On x86_64-linux you can run 32-bit binaries. On powerpc64le-linux you can't. It's that simple. -m32 support in powerpc64le gcc, by default, doesn't make sense until we have - supported and tested compat layer in the kernel - supported and tested gcc, binutils and glibc We might even want to change the 32-bit ABI for powerpcle. The change I made wasn't "just to be able to omit" --disable-multilib. It was also to fix the wrong default of enabling -m32 support in powerpc64le gcc. Another data point: llvm doesn't support -m32
[Bug ada/65477] New: gnat is built with nodlopen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65477 Bug ID: 65477 Summary: gnat is built with nodlopen Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: pavel at zhukoff dot net Created attachment 35068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35068&action=edit test program It's not possible to write shared plugins in ada because libgnat (and only libgnat from gcc) is built with nodlopen option. Example: Error: unable to load plugin "~/.weechat/plugins/liblibaweeplug.so": libgnat-4.9.so: shared object cannot be dlopen()ed How to reproduce: Try to dlopen libgnat.so. dlopen returns NULL works fine for libc/libm/etc
[Bug fortran/59198] [4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198 --- Comment #25 from Paul Thomas --- Author: pault Date: Thu Mar 19 20:12:29 2015 New Revision: 221523 URL: https://gcc.gnu.org/viewcvs?rev=221523&root=gcc&view=rev Log: 2014-03-19 Paul Thomas PR fortran/59198 * trans-types.c (gfc_get_derived_type): If an abstract derived type with procedure pointer components has no other type of component, return the backend_decl. Otherwise build the components if any of the non-procedure pointer components have no backend_decl. 2014-03-19 Paul Thomas PR fortran/59198 * gfortran.dg/proc_ptr_comp_44.f90 : New test * gfortran.dg/proc_ptr_comp_45.f90 : New test Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_44.f90 branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_45.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/trans-types.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 CC||hubicka at gcc dot gnu.org Assignee|hubicka at ucw dot cz |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka --- Mine. The type1 should not be in the vtable hash. I suppose it is an issue with merging non-polymorphic and polymorphic type over ODR violation.
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 --- Comment #13 from Vladimir Makarov --- Author: vmakarov Date: Thu Mar 19 19:59:38 2015 New Revision: 221522 URL: https://gcc.gnu.org/viewcvs?rev=221522&root=gcc&view=rev Log: 2015-03-19 Vladimir Makarov PR rtl-optimization/63491 * lra-constraints.c (check_and_process_move): Use src instead of sreg. Remove some dead code. 2015-03-19 Vladimir Makarov PR rtl-optimization/63491 * gcc.target/powerpc/pr63491.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr63491.c Modified: trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 CC||rguenther at suse dot de Ever confirmed|0 |1 --- Comment #3 from Jan Hubicka --- Confirmed. Actually I think this is more for Richard. The issues here is, I blieve, the fact that non-gimple-register return values are consiered to be stores that invalidate the memory context. It is FRE1 that does the optimization.
[Bug ada/65476] New: Long_Float array does not byte swap correctly when set to Scalar_Storage_Order with High Order First
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65476 Bug ID: 65476 Summary: Long_Float array does not byte swap correctly when set to Scalar_Storage_Order with High Order First Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: daniel.merrill at psware dot com CC: ebotcazou at gcc dot gnu.org Created attachment 35067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35067&action=edit code to reproduce the issue. When an array of Long_Floats is set to a scalar_storage_order of High_Order_First, only the two 32 bit words that make up the 64 bit value are swapped with each other but the bytes under those words are not swapped properly. Attached is a simple program that reproduces the behavior. If you examine the stored values you could get the right value by performing a byte swap on the underlying 32 bit value.
[Bug c++/65046] [5 regression] -Wabi-tag doesn't warn about variables or function return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #5 from Daniel Krügler --- (In reply to aral from comment #3) > I don't argue that it might be a misunderstanding of the user, hence my > suggestion 1) - however, I disagree with your wording "clearly documented" > as far as > > (a) http://en.cppreference.com/w/cpp/regex/regex_search and > (b) http://www.cplusplus.com/reference/regex/regex_search/ > > are concerned. I could not find any clear statement on "c++ official > language reference" with a google search. Is (a) official? No, neither (a) nor (b) are official C++ Standard specifications. A relevant one would be ISO/IEC 14882:2011 for C++11 for example. The Standard itself is no text book, so your definition of "clarity" does need to be reflected by that. See e.g. the link provided on https://isocpp.org/std/the-standard to retrieve it or as an approximation to the official document refer to the current working *draft* that can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf But all this exceeds the responsibility for this bug tracking system. You could probably request an enhancement of the libstdc++ documentation, but I believe that a priority of P3 major is not an appropriate one for this.
[Bug c++/65046] [5 regression] -Wabi-tag doesn't warn about variables or function return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Mar 19 19:31:48 2015 New Revision: 221521 URL: https://gcc.gnu.org/viewcvs?rev=221521&root=gcc&view=rev Log: PR c++/65046 Automatically propagate ABI tags to variables and functions from their (return) type. * class.c (check_tag): Handle variables and functions. (mark_or_check_attr_tags): Split out from find_abi_tags_r. (mark_or_check_tags): Likewise. (mark_abi_tags): Use it. Rename from mark_type_abi_tags. (check_abi_tags): Add single argument overload for decls. Handle inheriting tags for decls. * mangle.c (write_mangled_name): Call it. (mangle_return_type_p): Split out from write_encoding. (unmangled_name_p): Split out from write_mangled_name. (write_mangled_name): Ignore abi_tag on namespace. * cp-tree.h (NAMESPACE_IS_INLINE): Replace NAMESPACE_ABI_TAG. * parser.c (cp_parser_namespace_definition): Set it. * name-lookup.c (handle_namespace_attrs): Use arguments. Warn about abi_tag attribute on non-inline namespace. * tree.c (check_abi_tag_args): Split out from handle_abi_tag_attribute. (handle_abi_tag_attribute): Allow tags on variables. Added: trunk/gcc/testsuite/g++.dg/abi/abi-tag14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/mangle.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/abi/abi-tag1.C trunk/gcc/testsuite/g++.dg/abi/abi-tag4.C trunk/gcc/testsuite/g++.dg/abi/abi-tag8.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/gnu/messages_members.cc trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/src/c++11/cxx11-shim_facets.cc
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #4 from aral at gmx dot de --- Addition: after you referred to the properties of match_results, I had a look at http://en.cppreference.com/w/cpp/regex/match_results which has a clearer wording. However, I still think this clear statement => "it's undefined behavior to examine std::match_results if the original character sequence was destroyed or iterators to it were invalidated for other reasons" should be added to the description of the functions that populate the match_results. "The user" (I, in this case) does not always check the descriptions of every single function parameter if the function description seems to give all the information needed to use it. What could be improved (to avoid bugs going undetected) is to raise an exception if the match_results are accessed after the haystack has been destroyed.
[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475 --- Comment #1 from Martin Liška --- In odr_vtable_hasher::equal: 585 t2 = TYPE_MAIN_VARIANT (t2); 586 if (t1 == t2) 587return true; 588 tree v1 = BINFO_VTABLE (TYPE_BINFO (t1)); 589 tree v2 = BINFO_VTABLE (TYPE_BINFO (t2)); 590 return (operand_equal_p (TREE_OPERAND (v1, 1), 591 TREE_OPERAND (v2, 1), 0) 592 && DECL_ASSEMBLER_NAME 593 (TREE_OPERAND (TREE_OPERAND (v1, 0), 0)) 594 == DECL_ASSEMBLER_NAME (gdb) p t1->type_non_common.binfo->binfo.vtable $4 = (tree) 0x0 (gdb) p t2->type_non_common.binfo->binfo.vtable $5 = (tree) 0x76e289b0 (gdb) p debug_tree(t1) constant 8> unit size constant 1> align 8 symtab 0 alias set -1 canonical type 0x76e2bd20 attributes value readonly constant static "cxx11\000">>> fields unit size align 8 symtab 0 alias set -1 canonical type 0x76e2bd20 attributes fields context chain > nonlocal VOID file 1.ii line 4 col 57 align 1 context result > context chain > (gdb) p debug_tree(t2) constant 64> unit size constant 8> align 64 symtab 0 alias set -1 canonical type 0x76e2ec78 fields unit size align 64 symtab 0 alias set -1 canonical type 0x76e2e9d8 fields context chain > ignored BLK file 2.ii line 9 col 37 size unit size align 64 offset_align 128 offset bit offset context chain external nonlocal suppress-debug VOID file 2.ii line 9 col 78 align 8 context result >> context chain > Thanks, Martin
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #3 from aral at gmx dot de --- I don't argue that it might be a misunderstanding of the user, hence my suggestion 1) - however, I disagree with your wording "clearly documented" as far as (a) http://en.cppreference.com/w/cpp/regex/regex_search and (b) http://www.cplusplus.com/reference/regex/regex_search/ are concerned. I could not find any clear statement on "c++ official language reference" with a google search. Is (a) official? Either way, (a) states "7) The overload 3 is prohibited from accepting temporary strings, otherwise this function populates match_results m with string iterators that become invalid immediately." I do not find this very clear, especially since 7) is denoted "since C++14", and the temporary strings are already a problem in C++11. How about a statement like this for 2), 3), 5) and 6)? And maybe a clearer wording? I find the abscence of such a warning, along with the "const" statement in the parameter declaration (indicating one could submit a string literal for const charT* s) misleading to say the least.
[Bug lto/65475] New: [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
Bug ID: 65475
Summary: [5 Regression] ICE in odr_vtable_hasher::equal
(Segmentation fault)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: hubicka at ucw dot cz
Reporter: marxin at gcc dot gnu.org
Hi.
Following ICE can be seen in boost library:
$ g++ -O2 1.ii 2.ii -flto
1.ii:4:45: warning: type ‘struct failure’ violates one definition rule [-Wodr]
class __attribute((__abi_tag__("cxx11"))) failure : A {};
^
2.ii:4:45: note: a type with different virtual table pointers is defined in
another translation unit
class __attribute((__abi_tag__("cxx11"))) failure {
^
1.ii:4:45: warning: type ‘struct failure’ violates one definition rule [-Wodr]
class __attribute((__abi_tag__("cxx11"))) failure : A {};
^
2.ii:4:45: note: a type with different bases is defined in another translation
unit
class __attribute((__abi_tag__("cxx11"))) failure {
^
lto1: internal compiler error: Segmentation fault
0x9024df crash_signal
../../gcc/toplev.c:383
0x781cf1 odr_vtable_hasher::equal(odr_type_d const*, tree_node const*)
../../gcc/ipa-devirt.c:591
0x781cf1 hash_table::find_slot_with_hash(tree_node const*, unsigned int, insert_option)
../../gcc/hash-table.h:981
0x77b9bd get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:1717
0x77d32c register_odr_type(tree_node*)
../../gcc/ipa-devirt.c:1839
0x5b4566 lto_read_decls
../../gcc/lto/lto.c:1946
0x5b4f0b lto_file_finalize
../../gcc/lto/lto.c:2236
0x5b4f0b lto_create_files_from_ids
../../gcc/lto/lto.c:2246
0x5b4f0b lto_file_read
../../gcc/lto/lto.c:2287
0x5b4f0b read_cgraph_and_symbols
../../gcc/lto/lto.c:2992
0x5b4f0b lto_main()
../../gcc/lto/lto.c:3462
$ cat 1.ii
namespace std {
class ios_base {
struct A {};
class __attribute((__abi_tag__("cxx11"))) failure : A {};
} a;
}
$ cat 2.ii
namespace std {
template class Trans_NS___cxx11_basic_ostringstream;
class ios_base {
class __attribute((__abi_tag__("cxx11"))) failure {
virtual char m_fn2();
};
};
class B : virtual ios_base {};
template class Trans_NS___cxx11_basic_ostringstream : B {
public:
void m_fn1();
};
}
class A {
public:
A(int) {
std::Trans_NS___cxx11_basic_ostringstream a;
a.m_fn1();
}
};
int b;
void fn1() { (A(b)); }
[Bug target/65474] sub-optimal code for __builtin_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474 Andrew Pinski changed: What|Removed |Added Target||i?86-*-* x86_64-*-* Component|middle-end |target --- Comment #1 from Andrew Pinski --- Conditional move might be slower on some processors. Yes this would be an optimization for -Os but it depends on the timings for the specific processor. Have you done a micro benchmark to find out which implementation is better on different processors?
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler --- The behaviour is intended and clearly documented by the specification of the Standard Library: match_results, such as cmath, just hold weak references (via its sub_match elements) to the original search sequence, so (2) is definitively not an option. This doesn't look like a defect to me, this is just a misunderstanding of the user about the semantics of std::regex_search.
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #6 from Martin Sebor --- Created attachment 35066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35066&action=edit Assembly emitted by gcc 5.0.0 20150319 after aplying the patch referenced in comment #5.
[Bug middle-end/65474] New: sub-optimal code for __builtin_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474
Bug ID: 65474
Summary: sub-optimal code for __builtin_abs
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
int foo(int x) {
return __builtin_abs(x);
}
~/workarea/gcc-r221398/build/install/bin/gcc -O2 -S 1.c -o 1.gcc.s
.cfi_startproc
movl%edi, %edx
movl%edi, %eax
sarl$31, %edx
xorl%edx, %eax
subl%edx, %eax
ret
.cfi_endproc
~/workarea/llvm-r224097/build/bin/clang -O2 -S 1.c -o 1.llvm.s
.cfi_startproc
movl%edi, %eax
negl%eax
cmovll %edi, %eax
retq
.cfi_endproc
[Bug debug/63572] [5 Regression] ICF breaks user debugging experience
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #13 from howarth at bromo dot med.uc.edu --- Is this bug going to be suspended for 5.0? If so, it would also allow Bug 65303, "Tracking bug for ICF issues", to be closed as well for 5.0.
[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 --- Comment #5 from Jan Hubicka --- yep, this seems to be the usual situation where visibilities does not mix that well with assumptions that program is linked with symbols defined in the headers. I suppose we could make C++ FE to track if a type has methods with visibility default declared (I can't track that from symbol table as they may be unreachable). In such case we may want to consider methods of that type with non-default visibility and no resolution info to be !can_refer_decl_in_current_unit_p Jason, would that make sense to you?
[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238 --- Comment #9 from Jakub Jelinek --- Patch awaiting ack: http://gcc.gnu.org/ml/gcc-patches/2015-03/msg00647.html
[Bug tree-optimization/65303] Tracking bug for ICF issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65303 Bug 65303 depends on bug 65380, which changed state. Bug 65380 Summary: [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Liška --- Fixed in 5.0.0.
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed in 5.0.0.
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #15 from Martin Liška --- Author: marxin Date: Thu Mar 19 17:37:15 2015 New Revision: 221519 URL: https://gcc.gnu.org/viewcvs?rev=221519&root=gcc&view=rev Log: Fix PR ipa/65380. PR ipa/65380 * ipa-icf.c (sem_function::merge): Do not merge DECL_EXTERNAL symbols. (sem_variable::merge): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #12 from Jakub Jelinek ---
For the early objsz pass, I'm afraid it can have security implications.
Artificial testcase:
extern char *strcpy (char *__restrict __dest, const char *__restrict __src)
__attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__nonnull__ (1, 2)));
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) char *
__attribute__ ((__nothrow__ , __leaf__)) strcpy (char *__restrict __dest, const
char *__restrict __src)
{
return __builtin___strcpy_chk (__dest, __src, __builtin_object_size (__dest,
2 > 1));
}
const char *str1 = "JIHGFEDCBA";
int
main ()
{
struct A { char buf1[9]; char buf2[1]; } a;
char *p = a.buf1;
char *q = p + 1;
char *r = q + 3;
char *t = r;
if (r != &a.buf1[4])
t = (char *) &a;
strcpy (t, str1 + 5);
return 0;
}
with the early objsz this will use 10 for __bos rather than 5, so will not
detect the buffer overflow.
So, if we want to go forward with that, perhaps:
1) the first instance should (also for performance reasons) only try to deal
with __bos calls where the second argument is 1 or 3, and leave 0 and 2 alone
for the second objsz pass
2) maybe instead of folding the __bos call into constant, it should turn it
into
MIN_EXPR <__bos, XX> where XX would be the value computed by the pass (for
__bos (, 3) MAX_EXPR). That way, we'd use the smaller value of the two passes.
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 --- Comment #6 from Martin Liška --- Author: marxin Date: Thu Mar 19 17:35:52 2015 New Revision: 221518 URL: https://gcc.gnu.org/viewcvs?rev=221518&root=gcc&view=rev Log: Fix for PR ipa/65465. PR ipa/65465 * cgraphunit.c (cgraph_node::create_wrapper): Correctly reset all fields of cgraph_thunk_info. * g++.dg/ipa/pr65465.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr65465.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 --- Comment #4 from Jason Merrill --- So what's happening here is that the compiler sees that *m is a Derived, so it can devirtualize the destructor call to ~Derived, and ~Derived refers to the vtable. One solution would be to give ~Derived default visibility and move its definition out of line. But calls to virt_func would probably produce direct calls and thus undefined symbol errors as well. It seems like your code is designed for calling through the vtable, and devirtualization breaks that design, so turning off devirtualization is the right approach. It might be possible to make the compiler more clever about recognizing patterns that don't work well with devirtualization and automatically suppressing it in such cases. Such as, in this case, seeing explicit default visibility on a constructor.
[Bug c/65466] Unnecessary source line output for "note: each undeclared identifier is reported only once"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- I implemented some finer-control for the caret in https://gcc.gnu.org/ml/gcc-patches/2012-04/msg01836.html that specifically fixed this case. However, I never got around to get it approved and committed it. Please, feel free to take that patch and get it reviewed and committed. (If I was re-doing that patch again, I will try to overload inform(), because inform_with_flags is just too much typing).
[Bug c++/46476] Missing Warning about unreachable code after return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476 --- Comment #6 from Manuel López-Ibáñez --- *** Bug 65472 has been marked as a duplicate of this bug. ***
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Manuel López-Ibáñez changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #7 from Manuel López-Ibáñez --- Please don't change the status of the PR. *** This bug has been marked as a duplicate of bug 46476 ***
[Bug c/46582] No warning is given about always false condition and unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46582 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- Probably a duplicate. *** This bug has been marked as a duplicate of bug 17534 ***
[Bug c/17534] gcc fails to diagnose suspect expressions that have incompatible bit masks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17534 Manuel López-Ibáñez changed: What|Removed |Added CC||d.g.gorbachev at gmail dot com --- Comment #9 from Manuel López-Ibáñez --- *** Bug 46582 has been marked as a duplicate of this bug. ***
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465
--- Comment #5 from Jakub Jelinek ---
Reduced testcase:
struct A {};
struct B { virtual A foo () const; };
struct C { A foo () const; };
struct D : virtual B { A foo () const {} };
struct F : D { virtual int bar () const; };
int F::bar () const { return 0; }
A C::foo () const { return A (); }
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Ulya changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #6 from Ulya --- (In reply to Manuel López-Ibáñez from comment #5) I see. Thank you for a detailed answer. :)
[Bug c++/46476] Missing Warning about unreachable code after return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476 Manuel López-Ibáñez changed: What|Removed |Added CC||skvadrik at gmail dot com --- Comment #5 from Manuel López-Ibáñez --- *** Bug 65472 has been marked as a duplicate of this bug. ***
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org Resolution|FIXED |DUPLICATE --- Comment #5 from Manuel López-Ibáñez --- (In reply to Ulya from comment #4) > So GCC's intended behavior is not to warn about unreachable code? No, but the previous implementation of Wunreachable-code was very broken and nobody knew how to fix it, thus it was eventually removed. Since then (years ago!), nobody has offered a new implementation, which perhaps shows that there is actually little interest in this warning in practice. In the past, we got more reports about Wunreachable-code bogus warnings than about missed ones. Unfortunately, there are very few GCC developers working on the C/C++ FEs right now and they are very busy with other more urgent things, like structural work and updating to new standards. In addition, implementing this properly in the FE would need some kind of control-flow graph, which GCC only has in the middle-end. BTW, I don't think it is useful to close these reports as INVALID, since they are in essence requests for a new implementation of -Wunreachable-code. On the other hand, it is not useful to have a PR for each possible testcase, since as far as we know, there is no one even planning to work on this, unfortunately. *** This bug has been marked as a duplicate of bug 46476 ***
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Ulya changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from Ulya --- So GCC's intended behavior is not to warn about unreachable code?
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marek Polacek --- Yes, the warning has been removed altogether. -Wunreachable-code is retained only for backwards compatibility.
[Bug libstdc++/65473] New: Including does not define __GLIBCXX__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473 Bug ID: 65473 Summary: Including does not define __GLIBCXX__ Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Hi, One would expect that including _any_ header from the standard library defines the relevant detection macros. For example, I usually include the header to check for libc++ (per http://goo.gl/eXNYJH). However, libstdc++'s headers do not always define those detection macros. Regards, Louis Dionne
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 --- Comment #2 from Ulya --- $ gcc -W -Wall -Wextra -c 1.c gives the same result: no warning
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- -Wunreachable-code does nothing and is ignored.
[Bug middle-end/65472] New: -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Bug ID: 65472
Summary: -Wunreachable-code failure
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 35065
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35065&action=edit
1.c
Given the following code:
extern void f ();
void g ()
{
for (;;)
{
f ();
continue;
f ();
}
}
$ gcc -Wunreachable-code -c 1.c
$ clang -Wunreachable-code -c 1.c
1.c:9:3: warning: code will never be executed [-Wunreachable-code]
f ();
^
1 warning generated.
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 --- Comment #5 from vehre at gcc dot gnu.org --- Fix available with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from vehre at gcc dot gnu.org --- Remain issue should be fixed with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||vehre at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #14 from vehre at gcc dot gnu.org --- Fix available with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html and https://gcc.gnu.org/ml/fortran/2015-03/msg00086.html
[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from vehre at gcc dot gnu.org --- Fix available with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 --- Comment #4 from Martin Liška --- Patch I've been testing: diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c index e640907..8b7d056 100644 --- a/gcc/cgraphunit.c +++ b/gcc/cgraphunit.c @@ -2484,8 +2484,9 @@ cgraph_node::create_wrapper (cgraph_node *target) /* Turn alias into thunk and expand it into GIMPLE representation. */ definition = true; + + memset (&thunk, 0, sizeof(cgraph_thunk_info)); thunk.thunk_p = true; - thunk.this_adjusting = false; create_edge (target, NULL, count, CGRAPH_FREQ_BASE); tree arguments = DECL_ARGUMENTS (decl); -- Martin
[Bug middle-end/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 ktkachov at gcc dot gnu.org changed: What|Removed |Added Component|target |middle-end --- Comment #19 from ktkachov at gcc dot gnu.org --- Change component
[Bug c++/62255] [4.8/4.9 Regression] Introducing an unrelated template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.5 |4.9.3 --- Comment #13 from Jason Merrill --- Fixed for 4.9.3/5.
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #6 from Markus Trippelsdorf --- (In reply to Matthias Klose from comment #5) > > Well, on x86_64 if you build gcc with --disable-multilib you still > > can compile with -m32 (even without a 32-bit user runtime). > > Why should this be different on ppc64le? > > $ gcc -m32 -c foo.c > foo.c:1:0: error: -m32 not supported in this configuration > > well, it is different, and this doesn't work on 4.8, 4.9 and 5 anymore. I agree with you. The question was directed to Alan.
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #5 from Matthias Klose --- > Well, on x86_64 if you build gcc with --disable-multilib you still > can compile with -m32 (even without a 32-bit user runtime). > Why should this be different on ppc64le? $ gcc -m32 -c foo.c foo.c:1:0: error: -m32 not supported in this configuration well, it is different, and this doesn't work on 4.8, 4.9 and 5 anymore.
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 Jason Merrill changed: What|Removed |Added Status|WAITING |NEW --- Comment #16 from Jason Merrill --- Taking this bug out of WAITING; I don't know why it was there.
[Bug c++/65457] ICE in libgfortran/ieee/ieee_arithmetic.F90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457 Bernd Edlinger changed: What|Removed |Added Target||arm-linux-gnueabihf Component|fortran |c++ Host||arm-linux-gnueabihf Build||arm-linux-gnueabihf --- Comment #3 from Bernd Edlinger --- The problem is in the C compiler: arm-linux-gnueabihf-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-5-20150315/gcc -I../../gcc-5-20150315/gcc/. -I../../gcc-5-20150315/gcc/../include -I../../gcc-5-20150315/gcc/../libcpp/include -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross/./gmp -I/home/ed/gnu/gcc-5-20150315/gmp -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross/./mpfr -I/home/ed/gnu/gcc-5-20150315/mpfr -I/home/ed/gnu/gcc-5-20150315/mpc/src -I../../gcc-5-20150315/gcc/../libdecnumber -I../../gcc-5-20150315/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5-20150315/gcc/../libbacktrace -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross/./isl/include -I/home/ed/gnu/gcc-5-20150315/isl/include -o tree-cfg.o -MT tree-cfg.o -MMD -MP -MF ./.deps/tree-cfg.TPo ../../gcc-5-20150315/gcc/tree-cfg.c -save-temps results in this wrong code: .loc 7 3334 0 mov r3, ip ... .loc 7 3334 0 movtr3, #:upper16:tree_code_length str r3, [sp, #8] ... but "ip" is undefined, and thus the inlined version of tree_operand_check accesses something completely wrong instead of tree_code_length.
[Bug c/65471] New: type interpretation in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
Bug ID: 65471
Summary: type interpretation in _Generic
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.gustedt at inria dot fr
This is a bug marker for an underspecification in the C11 standard, that has
been observed in DR#423
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_423
gcc and clang went quite opposite ways to resolve that issue, resulting in
severe incompatibility for _Generic expression that use qualifiers or arrays.
The following six lines illustrate the problem
char const* a = _Generic("bla", char*: "blu"); // clang error
char const* b = _Generic("bla", char[4]: "blu"); // gcc error
char const* c = _Generic((int const){ 0 }, int: "blu");// clang error
char const* d = _Generic((int const){ 0 }, int const: "blu"); // gcc error
char const* e = _Generic(+(int const){ 0 }, int: "blu"); // both ok
char const* f = _Generic(+(int const){ 0 }, int const: "blu"); // both error
the last two lines, where gcc and clang agree, points to the nature of the
problem: gcc treats all such expressions as rvalues, clang as lvalues.
[Bug middle-end/65449] -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449 --- Comment #3 from Bernd Edlinger --- Yes, but that is not the fault of the strict volatile code path any more. For bit-fields this redundant read is exactly what AAPCS demands: "7.1.7.5 Volatile bit - fields preserving number and width of container accesses When a volatile bit-field is read, its container must be read exactly once using the access width appropriate to the type of the container. When a volatile bit-field is written, its container must be read exactly once and written exactly once using the access width appropriate to the type of the container. The two accesses are not atomic." IMO, the problem is this: In store_fixed_bit_field_1 we do not know if the access is on a packed structure member where the extra read is not necessary, or if we have a bit-field where the extra read would be mandatory, even if the complete container is overwritten. BTW: What happens in your example if you use -O0? Isn't there still an unaligned stw access? That's because you example is in a way invalid C. You can't set an int* to an unaligned address, it must be at least aligned to the GET_MODE_ALIGNMENT(SImode).
[Bug middle-end/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 Richard Biener changed: What|Removed |Added Known to work|5.0 | Summary|[4.9 Regression] memory hog |[4.9/5 Regression] memory ||hog Known to fail||5.0 --- Comment #9 from Richard Biener --- Reverted.
[Bug middle-end/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #10 from Richard Biener --- Author: rguenth Date: Thu Mar 19 13:36:18 2015 New Revision: 221515 URL: https://gcc.gnu.org/viewcvs?rev=221515&root=gcc&view=rev Log: 2015-03-19 Richard Biener Revert 2015-03-10 Richard Biener PR middle-end/63155 * tree-ssa-coalesce.h (verify_ssa_coalescing): Declare. * tree-ssa-coalesce.c: Include timevar.h. (attempt_coalesce): Handle graph being NULL. (coalesce_partitions): Call verify_ssa_coalescing if ENABLE_CHECKING. Split out abnormal coalescing to ... (perform_abnormal_coalescing): ... this function. (coalesce_ssa_name): Perform abnormal coalescing without computing live/conflict. (verify_ssa_coalescing_worker): New function. (verify_ssa_coalescing): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-coalesce.c trunk/gcc/tree-ssa-coalesce.h
[Bug target/65459] SLOW_UNALIGNED_ACCESS unconditionally set to 1 for ARM targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #2 from ktkachov at gcc dot gnu.org ---
FWIU ARMv6 and later supports unaligned accesses.
I guess the performance of unaligned accesses differs between cores.
The documentation for SLOW_UNALIGNED_ACCESS says:
"Define this macro to be the value 1 if memory accesses described by the
@var{mode} and @var{alignment} parameters have a cost many times greater
than aligned accesses, for example if they are emulated in a trap
handler."
It seems to me that on some modern cores even if unaligned access is more
expensive than normal it wouldn't be 'many times greater' so we should
definitely investigate setting this in a more intelligent way.
[Bug preprocessor/8270] [4.8/4.9/5 Regression] back-slash white space newline with comments, no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #55 from Kai Tietz ---
Well, by looking into the standard ISO/IEC 9899:TC3 I found the following
statement:
5.1.12 Translation phase
"2. Each instance of a backslash character (\) immediately followed by a
new-line
character is deleted, splicing physical source lines to form logical source
lines.
Only the last backslash on any physical source line shall be eligible for being
part of such a splice. A source file that is not empty shall end in a new-line
character, which shall not be immediately preceded by a backslash character
before any such splicing takes place."
For ISO/IEC 14882:2003 we see at topic "2 Lexical Convention"
"2 Each instance of a new-line character and an immediately preceding backslash
character is deleted, splicing physical source lines to form logical source
lines. If, as a result, a character sequence that matches the syntax of a
universal-character-name is produced, the behavior is undefined. If a source
file that is not empty does not end in a new-line character, or ends in a
new-line character immediately preceded by a backslash character, the behavior
is undefined."
So the handling of backslash whitespace newline is clearly a gnu-extension and
not part of the standard.
I suggest something like this patch for fixing standard-requirement.
Additionally we could check here for cpp_option lang being gnu-style for
allowing 'backslash,whitespaces,newling' too.
Index: lex.c
===
--- lex.c (Revision 221514)
+++ lex.c (Arbeitskopie)
@@ -896,6 +896,11 @@ _cpp_clean_line (cpp_reader *pfile)
p--;
if (p - 1 != pbackslash)
goto done;
+ if (p != d)
+ {
+ ++p;
+ goto done;
+ }
/* Have an escaped newline; process it and proceed to
the slow path. */
@@ -917,13 +922,19 @@ _cpp_clean_line (cpp_reader *pfile)
if (s == buffer->rlimit)
break;
- /* Escaped? */
+ /* Escaped?
+But make sure it isn't a backslash followed by a
+whitespace. */
p = d;
while (p != buffer->next_line && is_nvspace (p[-1]))
p--;
if (p == buffer->next_line || p[-1] != '\\')
break;
-
+ if (p != d)
+ {
+ ++p;
+ break;
+ }
add_line_note (buffer, p - 1, p != d ? ' ': '\\');
d = p - 2;
buffer->next_line = p - 1;
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #11 from Richard Biener --- Created attachment 35064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35064&action=edit patch I am testing the attached, testcases to be ameded from the dups.
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #10 from Richard Biener --- I do think that the gimplifiers "folding" is premature. All propagators know to apply the trick internally. This premature folding is probably to avoid regressions with removing the invalid maybe_fold_* stuff. I'll see whether removing it is safe. Of course it won't fix the testcase on its own - CCP happily applies the same trick to forward the "constant" address to the builtin call: --- t.c.028t.copyrename12015-03-19 12:52:53.875179949 +0100 +++ t.c.029t.ccp1 2015-03-19 12:52:53.876179961 +0100 @@ -25,21 +25,15 @@ struct A a; const char * str1.0_2; const char * _3; - char * _4; - int _7; - long unsigned int _8; char * _9; : str1.0_2 = str1; _3 = str1.0_2 + 5; - _4 = &a.buf1 + 4; - _8 = __builtin_object_size (_4, 1); - _9 = __builtin___strcpy_chk (_4, _3, _8); + _9 = __builtin___strcpy_chk (&MEM[(void *)&a + 4B], _3, 6); also folding the object-size call at the same time (to the bogus value because of passing it &MEM[(void *)&a, +4B] as well). I think it is desirable to fold the object-size call here and we can certainly special-case this particular case (looking at the def of _4 instead of its lattice value). But not sure if that's a good enough fix for the general issue. After "fixing" the gimplifier we have to make sure neither CCP1, CCP2 or FRE1 perform this trick (forwprop would also wreck things for slightly more complicated cases).
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #9 from Jakub Jelinek --- For the option of not folding this to MEM_REFs before objsz pass, I'd note this could be just about the &MEM_REF cases, if there is an actual memory access, so we aren't taking the address of the MEM_REF, then we can use MEM_REF as before. Similarly if we are folding &a + 4 into &MEM_REF[&a + 4] it would be fine, just we'd avoid doing that early for &a.field + 4.
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #8 from Jakub Jelinek --- So, given that you promoted this to P1, what are we going to do with this? This indeed started with r214941, and from objsz POV, in *.original, while it changed from: - strcpy (&a.buf1[4], str1 + 5); + strcpy ((char *) &a.buf1 + 4, str1 + 5); it is still reasonable, no information is lost. The information is lost during gimplification, where we gimplify it as: - strcpy (&a.buf1[4], D.1762); + strcpy (&MEM[(void *)&a + 4B], D.1762); and there we already lost the info whether it was strcpy (&a.buf1 + 4, ...) or strcpy (&a, ...), where we really don't want to treat those two the same. So, either we should avoid folding this to a MEM_REF before objsz pass, or allow MEM_REF operand to be (perhaps just before objsz pass) not just SSA_NAME or ADDR_EXPR of a DECL, but also ADDR_EXPR of handled_component_p and only lower it later (lose the information on where it pointed to). Or add optional third argument to MEM_REF that would contain say the COMPONENT_REF (if any) with PLACEHOLDER_EXPR inside for the type of the DECL in ADDR_EXPR in the first operand. Something else?
[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini --- Done.
[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Mar 19 11:02:47 2015 New Revision: 221513 URL: https://gcc.gnu.org/viewcvs?rev=221513&root=gcc&view=rev Log: 2015-03-19 Paolo Carlini PR c++/52659 * g++.dg/cpp0x/deleted11.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted11.C Modified: trunk/gcc/testsuite/ChangeLog
