[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452
--- Comment #2 from Ray Strode rstrode at redhat dot com ---
probably should catch
if (foo == foo) {
}
type situations too.
[Bug rtl-optimization/65078] [5 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35044 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35044action=edit gcc5-pr65078.patch Untested fix using a pre-reload splitter of mov[sd]i if the source is SI/DImode lowpart subreg of 16/32/64 byte vector register.
[Bug target/64208] [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208 Yvan Roux yroux at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||yroux at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |yroux at gcc dot gnu.org --- Comment #2 from Yvan Roux yroux at gcc dot gnu.org --- Regression was introduced on trunk and 4.9 branch by fix of PR rtl-optimization/60969 and then workaround by r211798 (-fuse-caller-save enable for ARM). The PR fix changes some IRA cost which makes it choose a IWMMXT_REGS (instead of a GENERAL_REGS one) for the result of iwmmxt_arm_movdi insn and the alternatives of this pattern make LRA stuck in a loop. The -fuse-caller-save patch fixed the issue because it adds IP and CC cloobers to CALL_INSN_FUNCTION_USAGE, which changes the register allocation (a GENERAL_REGS is selected this time), but the real issue is in the alternatives description of iwmmxt_arm_movdi insn. I've a patch for it that I'll submit.
[Bug target/65456] New: powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 Bug ID: 65456 Summary: powerpc64le autovectorized copy loop missed optimization Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Created attachment 35049 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35049action=edit Testcase pulled from valgrind The attached copy loop (out of valgrind) produces some pretty bad code: df8: e4 06 9e 78 rldicr r30,r4,0,59 dfc: e4 26 df 78 rldicr r31,r6,4,59 e00: 10 00 84 38 addir4,r4,16 e04: 01 00 c6 38 addir6,r6,1 e08: 99 f6 20 7c lxvd2x vs33,0,r30 e0c: 57 0a 21 f0 xxswapd vs33,vs33 e10: 2b 03 a1 11 vperm v13,v1,v0,v12 e14: 97 0c 01 f0 xxlor vs32,vs33,vs33 e18: 56 6a 0d f0 xxswapd vs0,vs45 e1c: 98 4f 1f 7c stxvd2x vs0,r31,r9 e20: d8 ff 00 42 bdnzdf8 memmove+0x6e8 Since we are using VSX storage ops, we should just align the source and do unaligned stores. That will remove the permute, and then the gcc pass to remove redundant swaps should kick in and remove them too.
[Bug c/48996] fixincl on Red Hat EL 5 breaks sys/stat.h fstat64()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48996 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Looks like a NOTABUG, and hardly a C FE issue.
[Bug c/65405] improve locations of diagnostics in c-pragma.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65405 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/65445] Improve [-W...] display for -Wformat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65445 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/64223] same warning repeated twice with same line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64223 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||mpolacek at gcc dot gnu.org
[Bug gcov-profile/64634] [4.8/4.9 Regression] gcov reports catch(...) as not executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64634 --- Comment #6 from Jörg Richter joerg.rich...@pdv-fs.de --- Is this stable enough to be considered for 4.9.3?
[Bug c/65446] New: Improve -Wformat-signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446 Bug ID: 65446 Summary: Improve -Wformat-signedness Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org As PR 65040 shows, the current implementation of -Wformat-signedness is not optimal. (When it is more robust, one could consider to re-enable it with -Wformat=2.) The idea of the warning is to warn for %ld, size_t_variable as one has to use %lu to print the negative values. Or reversely using %u for a signed value, where it is even more likely that the issue occurs. See also cppcheck --enable=warning which supports this warning. (But its warning pattern makes more sense than GCC's.) GCC's current implementation warns too often - and misses some cases. The main bug is that it doesn't take type promotion into account. In particular: It warns for: printf (%u\n, unsigned_short); but shouldn't: First, %u and unsigned_short are both unsigned. (It also shouldn't and doesn't warn for %d with unsigned short as all values are representible by %d. It doesn't warn but should warn for printf(%u\n, _short); As passing, e.g., (short)-1 to %u will print the wrong value (UINT_MAX instead of -1). GCC currently also warns for printf(%x\n, 1), which is very questionable.
[Bug c/65445] New: Improve [-W...] display for -Wformat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65445 Bug ID: 65445 Summary: Improve [-W...] display for -Wformat Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Currently, the -Wformat suboptions (-Wformat-contains-nul, etc.) are shown as [-Wformat=] - it would be useful to have the individual flag (such as [-Wformat-contains-nul]) instead. Originally reported as PR 65040 comment 18
[Bug c/45320] Strict-aliasing misdetection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45320 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Not a bug.
[Bug c/43827] Intrinsic possibility: does not alias global data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Preprocessed source missing for several years, closing.
[Bug c/65446] Improve -Wformat-signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65446 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #0) It doesn't warn but should warn for printf(%u\n, _short); Actually, it (correctly) does warn in this case (as short it promoted to int, which is also unsigned).
[Bug c/64609] No -Wbool-compare warning on (a = 0 0) = 4 and 0 a 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64609 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/64610] No -Wbool-compare warning on (0 != a) = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64610 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 Ever confirmed|0 |1
[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 --- Comment #36 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #35) Author: jvdelisle Date: Tue Mar 17 01:22:12 2015 New Revision: 221473 URL: https://gcc.gnu.org/viewcvs?rev=221473root=gccview=rev Log: 2015-03-16 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64432 * gfortran.dg/system_clock_3.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08 Modified: trunk/gcc/testsuite/ChangeLog Jerry, are you sure that .and.ing the conditions in the testcase is correct, or shouldn't they rather be .or.ed?
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0) (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed ?
[Bug target/64802] [ARM] Selecting an -mcpu or -march that supports only one of ARM/Thumb should default to the ISA that *is* supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64802 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Confirmed.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #2 from Jens Gustedt jens.gustedt at inria dot fr --- Since typeof is a gcc extension, there is not much arguing about it, but this sounds wrong to me. Use cases I have, and that I seen used by others are for example something like _Atomic int a; __typeof__(a) b __attribute__((weak,alias(a))); This would systematically fail with that approach. When _Atomic will go into wider use these difficulties will pop up more often. Eliminating qualifiers in expressions is easy for arithmetic types at least, something like __typeof__((a)+0) b; should always do the trick. In P99 I have implemented an equivalent to stdatomic.h that seems to work well without assuming a drop of qualifiers. (and BTW, the current version of stdatomic.h uses __auto_type, which makes it incompatible with clang.)
[Bug inline-asm/65436] Max number of extended asm +input operands currently limited to 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Also for vectors should you not use intrinsics instead of the asm. Also if you are writing to all of the registers, won't it be easier to write the function in pure assembly code rather than writing the code partly in C and partly in assembly code. Clobbers don't count towards the total and should be used instead.
[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 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #6 from Alexandre Oliva aoliva at gcc dot gnu.org --- The problem starts in the first copyrename pass. We refrain from coalescing variables if neither has a usable root. This causes us to fail to coalesce partitions that we would coalesce if only we tried them in a different order (i.e., P1 and P2 fail but either one coalesces with P3, and then the other would coalesce with that union). This is exactly what happens in AO_myload with -DOPT: partitions _3 and _6 won't coalesce, and then result_4 and _6 coalesce, which would enable _3 to coalesce too. This in turn brings additional rootless variables into stm_load, which again fail to coalesce because we try them first (_36 and _4 fails, and l_11 and _36 passes, so that with _4 would work). Without -DOPT, we succeed in coalescing result (there are fewer SSA names), and when that is inlined, it gets there with a root symbol, so that coalescing of _36 and result_4 succeeds. In both cases, we coalesce l_11 with result_36, and it is precisely because _4 remains separate that we end up introducing copies in new blocks when going out of SSA into RTL. Coalescing SSA names even when neither has a root removes the optimization differences for this testcase.
[Bug fortran/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35047 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35047action=edit gcc5-pr65450.patch Fix that passed bootstrap/regtest on x86_64-linux and i686-linux. It is I think conservatively correct, on the other side we don't have any ccp pass after vectorization that could recompute that info, only vrp2 which doesn't do zero bits computation, so perhaps we should try harder.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- By design, typeof removes qualifiers in certain cases. Currently it only removes them from atomic types (as needed for use in stdatomic.h), but arguably it should do so more generally - this would be useful for certain macros when passed const arguments, and would reflect that qualifiers on rvalues are not meaningful in C standard terms (so rvalues should always be considered to have unqualified type) but GCC's internal representation may or may not have them. /* For use in macros such as those in stdatomic.h, remove all qualifiers from atomic types. (const can be an issue for more macros using typeof than just the stdatomic.h ones.) */
[Bug ada/65451] gnat bug: Storage_Error stack overflow or erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-17 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Concatenate the Ada files listed in the report, gzip and attach the result.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 17 Mar 2015, jens.gustedt at inria dot fr wrote: Eliminating qualifiers in expressions is easy for arithmetic types at least, something like __typeof__((a)+0) b; No, that would not work for the uses in stdatomic.h. The temporary must have the unqualified, non-atomic type when a is, for example, _Atomic char; there can't be any promotions as otherwise the type would be wrong when the address of the temporary is taken. (and BTW, the current version of stdatomic.h uses __auto_type, which makes it incompatible with clang.) Well, GCC's stdatomic.h only ever needs to be compatible with the same version of GCC it ships with. __auto_type is to avoid duplicate evaluations of side-effects in operands with variably modified types (a variably modified argument to typeof is evaluated, unlike a non-VM argument); see gcc.dg/atomic/stdatomic-vm.c.
[Bug c/65455] New: typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 Bug ID: 65455 Summary: typeof _Atomic fails Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.gustedt at inria dot fr The following declarations _Atomic int a; __typeof__(a) a; result in compile errors: typeof_atomic.c:2:15: error: conflicting type qualifiers for 'a' __typeof__(a) a; ^ typeof_atomic.c:1:13: note: previous declaration of 'a' was here _Atomic int a; This could be related to bug #65345. Jens
[Bug inline-asm/65436] Max number of extended asm +input operands currently limited to 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436 David gccbugzilla at limegreensocks dot com changed: What|Removed |Added CC||gccbugzilla@limegreensocks. ||com --- Comment #2 from David gccbugzilla at limegreensocks dot com --- In fact, this effect of '+' is explicitly documented at https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#OutputOperands: Operands using the '+' constraint modifier count as two operands (that is, both as input and output) towards the total maximum of 30 operands per asm statement. Have you actually hit this limit? Or is this a theoretical discussion?
[Bug fortran/65450] New: [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Bug ID: 65450 Summary: [5.0 Regression]: Unaligned access with -O3 -mtune=k8 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com The compiler generates unaligned access for Polyhedron channel.f90 test when compiled with -O2 -mtune=k8: /home/uros/gcc-build/gcc/gfortran -B/home/uros/gcc-build/gcc -B/home/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/ -B/home/uros/gcc-build/x86_64-unknown-linux-gnu/libquadmath/.libs -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/.libs -L-L/home/uros/gcc-build/x86_64-unknown-linux-gnu/libquadmath/.libs -O2 -ffast-math -mtune=k8 channel.f90 LD_LIBRARY_PATH=/home/uros/gcc-build/gcc:/home/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/.libs:/home/uros/gcc-build/x86_64-unknown-linux-gnu/libquadmath/.libs ./a.out ... Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x2AC9058B3C27 #1 0x2AC9058B2E20 #2 0x31CDC3002F #3 0x402AFB in ddx at channel.f90:247 Segmentation fault (gdb) r ... Program received signal SIGSEGV, Segmentation fault. 0x00402afb in ddx (array=..., __result=...) at channel.f90:247 247 ddx(2:I-1,1:J) = array(3:I,1:J)-array(1:I-2,1:J)! interior points (gdb) bt #0 0x00402afb in ddx (array=..., __result=...) at channel.f90:247 #1 sw () at channel.f90:148 #2 0x00404cfd in main (argc=optimized out, argv=optimized out) at channel.f90:234 #3 0x0031cdc1d9f4 in __libc_start_main () from /lib64/libc.so.6 #4 0x00400909 in _start () (gdb) disass ... 0x00402acc +7644: movaps %xmm4,-0x20(%rdx) 0x00402ad0 +7648: movlpd -0x10(%rax),%xmm0 0x00402ad5 +7653: movhpd -0x8(%rax),%xmm0 0x00402ada +7658: movapd %xmm0,%xmm4 0x00402ade +7662: subpd %xmm3,%xmm4 0x00402ae2 +7666: movaps %xmm4,-0x10(%rdx) 0x00402ae6 +7670: cmp$0xf4,%rdi 0x00402aed +7677: jne0x402a71 sw+7553 0x00402aef +7679: lea0x20(%rcx),%rdi 0x00402af3 +7683: add$0x20,%rax 0x00402af7 +7687: add$0x20,%rdx = 0x00402afb +7691: movapd -0x20(%rax),%xmm3 0x00402b00 +7696: mov$0xf6,%r11d 0x00402b06 +7702: xor%ecx,%ecx 0x00402b08 +7704: movapd %xmm3,%xmm4 0x00402b0c +7708: subpd %xmm0,%xmm4 ... (gdb) p/x $rax $3 = 0x8c5a38 The failure can also be seen on SUSE gcc tester [1]. [1] http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-performance-latest
[Bug c++/65312] Implicitly-declared default constructor must be defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Closing then.
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- The problematic instruction (insn 1717) is generated from: ;; vect__1095.501_3524 = MEM[base: vectp.499_3571, offset: 0B]; (insn 1717 1716 0 (set (reg:V2DF 1511 [ vect__1095.501 ]) (mem:V2DF (reg/f:DI 638 [ vectp.499 ]) [7 MEM[base: vectp.499_3571, offset: 0B]+0 S16 A256])) channel.f90:247 -1 (nil))
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358
--- Comment #14 from ktkachov at gcc dot gnu.org ---
Right, I think the root cause is the emit_push_insn in expr.c.
It's supposed to push what needs to be pushed from a partial argument onto the
stack and do the moves into the registers.
Currently it performs the pushes and then does the moves, which does the wrong
things if the pushing destroys stack elements that it wants to load into
registers. Doing the load-to-registers part first and the pushing second fixed
this for me and generated the below:
foo:
@ args = 16, pretend = 8, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
sub sp, sp, #8
mov r0, r1
mov r1, r2
str lr, [sp, #-4]!
ldr lr, [sp, #16]
mov ip, sp
str r3, [ip, #8]!
ldmia ip, {r2, r3}
str lr, [sp, #12]
ldr lr, [sp], #4
add sp, sp, #8
b bar
which still does the tail call optimisation. I haven't tested it more
extensively yet, so I'll be taking that approach and prepare and test a patch.
[Bug rtl-optimization/65078] [5 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, I have managed to reproduce it, but only if it is preprocessed with each compiler separately. Seems it is the _mm_storel_epi64 change from r217608 that matters here, if I use the pre-r217608 content of that inline function, I get 25 %esp references with all compilers I've tried, with r217608 or later _mm_storel_epi64 I get 75 %esp references even with 4.8.
[Bug middle-end/65449] New: -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
Bug ID: 65449
Summary: -fstrict-volatile-bitfields affects volatile pointer
dereference and produce wrong codes
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ma.jiang at zte dot com.cn
Hi,all.
It seems that -fstrict-volatile-bitfields can affect volatile pointer
dereference. However, the gcc manual said this option should only affect
accesse to bit-fields or structure fields.
Compiling the test case:
char mt[20];
void main()
{
void *mm=(mt[1]);
*((volatile int *)mm)=4;
}
with -O2 -mstrict-align -fstrict-volatile-bitfields on PPC. We can see that
*((volatile int *)mm)=4 is done by a single stw. Beware that -mstrict-align
means a non-aligned memory access is disallowed, and (mt[1]) is obviously not
a address aligned to 4-bytes boundary. The compiler should have no reasons to
produce a unaligned stw when mstric-align is on.
Further more,compiling with -O2 -mstrict-align -fno-strict-volatile-bitfields,
the compiler will produce four lbz/stb pairs for *((volatile int *)mm)=4;.
This is ridiculous as the C standard does not require the read, and surely no
performance benefits could grain from these lbz.
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 35042 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35042action=edit Testcase from Polyhedron testsuite
[Bug rtl-optimization/65078] [5 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, in *.optimized the changes are just 16 times a difference like:
- _62 = __builtin_ia32_vec_ext_v2di (_63, 0);
+ _62 = BIT_FIELD_REF _63, 64, 0;
And during expansion, the difference is:
-;; _62 = __builtin_ia32_vec_ext_v2di (_63, 0);
-
-(insn 42 41 43 (set (reg:V2DI 329)
-(subreg:V2DI (reg:V16QI 138 [ D.4823 ]) 0)) ./include/emmintrin.h:722
-1
- (nil))
-
-(insn 43 42 44 (set (reg:DI 330)
-(vec_select:DI (reg:V2DI 329)
-(parallel [
-(const_int 0 [0])
-]))) ./include/emmintrin.h:722 -1
- (nil))
-
-(insn 44 43 0 (set (reg:DI 136 [ D.4825 ])
-(reg:DI 330)) ./include/emmintrin.h:722 -1
- (nil))
-
-;; MEM[(long long int *)dest_268] = _62;
-
-(insn 45 44 0 (set (mem:DI (reg/v/f:SI 317 [ dest ]) [3 MEM[(long long int
*)dest_268]+0 S8 A64])
-(reg:DI 136 [ D.4825 ])) ./include/emmintrin.h:722 -1
- (nil))
+;; MEM[(long long int *)dest_268] = _62;
+
+(insn 42 41 43 (set (reg:TI 329)
+(subreg:TI (reg:V16QI 138 [ D.4825 ]) 0)) ./include/emmintrin.h:722 -1
+ (nil))
+(insn 43 42 0 (set (mem:DI (reg/v/f:SI 317 [ dest ]) [3 MEM[(long long int
*)dest_268]+0 S8 A64])
+(subreg:DI (reg:TI 329) 0)) ./include/emmintrin.h:722 -1
+ (nil))
With the new storel_epi64 we get before RA:
(insn 43 40 44 3 (set (mem:DI (reg/v/f:SI 317 [ dest ]) [3 MEM[(long long int
*)dest_268]+0 S8 A64])
(subreg:DI (reg:V16QI 328) 0)) ./include/emmintrin.h:722 89
{*movdi_internal}
(expr_list:REG_DEAD (reg:V16QI 328)
(nil)))
out of this, and not surprisingly the RA reloads it by storing the V16QI 328
into stack and loads back a DImode value, while with the old intrinsic before
RA we have:
(insn 45 43 46 3 (set (mem:DI (reg/v/f:SI 317 [ dest ]) [3 MEM[(long long int
*)dest_268]+0 S8 A64])
(vec_select:DI (subreg:V2DI (reg:V16QI 328) 0)
(parallel [
(const_int 0 [0])
]))) ./include/emmintrin.h:722 3660 {*vec_extractv2di_0_sse}
(expr_list:REG_DEAD (reg:V16QI 328)
(nil)))
and don't need to spill that. Now the question is if we can tell RA somehow
(secondary reload) that to get a DImode lowpart subreg (and SImode too?) out of
a vector register it can use the *vec_extractv2di_0_sse instruction for that.
Or add !TARGET_64BIT pattern for storing a DImode lowpart subreg of a vector
register (any mode there?) into memory? Or ensure that the BIT_FIELD_REF is
expanded as the builtin used to be.
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed between r220156 (2015-01-27, OK) and r220302 (2015-01-31, segfault). I am not sure this is a fortran problem (no segfault if the code is compiled with '-O3 -fno-tree-vectorize -mtune=k8').
[Bug c++/65448] New: Allow for cascade includes in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65448 Bug ID: 65448 Summary: Allow for cascade includes in error messages Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ethouris at gmail dot com When gcc reports a compile error that refers to a line in a file that is included by another include file, which is finally included by the *.cpp file being compiled, it reports the error more-less this way: In file included from file1.h:10:1, from file2.h:11:1, from file.cpp:9:0: file3.h:25:0: error: 'symbol' does not name a type Most tools that use these error reports simply skip the first three lines, as they do not look like standard compiler error format. It would be nice to have at least an option to change the format into something like this: file1.h:10:1: note: In file included from here, file2.h:11:1: note: from here, file.cpp:9:0: note: from here, file3.h:25:0: error: 'symbol' does not name a type Some programming mistakes are very tough to determine without the cascade include information (such as forgetting a semicolon in some declaration before an #include directive).
[Bug c++/65312] Implicitly-declared default constructor must be defined as deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65312 --- Comment #5 from radventure at yandex dot ru --- (In reply to Marek Polacek from comment #4) Looks like this PR could be resolved as a NOTABUG? Agree
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Tue Mar 17 10:34:11 2015 New Revision: 221475 URL: https://gcc.gnu.org/viewcvs?rev=221475root=gccview=rev Log: PR target/65296 * config/avr/avr.opt (-nodevicelib): New option. * doc/invoke.texi (AVR Options): Document it. * config/avr/avrlibc.h (LIB_SPEC, LIBGCC_SPEC) [avr1]: Don't link libgcc.a, libc.a, libm.a. * config/avr/specs.h: Same. * config/avr/gen-avr-mmcu-specs.c (print_mcu): Don't print specs which don't (directly) depend on the device. Print more help. (*avrlibc_devicelib) [-nodevicelib]: Don't link libdev.a. (*cpp): Don't define __AVR_DEV_LIB_NAME__. * config/avr/driver-avr.c: Remove -nodevicelib from option list in case of an error. (avr_devicespecs_file): Use suffix %s instead of absolute path for specs file name. * config/avr/avr-arch.h (avr_mcu_t) [.library_name]: Remove. * config/avr/avr-mcus.def: Adjust initializers and comments. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-arch.h trunk/gcc/config/avr/avr-devices.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/avrlibc.h trunk/gcc/config/avr/driver-avr.c trunk/gcc/config/avr/gen-avr-mmcu-specs.c trunk/gcc/config/avr/specs.h trunk/gcc/doc/invoke.texi
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Most likely r220244, but have to verify that.
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 --- Comment #15 from fiesh at zefix dot tv --- Boost 1.58.0 has a workaround by making one function explicit. (https://github.com/boostorg/polygon/commit/634aa3de29d63dcf02a478ca2b5045c5e9ccb7e0) Since this means the bug becomes irrelevant for me, I suppose the number of people who do find the bug relevant has decreased to zero. ;)
[Bug tree-optimization/65447] New: AArch64: iv-opt causes bad addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65447
Bug ID: 65447
Summary: AArch64: iv-opt causes bad addressing
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Hi,
For below case extracted from spec2006 (and even worse in real case), loops
containing a significant number of memory accesses generate very inefficient
code. This is due to iv-opt hitting a limit and choosing the wrong induction
variable, resulting in addressing modes with huge offsets and all loads/stores
expanded into 2 or 3 instructions.
The source code is like:
void foo (double *p)
{
int i;
for (i = -2; i 20; i+= 40)
{
p[i+0] = 1.0;
p[i+1] = 1.0;
p[i+2] = 1.0;
p[i+3] = 1.0;
p[i+4] = 1.0;
p[i+5] = 1.0;
p[i+6] = 1.0;
p[i+7] = 1.0;
p[i+8] = 1.0;
p[i+9] = 1.0;
p[i+10] = 1.0;
p[i+11] = 1.0;
p[i+12] = 1.0;
p[i+13] = 1.0;
p[i+14] = 1.0;
p[i+15] = 1.0;
p[i+16] = 1.0;
p[i+17] = 1.0;
p[i+18] = 1.0;
p[i+19] = 1.0;
p[i+20] = 1.0;
p[i+21] = 1.0;
p[i+22] = 1.0;
p[i+23] = 1.0;
p[i+24] = 1.0;
p[i+25] = 1.0;
p[i+26] = 1.0;
p[i+27] = 1.0;
p[i+28] = 1.0;
p[i+29] = 1.0;
p[i+30] = 1.0;
p[i+31] = 1.0;
p[i+32] = 1.0;
p[i+33] = 1.0;
p[i+34] = 1.0;
p[i+35] = 1.0;
p[i+36] = 1.0;
p[i+37] = 1.0;
p[i+38] = 1.0;
p[i+39] = 1.0;
}
}
And comparison of generated assembly and the optimal one:
*** test.S2015-03-17 17:04:41.677033862 +0800
--- ../../../trunk-orig/target/bin/test.S2015-03-17 17:03:45.377033869
+0800
***
*** 7,40
.typefoo, %function
foo:
fmovd0, 1.0e+0
! subx1, x0, #159744
! addx2, x0, 1597440
! subx0, x1, #256
! addx1, x2, 2560
.p2align 2
.L2:
! stpd0, d0, [x0]
! stpd0, d0, [x0, 16]
! stpd0, d0, [x0, 32]
! stpd0, d0, [x0, 48]
! stpd0, d0, [x0, 64]
! stpd0, d0, [x0, 80]
! stpd0, d0, [x0, 96]
! stpd0, d0, [x0, 112]
! stpd0, d0, [x0, 128]
! stpd0, d0, [x0, 144]
! stpd0, d0, [x0, 160]
! stpd0, d0, [x0, 176]
! stpd0, d0, [x0, 192]
! stpd0, d0, [x0, 208]
! stpd0, d0, [x0, 224]
! stpd0, d0, [x0, 240]
! addx0, x0, 320
! cmpx1, x0
! stpd0, d0, [x0, -64]
! stpd0, d0, [x0, -48]
! stpd0, d0, [x0, -32]
! stpd0, d0, [x0, -16]
bne.L2
ret
.sizefoo, .-foo
--- 7,53
.typefoo, %function
foo:
fmovd0, 1.0e+0
! movx8, 56064
! movkx8, 0x1a, lsl 16
! movx3, 0
.p2align 2
.L2:
! addx2, x0, x3
! addx3, x3, 320
! subx1, x2, #159744
! subx2, x2, #155648
! subx4, x2, #4088
! subx7, x2, #4080
! stpd0, d0, [x1, -256]
! subx6, x2, #4072
! subx5, x2, #4064
! stpd0, d0, [x1, -240]
! cmpx3, x8
! stpd0, d0, [x1, -224]
! stpd0, d0, [x1, -208]
! stpd0, d0, [x1, -192]
! stpd0, d0, [x1, -176]
! stpd0, d0, [x1, -160]
! stpd0, d0, [x1, -144]
! stpd0, d0, [x1, -128]
! stpd0, d0, [x1, -112]
! stpd0, d0, [x1, -96]
! stpd0, d0, [x1, -80]
! stpd0, d0, [x1, -64]
! stpd0, d0, [x1, -48]
! stpd0, d0, [x1, -32]
! stpd0, d0, [x1, -16]
! strd0, [x1]
! subx1, x2, #4048
! strd0, [x4]
! subx4, x2, #4056
! subx2, x2, #4040
! strd0, [x7]
! strd0, [x6]
! strd0, [x5]
! strd0, [x4]
! strd0, [x1]
! strd0, [x2]
bne.L2
ret
.sizefoo, .-foo
Actually in this case most IVs differ to each other by a constant offset of
base address, they point to same memory object and have same step. These
address type IVs should be categorize into a single group as if it's ONE IV
use. As a result, the number of IV uses can be decreased thus we can run
expensive IV algorithm to make better choice.
I can see this only hits architectures like arm/aarch64, because it has more
addressing modes than simple register direct one, also it doesn't support
arbitrary constant offset in memory reference. But, anyway, this should be
handled as target independent issue.
I am working on this.
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #0) The compiler generates unaligned access for Polyhedron channel.f90 test when compiled with -O2 -mtune=k8: Whoops, this should read -O3 -mtune=k8. /home/uros/gcc-build/gcc/gfortran -B/home/uros/gcc-build/gcc -B/home/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/ -B/home/uros/gcc-build/x86_64-unknown-linux-gnu/libquadmath/.libs -L/home/uros/gcc-build/x86_64-unknown-linux-gnu/libgfortran/.libs -L-L/home/uros/gcc-build/x86_64-unknown-linux-gnu/libquadmath/.libs -O2 -ffast-math -mtune=k8 channel.f90 And here. Correct flags are -O3 -mtune=k8. Everything reported is compiled with these two flags only.
[Bug ipa/65439] [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf Equal symbols: 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|hppa2.0w-hp-hpux11.11, |hppa2.0w-hp-hpux11.11, |x86_64-apple-darwin1* |x86_64-apple-darwin* CC||iains at gcc dot gnu.org Host|hppa2.0w-hp-hpux11.11, |hppa2.0w-hp-hpux11.11, |x86_64-apple-darwin1* |x86_64-apple-darwin* Build|hppa2.0w-hp-hpux11.11, |hppa2.0w-hp-hpux11.11, |x86_64-apple-darwin1* |x86_64-apple-darwin* --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Also seen on powerpc-apple-darwin9.
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #15 from ktkachov at gcc dot gnu.org --- Hmmm, actually it's not that simple, as testing showed. The comment at the final load-to-regs code says: /* If part should go in registers, copy that part into the appropriate registers. Do this now, at the end, since mem-to-mem copies above may do function calls. */ So just moving this at the beginning is not going to work. Another question that comes up is: why didn't the code in calls.c not catch that we're reading from a clobbered location and cancel the tail call? It's supposed to do that with check_sibcall_argument_overlap at various points in the expansion, but it doesn't catch this case.
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed: see comment 3.
[Bug fortran/65450] [4.9/5 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, I believe it is incorrect ALIGN info as can be seen in the
-fdump-tree-all-alias dumps.
Seems with current trunk on x86_64-linux and
-g -quiet -mtune=amdfam10 -O3 pr65450.f90
the problematic memory load which should have been movupd and is movapd instead
is using _3571:
# ALIGN = 32, MISALIGN = 0
vectp.499_3571 = vectp.499_1481 + 64;
which has been created by aprefetch pass from:
# ALIGN = 32, MISALIGN = 0
vectp.499_135 = vectp.499_1480 + 16;
which has been created by pcom pass from:
# ALIGN = 32, MISALIGN = 0
vectp.499_1480 = vectp.499_1481 + 16;
which has been created during vectorization by vect_create_data_ref_ptr -
create_iv - make_ssa_name for dr:
#(Data Ref:
# bb: 43
# stmt: _1095 = MEM[(real(kind=8)[0:D.3649] *)_558][_1094];
# ref: MEM[(real(kind=8)[0:D.3649] *)_558][_1094];
# base_object: MEM[(real(kind=8)[0:D.3649] *)_558];
# Access function 0: {_1086 + 3, +, 1}_41
#)
- _1480 is indx_after_incr.
The base_object is indeed 32 byte aligned:
# RANGE [-6442450944, 6] NONZERO 18446744073709551600
_557 = _556 * 3;
# PT = { D.3692 } (nonlocal)
# ALIGN = 32, MISALIGN = 0
_558 = u[_557];
- u is a common aligned to 32 bytes:
static real(kind=8) u[9];
and 3 is divisible by 16, and it is ARRAY_REF, so the offset from u[0] is
a multiple of 128 bytes. But that doesn't tell anything about what values
_1094 can have.
I see vect_create_addr_base_for_vector_ref already always overrides the
align/misalign info after duplicating DR_PTR_INFO, and so does bump_vector_ptr,
but vect_create_data_ref_ptr trusts DR_PTR_INFO. But from what I can
understand, it is just the points to info, and alignment info in there is
solely for the base address, but not necessarily for the whole DR.
Richard, do you agree? Now the question is what we can do here, if in all the
spots in vect_create_data_ref_ptr we should just set it to unknown alignment,
or if we can do better (and how).
[Bug c++/65061] [4.8/4.9/5 Regression] Issue with using declaration and member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65061 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Mar 17 17:38:25 2015 New Revision: 221478 URL: https://gcc.gnu.org/viewcvs?rev=221478root=gccview=rev Log: PR c++/65061 * parser.c (cp_parser_template_name): Call strip_using_decl. Added: trunk/gcc/testsuite/g++.dg/inherit/using8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177 --- Comment #19 from Jeffrey A. Law law at redhat dot com --- I'm still getting up to speed here, but this sounds vaguely familiar to something we've run into before. https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01073.html Is when the code moved to a later point, but that should at least give you an idea of the issue the code is trying to resolve. I'm hoping to dig deeper into this BZ in the next day or so, but figured I'd pass that along since a quick scan of your comments reminded me of that issue.
[Bug c++/65072] Segfault when parsing dectlype in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org ---
And clang accepts it.
It looks like we don't need the C around decltype:
template typename class C
{
struct
{
int i;
};
auto operator*(const C m) - decltype (m.i);
};
void fn1 (const Cfloat);
Cfloat a;
This one is accepted by clang, gcc 5/4.9/4.8 ICE.
[Bug ipa/65439] [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf Equal symbols: 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Can you attach the dump file? It is probalby due to lack of aliases, but I am bit surprises the number of equal symbols grows up.
[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 #7 from Jeffrey A. Law law at redhat dot com --- OK, but why does this make such a difference in the final result. Ie, what happens as we get into RTL. It would also be helpful to see the current desired output for the case where we've regressed.
[Bug c++/65072] Segfault when parsing dectlype in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
I couldn't bisect this, but started before r193621.
A bit more reduced:
template typename class C
{
struct
{
int i;
};
auto operator*(const C m) - C decltype (m.i);
};
void fn1 (const Cfloat);
Cfloat a;
[Bug c++/65072] Segfault when parsing dectlype in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- EDG rejects it: tes2.ii(7): error: incomplete type is not allowed auto operator*(const C m) - C decltype (m.i); ^
[Bug ipa/65439] [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf Equal symbols: 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 35045 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35045action=edit dump-ipa-icf of ipa-icf-4.C Can you attach the dump file? It is probalby due to lack of aliases, but I am bit surprises the number of equal symbols grows up. Done.
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Xiao Jia from comment #7) Adding const makes it compile. Is this the intended behavior or not? Yes, of course. A const-reference causes a temporary to be created, you didn't bind to the packed field: Squeeze oj; oj.s = 0; const short pit(oj.s); oj.s = 1; printf(%d %d, oj.s, pit); This shows that oj.s and pit are not the same variable.
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
Xiao Jia xiaoj at google dot com changed:
What|Removed |Added
CC||xiaoj at google dot com
--- Comment #7 from Xiao Jia xiaoj at google dot com ---
What is the status of this?
Adding const makes it compile. Is this the intended behavior or not?
struct Squeeze
{
short s;
} __attribute__((aligned(1), packed));
void VerticallyChallenged(const short) {}
int main()
{
Squeeze oj;
const short pit(oj.s);
VerticallyChallenged(pit);
VerticallyChallenged(oj.s);
}
[Bug ipa/65439] [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf Equal symbols: 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65439 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- I see, the difference is _ZN12_GLOBAL__N_11AC1Ev that is same body alias on targets supporting it, but not on Darwin where C++ FE produces a duplicate. I suppose we want just relax the testcase template to accept this equivalence, but my connection is bit too iffy to do it right now.
[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 #8 from Jan Hubicka hubicka at gcc dot gnu.org --- I am with terrible internet connection and it still does not reproduce for me (I suppose difference between GNU LD and gold). It is however clear what happens, we try to add symbol's alias that is external and we do not expect external symbols to be in partitions. Does the following (untested) help? Index: lto-partition.c === --- lto-partition.c (revision 221399) +++ lto-partition.c (working copy) @@ -198,7 +198,7 @@ /* Add all aliases associated with the symbol. */ FOR_EACH_ALIAS (node, ref) -if (!node-weakref) +if (!node-weakref !DECL_ExTERNAL (node-decl)) add_symbol_to_partition_1 (part, ref-referring); /* Ensure that SAME_COMDAT_GROUP lists all allways added in a group. */
[Bug inline-asm/65436] Max number of extended asm +output operands currently limited to 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436 --- Comment #6 from Adam Warner adam at consulting dot net.nz --- Sorry, I did not mean to send my previous comment. I updated the title and a hasty comment I was about to edit got added. It is unfair to dismiss my enhancement request as invalid. I correctly explained the current limitation (which happens to match the documentation!), proposed raising the limit from 30 to 80+ (marked as an enhancement request), and provided code which tests a limit up to 2x39=78 double-counted operands. I'm told it is too costly to raise this limit due to the way gcc handles asm operands internally. I think this is will-not-fix territory due to the current architecture of gcc. How does clang manage to compile the same code? I know of no public code where gcc's 15/30 asm operand limit has been a problem. The limitations I'm hitting in private code are naturally not your primary, secondary nor even tertiary concern. The limitation will only be important if the technique is used in a popular project where benchmark competition across compilers encourages gcc to remove the limitation.
[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 --- Comment #38 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Wed Mar 18 01:47:12 2015 New Revision: 221482 URL: https://gcc.gnu.org/viewcvs?rev=221482root=gccview=rev Log: 2015-03-17 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/64432 * gfortran.dg/system_clock_3.f08: Adjust test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/system_clock_3.f08
[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 #9 from Jan Hubicka hubicka at gcc dot gnu.org --- please also attachg WPA dump of -fdump-ipa-cgraph. I would be interested what visibility _ZTCN7Utility2IO12GUnzipStreamE0_So/7 has.
[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 #10 from Jan Hubicka hubicka at gcc dot gnu.org ---
Actually perhaps we manage to produce external alias of non-external symbol
that also should not happen.
Index: ipa-icf.c
===
--- ipa-icf.c (revision 221461)
+++ ipa-icf.c (working copy)
@@ -809,6 +809,15 @@ sem_function::merge (sem_item *alias_ite
bool original_address_matters = original-address_matters_p ();
bool alias_address_matters = alias-address_matters_p ();
+ if (DECL_EXTERNAL (alias-decl))
+{
+ if (dump_file)
+ fprintf (dump_file,
+Not unifying;
+alias is external.\n\n);
+ return false;
+}
+
if (DECL_NO_INLINE_WARNING_P (original-decl)
!= DECL_NO_INLINE_WARNING_P (alias-decl))
{
@@ -1767,6 +1870,14 @@ sem_variable::merge (sem_item *alias_ite
Symbol aliases are not supported by target\n\n);
return false;
}
+ if (DECL_EXTERNAL (alias-decl))
+{
+ if (dump_file)
+ fprintf (dump_file,
+Not unifying;
+alias is external.\n\n);
+ return false;
+}
sem_variable *alias_var = static_castsem_variable * (alias_item);
May help.
[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 #9 from Alexandre Oliva aoliva at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #7) OK, but why does this make such a difference in the final result. Ie, what happens as we get into RTL. Err, I covered that bit in my description: we emit a number of copies, each with a new BB of its own. The additional pseudo survives all the way to the end, and so do the copies, which is enough to explain the additional stack slot. Further rearrangement of code also follows from the additional blocks. (In reply to Andrew Macleod from comment #8) most of these kinds of restrictions were rooted in some kind of rationale... usually from examining an issue of some sort and introducing the restriction to avoid it. This one was added by https://gcc.gnu.org/ml/gcc-patches/2012-08/msg00517.html The description mentions out-of-SSA coalescing, but not copyrename coalescing, which is what this is about. Since there were not anonymous SSA names before, the introduced condition would necessarily not be met, so it effectively reduced the amount of copyrename coalescing without any rationale AFAICT. Richi, do you happen to have any insight as to why you changed copyrename to avoid coalescing rootless ssa names? Reverting it doesn't seem to have any ill effects on code correctness (unlike allowing coalescing between rooted and rootless vars during out-of-ssa, in gimple_can_coalesce_p, which breaks codegen badly, though I haven't dug into why). I'll attach a patch I'm testing to that effect momentarily.
[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 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #11 from Alexandre Oliva aoliva at gcc dot gnu.org --- Uhh, Richi, there's a question for you in comment 9, but I forgot to cc: you before saving the post.
[Bug target/28586] thowing exception before main() leads to crash on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586 --- Comment #5 from Zoltan Hidvegi zoltan at hidvegi dot com --- Btw. the original testcase was really failing because of Bug 33704, and it seems that is already fixed, however it's still open, or is it not fully fixed?
[Bug c++/64626] C++14 single quote should not always be a digit separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64626
emsr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from emsr at gcc dot gnu.org ---
libcpp/
2015-03-16 Edward Smith-Rowland 3dw...@verizon.net
PR c++/64626
* lex.c (lex_number): If a number ends with digit-seps (') skip back
and let lex_string take them.
gcc/testsuite/
2015-03-16 Edward Smith-Rowland 3dw...@verizon.net
PR c++/64626
g++.dg/cpp1y/pr64626-1.C: New.
g++.dg/cpp1y/pr64626-2.C: New.
g++.dg/cpp1y/digit-sep-neg.C: Adjust errors and warnings.
[Bug middle-end/34010] [4.8/4.9/5 Regression] ppc64 bad stdargs codegen for zero sized objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010 --- Comment #8 from Aldy Hernandez aldyh at gcc dot gnu.org --- PING
[Bug middle-end/34010] [4.8/4.9/5 Regression] ppc64 bad stdargs codegen for zero sized objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #9 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- I haven't had a ppc64 box for years. Either, the tests results mailing list or you'd have to ask one of the darwin ppc64 people. Jack and Iain I think both still have ppc64 boxes.
[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 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #10 from Alexandre Oliva aoliva at gcc dot gnu.org --- Created attachment 35048 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35048action=edit Patch that restores coalescing of anonymous SSA vars
[Bug inline-asm/65436] Max number of extended asm +output operands currently limited to 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436 Adam Warner adam at consulting dot net.nz changed: What|Removed |Added Summary|Max number of extended asm |Max number of extended asm |+input operands currently |+output operands currently |limited to 15 |limited to 15 --- Comment #4 from Adam Warner adam at consulting dot net.nz --- Yes I've hit the limit. A limit that your competition clang does not have. This is not a theoretical discussion.
[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 #12 from Alexandre Oliva aoliva at gcc dot gnu.org --- I just noticed that I reversed with and without -DOPT in my analysis in comment 6. Apologies for any confusion this may have caused.
[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 #13 from Alexandre Oliva aoliva at gcc dot gnu.org --- I looked further into why changing gimple_can_coalesce_p didn't work: build_ssa_conflict_graph only marks conflicts between SSA names if they share the same base variable. This explains why we have a conflict in the conflict map with -DOPT, in which l_4, values_29 and now_30 all have base variables, whereas without -DOPT they don't. So, we can't coalesce them with _10 and _28, even though 10 and 29 do conflict. I ran a test in which I allowed values_29 and _28 to coalesce, by hooking into gimple_can_coalesce_p during an -UOPT out-of-ssa and getting it to return true. This yielded the same partition map as the -DOPT case, but an empty conflict map for the reason above. The sorted coalesce list was the same, too, so we coalesced values_29 and _28, as in -DOPT, but then, due to the lack of the conflict, we also coalesced _10 into the same partition. This experimental additional invalid coalescing in turn caused other differences in the generated RTL. At this point I'll sum up my findings: - we fail to coalesce during copyrename because we've ruled out, at that point, coalescing of anonymous SSA names. as a consequence, only some coalescing opportunities are taken, leaving some anonymous names that we try to coalesce first not coalesced - as a consequence, we fail to coalesce some SSA names because some of the SSA variables have become anonymous whereas others aren't - as a consequence, we emit additional copies in additional BBs, and they survive all the way to the end of compilation Although changing copyrename to allow coalescing in these cases fixes the problem, I suppose it would also be possible to change out-of-ssa to compensate; we would have to somehow mark conflicts between anonymous and non-anonymous variables in the conflict graph, though.
[Bug middle-end/34010] [4.8/4.9/5 Regression] ppc64 bad stdargs codegen for zero sized objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34010 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org --- Segher, the only struct-layout-1.c failure I see that is related to PPC on the GCC test results list is yours for -m32 -mpowerpc64 running on ppc64. This is 32-bit powerpc but with the ppc64 instruction set, is it not? Did this test ever work? FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o link ...from: https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg01870.html That is, is it legitimately a regression?
[Bug inline-asm/65436] Max number of extended asm +output operands currently limited to 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65436 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Adam Warner from comment #4) Yes I've hit the limit. A limit that your competition clang does not have. This is not a theoretical discussion. What kind of inline-asm are you using this for?
[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 --- Comment #37 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- (In reply to Harald Anlauf from comment #36) --snip--- are you sure that .and.ing the conditions in the testcase is correct, or shouldn't they rather be .or.ed? Oh of course. Thanks Harald. I will set it right
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #6 from David gccbugzilla at limegreensocks dot com ---
Actually, the code already uses InterlockedCompareExchange. UNLESS users
explicitly tell it not to:
#ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES
static inline long
__gthr_i486_lock_cmp_xchg(long *__dest, long __xchg, long __comperand)
{
long result;
__asm__ __volatile__ (\n\
lock\n\
cmpxchg{l} {%4, %1|%1, %4}\n
: =a (result), =m (*__dest)
: 0 (__comperand), m (*__dest), r (__xchg)
: cc);
return result;
}
#define __GTHR_W32_InterlockedCompareExchange __gthr_i486_lock_cmp_xchg
#else /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */
#define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange
#endif /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */
Since we are talking about postponing this to stage 1 (which I do not object
to), what if we change this to something like:
#ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES
#error __GTHREAD_I486_INLINE_LOCK_PRIMITIVES is no longer supported. Remove
this definition to use system calls for Win98 and above.
#else /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */
#define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange
#endif /* __GTHREAD_I486_INLINE_LOCK_PRIMITIVES */
Then wait to see if anyone cares.
I am ok with either fixing it (by adding the memory clobber) or removing it
(since the problem it was intended to fix only happens on OSs that aren't
supported anymore). But leaving it as-is leaves open the possibility that
people are using this without even knowing it (and getting
nearly-impossible-to-track-down timing problems). Or that someone might
copy/paste this code into their own projects.
[Bug target/28586] thowing exception before main() leads to crash on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586 Zoltan Hidvegi zoltan at hidvegi dot com changed: What|Removed |Added CC||zoltan at hidvegi dot com --- Comment #4 from Zoltan Hidvegi zoltan at hidvegi dot com --- This testcase fails with gcc-4.8, but works with g++-4.9 and later on AIX both for 32-bit and 64-bit, even though MD_FALLBACK_FRAME_STATE_FOR is not implemented for 64-bit AIX. Is there still a bug here? Maybe this works but there are still issues when using dlopen or shared libaries? I've tried to create a failing testcase using dlopen etc. for gcc-4.9 or later, but everything I've tried works the same on AIX and Linux.
[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 #4 from vries at gcc dot gnu.org --- (In reply to vries from comment #3) (In reply to vries from comment #2) The problem with this transformation is that '_20 + 1' might overflow, that's what the comment 'This may need some additional preconditioning in case NIT = ~0' refers to. AFAIU, we might also move 'ivtmp_6 = ivtmp_y + 1' to the end of bb4. That way it's not triggered at loop entry, as before the transformation, eliminating the need for '_20 + 1'. One thing I overlooked there: _20 = n_4(D) + 4294967295; If n == 0, we don't reach the loop. If n == 1, we reach the loop, and _20 == 0. And when we reach the loop condition from loop entry with ivtmp == 0, ivtmp _20 will evaluate to false, and we won't even enter the loop. That's the problem we're trying to solve using '_20 + 1'. And moving 'ivtmp_6 = ivtmp_y + 1' to the end of bb4 doesn't fix that.
[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 Andrew Macleod amacleod at redhat dot com changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #8 from Andrew Macleod amacleod at redhat dot com --- (In reply to Alexandre Oliva from comment #6) Coalescing SSA names even when neither has a root removes the optimization differences for this testcase. I would worry about side effects... Coalescing is always a balancing act. If you allow things to coalesce when neither has a root, a few of those coalesced together may prevent a coalesce with a much more desirable root in other programs. And of course more coalesces may mean longer live ranges... so any changes like this need a lot of studying of side effects on a much larger set of problems. It was a long time ago, so I don't remember the reasons, but most of these kinds of restrictions were rooted in some kind of rationale... usually from examining an issue of some sort and introducing the restriction to avoid it. The original conditions may no longer exist, but we'd have to run tests to make sure nothing shows up. Perhaps tweaking the costing model could help too.
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177 --- Comment #20 from Sebastian Pop spop at gcc dot gnu.org --- Created attachment 35046 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35046action=edit fix The attached patch fixes the problem by not creating diamonds in the copied jump-thread. I'm bootstrapping and regtesting this on x86_64-linux and I will send the patch for review after it passes.
[Bug c/65345] ICE with _Generic selection on _Atomic int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Patch queued for next stage1: https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00698.html
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Also crashes with -mtune=amdfam10. But in this case it even crashes when compiled with 4.9.2.
[Bug rtl-optimization/65078] [5 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65078
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
During the expansion, we don't try vec_extract because we are trying to extract
low DImode (64bits) out of a V16QImode pseudo, which is not really vector
element extraction, and the middle end doesn't know that on this target it is
beneficial to just subreg the V16QImode pseudo to identically sized vector with
different sized elements (V2DImode in this case).
So, in order to handle this at the expansion level, we probably would need to
add some new optab like vec_extract that would be not just about the source
mode, but also target mode (conversion optab?), or some target hook or macro
that would instruct the middle-end to also try to subreg the vector mode to
identically sized other vector mode before trying vec_extract.
Immediately after the vec_extract check, we already convert the V16QImode to
TImode and force_reg it, so that is the last spot that can do something about
it during expansion.
To fix this up before reload, we have the option of either !reload_completed
splitter or some combiner pattern(s).
Short testcase that shows hopefully optimal or close to that output for f5-f8
and really bad code for f1-f4, both with -O2 -m64 and -O2 -msse2 -m32.
typedef unsigned char V __attribute__((vector_size (16)));
typedef unsigned long long W __attribute__((vector_size (16)));
typedef unsigned int T __attribute__((vector_size (16)));
void
f1 (unsigned long long *x, V y)
{
*x = ((W)y)[0];
}
unsigned long long
f2 (V y)
{
return ((W)y)[0];
}
void
f3 (unsigned int *x, V y)
{
*x = ((T)y)[0];
}
unsigned int
f4 (V y)
{
return ((T)y)[0];
}
void
f5 (unsigned long long *x, W y)
{
*x = ((W)y)[0];
}
unsigned long long
f6 (W y)
{
return ((W)y)[0];
}
void
f7 (unsigned int *x, T y)
{
*x = ((T)y)[0];
}
unsigned int
f8 (T y)
{
return ((T)y)[0];
}
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Works fine with -fwrapv...
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- Also crashes with -mtune=amdfam10. But in this case it even crashes when compiled with 4.9.2. Revision r204000 (2013-10-24) is OK, r204945 (2013-11-18) is not. Works fine with -fwrapv... Confirmed.
[Bug ada/65451] New: gnat bug: Storage_Error stack overflow or erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451 Bug ID: 65451 Summary: gnat bug: Storage_Error stack overflow or erroneous memory access Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: gnugcc at marino dot st Host: x86_64-unknown-dragonfly4.1 Target: x86_64-unknown-dragonfly4.1 Build: x86_64-unknown-dragonfly4.1 I was testing the latest gcc-5 snapshot against FreeBSD Ada ports (which DragonFly uses). I am seeing an intermittent GNAT BUG error on the Matreshka port ( http://freshports/devel/matreshka ): ada -c -fPIC -g -gnatwa -gnat12 -gnatW8 -O2 -gnatn matreshka-internals-strings.adb +===GNAT BUG DETECTED==+ | 5.0.0 20150315 (experimental) -= GNAT AUX [DragonFly64] (x86_64-aux-dragonfly4.1) | | Storage_Error stack overflow or erroneous memory access | | Error detected at matreshka-internals-utf16.adb:45:33| | 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 command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings.adb /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/league.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-counters.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-unicode.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-unicode-ucd.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-utf16.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-generic_test_and_set.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings-configuration__x86_64.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings-handlers.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/arch/x86_64/matreshka-internals-strings-handlers-x86_64.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-strings-handlers-portable.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/arch/x86_generic/matreshka-internals-strings-handlers-generic_x86_sse2.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/arch/x86_generic/matreshka-internals-strings-handlers-x86_utilities.ads /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-generic_test_and_set__gcc__64.adb /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-atomics-counters__gcc.adb /wrkdirs/devel/matreshka/work/matreshka-0.6.0/source/league/matreshka-internals-utf16.adb compilation abandoned gprbuild: *** compilation phase failed Makefile.build:36: recipe for target 'league' failed gmake[2]: *** [league] Error 4 gmake[2]: Leaving directory '/wrkdirs/devel/matreshka/work/matreshka-0.6.0' Makefile:21: recipe for target 'all' failed gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory '/wrkdirs/devel/matreshka/work/matreshka-0.6.0' *** Error code 1 I suspect this isn't enough information to diagnose anything. The link to the source is found on the freshports site, and some patches are in the svn repo. There are an additional three patches that I was testing that are needed to build on gcc-5 (e.g. missing explicit limited keyword patch) I just want to get this documented for now. Let me know what I can provide to help troubleshoot it.
[Bug fortran/65450] [5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #9) Also crashes with -mtune=amdfam10. But in this case it even crashes when compiled with 4.9.2. Revision r204000 (2013-10-24) is OK, r204945 (2013-11-18) is not. Works fine with -fwrapv... Confirmed. r204257 in particular.
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 Ever confirmed|0 |1 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- This patch is clear stage 1 material. Patch itself looks ok, but raises a completely different question. Modern versions of mingw provides all Interlocked-functions, so we might want to use this instead. The argument about Win95/98 compatibility is actually pretty borged, as we have already in some of gcc's target-libraries strong requirements of using at least NT 4.0, and/or even more modern.
[Bug ada/65451] gnat bug: Storage_Error stack overflow or erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451 --- Comment #1 from John Marino gnugcc at marino dot st --- Note that I saw this on 20150308 snapshot with Matreshka too in a different file. That snapshot also failed on building OpenToken with a GNAT BUG, but OpenToken builds fine with 20150315 snapshot.
[Bug fortran/65450] [4.9 5.0 Regression]: Unaligned access with -O3 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65450 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.9.3 Summary|[5.0 Regression]: Unaligned |[4.9 5.0 Regression]: |access with -O3 -mtune=k8 |Unaligned access with -O3 ||-mtune=k8 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Dominique d'Humieres from comment #9) Also crashes with -mtune=amdfam10. But in this case it even crashes when compiled with 4.9.2. Revision r204000 (2013-10-24) is OK, r204945 (2013-11-18) is not. Probably the cause of failure for channel testcase at SUSE's amdfam10 tester [1], but nobody noticed. [1] http://gcc.opensuse.org/c++bench-frescobaldi/polyhedron/polyhedron-summary.txt-2-0.html
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452 David Malcolm dmalcolm at gcc dot gnu.org changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm dmalcolm at gcc dot gnu.org --- Some context from our IRC chat, for other gcc devs: I just wrote: if (strcmp (foo, foo) == 0) instead of if (strcmp (self-priv-foo, foo) == 0) in a patch... thankfully got noticed in review.
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452 David Malcolm dmalcolm at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/65453] New: ICE in build_function_decl, at fortran/trans-decl.c:2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65453 Bug ID: 65453 Summary: ICE in build_function_decl, at fortran/trans-decl.c:2001 Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: diagnostic, error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following invalid code ICEs without error message in build_function_decl, at fortran/trans-decl.c:2001 procedure() :: foo contains subroutine foo() end end
[Bug c++/65143] [C++11] missing devirtualization for virtual base in final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143 --- Comment #4 from Balakrishnan B balakrishnan.erode at gmail dot com --- Thanks for confirming!
[Bug ada/65451] gnat bug: Storage_Error stack overflow or erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65451 --- Comment #2 from John Marino gnugcc at marino dot st --- right url for freshports: http://www.freshports.org/devel/matreshka
[Bug c/65452] New: strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452 Bug ID: 65452 Summary: strcmp (foo, foo) could give a warning Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rstrode at redhat dot com Created attachment 35043 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35043action=edit example that could warn sometimes gcc will give a warning like: warning: the address of 'foo' will always evaluate as 'true' if the address foo is used in a conditional expression. It would be useful if there was also a warning of the form: warning: the comparison of 'foo' with itself will always evaluate as 'true' if the code does if (strcmp (foo, foo) == 0) or similar.
[Bug fortran/65453] ICE in build_function_decl, at fortran/trans-decl.c:2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65453 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-17 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.6.4 up to trunk (5.0).
[Bug fortran/51550] ICE in gfc_get_derived_type, at fortran/trans-types.c:2401
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51550 vehre at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #6 from vehre at gcc dot gnu.org --- I am working on fixing the remaining issue open to resolve this problem completely. During inspection of your code I figured, that the implementation of add_key_only () does not work. I had to change it this way: subroutine add_key_only( json_object, key ) type(json_data), target :: json_object character(len=*) :: key type(json_value), pointer :: value type(json_value), pointer :: last last = json_object%key_value if (associated (last)) then do while ( associated(last%next) ) write(*,*) 'Key found: ', last%key last = last%next enddo end if allocate( value ) allocate( character(len=len(key)) :: value%key ) value%key = key write(*,*) 'Inserting key: ', value%key, ', len: ', len(value%key) if (associated (last)) then last%next = value else json_object%key_value = value end if end subroutine add_key_only Which now works as expected.
