[Bug tree-optimization/56478] [4.8 Regression] ICE: Floating point exception in tree_estimate_probability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56478
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-02-28
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.8.0
Summary|Regression: ICE: Floating |[4.8 Regression] ICE:
|point exception in |Floating point exception in
|tree_estimate_probability |tree_estimate_probability
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek 2013-02-28
07:52:24 UTC ---
Slightly cleaned up testcase:
int a;
void
foo ()
{
int b;
for (b = 0;; b++)
a = 0 < -__LONG_LONG_MAX__ - 1 - b ? : 0;
}
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187277
[Bug inline-asm/56479] New: Register allocator can't allocate two 4-byte variables into 8 registers for inline asm on avr-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56479
Bug #: 56479
Summary: Register allocator can't allocate two 4-byte variables
into 8 registers for inline asm on avr-gcc
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shuly...@gmail.com
Hi!
When I try to compile the following code with avr-gcc for atmega2560 cpu:
#include
uint64_t asmfoo(uint32_t x, uint32_t y);
int main(void)
{ return (int)asmfoo(1234, 5678); }
uint64_t asmfoo(uint32_t x, uint32_t y)
{
uint64_t z;
asm volatile (
"nop \n\t" //I'm going to make use of fmul instructions here
"nop \n\t" //which only accept r16-r23 registers
"nop \n\t"
: [Z]"=&r"(z) //"r" is any general register (r1-r32)
: [X]"a"(x), [Y]"a"(y) //"a" is a simple upper register (r16-r23)
);
return z;
}
-
I get the following error:
$ avr-gcc-4.7.2 -c test.c
test.c: In function 'asmfoo':
test.c:13: error: can't find a register in class 'SIMPLE_LD_REGS' while
reloading 'asm'
test.c:13: error: 'asm' operand has impossible constraints
I have tested it with 4.3.2 and 4.7.2 with different optimization levels.
On the other hand, the following code DOES compile:
-
#include
uint64_t asmfoo(uint64_t x, uint32_t y);
int main(void)
{ return (int)asmfoo(1234, 5678); }
uint64_t asmfoo(uint64_t x, uint32_t y) // <-note the uint64_t
{
uint64_t z;
asm volatile (
"nop \n\t"
"nop \n\t"
"nop \n\t"
: [Z]"=&r"(z)
: [X]"a"(x) // <-note the absence of y
);
return z;
}
-
[Bug target/56473] Cross Compile Ubuntu x86_64 to Raspberry Pi Code Seg Faults When Executed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56473
--- Comment #4 from Thomas Dean 2013-02-28
00:38:56 UTC ---
Looking again at gdb, _start from ubuntu is not the same as _start on
RaspberryPi, although both compiler versions are the same.
###
## build on ubuntu
## gdb on raspi
tomdean@raspberrypi:~/p9x79/bug$ gdb hello
GNU gdb (GDB) 7.4.1-debian
Reading symbols from /home/tomdean/p9x79/bug/hello...done.
(gdb) b main
Breakpoint 1 at 0x8364: file hello.c, line 3.
(gdb) r
Starting program: /home/tomdean/p9x79/bug/hello
Program received signal SIGSEGV, Segmentation fault.
0x000573a6 in ?? ()
(gdb) bt
#0 0x000573a6 in ?? ()
#1 0x82ee in _start ()
(gdb) disassemble/r _start
Dump of assembler code for function _start:
0x82e4 <+0>: 4f f0 00 0b mov.w r11, #0
0x82e8 <+4>: 4f f0 00 0e mov.w lr, #0
0x82ec <+8>: 5d f8 04 1b ldr.w r1, [sp], #4
0x82f0 <+12>:6a 46 mov r2, sp
0x82f2 <+14>:4d f8 04 2d str.w r2, [sp, #-4]!
0x82f6 <+18>:4d f8 04 0d str.w r0, [sp, #-4]!
0x82fa <+22>:df f8 14 c0 ldr.w r12, [pc, #20] ; 0x8310
<_start+44>
0x82fe <+26>:4d f8 04 cd str.w r12, [sp, #-4]!
0x8302 <+30>:04 48 ldr r0, [pc, #16] ; (0x8314 <_start+48>)
0x8304 <+32>:04 4b ldr r3, [pc, #16] ; (0x8318 <_start+52>)
0x8306 <+34>:ff f7 da ef blx 0x82bc <__libc_start_main>
0x830a <+38>:ff f7 e6 ef blx 0x82d8
0x830e <+42>:00 00 bd 83 ;
instruction: 0x83bd
0x8312 <+46>:00 00 5c 83 cmphi r12, #0
0x8316 <+50>:00 00 79 83 cmnhi r9, #0
0x831a <+54>:00 00 03 4b blmi0xc8322
End of assembler dump.
###
## compile on ubuntu
## link on raspi
## gdb on raspi
ubuntu> arm-linux-gnueabihf-gcc-4.6 -g -mcpu=arm1176jzf-s -mfpu=vfp
-mfloat-abi=hard -marm hello.c -Wl,-t -c -o hello.o
tomdean@raspberrypi:~/p9x79/bug$ arm-linux-gnueabihf-gcc-4.6 -g
-mcpu=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -marm hello.o -Wl,-t -o
~/work/hello
tomdean@raspberrypi:~/p9x79/bug$ gdb ~/work/hello
GNU gdb (GDB) 7.4.1-debian
Reading symbols from /home/tomdean/work/hello...done.
(gdb) b main
Breakpoint 1 at 0x8398: file hello.c, line 3.
(gdb) r
Starting program: /home/tomdean/work/hello
Breakpoint 1, main () at hello.c:3
3 return 0;
(gdb) disassemble/r _start
Dump of assembler code for function _start:
0x82e4 <+0>: 00 b0 a0 e3 mov r11, #0
0x82e8 <+4>: 00 e0 a0 e3 mov lr, #0
0x82ec <+8>: 04 10 9d e4 pop {r1}; (ldr r1,
[sp], #4)
0x82f0 <+12>:0d 20 a0 e1 mov r2, sp
0x82f4 <+16>:04 20 2d e5 push{r2}; (str r2, [sp,
#-4]!)
0x82f8 <+20>:04 00 2d e5 push{r0}; (str r0, [sp,
#-4]!)
0x82fc <+24>:10 c0 9f e5 ldr r12, [pc, #16] ; 0x8314
<_start+48>
0x8300 <+28>:04 c0 2d e5 push{r12} ; (str r12,
[sp, #-4]!)
0x8304 <+32>:0c 00 9f e5 ldr r0, [pc, #12] ; 0x8318
<_start+52>
0x8308 <+36>:0c 30 9f e5 ldr r3, [pc, #12] ; 0x831c
<_start+56>
0x830c <+40>:eb ff ff eb bl 0x82c0 <__libc_start_main>
0x8310 <+44>:f0 ff ff eb bl 0x82d8
0x8314 <+48>:0c 84 00 00 andeq r8, r0, r12, lsl #8
0x8318 <+52>:90 83 00 00 muleq r0, r0, r3
0x831c <+56>:ac 83 00 00 andeq r8, r0, r12, lsr #7
End of assembler dump.
[Bug target/56473] Cross Compile Ubuntu x86_64 to Raspberry Pi Code Seg Faults When Executed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56473 --- Comment #3 from Thomas Dean 2013-02-28 00:24:44 UTC --- On Ubuntu, I recompiled with -g On RaspberryPi, I ran gdb on the resulting executable tomdean@raspberrypi:~/p9x79/bug$ gdb hello GNU gdb (GDB) 7.4.1-debian Reading symbols from /home/tomdean/p9x79/bug/hello...done. (gdb) b main Breakpoint 1 at 0x8364: file hello.c, line 3. (gdb) r Starting program: /home/tomdean/p9x79/bug/hello Program received signal SIGSEGV, Segmentation fault. 0x000573a6 in ?? () (gdb) bt #0 0x000573a6 in ?? () #1 0x82ee in _start () I think the ubuntu crtxxx.o files and the unbunt arm-linux-gnueabihf-gcc-4.6 libs were not built correctly. diff says they are not the same as the RaspberryPi files. If I compile on ubuntu and link on RaspberryPi, all is well. If I compile on ubuntu and link, using the crtxxx.o and libs from RaspberryPi, all is well.
[Bug tree-optimization/56478] New: Regression: ICE: Floating point exception in tree_estimate_probability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56478
Bug #: 56478
Summary: Regression: ICE: Floating point exception in
tree_estimate_probability
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following snippet (generated by csmith) causes top-of-trunk to generate an
ICE at -O2 and above. This is a regression from 4.7 which compiles the code
fine.
$ gcc-trunk --version
gcc-trunk (GCC) 4.8.0 20130227 (experimental) [trunk revision 196310]
$ cat crash2.c
/* gcc-trunk -O2+ */
int a;
void fn1 ()
{
int b;
b = 0;
for (;; b++)
a = 0 < -9223372036854775807LL - 1 - b ? : 0;
}
$ gcc-trunk -O -c crash2.c
$ gcc-4.7 -O2 -c crash2.c
$ gcc-trunk -O2 -c crash2.c
crash2.c: In function ‘fn1’:
crash2.c:9:1: internal compiler error: Floating point exception
}
^
0x7a32df crash_signal
../../gcc-trunk/gcc/toplev.c:332
0x7274ce predict_iv_comparison
../../gcc-trunk/gcc/predict.c:1231
0x7274ce predict_loops
../../gcc-trunk/gcc/predict.c:1552
0x7274ce tree_estimate_probability()
../../gcc-trunk/gcc/predict.c:2276
0x7277c0 tree_estimate_probability_driver
../../gcc-trunk/gcc/predict.c:2313
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
[Bug fortran/56477] [4.8 Regression] ICE on invalid with pointer assignment to function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56477 --- Comment #2 from Thomas Koenig 2013-02-27 22:31:08 UTC --- > where value->symtree->n.sym->ns->parent is NULL. Should be rvalue->symtree->n.sym->ns->parent (copy&paste error).
[Bug fortran/56477] [4.8 Regression] ICE on invalid with pointer assignment to function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56477 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code Last reconfirmed||2013-02-27 CC||burnus at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 Summary|ICE on invalid with pointer |[4.8 Regression] ICE on |assignment to function |invalid with pointer |result |assignment to function ||result Target Milestone|--- |4.8.0 --- Comment #1 from Thomas Koenig 2013-02-27 22:14:33 UTC --- The problem is in for (ns = rvalue->symtree->n.sym->ns; ns->proc_name && ns->proc_name->attr.flavor != FL_PROCEDURE; ns = ns->parent) where value->symtree->n.sym->ns->parent is NULL. Does not happen with 4.7 or 4.6.
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #5 from Karlson2k 2013-02-27 22:07:21 UTC --- (In reply to comment #3) > Well, AC_TRY_RUN is for sure the wrong approach here. As such tests are > failing badly on cross-compilers. > I think sanest way to solve this is by special-casing mingw targets. This test is already skipped for cross-compilers and done only for native compilers. So AC_TRY_RUN is the only solution, that can check compiler's capabilities (and not the shell's).
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #15 from Jakub Jelinek 2013-02-27 22:06:39 UTC --- Author: jakub Date: Wed Feb 27 22:06:21 2013 New Revision: 196325 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196325 Log: PR middle-end/56461 * tree-vect-data-refs.c (vect_permute_load_chain): Avoid using copy method on dr_chain and result_chain. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #14 from Jakub Jelinek 2013-02-27 22:05:46 UTC --- Author: jakub Date: Wed Feb 27 22:05:33 2013 New Revision: 196324 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196324 Log: PR middle-end/56461 * tree-ssa-loop-niter.c (maybe_lower_iteration_bound): Call pointer_set_destroy on not_executed_last_iteration. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug fortran/56477] New: ICE on invalid with pointer assignment to function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56477 Bug #: 56477 Summary: ICE on invalid with pointer assignment to function result Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: abenso...@gmail.com The following causes an ICE with gfortran 4.8.0 r196316: module s contains function so() implicit none integer, target :: so integer, pointer :: sp sp => so return end function So end module s $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson --enable-languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson Thread model: posix gcc version 4.8.0 20130227 (experimental) (GCC) $ gfortran -c -o ICEtest.o ICEtest.F90 -Wall f951: internal compiler error: Segmentation fault 0x92f79f crash_signal ../../gcc-trunk/gcc/toplev.c:332 0x4fdbf2 gfc_check_pointer_assign(gfc_expr*, gfc_expr*) ../../gcc-trunk/gcc/fortran/expr.c:3734 0xd6 resolve_code ../../gcc-trunk/gcc/fortran/resolve.c:10261 0x557c5e resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14972 0x557b67 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.c:14958 0x548aa2 gfc_resolve ../../gcc-trunk/gcc/fortran/resolve.c:15000 0x53d186 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4608 0x579415 gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. The "-Wall" is important - without the code compiles without complaint. I tagged this as invalid(?) because I don't think that giving the function return value the TARGET attribute makes sense, although I couldn't find anything that clearly says it's not allowed.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #13 from Jakub Jelinek 2013-02-27 21:41:03 UTC --- Author: jakub Date: Wed Feb 27 21:40:53 2013 New Revision: 196323 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196323 Log: PR middle-end/56461 * tree-vect-loop.c (vectorizable_reduction): Release vect_defs vector. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #12 from Jakub Jelinek 2013-02-27 21:36:09 UTC --- Author: jakub Date: Wed Feb 27 21:35:53 2013 New Revision: 196322 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196322 Log: PR middle-end/56461 * ipa-pure-const.c (propagate): Use FOR_EACH_FUNCTION instead of FOR_EACH_DEFINED_FUNCTION when freeing state. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #11 from Jakub Jelinek 2013-02-27 21:35:17 UTC --- Author: jakub Date: Wed Feb 27 21:35:06 2013 New Revision: 196321 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196321 Log: PR middle-end/56461 * df-scan.c (df_insn_delete): Use df_scan_free_mws_vec before pool_free. (df_insn_rescan_debug_internal): Use df_scan_free_mws_vec before overwriting it. Modified: trunk/gcc/ChangeLog trunk/gcc/df-scan.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #10 from Jakub Jelinek 2013-02-27 21:34:35 UTC --- Author: jakub Date: Wed Feb 27 21:34:27 2013 New Revision: 196320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196320 Log: PR middle-end/56461 * ipa-cp.c (decide_whether_version_node): Call vec_free on known_aggs[i].items and release known_aggs vector. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #9 from Jakub Jelinek 2013-02-27 21:33:28 UTC --- Author: jakub Date: Wed Feb 27 21:33:20 2013 New Revision: 196319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196319 Log: PR middle-end/56461 * ipa-reference.c (propagate): Free node_info even for alias nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-reference.c
[Bug go/56431] -lpthread should be added to -lgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #6 from H.J. Lu 2013-02-27 21:20:53 UTC --- (In reply to comment #5) > I see. Interesting. I wonder if that is a bug in gold. I wonder what other I think this is related to the gold bug: http://sourceware.org/bugzilla/show_bug.cgi?id=15153 > ELF linkers do. On Linux, ld and gold set the standard.
[Bug libgcc/56460] _Unwind_Find_FDE is O(n) in the number of frame infos, (and LLVM's JIT will generate many of them)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460 Steven Bosscher changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug libgcc/56460] _Unwind_Find_FDE is O(n) in the number of frame infos, (and LLVM's JIT will generate many of them)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460 Steven Bosscher changed: What|Removed |Added CC|steven at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #6 from Steven Bosscher 2013-02-27 21:14:17 UTC --- Mine now.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-27 Ever Confirmed|0 |1
[Bug libgcc/56460] _Unwind_Find_FDE is O(n) in the number of frame infos, (and LLVM's JIT will generate many of them)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460 --- Comment #5 from stevenb.gcc at gmail dot com 2013-02-27 21:09:55 UTC --- > --- Comment #4 from Chris Reed 2013-02-27 12:15:52 > UTC --- > Yes, I'm happy to address the copyright issue - the copyright disclaimer route > seems simpler. I can take care of a patch along the lines of your idea. Working on it already. It's too late now for GCC 4.8 but I will attach the patch to this bug report when it's ready.
[Bug go/56431] -lpthread should be added to -lgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #5 from Ian Lance Taylor 2013-02-27 21:07:59 UTC --- I see. Interesting. I wonder if that is a bug in gold. I wonder what other ELF linkers do.
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #4 from Paolo Carlini 2013-02-27 20:24:30 UTC --- I agree. Care to send a patch for that?
[Bug tree-optimization/56476] ARM volatile writes/str creates superfluous and uncalled for read/ldr with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56476 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski 2013-02-27 19:46:16 UTC --- Already fixed for 4.7.3 and above. *** This bug has been marked as a duplicate of bug 56098 ***
[Bug middle-end/56098] [4.6 Regression] conditional write through volatile pointer produces unintended read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098 Andrew Pinski changed: What|Removed |Added CC||joff at embeddedarm dot com --- Comment #10 from Andrew Pinski 2013-02-27 19:46:16 UTC --- *** Bug 56476 has been marked as a duplicate of this bug. ***
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475
--- Comment #3 from Kai Tietz 2013-02-27 19:45:53
UTC ---
(In reply to comment #1)
> We had an AC_TRY_RUN test, but such kind of test give a lot of problems and we
> removed it. We had:
>
> AC_TRY_RUN([#include
> int main()
> {
> return !(fopen("/dev/random", "r")
> && fopen("/dev/urandom", "r"));
> }
> ],
> [ac_random_tr1=yes], [ac_random_tr1=no],
> [ac_random_tr1=no])
> ])
>
> Kai, can you suggest something working on MinGW and not using an AC_TRY_RUN?
> Or
> you can just special case MinGW. I have no way of testing such fixes, sorry.
Well, AC_TRY_RUN is for sure the wrong approach here. As such tests are
failing badly on cross-compilers.
I think sanest way to solve this is by special-casing mingw targets.
[Bug tree-optimization/56476] ARM volatile writes/str creates superfluous and uncalled for read/ldr with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56476 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Component|target |tree-optimization --- Comment #1 from Andrew Pinski 2013-02-27 19:41:43 UTC --- The tree pass CSElim is doing this for some reason. I think it forgot to check for volatileness.
[Bug go/56431] -lpthread should be added to -lgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431
--- Comment #4 from H.J. Lu 2013-02-27 19:36:07
UTC ---
(In reply to comment #3)
> Object OBJ has a weak reference to SYM.
>
> OBJ is linked against shared library S1. S1 does not define SYM.
>
> S1 happens to be linked against shared library S2. S2 does define SYM.
>
> That will work fine: at runtime OBJ will see that SYM is defined, because S1
> brings in S2.
>
This isn't what happens. Since gold doesn't check S2 at link-time, it
resolves SYM to 0:
[hjl@gnu-6 pr15149]$ cat foo.c
#include
extern int xxx () __attribute__((weak));
int
foo ()
{
if (&xxx)
return xxx ();
return 1;
}
int
main ()
{
printf ("xxx: %d\n", foo ());
return 0;
}
[hjl@gnu-6 pr15149]$ cat xxx.c
int
xxx ()
{
return 0;
}
[hjl@gnu-6 pr15149]$ cat yyy.c
/* Dummy */
[hjl@gnu-6 pr15149]$ make y
gcc -Wl,--no-copy-dt-needed-entries-c -o foo.o foo.c
gcc -Wl,--no-copy-dt-needed-entries -shared -fPIC -o libxxx.so xxx.c
gcc -Wl,--no-copy-dt-needed-entries -shared -fPIC -o libyyy.so yyy.c libxxx.so
-Wl,-rpath,.
gcc -Wl,--no-copy-dt-needed-entries -fuse-ld=gold -B./ -Wl,--no-as-needed -o y
foo.o libyyy.so -Wl,-rpath,.
[hjl@gnu-6 pr15149]$ ./y
xxx: 1
[hjl@gnu-6 pr15149]$
38: 0 NOTYPE WEAK DEFAULT UND xxx
If gold sees SYM defined in S2, it will create a R_X86_64_JUMP_SLO relocation,
set xxx value to the PLT entry and resolve xxx to the PLT entry.
00401ad0 00070007 R_X86_64_JUMP_SLO 00400570 xxx + 0
7: 00400570 0 FUNCWEAK DEFAULT UND xxx
That is the difference between seeing SYM in S2 or not.
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #2 from Karlson2k 2013-02-27 19:28:17 UTC --- Better to open random devices with "rb"? Or just 'stat' device?
[Bug c/56476] New: ARM volatile writes/str creates superfluous and uncalled for read/ldr with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56476
Bug #: 56476
Summary: ARM volatile writes/str creates superfluous and
uncalled for read/ldr with -Os
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@embeddedarm.com
Gcc 4.7.1 crosscompiler ARM EABI target, x86 Linux host.
In the below code, there are only writes to the "regs" volatile unsigned int *.
Yet, compiling with "-Os", "-O2", or "-O -ftree-vrp" yields code that will do
an uncalled for ldrne in the assembler output. This is bad as this volatile
unsigned int * represents hardware registers where bus reads have side-effects
and reading a value and then writing the same value back to the same location
is not an equivalent operation to doing nothing at all.
Several gcc versions have been tested and all but some really old 3.3.4 gcc
toolchain exhibited this. (4.6.1 and a 4.4.4 were tested also and had the bug)
//Jesse Off
volatile unsigned int * regs;
void test(void)
{
int i, x;
regs[0x708 / 4] = 0xdeadbeef;
for (i = 0xbad; i >= 0; i--) {
if (i == 1)
regs[0x708 / 4] = 0xbeefdead;
for (x = 1; x >= 0; x--) {
regs[0x708 / 4] = 0xbadcab;
regs[0x704 / 4] = x;
}
}
}
/*
BROKEN ASM (Compiled with -Os)
:
0: e59f3048ldr r3, [pc, #72] ; 50
4: e59f2048ldr r2, [pc, #72] ; 54
8: e5933000ldr r3, [r3]
c: e92d4010push{r4, lr}
10: e59f1040ldr r1, [pc, #64] ; 58
14: e5832708str r2, [r3, #1800] ; 0x708
18: e59f203cldr r2, [pc, #60] ; 5c
1c: e3a04001mov r4, #1
20: e3a0c000mov ip, #0
24: e3520001cmp r2, #1
28: 15930708ldrne r0, [r3, #1800] ; 0x708
^^^--- NOT SAFE!
2c: 059f002cldreq r0, [pc, #44] ; 60
30: e2522001subsr2, r2, #1
34: e5830708str r0, [r3, #1800] ; 0x708
38: e5831708str r1, [r3, #1800] ; 0x708
3c: e5834704str r4, [r3, #1796] ; 0x704
40: e5831708str r1, [r3, #1800] ; 0x708
44: e583c704str ip, [r3, #1796] ; 0x704
48: 2af5bcs 24
4c: e8bd8010pop {r4, pc}
50: .word 0x
54: deadbeef.word 0xdeadbeef
58: 00badcab.word 0x00badcab
5c: 0bad.word 0x0bad
60: beefdead.word 0xbeefdead
RIGHT AND WORKING (Compiled with -O) (no superfluous ldr on a volatile)
:
0: e52d4004push{r4}; (str r4, [sp, #-4]!)
4: e59f304cldr r3, [pc, #76] ; 58
8: e5933000ldr r3, [r3]
c: e59f2048ldr r2, [pc, #72] ; 5c
10: e5832708str r2, [r3, #1800] ; 0x708
14: e59f2044ldr r2, [pc, #68] ; 60
18: e59f1044ldr r1, [pc, #68] ; 64
1c: e3a0c001mov ip, #1
20: e3a0mov r0, #0
24: e59f403
[Bug c++/55340] Invalid maybe unitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55340 --- Comment #3 from Johnny Willemsen 2013-02-27 19:20:24 UTC --- Thanks for checking this, will also try 4.8.0 at some point. We have hundreds of tests using C++11 extensively and this was the only one exposing this warning. This is mostly generated code and I tried to reduce it further, but when I reduced it further the warning was gone. I didn't had a clue why it could be triggered, that lack of knowledge prevented me from reducing the test case further
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475
Paolo Carlini changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #1 from Paolo Carlini 2013-02-27
19:12:56 UTC ---
We had an AC_TRY_RUN test, but such kind of test give a lot of problems and we
removed it. We had:
AC_TRY_RUN([#include
int main()
{
return !(fopen("/dev/random", "r")
&& fopen("/dev/urandom", "r"));
}
],
[ac_random_tr1=yes], [ac_random_tr1=no],
[ac_random_tr1=no])
])
Kai, can you suggest something working on MinGW and not using an AC_TRY_RUN? Or
you can just special case MinGW. I have no way of testing such fixes, sorry.
[Bug libstdc++/56475] New: Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 Bug #: 56475 Summary: Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@narod.ru Host: mingw32 Target: mingw32, mingw32-w64 When building native compiler for MinGW/MinGW-w64 'configure' checks for /dev/random simply by if test -r /dev/random && test -r /dev/urandom; then glibcxx_cv_random_tr1=yes; else glibcxx_cv_random_tr1=no; fi Result of this test is incorrect at least for MinGW. MinGW shell is executed in MSYS subsystem, so those devices is available for shell, but MinGW compiled programs will have no access to /dev/random. For some other platforms situation can be the same (/dev/random available for shell, but not for compiled program). I suggest to do a real compile-link-execute test instead of weak shell emulation.
[Bug c++/55788] inlining failed in call to always_inline: mismatched arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55788 --- Comment #3 from Jakub Jelinek 2013-02-27 18:52:05 UTC --- Sounds like dup of PR52888. Richard, is that safely backportable, or not?
[Bug go/56431] -lpthread should be added to -lgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #3 from Ian Lance Taylor 2013-02-27 18:49:43 UTC --- Object OBJ has a weak reference to SYM. OBJ is linked against shared library S1. S1 does not define SYM. S1 happens to be linked against shared library S2. S2 does define SYM. That will work fine: at runtime OBJ will see that SYM is defined, because S1 brings in S2. Suppose that, later on, S1 is not linked against S2. That will also work fine: at runtime OBJ will see that SYM is not defined. Right now GNU ld is issuing a warning because it sees that the weak reference from OBJ will be defined at runtime by S2, brought in at runtime because S1 is linked against S2. GNU ld is suggesting that OBJ should be linked against S2 directly. But nothing will go wrong if S1 is changed such that it does not link against S2. Therefore, GNU ld's warning is inappropriate. There is no reason to link OBJ against S2 in this case.
[Bug c++/55813] Poorly named/documented option Wctor-dtor-privacy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55813 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-27 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2013-02-27 18:43:25 UTC --- Mine.
[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-27 Ever Confirmed|0 |1 --- Comment #5 from Dominique d'Humieres 2013-02-27 18:37:48 UTC --- Confirmed.
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617 Dominique d'Humieres changed: What|Removed |Added CC||stefano.borini at ferrara ||dot linux.it --- Comment #36 from Dominique d'Humieres 2013-02-27 18:18:38 UTC --- *** Bug 51286 has been marked as a duplicate of this bug. ***
[Bug fortran/51286] function with print statement hangs when called as argument of a print statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51286 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Dominique d'Humieres 2013-02-27 18:18:37 UTC --- > Aren't you using some Mac OSX? If so, it is a duplicate of pr30617. No answer, so closing as duplicate. *** This bug has been marked as a duplicate of bug 30617 ***
[Bug c++/56358] [C++11] Erroneous interaction of typedef and inherited constructor declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56358 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 --- Comment #4 from Jason Merrill 2013-02-27 18:15:02 UTC --- Fixed.
[Bug c++/56323] [C++11] cannot compile inherited constructor for typedef'ed base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56323 --- Comment #5 from Jason Merrill 2013-02-27 18:13:34 UTC --- Author: jason Date: Wed Feb 27 18:13:24 2013 New Revision: 196316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196316 Log: PR c++/56358 PR c++/56323 * name-lookup.c (do_class_using_decl): Use ctor_identifier instead of the base name for inheriting ctors. (push_class_level_binding_1): Remove inheriting ctor handling. * pt.c (tsubst_decl) [USING_DECL]: Likewise. * class.c (add_implicitly_declared_members): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/inherit/using5.C trunk/gcc/testsuite/g++.old-deja/g++.other/using3.C
[Bug c++/56358] [C++11] Erroneous interaction of typedef and inherited constructor declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56358 --- Comment #3 from Jason Merrill 2013-02-27 18:13:36 UTC --- Author: jason Date: Wed Feb 27 18:13:24 2013 New Revision: 196316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196316 Log: PR c++/56358 PR c++/56323 * name-lookup.c (do_class_using_decl): Use ctor_identifier instead of the base name for inheriting ctors. (push_class_level_binding_1): Remove inheriting ctor handling. * pt.c (tsubst_decl) [USING_DECL]: Likewise. * class.c (add_implicitly_declared_members): Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/g++.dg/inherit/using5.C trunk/gcc/testsuite/g++.old-deja/g++.other/using3.C
[Bug target/56473] Cross Compile Ubuntu x86_64 to Raspberry Pi Code Seg Faults When Executed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56473 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #2 from Andrew Pinski 2013-02-27 18:13:00 UTC --- Have you tried running gdb on it to see why it is segfaulting? It sounds like you are using maybe an incompatible ABI.
[Bug c++/17232] classes and class template specializations treated differently w.r.t. core issue #337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17232 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Known to fail||
[Bug c++/55788] inlining failed in call to always_inline: mismatched arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55788 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-27 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2013-02-27 18:01:57 UTC --- I can confirm that mainline is fine. Shall we close this?
[Bug ada/56474] New: GNAT computes size of the object to be allocated incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 Bug #: 56474 Summary: GNAT computes size of the object to be allocated incorrectly Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: pa...@zhukoff.net 100% reproducible Smaller reproducer: with Ada.Streams; package Pkg is use type Ada.Streams.Stream_Element_Offset; type Vector (Size : Ada.Streams.Stream_Element_Offset) is record Value : Ada.Streams.Stream_Element_Array (0 .. Size); end record; Empty_Vector : Vector (-1); end Pkg; with Pkg; procedure Bbb is begin null; end Bbb; $ gnatmake bbb gcc -c bbb.adb gcc -c pkg.ads pkg.ads:10:04: warning: "Storage_Error" will be raised at run time gnatbind -x bbb.ali gnatlink bbb.ali $ ./bbb raised STORAGE_ERROR : object too large
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #8 from Jakub Jelinek 2013-02-27 17:25:10 UTC --- Some more patches have been posted to gcc-patches and I'm going to post even more. There are two issues I don't have a solution for if anybody is interested. Testcase: cd gcc/testsuite/gcc.dg/vect valgrind --leak-check=full /usr/src/gcc/obj/gcc/cc1 -O3 -mavx -ftree-vectorize \ -isystem /usr/src/gcc/obj/gcc/include/ -quiet -o slp-reduc-6.c ==4841== 368 bytes in 2 blocks are definitely lost in loss record 533 of 626 ==4841==at 0x4A06B0F: calloc (vg_replace_malloc.c:593) ==4841==by 0x111D788: xcalloc (xmalloc.c:162) ==4841==by 0xC4742D: new_stmt_vec_info(gimple_statement_d*, _loop_vec_info*, _bb_vec_info*) (tree-vect-stmts.c:5930) ==4841==by 0xC5452B: vect_create_epilog_for_reduction(vec, gimple_statement_d*, int, tree_code, vec, int, bool, _slp_tree*) (tree-vect-loop.c:3867) ==4841==by 0xC57FDB: vectorizable_reduction(gimple_statement_d*, gimple_stmt_iterator*, gimple_statement_d**, _slp_tree*) (tree-vect-loop.c:5209) ==4841==by 0xC470D1: vect_transform_stmt(gimple_statement_d*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) (tree-vect-stmts.c:5823) ==4841==by 0xC594F1: vect_transform_loop(_loop_vec_info*) (tree-vect-loop.c:5736) ==4841==by 0xC6B249: vectorize_loops() (tree-vectorizer.c:123) ==4841==by 0xB91101: tree_vectorize() (tree-ssa-loop.c:222) ==4841==by 0x963835: execute_one_pass(opt_pass*) (passes.c:2330) ==4841==by 0x963A29: execute_pass_list(opt_pass*) (passes.c:2378) ==4841==by 0x963A5A: execute_pass_list(opt_pass*) (passes.c:2379) ==4841== ==4841== 13,678 bytes in 1 blocks are definitely lost in loss record 619 of 626 ==4841==at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==4841==by 0x111D747: xmalloc (xmalloc.c:147) ==4841==by 0x10E6CD4: read_file(cpp_reader*, _cpp_file*) (files.c:693) ==4841==by 0x10E787A: _cpp_stack_file (files.c:794) ==4841==by 0x10DF510: do_include_common(cpp_reader*, include_type) (directives.c:793) ==4841==by 0x10E0320: _cpp_handle_directive (directives.c:492) ==4841==by 0x10ECC6C: _cpp_lex_token (lex.c:1990) ==4841==by 0x10F1967: cpp_get_token_1(cpp_reader*, unsigned int*) (macro.c:2355) ==4841==by 0x5CE3AA: c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) (c-lex.c:300) ==4841==by 0x568908: c_lex_one_token(c_parser*, c_token*) (c-parser.c:218) ==4841==by 0x568D07: c_parser_peek_token(c_parser*) (c-parser.c:398) ==4841==by 0x568D32: c_parser_next_token_is(c_parser*, cpp_ttype) (c-parser.c:410)
[Bug go/56431] -lpthread should be added to -lgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #2 from H.J. Lu 2013-02-27 16:59:17 UTC --- The new GNU ld is complaining about an undefined weak reference because it sees libpthread.so from DT_NEEDED in libgo.so. The old GNU ld just silently adds libpthread.so from DT_NEEDED in libgo.so. When creating executables, GNU ld checks DT_NEEDED in DSOes on command line. Since libpthread.so is included from libgo.so for creating executables, it expects libpthread.so will be used and pthread_sigmask is defined at run-time
[Bug lto/55493] [4.8 Regression] LTO always ICEs on native i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55493 Fanael changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #11 from Fanael 2013-02-27 16:39:56 UTC --- Revision 196313 appears to work.
[Bug c++/50939] [C++0x] lambda expression causes ICE when lambda captures const variable and odr-uses the variable in function templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50939 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.3, 4.8.0 Resolution||FIXED --- Comment #1 from Paolo Carlini 2013-02-27 16:29:07 UTC --- This is fixed mainline and 4.7.3.
[Bug c++/55135] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Paolo Carlini changed: What|Removed |Added Status|WAITING |UNCONFIRMED CC||stevenb.gcc at gmail dot ||com Ever Confirmed|1 |0 --- Comment #8 from Paolo Carlini 2013-02-27 16:20:47 UTC --- I can't reproduce the crash either. I'm not sure if we should keep the PR open as regards compile-time performance issues (or we have already a similar testcase in Bugzilla?) Steven?
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|jamborm at gcc dot gnu.org |unassigned at gcc dot
||gnu.org
--- Comment #11 from Martin Jambor 2013-02-27
16:11:02 UTC ---
OK, patch http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01233.html
fixes the testcase from comment #7 and patch
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01235.html should avoid
some further (although apparently not that crucial) differences in SRA
-g and -g0 output. Unfortunately, they do not fix the debug
comparison failure from comment #9.
The problematic difference is:
--- testcase.gkd2013-02-27 16:25:54.036565436 +0100
+++ testcase.gk.gkd 2013-02-27 16:25:54.185565083 +0100
@@ -140,3 +140,3 @@
(insn:TI# 0 0 5 (set (reg/f:DI 6 bp [orig:62 D. ] [62])
-(mem/f:DI (const_int 0 [0]) [ *control_var_27(D)+0 S8 A64]))
testcase.ii:166# {*movdi_internal_rex64}
+(mem/f:DI (const_int 0 [0]) [ *control_var_28(D)+0 S8 A64]))
testcase.ii:166# {*movdi_internal_rex64}
(nil))
and appears for the first time in release_ssa pass. It seems to me
that (right after early SRA), two SSA names simply have a different
order in -g0 and -g compilations:
-SSA_NAME 63: elim_cost$complexity_63
- DEF: elim_cost$complexity_63 = PHI
+SSA_NAME 63: cost$cost_63
+ DEF: cost$cost_63 = PHI
-SSA_NAME 71: cost$cost_71
- DEF: cost$cost_71 = PHI
+SSA_NAME 71: elim_cost$complexity_71
+ DEF: elim_cost$complexity_71 = PHI
Also, if I just do not produce DEBUG statements with
elim_cost$complexity on the RHS, the problem goes away. However, I do
not anything wrong with the statements. Later, just before
release_ssa, three SSA names have different order:
-SSA_NAME 67: .MEM_67
- DEF: comp ={v} {CLOBBER};
+SSA_NAME 63: cost$cost_63
+ DEF: cost$cost_63 = PHI
-SSA_NAME 70: control_var_70(D)
- DEF: GIMPLE_NOP
+SSA_NAME 67: .MEM_67
+ DEF: comp ={v} {CLOBBER};
-SSA_NAME 71: cost$cost_71
- DEF: cost$cost_71 = PHI
+SSA_NAME 70: control_var_70(D)
+ DEF: GIMPLE_NOP
...and control_var manages to leak to the final dump, causing the
failure.
I'll return to this bug in a few days, but now I need a break from it,
so I'm un-assigning myself.
[Bug c++/55170] incorrect mangling, should not include prefix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55170 --- Comment #2 from Paolo Carlini 2013-02-27 16:07:16 UTC --- Jason, did you notice this issue?
[Bug c++/55340] Invalid maybe unitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55340 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Paolo Carlini 2013-02-27 16:03:22 UTC --- Mainline (would be 4.8.0) is fine and I can't even compile the testcase with 4_6-branch, thus this isn't a regression. In the future, please do your best to reduce the size of your testcase: in 99.999 % of the cases, 2-3 KB are enough.
[Bug fortran/51993] Erroneous type component initialization leads to internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51993 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-27 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2013-02-27 15:56:31 UTC --- It affects also 4.8.
[Bug c/56473] Cross Compile Ubuntu x86_64 to Raspberry Pi Code Seg Faults When Executed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56473 --- Comment #1 from Jonathan Wakely 2013-02-27 15:41:34 UTC --- If these files come form an Ubuntu package then it should be reported to Ubuntu
[Bug c/56473] New: Cross Compile Ubuntu x86_64 to Raspberry Pi Code Seg Faults When Executed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56473
Bug #: 56473
Summary: Cross Compile Ubuntu x86_64 to Raspberry Pi Code Seg
Faults When Executed
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tomd...@speakeasy.org
Created attachment 29548
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29548
Script of the compile/link
I compiled and linked on Ubuntu x86_64 for the Raspberry Pi.
The compiler/linker completed with no errors.
int main() { return 0;}
When hello is executed on Raspberry Pi, I got a Segmentation fault.
If I compile on Ubuntu with -nostdlib and explicitly list the Raspberry Pi
crtxxx.o files and the Raspberry Pi libs, the resultant executable completes
without error on Raspberry Pi.
I attached a script of the compile actions on Ubuntu.
I believe this to be a problem with the crt.o files and the libs
distributed with arm-linux-gnueabihf-gcc-4.6 package.
The same package on Raspberry Pi works Ok.
On Ubuntu
> uname -a
Linux P9X79 3.2.0-38-generic #60-Ubuntu SMP Wed Feb 13 13:22:43 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
On Raspberry Pi
> uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l
GNU/Linux
[Bug go/56431] -lpthread should be added to -lgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56431 --- Comment #1 from Ian Lance Taylor 2013-02-27 14:54:22 UTC --- The reference to pthread_sigmask in generic-morestack.c is weak, and the code handles the weak reference correctly. It looks like gold is doing the right thing by emitting a weak reference. I don't understand why GNU ld is complaining about an undefined weak reference. As far as I can see, this is a GNU ld bug; it should be testing h->ref_regular_nonweak in the code that issues this "is defined in DSO" warning.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #7 from Jakub Jelinek 2013-02-27 14:01:20 UTC --- Author: jakub Date: Wed Feb 27 14:01:08 2013 New Revision: 196313 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196313 Log: PR middle-end/56461 * tree-flow.h (edge_var_map_vector): Change into va_heap, vl_embed vector. * tree-ssa.c (redirect_edge_var_map_add): Use vec_safe_reserve and vec_safe_push, always update *slot. (redirect_edge_var_map_clear): Use vec_free. (redirect_edge_var_map_dup): Use vec_safe_copy and vec_safe_reserve. (free_var_map_entry): Use vec_free. * tree-cfgcleanup.c (remove_forwarder_block_with_phi): Use FOR_EACH_VEC_SAFE_ELT instead of FOR_EACH_VEC_ELT. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfgcleanup.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa.c
[Bug fortran/50537] explicit interface required (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537 Tobias Burnus changed: What|Removed |Added Keywords||accepts-invalid CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2013-02-27 14:00:57 UTC --- For reference, Fortran 2008, "12.4.2.2 Explicit interface": "A procedure other than a statement function shall have an explicit interface if it is referenced and [...] "(3) the procedure has a result that [...] "(c) has a nonassumed type parameter value that is not a constant expression," (Side note: As it is not a constraint, a compiler is not required to diagnose it. However, as it can detect it in this case, it should.)
[Bug fortran/56459] Wrongly rejects "TYPE(CHARACTER*1,)" (with comma)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56459 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2013-02-27 13:54:37 UTC --- Note: This might get fixed via an interpretation request, cf. http://mailman.j3-fortran.org/pipermail/j3/2013-February/006161.html
[Bug c++/55786] g++ segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55786 Paolo Carlini changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-02-27 Ever Confirmed|0 |1
[Bug c++/55737] Template and the constant, short-form if-then-else condition issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55737 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Paolo Carlini 2013-02-27 13:05:53 UTC --- Closing.
[Bug c++/55773] C++ class object destructors are not called which a static class object in destructor function in a shared library after dlclose is called.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55773 --- Comment #3 from Paolo Carlini 2013-02-27 13:03:24 UTC --- You didn't provide any detail about your system. See: http://gcc.gnu.org/bugs/#report On a modern x86_64-linux system the problem cannot be reproduced with current gcc-4_4, 4_5, 4_6, 4_7, neither in mainline.
[Bug fortran/53521] [4.5/4.6/4.7/4.8 Regression] Memory leak with zero-sized array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521 Dominique d'Humieres changed: What|Removed |Added CC||xarthisius.kk at gmail dot ||com --- Comment #15 from Dominique d'Humieres 2013-02-27 12:44:31 UTC --- *** Bug 49241 has been marked as a duplicate of this bug. ***
[Bug fortran/49241] memory leak with lhs realloc of zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49241 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #5 from Dominique d'Humieres 2013-02-27 12:44:30 UTC --- Fixed by revision 188062 and branches: 4.5, 4.6 and 4.7. *** This bug has been marked as a duplicate of bug 53521 ***
[Bug libgcc/56460] _Unwind_Find_FDE is O(n) in the number of frame infos, (and LLVM's JIT will generate many of them)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56460 --- Comment #4 from Chris Reed 2013-02-27 12:15:52 UTC --- Yes, I'm happy to address the copyright issue - the copyright disclaimer route seems simpler. qsort'ing the entire array was more for simplicity - I was more concerned by the performance of throwing a lot of exceptions than the one time cost of sorting the array (and I expect an ever changing number of registrations would be unusual). The sort order was changed simply because it matched the bsearch algorithm used elsewhere and seemed more intuitive. I considered a binary tree; a sorted array was just simpler to implement.
[Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
Summary|Program crashes when|Program crashes when
|allocating a derived type |allocating a derived type
|with a character|with an allocatable
|allocatable array |component
|component. |
--- Comment #1 from janus at gcc dot gnu.org 2013-02-27 11:55:37 UTC ---
Reduced test case:
program main
implicit none
type :: containerType
real, dimension(1000) :: arrayData
integer, allocatable :: allo
end type
type (containerType),allocatable :: container
allocate(container)
end program
Note: The allocatable component does not have to be CHARACTER, but the array
needs to be very large in order to trigger the error. The generated code is:
container = 0B;
if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (container !=
0B), 0))
{
_gfortran_runtime_error_at (...);
}
else
{
container = (struct containertype *) __builtin_malloc (4008);
if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (container
== 0B), 0))
{
_gfortran_os_error (...);
}
}
container->allo = 0B;
{
struct containertype containertype.0;
if (container != 0B) goto L.1;
container = (struct containertype *) __builtin_calloc (1, 4008);
L.1:;
containertype.0.allo = 0B;
*container = containertype.0;
}
I don't really understand why 'container' is being allocated twice: Once with
__builtin_malloc and once with __builtin_calloc. Looks like we're leaking
memory here.
Valgrind reports:
==28612== Warning: client switching stacks? SP change: 0x7fefffbe0 -->
0x7fc9da1d0
==28612== to suppress, use: --max-stackframe=4016 or greater
==28612== Invalid write of size 8
==28612==at 0x4008E5: MAIN__ (in /home/jweil/GSoC/PRs/56471/a.out)
==28612==by 0x4009D2: main (in /home/jweil/GSoC/PRs/56471/a.out)
==28612== Address 0x7fc9da1c8 is on thread 1's stack
==28612==
==28612== Can't extend stack to 0x7fc9d95e0 during signal delivery for thread
1:
==28612== no stack segment
==28612==
==28612== Process terminating with default action of signal 11 (SIGSEGV)
==28612== Access not within mapped region at address 0x7FC9D95E0
==28612==at 0x4008E5: MAIN__ (in /home/jweil/GSoC/PRs/56471/a.out)
==28612== If you believe this happened as a result of a stack
==28612== overflow in your program's main thread (unlikely but
==28612== possible), you can try to increase the size of the
==28612== main thread stack using the --main-stacksize= flag.
==28612== The main thread stack size used in this run was 8388608.
Indeed the segfault seems to be due to a stack overflow.
[Bug rtl-optimization/56466] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1629 (loop with header n not in loop tree !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56466 Marek Polacek changed: What|Removed |Added Component|tree-optimization |rtl-optimization --- Comment #5 from Marek Polacek 2013-02-27 11:41:24 UTC --- Thanks, I'm testing a fix for that. Also changing the component, we're really on the RTL level here.
[Bug other/56472] New: vcondu undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56472 Bug #: 56472 Summary: vcondu undocumented Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: pa...@matos-sorge.com vcondu pattern is undocumented at: http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gccint/Standard-Names.html
[Bug fortran/53310] [4.5/4.6/4.7/4.8 Regression] EOSHIFT leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53310 Dominique d'Humieres changed: What|Removed |Added CC||herve.manche at libertysurf ||dot fr --- Comment #8 from Dominique d'Humieres 2013-02-27 11:09:50 UTC --- *** Bug 51487 has been marked as a duplicate of this bug. ***
[Bug fortran/51487] leak memory with eoshift(..,...,boundary)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51487 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Dominique d'Humieres 2013-02-27 11:09:50 UTC --- This appears to be a duplicate of pr53310 fixed on trunk at revision 187395 and backported to 4.5-4.7. *** This bug has been marked as a duplicate of bug 53310 ***
[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242 Paolo Carlini changed: What|Removed |Added CC|jason at gcc dot gnu.org| --- Comment #26 from Paolo Carlini 2013-02-27 10:32:49 UTC --- Note: I'm keeping this open because we may want to do something about the warning: http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00786.html
[Bug c++/54383] Internal compiler error for lamba function using this-> with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383 Paolo Carlini changed: What|Removed |Added CC|jason at gcc dot gnu.org| --- Comment #4 from Paolo Carlini 2013-02-27 10:26:29 UTC --- Jason, I see you are already working on this one: please double check that PR56464 is an exact duplicate. Thanks!
[Bug c++/54383] Internal compiler error for lamba function using this-> with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383 Paolo Carlini changed: What|Removed |Added CC||ogoffart at kde dot org --- Comment #3 from Paolo Carlini 2013-02-27 10:24:21 UTC --- *** Bug 56464 has been marked as a duplicate of this bug. ***
[Bug c++/56464] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 --- Comment #3 from Paolo Carlini 2013-02-27 10:24:21 UTC --- *** This bug has been marked as a duplicate of bug 54383 ***
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 Paolo Carlini changed: What|Removed |Added CC||ogoffart at kde dot org --- Comment #18 from Paolo Carlini 2013-02-27 10:21:37 UTC --- *** Bug 56464 has been marked as a duplicate of this bug. ***
[Bug c++/56464] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini 2013-02-27 10:21:37 UTC --- Right now we don't have that many left, but this one is a Dup of PR54383. *** This bug has been marked as a duplicate of bug 53383 ***
[Bug fortran/56471] New: Program crashes when allocating a derived type with a character allocatable array component.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471 Bug #: 56471 Summary: Program crashes when allocating a derived type with a character allocatable array component. Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: vladimir.f...@gmail.com Created attachment 29547 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29547 reproduction source file The attached program crashes when executing the allocate statement. Originally reported in http://stackoverflow.com/questions/15107976/why-does-the-following-fortran-code-allocate-on-the-stack-heap-depending-on-the gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3 Driving: gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8-20130224/configure --enable-languages=c,c++,fortran --with-cloog --prefix=/usr/local/gcc-4.8 Thread model: posix gcc version 4.8.0 20130224 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 allocate.f90 -quiet -dumpbase allocate.f90 -mtune=generic -march=x86-64 -auxbase allocate -g -gdwarf-3 -version -fcheck=all -fbacktrace -fintrinsic-modules-path /usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/finclude -o /tmp/cc6wTJXo.s GNU Fortran (GCC) version 4.8.0 20130224 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20130224 (experimental), GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.8.0 20130224 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.0 20130224 (experimental), GMP version 5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o /tmp/ccSfTbSl.o /tmp/cc6wTJXo.s GNU assembler version 2.22 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 12.2) 2.22 Reading specs from /usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/:/opt/intel/composer_xe_2013.1.117/ipp/../compiler/lib/intel64/:/opt/intel/composer_xe_2013.1.117/ipp/lib/intel64/:/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/:/opt/intel/composer_xe_2013.1.117/mkl/lib/intel64/:/opt/intel/composer_xe_2013.1.117/tbb/lib/intel64/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbegin.o -L/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0 -L/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64 -L/opt/intel/composer_xe_2013.1.117/ipp/../compiler/lib/intel64 -L/opt/intel/composer_xe_2013.1.117/ipp/lib/intel64 -L/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64 -L/opt/intel/composer_xe_2013.1.117/mkl/lib/intel64 -L/opt/intel/composer_xe_2013.1.117/tbb/lib/intel64 -L/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../.. /tmp/ccSfTbSl.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/crtend.o /usr/lib/../lib64/crtn.o :~/f/errors> ./a.out Neoprávněný přístup do paměti (SIGSEGV)
[Bug c++/56462] Simple use of auto in template function causes internal error in type_unification_real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56462 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #2 from Paolo Carlini 2013-02-27 09:52:35 UTC --- I guess we can safely close it then.
[Bug target/56446] [4.6/4.7/4.8 Regression] Generate one fewer relocation when calling a checked weakref function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P2 Component|tree-optimization |target
[Bug bootstrap/56424] [4.8 Regression] ICE at tree-inline.c:2833 on a-nllcef.ads at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/56466] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1629 (loop with header n not in loop tree !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56466
--- Comment #4 from Richard Biener 2013-02-27
09:40:09 UTC ---
RTL unrolling does excessive manual verify_loop_structure calls. I suppose
we can either add an argument to verify_loop_structure to say whether to
check only existing loops or remove the checking, or make sure to fixup
loops.
For sure checking the whole loop tree after processing one innermost loop
is excessive:
/* Depending on FLAGS, check whether to peel loops completely and do so. */
static void
peel_loops_completely (int flags)
{
struct loop *loop;
loop_iterator li;
/* Scan the loops, the inner ones first. */
FOR_EACH_LOOP (li, loop, LI_FROM_INNERMOST)
{
...
if (loop->lpt_decision.decision == LPT_PEEL_COMPLETELY)
{
report_unroll_peel (loop, locus);
peel_loop_completely (loop);
#ifdef ENABLE_CHECKING
verify_loop_structure ();
#endif
}
}
I'd have a changed flag and do a single
if (changed)
fix_loop_structure (NULL);
which also does the verification at the end. Same applies to the loop
in the caller.
[Bug target/56470] New: [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470
Bug #: 56470
Summary: [4.8 Regression] ICE output_operand: invalid shift
operand
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: arm
int w[5];
void
foo (int x, unsigned y)
{
long long r = 0;
long long s;
int i;
switch (x)
{
case 1:
for (i = 0; i < 4; i++)
{
if (!y)
s = (w[9] << (10 - 2 * i)) >> (32 - 5 * i + 5 * i);
r |= (s & 0x) << (i * 5);
}
break;
case 3:
r = w[x] >> y;
}
w[x] = r;
}
ICEs at -O2 on arm-linux-gnuabi. This reduced testcase ICEs also in 4.7, but
the unreduced one at https://bugzilla.redhat.com/show_bug.cgi?id=915830#c1
only ICEs in 4.8 and not in 4.7.
I wonder why arm backend uses constraints (N) to enfore the shift count in the
range, rather than e.g. masking the operand & 31 if CONST_INT before printing.
Shift counts >= 32 for SImode are of course undefined behavior, so it really
doesn't matter what gets emitted, but we shouldn't ICE on it.
[Bug libstdc++/56468] Clang exposes bug with unexpected forward-declaration of type_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56468 --- Comment #3 from Jonathan Wakely 2013-02-27 09:33:27 UTC --- It's because of the implicit declaration of std::type_info, G++ correctly diagnoses similar cases with altered namespace names or type names, it only happens for std::type_info. I see no harm in adding an explicit declaration to the libstdc++ header so it works with clang and other compilers that don't declare std::type_info automatically.
[Bug fortran/50190] linkpk bench of polyhedron fails during validation with gcc trunk when it is compiled with -Ofast on amd64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50190 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #3 from Richard Biener 2013-02-27 09:32:48 UTC --- wontfix.
[Bug middle-end/45472] [4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472 Andrey Belevantsev changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] |[Middle-end volatile|[Middle-end volatile |semantics] ICE: in |semantics] ICE: in |move_op_ascend, at |move_op_ascend, at |sel-sched.c:6124 with |sel-sched.c:6124 with |-fselective-scheduling2 |-fselective-scheduling2 --- Comment #28 from Andrey Belevantsev 2013-02-27 09:04:31 UTC --- Fixed on trunk.
[Bug middle-end/45472] [4.6/4.7/4.8 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472 --- Comment #27 from Andrey Belevantsev 2013-02-27 08:56:15 UTC --- Author: abel Date: Wed Feb 27 08:56:08 2013 New Revision: 196308 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196308 Log: PR middle-end/45472 gcc/ * sel-sched-ir.c (merge_expr): Also change vinsn of merged expr when the may_trap_p bit of the exprs being merged differs. Reorder tests for speculativeness in the logical and operator. testsuite/ * gcc.dg/45472.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45472.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug c/56463] infinite loop when having integer overflow in a simple accumulator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463 --- Comment #5 from Cristóbal Camarero 2013-02-27 08:19:04 UTC --- Dominique, I think the test I found is more problematic than yours. Since in mine, the huge value is completely independent of the ending condition. Hence most people would expect the loop to end without care of what happens to the accumulator variable 'a'. Exploring the intermediate steps of my test (with gcc test.c -O2 -fdump-tree-all) I see that in test.c.119t.ivopts the condition of the loop is changed from 'ivtmp.8_3 != 0' to 'a_25 != 1267128320', which would be correct considering overflow. From here the situation must be similar to Dominique's examples. In test.c.123t.vrp2 we see that the Value Range Propagation has decided that the ending condition never happens, probably because the ranges have no modular considerations. The ending condition and the printf are eliminated. In a later stage the infinite loop is substituted by an empty infinite loop. I suppose that this is not technically a bug. However, the lack of warning IS a bug. And a coherent behaviour would still being a good enhancement.
