[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|middle-end |tree-optimization Target Milestone|--- |4.6.4
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-20 16:46:04 UTC --- Created attachment 29227 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29227 gcc48-pr56051.patch Untested fix. As the testcase shows, also a widening conversion can be a problem, if it extends from signed integral type to wider unsigned one, because then for Y equal to bitsize of the narrower type - 1 we get more than one bit set. On the other side, the optimization doesn't hit when X isn't an ARRAY_REF, but just an integral variable, because then arg0 and arg1 are swapped. Guess for 4.9 we should handle those cases too.
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-20 17:42:30 UTC --- Since http://gcc.gnu.org/viewcvs?root=gccview=revrev=193570 you need: --param max-completely-peeled-insns=129 to make this happen, as the defaults were lowered from 400 to 100.
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-20 18:35:20 UTC --- Yeah, I'm afraid assuming you never do 1 31 is going to break simply way too much code in the wild.
[Bug c++/56059] [4.7/4.8 Regression] SIGSEGV on invalid C++11 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56059 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-21 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.7.3 Summary|SIGSEGV on invalid C++11|[4.7/4.8 Regression] |code|SIGSEGV on invalid C++11 ||code Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 06:53:27 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=189298
[Bug c++/56060] ICE on invalid code in type_dependent_expression_p, at cp/pt.c:19742
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56060 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 06:56:14 UTC --- Seems to be very old, started in between r126000 and r127000.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #29211|0 |1 is obsolete|| Attachment #29217|0 |1 is obsolete|| Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #42 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 11:41:11 UTC --- Created attachment 29234 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29234 gcc48-pr55742.patch Updated patch that subsumes both the original patch and the incremental one, and hopefully cures also (1), (2) and (3) above, except that the testsuite coverage still should be improved (I've added just 5 new tests from the snippets I had around) and documentation needs to be written.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 12:53:09 UTC --- I've tried to reproduce this with a cross compiler (without cross binutils) on x86_64-linux host, but it ICEs elsewhere: ../configure --target powerpc-ibm-aix5.3.1 --disable-bootstrap --enable-languages=c make cd gcc sed -i -e 's/^.*HAVE_AS_TLS.*$/#define HAVE_AS_TLS 1/' auto-host.h make cc1 ./cc1 -O -fschedule-insns -fselective-scheduling -fpic -fprofile-generate pr50907.c -maix32 But this ICEs in: #0 0x00cca50b in get_pool_constant (addr=0x71aa7ee0) at ../../gcc/varasm.c:3631 #1 0x00ce285c in rs6000_delegitimize_address (orig_x=0x71a7aa20) at ../../gcc/config/rs6000/rs6000.c:5834 #2 0x00a04b0e in avoid_constant_pool_reference (x=0x71a7aa38) at ../../gcc/simplify-rtx.c:220 #3 0x00e7c211 in equiv_constant (x=0x71a7aa38) at ../../gcc/cse.c:3797 #4 0x00e7a811 in fold_rtx (x=0x71a7aa38, insn=0x71aa6750) at ../../gcc/cse.c:3122 #5 0x00e7dd3c in cse_insn (insn=0x71aa6750) at ../../gcc/cse.c:4573 #6 0x00e833f1 in cse_extended_basic_block (ebb_data=0x7fffdf40) at ../../gcc/cse.c:6405 #7 0x00e83990 in cse_main (f=0x71a89200, nregs=190) at ../../gcc/cse.c:6583 #8 0x00e8569c in rest_of_handle_cse () at ../../gcc/cse.c:7433 on (symbol_ref:SI (*LCM..0) [flags 0x2]) (note, not CONSTANT_POOL_ADDRESS_P) created by rs6000_legitimize_tls_address_aix: 5955 rtx modaddr = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (tlsname)); 5956 SYMBOL_REF_FLAGS (modaddr) |= SYMBOL_FLAG_LOCAL; and the ICE is on: 5830#ifdef HAVE_AS_TLS 5831 /* Do not associate thread-local symbols with the original 5832 constant pool symbol. */ 5833 if (TARGET_XCOFF 5834 SYMBOL_REF_TLS_MODEL (get_pool_constant (y)) = TLS_MODEL_REAL) 5835return orig_x; 5836#endif orig_x is (unspec:SI [ (symbol_ref:SI (*LCM..0) [flags 0x2]) (reg:SI 2 2) ] UNSPEC_TOCREL) Am I missing something here? Why does it assume that y is a CONSTANT_POOL_ADDRESS_P SYMBOL_REF? Alternatively, can you please attach auto-host.h, perhaps there is something I need to tweak further to reproduce.
[Bug fortran/56052] [4.7/4.8 Regression] [OOP] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 13:03:03 UTC --- Yeah, if this ever worked, it was by pure accident. OpenMP 3.1 vs. Fortran OOP is simply undefined territory, gfortran won't run e.g. any constructors/destructors of privatized vars with class types, etc.
[Bug fortran/56052] [4.7/4.8 Regression] [OOP] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 15:25:00 UTC --- Using your auto-host.h (with the exception of HAVE_DECL_BASENAME - clearly host rather than target thing) with i686-linux - powerpc-ibm-aix7.1.0.0 cross I still get the same ICE I've talked about earlier in #c12 (for x86_64-linux - ppc-aix cross I need to also change SIZEOF_LONG and SIZEOF_VOID_P in auto-host.h to 8, but it also ICEs in the same spot).
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889
--- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21
15:54:08 UTC ---
Indeed, with #c18 patch I can reproduce the ICE. Andrey, can you try that too?
On x86_64-linux, do for current trunk + #c18 patch applied:
mkdir obj
cd obj
../configure --target powerpc-ibm-aix7.1.0.0 --disable-bootstrap \
--enable-languages=c
make -j4
# The above command will fail, due to missing as/ld, but that is fine.
# You can even Ctrl-C it earlier, after gcc/auto-host.h is created
cd gcc
mv auto-host.h{,.bak}
wget http://gcc.gnu.org/bugzilla/attachment.cgi?id=29237 -O auto-host.h
sed -i -e 's/#define HAVE_DECL_BASENAME 0/#define HAVE_DECL_BASENAME 1/' \
-e 's/#define SIZEOF_LONG 4/#define SIZEOF_LONG 8/' \
-e 's/#define SIZEOF_VOID_P 4/#define SIZEOF_VOID_P 8/' auto-host.h
make -j4 cc1
cp -a ../../gcc/testsuite/gcc.dg/tree-prof/pr45354.c .
./cc1 -O -fschedule-insns -fselective-scheduling -fpic \
-fprofile-generate pr45354.c -maix32
[Bug fortran/56052] [4.7/4.8 Regression] [OOP] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 17:20:11 UTC --- Created attachment 29243 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29243 gcc48-pr56052.patch Anyway, the following patch fixes the ICE, by making the artificial var DECL_ARTIFICIAL (and no need to emit it into debug info anyway). If it is DECL_ARTIFICIAL, then the Fortran privatize_by_reference hook won't return true on it, even when it has POINTER_TYPE type.
[Bug rtl-optimization/56069] New: [4.6/4.7/4.8 Regression] RA pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Bug #: 56069
Summary: [4.6/4.7/4.8 Regression] RA pessimization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: rsand...@gcc.gnu.org, vmaka...@gcc.gnu.org
Target: x86_64-linux
Since http://gcc.gnu.org/viewcvs?root=gccview=revrev=139993
unsigned long foo (unsigned long mem)
{
return (mem 3) | (1UL 44);
}
unsigned long bar (unsigned long mem)
{
return (mem 3) + (1UL 44);
}
on x86_64-linux at -O2 (and -Os) the generated code for foo is one insn longer.
We used to emit:
shrq$3, %rdi
movabsq $17592186044416, %rax
orq %rdi, %rax
ret
but now emit:
movq%rdi, %rax
movabsq $17592186044416, %rdx
shrq$3, %rax
orq %rdx, %rax
ret
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 17:55:46 UTC --- Author: jakub Date: Mon Jan 21 17:55:34 2013 New Revision: 195343 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195343 Log: PR tree-optimization/56051 * fold-const.c (fold_binary_loc): Don't fold X (cast) (1 Y) into (X Y) != 0 if cast is either a narrowing conversion, or widening conversion from signed to unsigned. * gcc.c-torture/execute/pr56051.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr56051.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 18:01:59 UTC --- Fixed on the trunk so far.
[Bug debug/54114] [4.8/4.9 Regression] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Component|lto |debug Target Milestone|4.8.0 |4.9.0 Summary|[4.8 Regression]|[4.8/4.9 Regression] |variable-tracking |variable-tracking |performance regression from |performance regression from |4.8-20120610 to |4.8-20120610 to |4.8-20120701|4.8-20120701 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-21 18:56:44 UTC --- Something to look for 4.9 then.
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 08:18:23 UTC --- Can't we in the movdi expander detect writing to volatile MEM and expand it as atomic_storedi with MEMMODEL_RELAXED instead?
[Bug libquadmath/56072] info page wrongly defines M_PI_2 and M_PI_4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56072 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 08:23:39 UTC --- Author: jakub Date: Tue Jan 22 08:23:32 2013 New Revision: 195360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195360 Log: PR libquadmath/56072 * libquadmath.texi (M_PI_2q, M_PI_4q): Fix up description. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/libquadmath.texi
[Bug libquadmath/56072] info page wrongly defines M_PI_2 and M_PI_4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56072 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 08:30:49 UTC --- Fixed for trunk.
[Bug rtl-optimization/55686] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55686 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 09:19:18 UTC --- Created attachment 29245 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29245 gcc48-pr55686.patch The UNSPEC_STOS way, untested so far. This doesn't attempt to solve the other issue, but I believe it isn't a regression, thus perhaps we could postpone the rest for 4.9?
[Bug middle-end/56074] [4.8 regression] ICE compiling gcc.dg/vect/pr49093.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56074 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-22 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 10:02:11 UTC --- Created attachment 29246 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29246 gcc48-pr56074.patch Untested fix.
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 10:33:53 UTC --- The patch isn't sufficient. For both -static-libasan -fsanitize=address and just -fsanitize=address, we want -Bstatic -lasan -Bdynamic resp. -lasan to go before all occurrences of the -lstdc++ or -lpthread or -lc, whether those come from user command line options or language specific driver hacks or specs expansion. For dynamic -lasan it is obviously enough if it goes before the first occurrence of -lstdc++, -lpthread or -lc, whatever is first, so in theory we could just add it as the very first (or one of the first) ld/collect2 command line options. libasan unfortunately crashes badly (without giving useful messages) if e.g. -lpthread comes before -lasan. And -lpthread can either come from -pthread on the command line, or -lpthread, similarly -lstdc++ from just linking with g++, or from -lstdc++ on the command line. Unfortunately, -Wl,-Bstatic resp. -Wl,-Bdynamic might be passed directly on the command line too, at random positions, so adding blindly -Bstatic -lasan -Bdynamic isn't very good idea either, especially because those options aren't counted, -Bstatic -Bstatic -lasan -Bdynamic will result in -Bdynamic after it.
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 10:52:55 UTC --- One way out of this would be for libasan.a to be an *.o object rather than *.a archive: mv libasan.a libasan_a.a gcc -Wl,-r -nostdlib -o libasan.a -Wl,--whole-archive libasan_a.a -Wl,--no-whole-archive and then it could be linked early. ASAN_STATIC_LIBS (-ldl -lpthread) for Linux would obviously come late in the command line, where we currently emitted -lasan too. -lasan resp. -Bstatic -lasan -Bdynamic would need to go before %o in LINK_COMMAND_SPEC in that case.
[Bug tree-optimization/56035] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 (loop n’s header does not belong directly to it !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56035
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22
11:38:47 UTC ---
EXIT with no predecessors is fine, if the body of the function always ends with
endless loops. Consider void foo (void) { for (;;); } which doesn't have any
EXIT predecessors either.
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 13:35:28 UTC --- Created attachment 29249 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29249 gcc48-pr55374.patch Untested fix. If -static-libasan is missing, it just moves -lasan early on ld command line (before %o, i.e. user input arguments), as we error out on -static and user -Bstatic would go after it, I think it is fine this way. For -static-libasan, we don't pass -lasan at all for -shared (we don't want many (partial) copies of libasan.a in various shared libraries plus executable), and just for executable link with -Bstatic --whole-archive -lasan --no-whole-archive -Bdynamic early on the command line.
[Bug c++/56059] [4.7 Regression] SIGSEGV on invalid C++11 code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56059 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression]|[4.7 Regression] SIGSEGV on |SIGSEGV on invalid C++11|invalid C++11 code |code| --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 14:59:49 UTC --- Fixed on the trunk.
[Bug rtl-optimization/55686] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55686 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 16:41:44 UTC --- Author: jakub Date: Tue Jan 22 16:41:30 2013 New Revision: 195381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195381 Log: PR target/55686 * config/i386/i386.md (UNSPEC_STOS): New. (strset_singleop, *strsetdi_rex_1, *strsetsi_1, *strsethi_1, *strsetqi_1): Add UNSPEC_STOS. * gcc.target/i386/pr55686.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55686.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56074] [4.8 regression] ICE compiling gcc.dg/vect/pr49093.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56074 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 17:03:47 UTC --- Author: jakub Date: Tue Jan 22 17:03:33 2013 New Revision: 195382 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195382 Log: PR middle-end/56074 * dumpfile.c (dump_loc): Only print loc if LOCATION_LOCUS (loc) isn't UNKNOWN_LOCATION nor BUILTINS_LOCATION. * tree-vect-loop-manip.c (find_loop_location): Also ignore stmt locations where LOCATION_LOCUS of the stmt location is UNKNOWN_LOCATION or BUILTINS_LOCATION. Modified: trunk/gcc/ChangeLog trunk/gcc/dumpfile.c trunk/gcc/tree-vect-loop-manip.c
[Bug rtl-optimization/55686] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55686 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 17:04:53 UTC --- Regression fixed. For the rest I think we can defer that for 4.9. Will open a PR for that.
[Bug middle-end/56074] [4.8 regression] ICE compiling gcc.dg/vect/pr49093.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56074 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 17:06:01 UTC --- Should be fixed now hopefully.
[Bug rtl-optimization/56069] [4.6/4.7/4.8/4.9 Regression] RA pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|[4.6/4.7/4.8 Regression] RA |[4.6/4.7/4.8/4.9 |pessimization |Regression] RA ||pessimization --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-22 21:10:34 UTC --- Deferring for 4.9 then.
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
08:06:57 UTC ---
struct T { int a; char b[]; };
struct T t = { .a = 1, .b = abc, .b[0] = '2' };
is enough, fails even with 3.2, so doesn't look like a regression.
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 08:37:39 UTC --- Author: jakub Date: Wed Jan 23 08:37:16 2013 New Revision: 195398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195398 Log: PR target/49069 * config/arm/arm.md (cbranchdi4, cstoredi4): Use s_register_operand instead of cmpdi_operand for first comparison operand. Don't assert that comparison operands aren't both constants. * gcc.dg/pr49069.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr49069.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug fortran/56052] [4.7/4.8 Regression] [OOP] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 08:44:00 UTC --- Author: jakub Date: Wed Jan 23 08:43:50 2013 New Revision: 195399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195399 Log: PR fortran/56052 * trans-decl.c (gfc_get_symbol_decl): Set DECL_ARTIFICIAL and DECL_IGNORED_P on select_type_temporary and don't set DECL_BY_REFERENCE. * gfortran.dg/gomp/pr56052.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr56052.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/49069] [4.6/4.7 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE in |ICE in gen_cstoredi4, at|gen_cstoredi4, at |config/arm/arm.md:7554 |config/arm/arm.md:7554 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 08:45:45 UTC --- Fixed on the trunk so far.
[Bug fortran/56052] [4.7 Regression] [OOP] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression] [OOP] |[4.7 Regression] [OOP] ICE |ICE in omp_add_variable, at |in omp_add_variable, at |gimplify.c:5606 |gimplify.c:5606 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 08:46:43 UTC --- Fixed on the trunk so far.
[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-23 CC||jakub at gcc dot gnu.org Target Milestone|4.8.0 |4.7.3 Summary|[4.8 Regression] ICE with |[4.7/4.8 Regression] ICE |C_PTR renaming and TRANSFER |with C_PTR renaming and ||TRANSFER Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 09:31:32 UTC --- The #c1 testcase started to be rejected with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177486 and then changed from an (invalid?) error into an ICE with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177527
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 09:43:31 UTC --- Would it help if libitm has been linked against libstdc++ on the targets which can't support weak properly?
[Bug tree-optimization/56075] [gcc-4.7.1] 64-bit version, -Os eliminate some line of code which working fine in gcc-4.6.2 64-bit version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56075 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 11:26:50 UTC --- Non-preprocessed testcase is useless (the original isn't preprocessed either). But furthermore, why do you expect that foo won't be optimized just into an empty function? If fun is inlined, it doesn't have any side-effects.
[Bug sanitizer/55989] [4.8 regresion] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55989 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 11:52:40 UTC --- Author: kcc Date: Wed Jan 23 11:41:33 2013 New Revision: 195404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195404 Log: libsanitizer merge from upstream r173241 Added: trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors_scanf.inc trunk/libsanitizer/sanitizer_common/sanitizer_lfstack.h trunk/libsanitizer/sanitizer_common/sanitizer_quarantine.h Removed: trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h trunk/libsanitizer/ChangeLog trunk/libsanitizer/MERGE trunk/libsanitizer/asan/asan_allocator.cc trunk/libsanitizer/asan/asan_allocator.h trunk/libsanitizer/asan/asan_allocator2.cc trunk/libsanitizer/asan/asan_globals.cc trunk/libsanitizer/asan/asan_intercepted_functions.h trunk/libsanitizer/asan/asan_interceptors.cc trunk/libsanitizer/asan/asan_internal.h trunk/libsanitizer/asan/asan_linux.cc trunk/libsanitizer/asan/asan_lock.h trunk/libsanitizer/asan/asan_mac.cc trunk/libsanitizer/asan/asan_malloc_mac.cc trunk/libsanitizer/asan/asan_mapping.h trunk/libsanitizer/asan/asan_new_delete.cc trunk/libsanitizer/asan/asan_poisoning.cc trunk/libsanitizer/asan/asan_rtl.cc trunk/libsanitizer/asan/asan_stats.cc trunk/libsanitizer/asan/asan_thread.cc trunk/libsanitizer/asan/asan_thread_registry.cc trunk/libsanitizer/asan/asan_thread_registry.h trunk/libsanitizer/asan/asan_win.cc trunk/libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc trunk/libsanitizer/include/sanitizer/asan_interface.h trunk/libsanitizer/interception/interception.h trunk/libsanitizer/merge.sh trunk/libsanitizer/sanitizer_common/sanitizer_allocator.h trunk/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h trunk/libsanitizer/sanitizer_common/sanitizer_atomic_msvc.h trunk/libsanitizer/sanitizer_common/sanitizer_common.cc trunk/libsanitizer/sanitizer_common/sanitizer_internal_defs.h trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc trunk/libsanitizer/sanitizer_common/sanitizer_list.h trunk/libsanitizer/sanitizer_common/sanitizer_mac.cc trunk/libsanitizer/sanitizer_common/sanitizer_mutex.h trunk/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h trunk/libsanitizer/sanitizer_common/sanitizer_symbolizer.cc trunk/libsanitizer/sanitizer_common/sanitizer_symbolizer.h trunk/libsanitizer/sanitizer_common/sanitizer_win.cc trunk/libsanitizer/tsan/tsan_fd.cc trunk/libsanitizer/tsan/tsan_fd.h trunk/libsanitizer/tsan/tsan_interceptors.cc trunk/libsanitizer/tsan/tsan_mman.cc trunk/libsanitizer/tsan/tsan_report.cc trunk/libsanitizer/tsan/tsan_report.h trunk/libsanitizer/tsan/tsan_rtl_mutex.cc trunk/libsanitizer/tsan/tsan_rtl_report.cc trunk/libsanitizer/tsan/tsan_stat.cc trunk/libsanitizer/tsan/tsan_stat.h trunk/libsanitizer/tsan/tsan_symbolize.cc trunk/libsanitizer/tsan/tsan_symbolize.h
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
12:26:30 UTC ---
(In reply to comment #25)
So, what is our decision?
Are we just doing
- static const uptr kHighMemEnd = 0x0fffUL;
+ static const uptr kHighMemEnd = 0x3fffUL;
, leaving SHADOW_OFFSET=(1ULL 41)
and using ADD instead of OR when applying SHADOW_OFFSET?
This seems to work on my ppc box (44-bit) with LLVM
(I've changed it to use ADD on PPC)
If that works, it is my preference. But needs testing, also with GCC, and with
both 44-bit and 46-bit AS.
BTW, I wonder why clang generates larger and slower code with ADD instead of
OR, at least gcc seems to generate generally better code with ADD, plus on
i?86/x86_64 it even has better HW support for that (for ADD can use both
add{l,q} and leal, allowing RA to generate better code). GCC for asan
generates always ADD, on all architectures, right now.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 13:05:57 UTC --- Why doesn't it error for unlimited stack say on x86_64? If the stack mapping size is unlimited, it also potentially overlaps with the shadow memory. If you have a growsdown mapping, it simply needs to be capped by the end of the shadow memory area resp. start of the high memory region.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #30 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 13:30:19 UTC --- What I mean, is a stack PROT_GROWSDOWN RLIM_INFINITY RLIMIT_STACK mapping is defined to be a mapping from the top of that mapping down to the first mapping of something else below it. Whether it is the shadow memory or something else doesn't matter. There is just no overlap in that case, so the error looks wrong to me.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 13:33:45 UTC --- I take it back, seems it is because the kernel mmaps the shared libraries in that range in this case. So indeed, you probably need a dynamic mapping, sorry for the noise. All that just to grow VA by 2 bits? Urgh. On x86_64 at least the address space was growing much more many years ago.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 13:40:57 UTC --- (In reply to comment #31) I've committed an upstream change http://llvm.org/viewvc/llvm-project?view=revrevision=173260 that makes kHighMemEnd dynamic. Hopefully, it will simplify further changes. I'd appreciate if someone who has access to a 46-bit AS machine propose a patch that works for both 44 and 46 AS w/ and w/o unlimited stack. Do you really want to make kHighMemEnd dynamic always? Shouldn't it be dynamic only when needed (i.e. for configurations like ppc64 which now require it)? Otherwise it will slow down many of the inlines that use this heavily. Furthermore, in configurations where kHighMemEnd is dynamic, also IMHO all asan_mapping.h defines that are based on it should also be global variables to avoid unnecessary runtime computations everywhere. I mean kHighMemBeg, kHighShadowBeg, kHighShadowEnd, kShadowGapEnd.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 13:49:17 UTC --- For 4.9, wouldn't it be better to get all functions through the very early passes (up to and including build_ssa (or one or three passes after it, but before pass_inline_parameters)), then in another loop run the rest of early passes (i.e. inline_parameters/einline, ..., eipa_sra, ..., pass_inline_parameters) and then the normal IPA queue? The amount of issues we have with functions not in SSA form yet, whether it is in early inliner, or eipa_sra, etc. is big.
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
14:23:30 UTC ---
Note, the code is not valid ISO C99, which forbids initialization of flexible
array members, but a GNU extension, apparently not sufficiently well defined.
E.g. in struct T t2 = { .a = 1, .b[0] = 'a' }; the .b[0] initializer is ignored
with a warning, only initializing it as whole, whether as in #c3 without that
extra , .b[0] = '2', or e.g. as in
struct T t3 = { .a = 1, .b = { [0] = 'a', [1] = 'b', [2] = 'c' } };
So the question is how exactly we want to handle the flexible array members vs.
designated initializers, if we take the size from the first initializer and all
further ones will be either ignored (if beyond that size) or overwrite the
initializer, or if we e.g. take the highest array index ever seen anywhere.
So, say, is
struct T t4 = { .a = 1, .b[5] = '5', .b[7] = '7' };
the same as
struct T t4 = { .a = 1, .b = { 0, 0, 0, 0, 0, '5' };
with warning or:
struct T t4 = { .a = 1, .b = { 0, 0, 0, 0, 0, '5', 0, '7' };
?
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
14:32:31 UTC ---
--- gcc/c/c-typeck.c.jj2013-01-11 09:02:31.0 +0100
+++ gcc/c/c-typeck.c2013-01-23 15:24:50.839173887 +0100
@@ -7574,7 +7574,9 @@ set_nonincremental_init_from_string (tre
end = p + TREE_STRING_LENGTH (str);
for (purpose = bitsize_zero_node;
- p end !tree_int_cst_lt (constructor_max_index, purpose);
+ p end
+(constructor_max_index == NULL_TREE
+ || !tree_int_cst_lt (constructor_max_index, purpose));
purpose = size_binop (PLUS_EXPR, purpose, bitsize_one_node))
{
if (wchar_bytes == 1)
makes this ICE go away, and #c3 then is handled with a warning the same as
struct T t = { .a = 1, .b = abc };
alone, so it is the same issue as t2 then. The rest I guess depends on how do
we want to exactly define the extension.
[Bug target/56056] [4.8 Regression] internal compiler error: in get_builtin_code_for_version, at config/i386/i386.c:28686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56056 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 16:38:31 UTC --- With the latest patch for PR55742, this doesn't ICE, but is properly rejected. Even with added __attribute__((target (default))) before the first function that is now required for the default mv version, only works if you fix up the second target attribute. *** This bug has been marked as a duplicate of bug 55742 ***
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||crrodriguez at opensuse dot ||org --- Comment #43 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23 16:38:31 UTC --- *** Bug 56056 has been marked as a duplicate of this bug. ***
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 09:37:17 UTC --- Dup. *** This bug has been marked as a duplicate of bug 52573 ***
[Bug rtl-optimization/52573] [4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 09:37:17 UTC --- *** Bug 56087 has been marked as a duplicate of this bug. ***
[Bug other/56076] [4.8 regression] Several 64-bit libgo tests FAIL in read_line_header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56076
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24
09:47:00 UTC ---
I guess if DW_AT_comp_dir attribute is missing, we could crash that way.
We could do:
--- libbacktrace/dwarf.c.jj2013-01-17 13:42:51.0 +0100
+++ libbacktrace/dwarf.c2013-01-24 10:43:38.234973942 +0100
@@ -1655,7 +1655,8 @@ read_line_header (struct backtrace_state
strnlen ((const char *) hdr_buf.buf, hdr_buf.left) + 1))
return 0;
dir_index = read_uleb128 (hdr_buf);
- if (IS_ABSOLUTE_PATH (filename))
+ if (IS_ABSOLUTE_PATH (filename)
+ || (dir_index == 0 u-comp_dir == NULL))
hdr-filenames[i] = filename;
else
{
or perhaps issue an error if dir_index == 0 u-comp_dir == NULL inside of
else.
But I believe even some GCC versions in the past were buggy and didn't emit
DW_AT_comp_dir always when needed, and other compilers could have similar bugs
too, so perhaps we should be more forgiving.
[Bug c++/56095] [4.6/4.7/4.8 Regression] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|Crash casting function |[4.6/4.7/4.8 Regression] |pointer as non-type |Crash casting function |template argument |pointer as non-type ||template argument --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 12:11:13 UTC --- I can, with everything starting from http://gcc.gnu.org/viewcvs?root=gccview=revrev=166167 You need --enable-checking=yes compiler though.
[Bug c++/56095] [4.6/4.7/4.8 Regression] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |4.6.4
[Bug middle-end/56077] [4.6/4.7/4.8 Regression] volatile ignored when function inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56077 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||abel at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|volatile ignored when |[4.6/4.7/4.8 Regression] |function inlined|volatile ignored when ||function inlined --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 12:30:54 UTC --- This (for -O2) regressed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=139854 (for -O -fschedule-insns2 it regressed later, when fwprop got added for -O1). r139854 added sel-sched support, but I believe it wasn't (and isn't) the default scheduler on x86_64/i?86, thus clearly the branch merge must have affected also behavior of the normal scheduler.
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 13:27:55 UTC --- Created attachment 29264 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29264 gcc48-pr56078.patch Patch I've bootstrapped/regtested. It seems in most places constructor_max_index == NULL was treated as unlimited bound (compared to e.g. constructor_max_index being -1 as zero size bound with nothing allowed), but these two spots either didn't handle it at all, or incorrectly. The patch fixes the new testcase, both that it doesn't ICE and behaves expectedly, but unfortunately at the same time regresses gcc.c-torture/compile/20030305-1.c testcase, which is no longer accepted. It was filed as ice-on-invalid, is it really supposed to be a valid GNU C99 testcase?
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 13:33:13 UTC --- Before my patch we got: 20030305-1.c:15:5: warning: excess elements in struct initializer [enabled by default] 20030305-1.c:15:5: warning: (near initialization for ‘s2_array[0]’) [enabled by default] 20030305-1.c:16:5: warning: excess elements in struct initializer [enabled by default] 20030305-1.c:16:5: warning: (near initialization for ‘s2_array[1]’) [enabled by default] 20030305-1.c:17:5: warning: excess elements in struct initializer [enabled by default] 20030305-1.c:17:5: warning: (near initialization for ‘s2_array[2]’) [enabled by default] and with the patch: 20030305-1.c:15:5: error: initialization of flexible array member in a nested context 20030305-1.c:15:5: error: (near initialization for ‘s2_array[0].s1_array’) 20030305-1.c:16:5: error: initialization of flexible array member in a nested context 20030305-1.c:16:5: error: (near initialization for ‘s2_array[1].s1_array’) 20030305-1.c:17:5: error: initialization of flexible array member in a nested context 20030305-1.c:17:5: error: (near initialization for ‘s2_array[2].s1_array’) instead. I'd lean towards the errors being correct, Joseph, do you agree? If so, I'll move the 20030305-1.c testcase into gcc.dg and add dg-error comments.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 14:19:17 UTC --- On a brief look, this doesn't look like using location of neighbouring statement, given: grep 66:1 pr56094.c.115t.cunroll | wc -l 0 grep 66:1 pr56094.c.119t.ivopts | wc -l 39
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 15:06:28 UTC --- So, the reason seems to be: mod = build2 (INIT_EXPR, TREE_TYPE (t), t, unshare_expr (val)); SET_EXPR_LOCATION (mod, EXPR_LOC_OR_HERE (val)); in: #0 internal_get_tmp_var (val=0x71aeaaa0, pre_p=0x7fffdda8, post_p=0x0, is_formal=true) at ../../gcc/gimplify.c:636 #1 0x00832a3e in get_formal_tmp_var (val=0x71aeaaa0, pre_p=0x7fffdda8) at ../../gcc/gimplify.c:657 #2 0x0084d3b7 in gimplify_expr (expr_p=0x7fffdcf8, pre_p=0x7fffdda8, post_p=0x7fffdbb0, gimple_test_f=0x80befc is_gimple_val(tree_node*), fallback=1) at ../../gcc/gimplify.c:8023 #3 0x0084f7c8 in force_gimple_operand_1 (expr=0x71aeaaa0, stmts=0x7fffdda8, gimple_test_f=0x80befc is_gimple_val(tree_node*), var=0x0) at ../../gcc/gimplify.c:8633 #4 0x0084f878 in force_gimple_operand_gsi_1 (gsi=0x7fffde60, expr=0x71aeaaa0, gimple_test_f=0x80befc is_gimple_val(tree_node*), var=0x0, before=true, m=GSI_SAME_STMT) at ../../gcc/gimplify.c:8669 #5 0x0084f923 in force_gimple_operand_gsi (gsi=0x7fffde60, expr=0x71aeaaa0, simple_p=true, var=0x0, before=true, m=GSI_SAME_STMT) at ../../gcc/gimplify.c:8698 #6 0x00b79414 in rewrite_use_nonlinear_expr (data=0x7fffdf70, use=0x1887f90, cand=0x1887f40) at ../../gcc/tree-ssa-loop-ivopts.c:6151 #7 0x00b79df5 in rewrite_use (data=0x7fffdf70, use=0x1887f90, cand=0x1887f40) at ../../gcc/tree-ssa-loop-ivopts.c:6358 #8 0x00b79eb7 in rewrite_uses (data=0x7fffdf70) at ../../gcc/tree-ssa-loop-ivopts.c:6391 #9 0x00b7b0a0 in tree_ssa_iv_optimize_loop (data=0x7fffdf70, loop=0x7198bb28) at ../../gcc/tree-ssa-loop-ivopts.c:6716 During original gimplification, I can understand the OR_HERE (aka input_location) part there, or in passes that maintain input_location. But generally force_gimple_operand* is often called even from passes that don't maintain reasonable input_location. So, either the above should be hack like if (gimplify_ctxp-into_ssa) SET_EXPR_LOCATION (mod, EXPR_LOCATION (val)); else SET_EXPR_LOCATION (mod, EXPR_LOC_OR_HERE (val)); (or gimplify_ctxp-use_input_location or whatever), or perhaps force_gimple_operand* should temporarily set input_location to UNKNOWN_LOCATION and restore it back from a saved copy before returning.
[Bug c/56078] causes cc1 to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56078 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24 16:59:56 UTC --- Author: jakub Date: Thu Jan 24 16:59:44 2013 New Revision: 195432 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195432 Log: PR c/56078 * c-typeck.c (set_nonincremental_init_from_string): If constructor_max_index is NULL, treat it as if tree_int_cst_lt returned false. (process_init_element): Likewise. * gcc.dg/pr56078.c: New test. * gcc.c-torture/compile/20030305-1.c: Add dg-error lines. Added: trunk/gcc/testsuite/gcc.dg/pr56078.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/20030305-1.c
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-24
17:26:48 UTC ---
--- gimplify.c.jj2013-01-11 09:02:55.0 +0100
+++ gimplify.c2013-01-24 18:15:54.246157569 +0100
@@ -8600,6 +8600,7 @@ force_gimple_operand_1 (tree expr, gimpl
{
enum gimplify_status ret;
struct gimplify_ctx gctx;
+ location_t saved_location;
*stmts = NULL;
@@ -8613,6 +8614,8 @@ force_gimple_operand_1 (tree expr, gimpl
push_gimplify_context (gctx);
gimplify_ctxp-into_ssa = gimple_in_ssa_p (cfun);
gimplify_ctxp-allow_rhs_cond_expr = true;
+ saved_location = input_location;
+ input_location = UNKNOWN_LOCATION;
if (var)
{
@@ -8634,6 +8637,7 @@ force_gimple_operand_1 (tree expr, gimpl
gcc_assert (ret != GS_ERROR);
}
+ input_location = saved_location;
pop_gimplify_context (NULL);
return expr;
seems to work (there are way too many uses of input_location in gimplify.c),
alternatively we could e.g. grab input_location temporarily just in
force_gimple_operand_gsi_1, depending on gimple_location of the stmt this
should be emitted before resp. after.
[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 09:08:14 UTC --- Well, we can also just use the first NOTE_INSN_BASIC_BLOCK resp. NOTE_INSN_FUNCTION_BEG, whichever comes first. The bigger problem with that ia64, pa and a few other targets use both PROLOGUE_BEFORE_EPILOGUE and non-default function_prologue hook, which emits some assembly stuff (even when they HAVE_prologue). Perhaps for those targets we'd need to emit the profiler code right away, and only postpone it until the first NOTE_INSN_BASIC_BLOCK/NOTE_INSN_FUNCTION_BEG if function_prologue hook is the default.
[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 09:35:17 UTC --- Created attachment 29271 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29271 gcc48-pr54793.patch So, e.g. this seems to work for me from quick testing. The insn chain scanning is there e.g. to emit the profiler stuff right away when final_start_function is called from output_mi_thunk on various targets.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 11:29:13 UTC --- Created attachment 29272 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29272 gcc48-pr56094.patch input_location is used heavily in the gimplifier, gimplify_expr sets it from the expression being currently gimplified (if it has any), and for temporaries and their initializers that are created while gimplifying that stmt it is intentional to use the location of that expression. I've bootstrapped/regtested this patch on i686-linux (no ada) so far, the lex.c hunk is to avoid ICEs when e.g. tree-parloops.c calls the make_type langhook (but there are other callers of that) with input_location of UNKNOWN_LOCATION. I was surprised there weren't regressions, given that input_location is used implicitly e.g. by all error/warning calls, unless they supply their own location.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 12:04:59 UTC --- (In reply to comment #13) You are explaining how it works right now. What I am asking is how we want it to work, that is, why the gimplifier needs to care about input_location and cannot use *always* the location of the expression being gimplified (or some sub-expression) or UNKNOWN_LOCATION for things that are compiler generated. Because not all the gimplifier routines see the current expression as whole, they can work on some subexpression etc., and not all expressions have location. So, you generally want to use a location of some expression (if known) for all the subexpressions that don't have their own location. Currently that is performed in the gimplifier by saving the current location in input_location variable and then lots of code use that. Alternative to that is use some different variable, gimplifier_location or whatever. But you'd really need to change lots of code for that, and I'd be afraid that some code that needs that could be shared between FEs and the gimplifier. E.g. make_node uses input_location, which is desirable in the FEs, but with such a change would be undesirable in the gimplifier. Does the diagnostic machinery assert that input_location != UNKNOWN_LOCATION? I think not. I seem to remember that we sometimes generate: warning:0:0: something but I am not sure if this happens for warning_at(UNKNOWN_LOCATION). E.g. for warning_at, instead of printing say: qqq.c: In function ‘foo’: qqq.c:4:34: warning: argument to ‘sizeof’ in ‘__builtin_memset’ call is the same expression as the destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess] if the first argument is changed to UNKNOWN_LOCATION, it prints: qqq.c: In function ‘foo’: cc1: warning: argument to ‘sizeof’ in ‘__builtin_memset’ call is the same expression as the destination; did you mean to provide an explicit length? [-Wsizeof-pointer-memaccess]
[Bug c++/56104] [4.7/4.8 Regression] Wrong dereferencing type-punned pointer warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56104 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-25 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.3 Summary|Wrong dereferencing|[4.7/4.8 Regression] Wrong |type-punned pointer|dereferencing type-punned |warning |pointer warning Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 14:35:46 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=176461 Of course, might be a FE bug which has been just latent before.
[Bug c++/56104] [4.7/4.8 Regression] Wrong dereferencing type-punned pointer warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56104 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 14:57:47 UTC --- Guess the relevant change in the patch is: --- trunk/gcc/cp/typeck.c2011/07/19 13:28:15176460 +++ trunk/gcc/cp/typeck.c2011/07/19 14:01:59176461 @@ -3078,8 +3078,7 @@ return error_mark_node; } /* ...and then the delta in the PMF. */ - instance_ptr = build2 (POINTER_PLUS_EXPR, TREE_TYPE (instance_ptr), - instance_ptr, fold_convert (sizetype, delta)); + instance_ptr = fold_build_pointer_plus (instance_ptr, delta); /* Hand back the adjusted 'this' argument to our caller. */ *instance_ptrptr = instance_ptr; where we didn't fold the POINTER_PLUS_EXPR in this case before (delta is 0 here), but now we do. The above is followed by: /* Next extract the vtable pointer from the object. */ vtbl = build1 (NOP_EXPR, build_pointer_type (vtbl_ptr_type_node), instance_ptr); vtbl = cp_build_indirect_ref (vtbl, RO_NULL, complain); if (vtbl == error_mark_node) return error_mark_node; and during cp_build_indirect_ref this warns, instance_ptr here is ADDR_EXPR of cc VAR_DECL, and as the class type of cc isn't virtual, it doesn't have a vtable pointer at the beginning.
[Bug c++/56104] [4.7/4.8 Regression] Wrong dereferencing type-punned pointer warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56104 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 15:05:48 UTC --- Given the /* If the object is not dynamic the access invokes undefined behavior. As it is not executed in this case silence the spurious warnings it may provoke. */ comment after it, can't we just build the INDIRECT_REF by hand instead of cp_build_indirect_ref ? Or revert richi's hunk and force always POINTER_PLUS_EXPR, even for zero offset? Then this warning isn't emitted.
[Bug middle-end/56098] [4.6/4.7/4.8 Regression] conditional write through volatile pointer produces unintended read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 15:34:58 UTC --- Created attachment 29275 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29275 gcc48-pr56098.patch Untested fix.
[Bug middle-end/56098] [4.6/4.7/4.8 Regression] conditional write through volatile pointer produces unintended read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 20:04:01 UTC --- Author: jakub Date: Fri Jan 25 20:03:54 2013 New Revision: 195475 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195475 Log: PR tree-optimization/56098 * tree-ssa-phiopt.c (nt_init_block): Don't call add_or_mark_expr for stmts with volatile ops. (cond_store_replacement): Don't optimize if assign has volatile ops. (cond_if_else_store_replacement_1): Don't optimize if either then_assign or else_assign have volatile ops. (hoist_adjacent_loads): Don't optimize if either def1 or def2 have volatile ops. * gcc.dg/pr56098-1.c: New test. * gcc.dg/pr56098-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56098-1.c trunk/gcc/testsuite/gcc.dg/pr56098-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug c++/56095] [4.6/4.7 Regression] Crash casting function pointer as non-type template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56095 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Crash |Crash casting function |casting function pointer as |pointer as non-type |non-type template argument |template argument | --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 20:04:59 UTC --- Fixed on the trunk so far.
[Bug middle-end/56098] [4.6/4.7 Regression] conditional write through volatile pointer produces unintended read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] |conditional write through |conditional write through |volatile pointer produces |volatile pointer produces |unintended read |unintended read --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-25 20:05:48 UTC --- Fixed on the trunk so far.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-26 10:05:58 UTC --- I must say I'm surprised by the gimple-fold.c test, I'd really expect additional DECL_VISIBILITY (decl) != VISIBILITY_DEFAULT . Another alternative to make those always hidden (which could be an exported ABI change for some shared libraries, though unlikely to be actually a real problem) would be to add some new bit, either in the tree itself, or better in symtab node, which would tell gimple-fold.c not to optimize it. Honza?
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-26 10:38:23 UTC --- BTW, I agree with Jason that we shouldn't optimize these vtable reads. When this hit libstdc++, it could hit very well any other C++ shared library which uses version scripts or some other ways how to enumerate what exactly is exported.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 08:19:43 UTC --- Because -gstabs etc. are still supported on most of the primary and secondary targets, and (to my surprise) some projects are still using it (I believe e.g. some Mozilla builds do as their bugreporting system only supports STABS, not DWARF). STABS hasn't been deprecated, so we can't just remove that support for 4.8 easily, yeah, we should probably deprecate it and remove later on.
[Bug c/56086] when compiling C code with -std=gnu99 macro __STDC_UTF_16__ is defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56086 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 08:28:40 UTC --- Let's CC Jason on this.
[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56117 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-28 CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 08:44:33 UTC --- As expected, regressed with the http://gcc.gnu.org/viewcvs?root=gccview=revrev=195211 change.
[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56117 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 08:51:39 UTC --- Created attachment 29289 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29289 gcc48-pr56117.patch Untested fix. For MEMs, sched-deps.c is calling cselib_lookup_from_insn, but for PREFETCH it wasn't doing that. As this is before cselib_process_insn is called, some REGs mentioned in the pattern might be never looked up yet at that point.
[Bug tree-optimization/56125] [4.7/4.8 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.3 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 09:15:09 UTC --- Regressed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=174446 Looking into it.
[Bug tree-optimization/56125] [4.7/4.8 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28
10:27:19 UTC ---
Created attachment 29292
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29292
gcc48-pr56125.patch
The bug is that the last two optimizations of pow (where 2c resp. 3c is a
non-zero integer) silently assume that the earlier optimizations already
handled the cases where already c (or 2c for the last optimization) is an
integer.
But that doesn't have to be the case, as shown by the testcase, the integer
optimization is guarded by c in [-1,2] or optimization for speed.
The optimize_function_for_speed_p () (or should that be
optimize_insn_for_speed_p?, the pow folding is inconsistent in that, and I
don't see e.g. rtl_profile_for_bb being called during this pass to make it
accurate)
is up for discussions, say on x86_64
__attribute__((cold)) double
foo (double x, double n)
{
double u = __builtin_pow (x, -1.5);
return u;
}
with it we get smaller code:
movsd .LC0(%rip), %xmm1
jmp pow
compared to:
sqrtsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
movsd .LC0(%rip), %xmm0
divsd %xmm1, %xmm0
without it, 7 bytes shorter.
[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstreamchar, std::char_traitschar, std::allocatorchar '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 11:27:51 UTC --- I meant the ABI checkers only. Anyway, on the other side given comments like: This mangling isn't part of the ABI specification; in the ABI specification, the vtable group is dumped in the same COMDAT as the main vtable, and is referenced only from that vtable, so it doesn't need an external name. For binary formats without COMDAT sections, though, we need external names for the vtable groups. and Construction virtual tables are not exported because they cannot be referred to from other object files; their name is not standardized by the ABI. perhaps making them hidden whenever possible is really desirable.
[Bug tree-optimization/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 12:10:57 UTC --- Just guessing, perhaps Darwin headers define memset using __builtin_memset? So, perhaps we should ditch #include string.h and define the prototypes ourselves, then it isn't dependent on the target headers.
[Bug testsuite/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 13:00:00 UTC --- Created attachment 29295 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29295 gcc48-pr56053.patch Untested fix.
[Bug bootstrap/56128] [4.8 Regression] No way to disable build of libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-28
CC||aoliva at gcc dot gnu.org,
||bonzini at gnu dot org,
||jakub at gcc dot gnu.org,
||kcc at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28
13:06:40 UTC ---
I think we should both avoid linux/futex.h includes (both in libsanitizer and
testsuite/g++.dg/asan/, both inherited from upstream), either by doing a
configure test for it and only including it if it works properly, or just do
what libgomp or libitm do, don't include linux/futex.h and instead define
FUTEX_{WAIT,WAKE} directly, and also have some --disable-libsanitizer configury
option, CCing some build maintainers for that on where and how should that be
done.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 14:05:48 UTC --- Author: jakub Date: Mon Jan 28 14:05:40 2013 New Revision: 195504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195504 Log: PR tree-optimization/56094 * gimplify.c (force_gimple_operand_1): Temporarily set input_location to UNKNOWN_LOCATION while gimplifying expr. * gcc.dg/pr56094.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56094.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56053 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 14:28:24 UTC --- Author: jakub Date: Mon Jan 28 14:28:16 2013 New Revision: 195505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195505 Log: PR testsuite/56053 * c-c++-common/asan/heap-overflow-1.c: Don't include stdlib.h and string.h. Provide memset, malloc and free prototypes, adjust line numbers in dg-output. * c-c++-common/asan/stack-overflow-1.c: Don't include string.h. Provide memset prototype and adjust line numbers in dg-output. * c-c++-common/asan/global-overflow-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/global-overflow-1.c trunk/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c trunk/gcc/testsuite/c-c++-common/asan/stack-overflow-1.c
[Bug testsuite/56053] FAIL: c-c++-common/asan/(global|stack)-overflow-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56053 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 14:31:35 UTC --- Should be fixed now.
[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 14:33:18 UTC --- Should be fixed now on the trunk, but keeping the PR open, so that we don't forget to revert and do a better fix instead.
[Bug tree-optimization/56125] [4.7/4.8 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 14:43:07 UTC --- Author: jakub Date: Mon Jan 28 14:43:03 2013 New Revision: 195507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195507 Log: PR tree-optimization/56125 * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Don't optimize pow(x,c) into sqrt(x) * powi(x, n/2) or 1.0 / (sqrt(x) * powi(x, abs(n/2))) if c is an integer or when optimizing for size. Don't optimize pow(x,c) into powi(x, n/3) * powi(cbrt(x), n%3) or 1.0 / (powi(x, abs(n)/3) * powi(cbrt(x), abs(n)%3)) if 2c is an integer. * gcc.dg/pr56125.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56125.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/56125] [4.7 Regression] -O2 -ffast-math generates bad code when dividing a double by the square of another double.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56125 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression] -O2|[4.7 Regression] -O2 |-ffast-math generates bad |-ffast-math generates bad |code when dividing a double |code when dividing a double |by the square of another|by the square of another |double. |double. --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 15:07:24 UTC --- Fixed on the trunk so far.
[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56117 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 16:50:39 UTC --- Author: jakub Date: Mon Jan 28 16:50:22 2013 New Revision: 195513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195513 Log: PR rtl-optimization/56117 * sched-deps.c (sched_analyze_2) case PREFETCH: For use_cselib call cselib_lookup_from_insn on the MEM before calling add_insn_mem_dependence. * gcc.dg/pr56117.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr56117.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/56117] [4.8 Regression] ICE: in cselib_subst_to_values, at cselib.c:1853 with -O2 -fsched2-use-superblocks and __builtin_prefetch()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56117 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 16:52:26 UTC --- Fixed.
[Bug rtl-optimization/55342] [4.8 Regression] [LRA,x86] Non-optimal code for simple loop with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2 CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-28 18:53:25 UTC --- I'm downgrading this to P2, it is unfortunate we generate slightly worse code on this testcase, but it is more important how LRA vs. reload behaves on average on various benchmarks etc. This doesn't mean this isn't important to look at, but I think it isn't a release blocker at this point.
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-29 09:13:27 UTC --- (In reply to comment #17) Note that there is at least one known bug in asan with -static-libstdc++ https://code.google.com/p/address-sanitizer/issues/detail?id=147 As with the patch for this PR -lasan is linked before -lstdc++, the wrapper should kick in. But the patch is still unreviewed.
[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-29 09:29:39 UTC --- Ah, you're right. My patch is mostly to fix -static-libasan or even non-static-libasan - to make sure it comes early and thus override what it thinks it actually overrides. For -static or -static-libstdc++ to work, you'd need --wrap=XXX ld options (and differently built libasan_static.a), but it'd be a mess. dlsym can't work in that case. We error for -static -fsanitize=address, we could similarly error for -static-libstdc++ -fsanitize=address combination.
[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-29
17:22:34 UTC ---
Other examples from
https://lists.fedoraproject.org/pipermail/devel/2013-January/175876.html
to test the potential warning (requires 32-bit integer and 64-bit long long):
void bar (void *);
void
fn1 (void)
{
unsigned int a[128];
int i;
for (i = 0; i 128; ++i)
a[i] = i * 0x0201;
bar (a);
}
void
fn2 (void)
{
unsigned long long a[128];
int i;
for (i = 0; i 128; i++)
a[i] = (i + 1LL) * 0x0123456789ABCDEFLL;
bar (a);
}
void
fn3 (void)
{
unsigned char a[16], b[16], c[16];
int i;
bar (b);
for (i = 0; i (int) (sizeof (a) / sizeof (a[0])); i++)
{
c[i + 8] = b[i];
a[i + 8] = b[i + 8];
}
bar (a);
bar (c);
}
void
fn4 (void)
{
unsigned int *a[32], *o, i;
bar (a);
for (i = 0; i = sizeof (a) / sizeof (a[0]); i++)
{
o = a[i];
bar (o);
}
}
void
fn5 (void)
{
unsigned short a[23940];
unsigned int b[1140];
int j;
bar (b);
for (j = 0; j 1140; j++)
a[23940 + j - 950] = b[j];
bar (a);
}
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-29 18:49:25 UTC --- Perhaps -fexcess-precision=standard might fix this too (and be less expensive).
[Bug bootstrap/56128] [4.8 Regression] No way to disable build of libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-30 08:13:29 UTC --- The issue unfortunately isn't old vs. new kernels, just using linux/* and asm/* headers, which as can be seen in this case sometimes aren't of a good quality, kernel treats them as kernel headers and whether they are usable in userland is far lower priority to them. So, if linux/* or asm/* includes can be avoided, it is always better to avoid them, and in this case it can be very easily avoided. And as for disabling whole sanitizer, how would you expect it to work? Just let users see a failed bootstrap and then find out they need to add --disable-target-libsanitizer to configure next time? OT, Richard, does --disable-target-libsanitizer work for you?
