BUG gcc 4.6.2 Illegal Instruction (core dumped)
hello i found some bug gcc 4.6.2 when i build asterisk 1.8 All started when i want build ipsec-0.8.0 http://sourceforge.net/projects/ipsec-tools/files/ipsec-tools/0.8.0/ I had a simple linux PC with installed OS Linux CentOS 6.2 CentOS 6.2 have a rpm installed gcc version 4.4.6-3 with configure parameters --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux when i try build this program i have a some errors. Solving this errors i replaced gcc version more then 4.4. I download version 4.6.2 and build gcc 4.6.2 in native mode with configure parameters like this --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux and like this --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux i install gcc 4.6.2 (with cloog and ppl) i successful build ipsec 0.8.0. The program ipsec successful work. After that i tried build asterisk version 1.8.9.2 The program successful build but when program start is crush with next error --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL (core dumped) +++ Illegal Instruction (core dumped) after that i install gcc 4.6.2 (without cloog and ppl) and rebuild asterisk version 1.8.9.2 The program successful build but when program start is crush with next error --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL (core dumped) +++ Illegal Instruction (core dumped) i tried rebuild gcc with any configure parameters, but asterisk does not start okey i get oldest version gcc 4.5.3 and build him with next parameters --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux after that i install gcc version 4.5.3 (without cloog and ppl) and rebuild asterisk version 1.8.9.2 The program successful build and program successful start without any errors after that i rebuild ipsec 0.8.0. The program ipsec successful work. -- View this message in context: http://old.nabble.com/BUG-gcc-4.6.2-Illegal-Instruction-%28core-dumped%29-tp33405023p33405023.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c/52410] New: BUG gcc 4.6.2 Illegal Instruction (core dumped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52410 Bug #: 52410 Summary: BUG gcc 4.6.2 Illegal Instruction (core dumped) Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: evrin...@gmail.com hello i found some bug gcc 4.6.2 when i build asterisk 1.8 All started when i want build ipsec-0.8.0 http://sourceforge.net/projects/ipsec-tools/files/ipsec-tools/0.8.0/ I had a simple linux PC with installed OS Linux CentOS 6.2 CentOS 6.2 have a rpm installed gcc version 4.4.6-3 with configure parameters --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux when i try build this program i have a some errors. Solving this errors i replaced gcc version more then 4.4. I download version 4.6.2 and build gcc 4.6.2 in native mode with configure parameters like this --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux and like this --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux i install gcc 4.6.2 (with cloog and ppl) i successful build ipsec 0.8.0. The program ipsec successful work. After that i tried build asterisk version 1.8.9.2 The program successful build but when program start is crush with next error --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL (core dumped) +++ Illegal Instruction (core dumped) after that i install gcc 4.6.2 (without cloog and ppl) and rebuild asterisk version 1.8.9.2 The program successful build but when program start is crush with next error --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL (core dumped) +++ Illegal Instruction (core dumped) i tried rebuild gcc with any configure parameters, but asterisk does not start okey i get oldest version gcc 4.5.3 and build him with next parameters --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux after that i install gcc version 4.5.3 (without cloog and ppl) and rebuild asterisk version 1.8.9.2 The program successful build and program successful start without any errors after that i rebuild ipsec 0.8.0. The program ipsec successful work.
[Bug c/52411] New: BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 Bug #: 52411 Summary: BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: evrin...@gmail.com hello i found some bug gcc 4.6.2 when i build asterisk 1.8 All started when i want build ipsec-0.8.0 http://sourceforge.net/projects/ipsec-tools/files/ipsec-tools/0.8.0/ I had a simple linux PC with installed OS Linux CentOS 6.2 CentOS 6.2 have a rpm installed gcc version 4.4.6-3 with configure parameters --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux when i try build this program i have a some errors. Solving this errors i replaced gcc version more then 4.4. I download version 4.6.2 and build gcc 4.6.2 in native mode with configure parameters like this --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux and like this --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux i install gcc 4.6.2 (with cloog and ppl) i successful build ipsec 0.8.0. The program ipsec successful work. After that i tried build asterisk version 1.8.9.2 The program successful build but when program start is crush with next error --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL (core dumped) +++ Illegal Instruction (core dumped) after that i install gcc 4.6.2 (without cloog and ppl) and rebuild asterisk version 1.8.9.2 The program successful build but when program start is crush with next error --- SIGILL (Illegal instruction) @ 0 (0) --- +++ killed by SIGILL (core dumped) +++ Illegal Instruction (core dumped) i tried rebuild gcc with any configure parameters, but asterisk does not start okey i get oldest version gcc 4.5.3 and build him with next parameters --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux after that i install gcc version 4.5.3 (without cloog and ppl) and rebuild asterisk version 1.8.9.2 The program successful build and program successful start without any errors after that i rebuild ipsec 0.8.0. The program ipsec successful work.
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468 --- Comment #8 from Oleg Endo 2012-02-28 08:41:28 UTC --- Created attachment 26768 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26768 Patch to add DImode abs The attached patch adds DImode abs and did not introduce new failures when tested against rev 184589. I'm a bit confused, as this is exactly the same code as I used before to add DImode abs, and before it was failing in some cases. Either there was another bug that got fixed in the middle-end optimizers, or this is just coincidence. I've seen that other expanders use force_reg to make sure that operands will be in regs ... would that be the safer way of doing it?
[Bug target/49868] Implement named address space to place/access data in flash memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868 --- Comment #16 from Georg-Johann Lay 2012-02-28 08:44:14 UTC --- Author: gjl Date: Tue Feb 28 08:44:08 2012 New Revision: 184614 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184614 Log: PR target/49868 PR target/52261 * doc/extend.texi (AVR Named Address Spaces): No more try to fix address spaces located outside of device flash. * config/avr/avr.h (base_arch_s): Remove field n_segments. (mcu_type_s): Add field n_flash. * config/avr/avr-devices.c (avr_arch_types): Remove .n_segments. Set .have_elpm and .have_elpmx to 1 for avrxmega4 and avrxmega5. (AVR_MCU): Add N_FLASH argument. * config/avr/avr-mcus.def (AVR_MCU): Add initializer for .n_flash. * config/avr/avr-c.c (avr_cpu_cpp_builtins): Only define built-in macro __FLASH if that address space makes sense for the device. * config/avr/avr.c (avr_out_lpm): Don't try to fix address spaces outside of target flash. (avr_asm_named_section): Ditto. (avr_asm_select_section): Ditto. (avr_addr_space_convert): Ditto. (avr_emit_movmemhi): Ditto. (avr_nonconst_pointer_addrspace, avr_pgm_check_var_decl): Error if address space is outside of device flash. (avr_insert_attributes): Ditto. (avr_xload_libgcc_p): Use avr_current_device->n_flash instead of avr_current_arch->n_segments. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-devices.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/doc/extend.texi
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 --- Comment #8 from Georg-Johann Lay 2012-02-28 08:44:15 UTC --- Author: gjl Date: Tue Feb 28 08:44:08 2012 New Revision: 184614 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184614 Log: PR target/49868 PR target/52261 * doc/extend.texi (AVR Named Address Spaces): No more try to fix address spaces located outside of device flash. * config/avr/avr.h (base_arch_s): Remove field n_segments. (mcu_type_s): Add field n_flash. * config/avr/avr-devices.c (avr_arch_types): Remove .n_segments. Set .have_elpm and .have_elpmx to 1 for avrxmega4 and avrxmega5. (AVR_MCU): Add N_FLASH argument. * config/avr/avr-mcus.def (AVR_MCU): Add initializer for .n_flash. * config/avr/avr-c.c (avr_cpu_cpp_builtins): Only define built-in macro __FLASH if that address space makes sense for the device. * config/avr/avr.c (avr_out_lpm): Don't try to fix address spaces outside of target flash. (avr_asm_named_section): Ditto. (avr_asm_select_section): Ditto. (avr_addr_space_convert): Ditto. (avr_emit_movmemhi): Ditto. (avr_nonconst_pointer_addrspace, avr_pgm_check_var_decl): Error if address space is outside of device flash. (avr_insert_attributes): Ditto. (avr_xload_libgcc_p): Use avr_current_device->n_flash instead of avr_current_arch->n_segments. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-c.c trunk/gcc/config/avr/avr-devices.c trunk/gcc/config/avr/avr-mcus.def trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/doc/extend.texi
[Bug rtl-optimization/52148] [4.7 regression] ICE: in spill_failure, at reload1.c:2120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52148 --- Comment #3 from Georg-Johann Lay 2012-02-28 08:51:42 UTC --- Author: gjl Date: Tue Feb 28 08:51:39 2012 New Revision: 184615 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184615 Log: PR target/52148 * config/avr/avr.md (movmem_): Replace match_operand that match only one single hard register with respective hard reg rtx. (movmemx_): Ditto. * config/avr/avr.c (avr_emit_movmemhi): Adapt expanding to new insn anatomy of movmem[x]_. (avr_out_movmem): Same for printing assembler and operand usage. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug target/52412] New: another unnecessary register move on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52412
Bug #: 52412
Summary: another unnecessary register move on arm
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-gnueabi
Compile following code with options -march=armv7-a -mthumb -Os
extern int Table[256];
typedef struct {
char* f0;
int f1;
int f2;
char f3[256];
int f4;
} S;
void t0m(S* s)
{
int i;
char ch = (char)(s->f1);
for (i = 0; i < 10 ; i++)
s->f4 = Table[s->f4 ^ ch];
s->f3[s->f1] = 1;
switch (s->f2) {
case 1:
*s->f0 = ch;
break;
case 2:
*s->f0 = ch;
break;
}
}
ARM gcc 4.7 generates:
t0m:
ldrr1, [r0, #4]
movsr2, #10
push{r4, r5, r6, lr}
uxtbr3, r1
ldrr5, .L7
movr6, r3// A
.L2:
ldrr4, [r0, #268]
subsr2, r2, #1
eorr4, r6, r4
ldrr4, [r5, r4, lsl #2]
strr4, [r0, #268]
bne.L2
addsr1, r0, r1
movsr2, #1
strbr2, [r1, #12]
ldrr2, [r0, #8]
cmpr2, #1
beq.L5
cmpr2, #2
bne.L1
.L5:
ldrr2, [r0, #0]
strbr3, [r2, #0]
.L1:
pop{r4, r5, r6, pc}
.L8:
.align2
.L7:
.wordTable
Instruction A moves register r3 to r6, but both r3 and r6 are read only in
following code, so any one is enough for following usage.
Compile it to arm mode instructions has the same problem.
[Bug bootstrap/52391] [4.7 regression] genattrtab almost 5X slower for m68k than in 4.6 and earlier releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52391 --- Comment #10 from Steven Bosscher 2012-02-28 09:00:21 UTC --- F, that backtrace was due to an error in the patch I had to look at what simplify_and_tree was doing. genattrtab is trying to simplify huge and-trees, mostly for m68k_sched_* symbol refs.
[Bug tree-optimization/52395] [4.7 Regression] Too conservative alignment info from SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52395
--- Comment #12 from rguenther at suse dot de
2012-02-28 09:02:04 UTC ---
On Mon, 27 Feb 2012, jamborm at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52395
>
> --- Comment #10 from Martin Jambor 2012-02-27
> 16:25:15 UTC ---
> (In reply to comment #4)
> > Martin, can we make sure that 'base' as passed to build_ref_for_offset
> > is not artificially constructed by any of its callers? Thus, that it is
> > at most the result of stripping some handled-component-refs from an
> > existing reference tree (that was not wrapped inside an ADDR_EXPR) in the
> > IL?
>
> As you noticed in PR 52402 IPA-SRA code does not use this function and
> IPA-CP only does so when the address argument is a global declaration,
> which should be always handled well by expand, I hope.
>
> However, I believe it's the plain ordinary SRA which can introduce,
> accesses which the base did not have before. Consider function foo in
> the following testcase:
>
> --
> typedef long long __m128i __attribute__ ((__vector_size__ (16),
> __may_alias__));
> typedef unsigned int uint32_t;
> extern void abort ();
>
> typedef struct
> {
> __m128i b;
> int a;
> } s_1a;
>
> typedef s_1a s_1m __attribute__((aligned(1)));
>
> typedef struct
> {
> char c;
> s_1m s;
> } __attribute__((packed)) s_2;
>
> void __attribute__((noinline, noclone))
> foo (s_1m *p)
> {
> __m128i v1 = {1,1};
> s_1a l;
>
> l = *p;
> l.b = v1;
> *p = l;
> }
>
> int
> main (int argc, char **argv)
> {
> __m128i v2 = {3,4};
> long long z[2];
> s_2 x;
>
>
> x.s.b = v2;
> foo (&x.s);
> __builtin_memcpy (&z, &x.s.b, sizeof (x.s.b));
>
> if (z[0] != 1 || z[1] != 1)
> abort ();
>
> return 0;
> }
> --
>
> The original foo:
>
> l = *p_2(D);
> l.b = { 1, 1 };
> *p_2(D) = l;
>
> is basically converted into (optimized dump):
>
> p_2(D)->b = { 1, 1 };
>
> so we have introduced a non-BLKmode access into a base which did not
> have it previously. I am not sure whether this fits your definition
> of base which was already there or not. On the other hand, this
> testcase passes with the patch from comment 6 (but fails with PR 50444
> fix reverted) and SRA never creates anything more beastly than this,
> i.e. forwarding scalar loads/stores across aggregate assignments.
>
> Does that answer your question?
Yes, I think so.
Richard.
[Bug rtl-optimization/52148] [4.7 regression] ICE: in spill_failure, at reload1.c:2120
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52148 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #4 from Georg-Johann Lay 2012-02-28 09:03:48 UTC --- Fixed as WORKSFORME: With the patch, the test case can be compiled. However, it does not fix the root cause of spill fails, see PR50925 for details.
[Bug rtl-optimization/52250] [4.7 Regression] ICE: in sel_remove_bb, at sel-sched-ir.c:5213 with -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fselective-scheduling2 and other flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250 Andrey Belevantsev changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Andrey Belevantsev 2012-02-28 09:04:46 UTC --- It should be possible to bootstrap, we generally keep an eye on it. Last time we did benchmarking I think was when Alexander implemented predication support, as it works on x86-64 as well (and helps pipelining there, too). Probably the slight improvement wasn't worth the slowdown, but Alexander should remember better for sure. And of course this can be re-benchmarked on Stage 1 with predication committed and enabled.
[Bug other/52278] [avr] inefficient register allocation for SUBREGs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 CC||eric.weddington at atmel ||dot com Ever Confirmed|0 |1
[Bug target/52261] [avr] Add support for AVR Xmega cores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52261 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Georg-Johann Lay 2012-02-28 09:11:29 UTC --- Closed: Basic XMEGA support seems to be complete now.
[Bug lto/52400] [4.6/4.7 Regression] lto1: ICE with extern on static linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52400 --- Comment #4 from Richard Guenther 2012-02-28 09:13:44 UTC --- Author: rguenth Date: Tue Feb 28 09:13:40 2012 New Revision: 184618 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184618 Log: 2012-02-28 Richard Guenther PR lto/52400 * lto.c (lto_register_function_decl_in_symtab): Do not register a reverse renamed decl mapping. * g++.dg/lto/pr52400_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr52400_0.C Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog
[Bug lto/52400] [4.6 Regression] lto1: ICE with extern on static linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52400 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.0 Resolution||FIXED Target Milestone|4.6.4 |4.7.0 Summary|[4.6/4.7 Regression] lto1: |[4.6 Regression] lto1: ICE |ICE with extern on static |with extern on static |linkage |linkage Known to fail|4.7.0 | --- Comment #5 from Richard Guenther 2012-02-28 09:14:35 UTC --- Fixed for 4.7. The fix is not backportable.
[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52402 Richard Guenther changed: What|Removed |Added Known to work||4.7.0 Known to fail|4.7.0 | --- Comment #4 from Richard Guenther 2012-02-28 09:16:20 UTC --- Fixed on trunk sofar.
[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52402 --- Comment #3 from Richard Guenther 2012-02-28 09:15:54 UTC --- Author: rguenth Date: Tue Feb 28 09:15:49 2012 New Revision: 184619 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184619 Log: 2012-02-28 Richard Guenther PR tree-optimization/52402 * ipa-prop.c (ipa_modify_call_arguments): Properly use mis-aligned types when creating the accesses at the call site. * gcc.dg/torture/pr52402.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52402.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52395] [4.7 Regression] Too conservative alignment info from SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52395 --- Comment #13 from Richard Guenther 2012-02-28 09:18:38 UTC --- Author: rguenth Date: Tue Feb 28 09:18:35 2012 New Revision: 184620 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184620 Log: 2012-02-28 Richard Guenther PR tree-optimization/52395 * tree-sra.c (build_ref_for_offset): Also look at the base TYPE_ALIGN when figuring out the alignment of the replacement. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
[Bug tree-optimization/52395] [4.7 Regression] Too conservative alignment info from SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52395 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Richard Guenther 2012-02-28 09:19:27 UTC --- Fixed.
[Bug libfortran/52413] New: Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413 Bug #: 52413 Summary: Incorrect behavior of FRACTION when applied to a constant Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fro...@enseeiht.fr Hi, I have a problem when applying "fraction" to a numerical constant, e.g. fraction(-2.0); a minimal example says it all: program test_frac real::x,y x=-2.0 x=fraction(x) write(*,*)x y=fraction(-2.0) write(*,*)y end program test_frac The output is -0.5000 0.5000 while one would expect -0.5000 -0.5000 I experienced this with gfortran 4.4, 4.5 and 4.6 on Ubuntu systems. On ifort 12, the result is correct. Regards, FHR
[Bug c/52410] BUG gcc 4.6.2 Illegal Instruction (core dumped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52410 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely 2012-02-28 09:39:21 UTC --- submitted twice *** This bug has been marked as a duplicate of bug 52411 ***
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #1 from Jonathan Wakely 2012-02-28 09:39:21 UTC --- *** Bug 52410 has been marked as a duplicate of this bug. ***
[Bug bootstrap/52414] New: [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Bug #: 52414 Summary: [4.7 Regression] syntax error in VERSION script Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Target: powerpc64-unknown-linux-gnu Just found, booting on gcc110 with rev. 184613. Configuration was with ../trunk/configure --prefix=$HOME --enable-languages=c,fortran --with-ppl --with-cloog Last output: Checking multilib configuration for libgomp... Checking multilib configuration for libstdc++-v3... make[3]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3' make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/home/tkoenig/trunk-bin/./gcc/xgcc -B/home/tkoenig/trunk-bin/./gcc/" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2 -D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500 --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/home/tkoenig" "infodir=/home/tkoenig/share/info" "libdir=/home/tkoenig/lib" "includedir=/home/tkoenig/include" "prefix=/home/tkoenig" "tooldir=/home/tkoenig/powerpc64-unknown-linux-gnu" "gxx_include_dir=/home/tkoenig/include/c++/4.7.0" "AR=ar" "AS=/home/tkoenig/trunk-bin/./gcc/as" "LD=/home/tkoenig/trunk-bin/./gcc/collect-ld" "RANLIB=ranlib" "NM=/home/tkoenig/trunk-bin/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive make[4]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3' Making all in include make[5]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/include' make[5]: Für das Ziel »all« ist nichts zu tun. make[5]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/include' Making all in libsupc++ make[5]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++' make[5]: Für das Ziel »all« ist nichts zu tun. make[5]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++' Making all in src make[5]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src' Making all in c++98 make[6]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++98' make[6]: Für das Ziel »all« ist nichts zu tun. make[6]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++98' Making all in c++11 make[6]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++11' make[6]: Für das Ziel »all« ist nichts zu tun. make[6]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/c++11' make[6]: Entering directory `/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src' /bin/sh ../libtool --tag CXX --mode=link /home/tkoenig/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/tkoenig/trunk-bin/./gcc -nostdin++ -L/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstc++-v3/src/.libs -B/home/tkoenig/powerpc64-unknown-linux-gnu/bin/ -B/home/tkoenig/powerpc64-unknown-linux-gnu/lib/ -isystem /home/tkonig/powerpc64-unknown-linux-gnu/include -isystem /home/tkoenig/powerpc64-unknown-linux-gnu/sys-include-Wl,-O1 -Wl,-z,relro -Wl,--c-sections -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:17:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /home/tkoenig/ib/../lib64 ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la libtool: link: /home/tkoenig/trunk-bin/./gcc/xgcc -shared-libgcc -B/home/tkoenig/trunk-bin/./gcc -nostdinc++ -L/home/tkoenig/trunk-bn/powerpc64-unknown-linux-gnu/libstdc++-v3/src -L/home/tkoenig/trunk-bin/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/toenig/powerpc64-unknown-linux-gnu/bin/ -B/home/tkoenig/powerpc64-unknown-linux-gnu/lib/ -isystem /home/tkoenig/powerpc64-unknown-linu-gnu/include -isystem /home/tkoenig/powerpc64-unkno
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Thomas Koenig changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Thomas Koenig 2012-02-28 09:45:40 UTC --- Adding release maintainer to CC.
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Jakub Jelinek 2012-02-28 09:46:50 UTC --- Should be fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184621
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406
--- Comment #2 from Jakub Jelinek 2012-02-28
09:54:01 UTC ---
Strangely,
/* PR tree-optimization/52406 */
extern void abort (void);
struct { int f1; } a[2];
int *b, *const k = &a[1].f1;
static int **c = &b;
int e, f, d;
int
main ()
{
int **l = &b;
*l = k;
for (; d <= 0; d++)
{
int *j = &e;
**c = 1;
*l = k;
*k ^= 0;
f = **l;
*j = f;
}
if (e != 1)
abort ();
return 0;
}
fails, but with
--- pr52406.c 2012-02-28 10:47:45.663204390 +0100
+++ pr52406.c 2012-02-28 10:47:56.695143490 +0100
@@ -1,9 +1,9 @@
/* PR tree-optimization/52406 */
extern void abort (void);
-struct { int f1; } a[2];
+int a[2];
-int *b, *const k = &a[1].f1;
+int *b, *const k = &a[1];
static int **c = &b;
int e, f, d;
it works (IL starts to differ during pcom), beyond the &a[1] vs. &a[1].f1
changes. So even if there isn't a wrong code, there would be at least
missed-optimization.
[Bug fortran/52387] I/O output of write after nonadvancing read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387 Tobias Burnus changed: What|Removed |Added Summary|I/O wrong output with |I/O output of write after |nonadvancing output |nonadvancing read --- Comment #5 from Tobias Burnus 2012-02-28 09:58:37 UTC --- >From the J3 discussion: While Bob thinks that the standard is obvious, Van disagrees, cf. http://j3-fortran.org/pipermail/j3/2012-February/005067.html I wrote a draft IR, which is available at http://j3-fortran.org/pipermail/j3/2012-February/005069.html I intent to submit the IR for the next meeting (presumably J3 #198 jointly with WG5 at Toronto in June).
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 --- Comment #3 from Jakub Jelinek 2012-02-28 10:14:57 UTC --- Indeed, it is pcom that breaks it. Before pcom we have: MEM[(int *)&a + 4B] = 1; D.1723_6 = a[1].f1; but pcom doesn't consider the first store to be possibly affecting the load: a_I_f1_lsm0.14_26 = a[1].f1; : # d_lsm0.12_12 = PHI MEM[(int *)&a + 4B] = 1; D.1723_6 = a_I_f1_lsm0.14_26;
[Bug bootstrap/52414] [4.7 Regression] syntax error in VERSION script
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52414 --- Comment #3 from Jakub Jelinek 2012-02-28 10:21:10 UTC --- Author: jakub Date: Tue Feb 28 10:21:03 2012 New Revision: 184624 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184624 Log: PR bootstrap/52414 * src/Makefile.am (libstdc++-symbols.ver): Only remove comment lines if they are at the beginning of lines (with optional whitespace before #). * src/Makefile.in: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog
[Bug rtl-optimization/52250] [4.7 Regression] ICE: in sel_remove_bb, at sel-sched-ir.c:5213 with -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fselective-scheduling2 and other flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52250 --- Comment #8 from Alexander Monakov 2012-02-28 10:20:58 UTC --- Like Andrey said, we verify that x86_64-linux bootstraps with sel-sched when submitting patches, but I do not remember any specific figures from the times when I did benchmarking. It's a good suggestion do to it again in the next stage 1.
[Bug target/52415] New: memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
Bug #: 52415
Summary: memcpy to local variable generates unnecessary stack
frame for armv7
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.f...@gmail.com
This test case uses memcpy to load the bytes of a float into an int:
$ cat m.c
int f(float *p) {
int i;
__builtin_memcpy(&i, p, sizeof i);
return i;
}
When compiled for armv7 I get:
$ cc1 -o - -O3 m.c -quiet -march=armv7 -mthumb
...
f:
@ args = 0, pretend = 0, frame = 4
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrr0, [r0, #0]@ unaligned
subsp, sp, #4
strr0, [sp, #0]@ unaligned
ldrr0, [sp, #0]
addsp, sp, #4
bxlr
...
The stack frame is unnecessary; it could compile to just:
ldrr0, [r0, #0]
bxlr
I'm using trunk rev 184597, configured with --target=arm-elf.
[Bug target/52407] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-02-28 10:39:53 UTC --- It looks like a bug in the way we expand the vector init: ;; MEM[(int64_t *)&w + 8B] = 2; (insn 39 38 40 (set (reg:DI 102) (const_int 2 [0x2])) t.c:19 -1 (nil)) (insn 40 39 41 (set (reg:DI 103) (vec_select:DI (reg/v:V2DI 98 [ w ]) (parallel [ (const_int 0 [0]) ]))) t.c:19 -1 (nil)) (insn 41 40 0 (set (reg/v:V2DI 98 [ w ]) (vec_concat:V2DI (reg:DI 102) (reg:DI 103))) t.c:19 -1 (nil)) ^^^ should be vec_concat 103 102 ;; MEM[(int64_t *)&w] = 2; (insn 42 41 43 (set (reg:DI 104) (const_int 2 [0x2])) t.c:19 -1 (nil)) (insn 43 42 44 (set (reg:DI 105) (vec_select:DI (reg/v:V2DI 98 [ w ]) (parallel [ (const_int 1 [0x1]) ]))) t.c:19 -1 (nil)) (insn 44 43 0 (set (reg/v:V2DI 98 [ w ]) (vec_concat:V2DI (reg:DI 105) (reg:DI 104))) t.c:19 -1 (nil)) ^^^ should be vec_concat 104 105 no?
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2012-02-28 10:42:47 UTC --- Mine.
[Bug lto/52405] undefined references in shared library when linking the shared library with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-28 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-02-28 10:44:20 UTC --- Please specify how you build/link your shared library. Which binutils version are you using? Are you using the linker plugin? Does it work with -fno-use-linker-plugin? Does it work with -flto-partition=none?
[Bug target/52404] internal compiler error: in setup_min_max_allocno_live_range_point, at ira-build.c:2425
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52404 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2012-02-28 10:45:42 UTC --- Fixed. I can reproduce it on older trunk.
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 --- Comment #5 from Richard Guenther 2012-02-28 11:06:16 UTC --- We have Creating dr for MEM[(int *)&a + 4B] base_address: &a offset from base address: 0 constant offset from base address: 4 step: 0 aligned to: 128 base_object: MEM[(int *)&a + 4B] Creating dr for a[1].f1 base_address: &a offset from base address: 0 constant offset from base address: 4 step: 0 aligned to: 128 base_object: a[0].f1 Access function 0: 1 thus we have an access function for a[1].f1 but no access function for MEM[(int *)&a + 4B]. That should cause it to conflict. (compute_affine_dependence (stmt_a = MEM[(int *)&a + 4B] = 1; ) (stmt_b = D.1724_6 = a[1].f1; ) (Data Dep: #(Data Ref: # bb: 5 # stmt: MEM[(int *)&a + 4B] = 1; # ref: MEM[(int *)&a + 4B]; # base_object: MEM[(int *)&a + 4B]; #) #(Data Ref: # bb: 5 # stmt: D.1724_6 = a[1].f1; # ref: a[1].f1; # base_object: a[0].f1; # Access function 0: 1 #) (no dependence) ) hmpf. dr_may_alias_p returns false because it feeds the oracle with the base objects!
[Bug target/52407] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Target||x86_64-*-* --- Comment #3 from Richard Guenther 2012-02-28 11:32:34 UTC --- Hmm, ix86_expand_vector_set has for the V2DI case ix86_expand_vector_extract (false, tmp, target, 1 - elt); if (elt == 0) tmp = gen_rtx_VEC_CONCAT (mode, tmp, val); else tmp = gen_rtx_VEC_CONCAT (mode, val, tmp); vs. for the V2DF case: tmp = gen_rtx_VEC_SELECT (inner_mode, target, tmp); if (elt == 0) op0 = val, op1 = tmp; else op0 = tmp, op1 = val; tmp = gen_rtx_VEC_CONCAT (mode, op0, op1); looks the V2DI case has swapped operands.
[Bug target/52407] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2012-02-28 11:34:36 UTC --- I'm testing a patch. The V2DF/SImode case is also bogus.
[Bug target/52407] [4.7 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Known to work||4.6.2 Target Milestone|--- |4.7.0 Summary|sse2 simd uint32_t and |[4.7 Regression] sse2 simd |int64_t and stack variable |uint32_t and int64_t and |initialization |stack variable ||initialization
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-02-28 11:45:04 UTC --- This is I believe because ARM is a STRICT_ALIGNMENT target and we thus do not transform the memcpy on the tree level. On the tree level nothing guarantees that 'p' is properly aligned.
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 --- Comment #2 from Jay Foad 2012-02-28 11:51:00 UTC --- > On the tree level nothing guarantees that 'p' is properly aligned. This is a digression, but what about C99 (Committee Draft -- April 12, 2011) 6.3.2.3p7: "A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined." Doesn't that guarantee that p is properly aligned? If not, how can I assert that p *is* properly aligned, so the compiler can turn the memcpy into an aligned load? Thanks.
[Bug target/52407] [4.7 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407
--- Comment #5 from Jakub Jelinek 2012-02-28
12:02:18 UTC ---
Triggered by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184435
Testcase:
/* PR target/52407 */
extern void abort (void);
typedef long long V __attribute__ ((vector_size (16)));
V ul[4], vl[4] = { {1, 2}, {3, 4}, {5, 6}, {7, 8} };
static void
foo (V *u, V *v, long long x, int m)
{
V w;
long long *p = (long long *) &w;
p[0] = p[1] = x;
while (m--)
*u++ = *v++ * w;
}
int
main ()
{
int i;
long long *pl;
pl = (long long *) &ul;
foo (ul, vl, 2, 4);
for (i = 0; i < 8; i++)
if (pl[i] != 2 * (i + 1))
abort ();
return 0;
}
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
--- Comment #3 from Richard Guenther 2012-02-28
12:15:53 UTC ---
(In reply to comment #2)
> > On the tree level nothing guarantees that 'p' is properly aligned.
>
> This is a digression, but what about C99 (Committee Draft -- April 12, 2011)
> 6.3.2.3p7:
>
> "A pointer to an object type may be converted to a pointer to a different
> object type. If the resulting pointer is not correctly aligned for the
> referenced type, the behavior is undefined."
>
> Doesn't that guarantee that p is properly aligned? If not, how can I assert
> that p *is* properly aligned, so the compiler can turn the memcpy into an
> aligned load? Thanks.
Well, not exactly. The GIMPLE IL does not map 1:1 to the C99 spec (after
all it has to support other languages besides C). There is no convenient
way for a frontend to tell the middle-end that 'p' is properly aligned
for a float. Note that the situation is complicated by the fact that,
as GCC extension, you can create a misaligned variant
typedef float my_float __attribute__((aligned(1)));
int f(my_float *p) {
int i;
__builtin_memcpy(&i, p, sizeof i);
return i;
}
which needs to be handled correctly as well (we don't on STRICT_ALIGNMENT
targets). The my_float * case is of course not covered by C99.
[Bug gcov-profile/52416] New: Branch coverage differences between 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52416
Bug #: 52416
Summary: Branch coverage differences between 4.4 and 4.5
Classification: Unclassified
Product: gcc
Version: 4.5.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: chateau.frede...@gmail.com
Hello,
I am using g++ versions coming with Ubuntu 11.10 and I am trying to use g++ and
lcov to analyse the line and branch coverage of my unit tests.
I discovered some significant differences in the number of branches reported
between version 4.4 (4.4.6) and 4.5 (4.5.4) (or 4.6 (4.6.1)).
I was trying to figure out which compilation flags were best in order to have
branch coverage information match more closely what I see in the source code
and avoid hidden branches (triggered by under the hood code) or suppressed
branches (because of optimizations).
Finally, it seems that -O0 -fno-inline -fno-default-inline
-fno-elide-constructors works best, at least with g++-4.4
Because, when I use g++-4.5 or g++-4.6, there are many additionnal branches
that do not directly come from the control flow in the source.
In the project I was analysis, the number of branches jumped from ~1950 to
~6600 !
In my point of view, the output of 4.4 is more meaningful than the output of
4.5/4.6.
I tried to make a little example program and tried to figure out if there was a
flags that could disable the generetion of these branches.
And indeed, with -fno-exceptions, I get the same exact result in 4.5/4.6 than
in 4.4. At least with my example program, because my whole project requires
exception handling to be activated.
Here is the example code:
#include
int main(int argc, char* argv[])
{
std::string val;
if(argc > 1)
{
val = argv[1];
}
if(argc == 2)
{
std::cout << val << std::endl;
}
else
{
std::cout << "Need one argument!" << std::endl;
}
}
With g++ 4.4, there are 8 branches.
With g++ 4.5, there are 16 branches !
Here is gcov output:
g++-4.5:
-:0:Source:myprog.cpp
-:0:Graph:myprog.gcno
-:0:Data:myprog.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:
function main called 1 returned 100% blocks executed 58%
1:3:int main(int argc, char* argv[])
-:4:{
2:5:std::string val;
call0 returned 100%
call1 returned 100%
call2 never executed
call3 never executed
1:6:if(argc > 1)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-:7:{
#:8:val = argv[1];
branch 0 never executed
branch 1 never executed
call2 never executed
-:9:}
1: 10:if(argc == 2)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-: 11:{
#: 12:std::cout << val << std::endl;
branch 0 never executed
branch 1 never executed
call2 never executed
branch 3 never executed
branch 4 never executed
call5 never executed
-: 13:}
-: 14:else
-: 15:{
1: 16:std::cout << "Need one argument!" << std::endl;
branch 0 taken 100% (fallthrough)
branch 1 taken 0%
call2 returned 100%
branch 3 taken 100% (fallthrough)
branch 4 taken 0%
call5 returned 100%
-: 17:}
function _Z41__static_initialization_and_destruction_0ii called 1 returned 100%
blocks executed 100%
function _GLOBAL__I_main called 1 returned 100% blocks executed 100%
3: 18:}
branch 0 taken 100% (fallthrough)
branch 1 taken 0%
branch 2 taken 100% (fallthrough)
branch 3 taken 0%
call4 returned 100%
-: 19:
With g++-4.4:
-:0:Source:myprog.cpp
-:0:Graph:myprog.gcno
-:0:Data:myprog.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:
function main called 1 returned 100% blocks executed 54%
1:3:int main(int argc, char* argv[])
-:4:{
1:5:std::string val;
call0 returned 100%
1:6:if(argc > 1)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-:7:{
#:8:val = argv[1];
call0 never executed
-:9:}
1: 10:if(argc == 2)
branch 0 taken 0% (fallthrough)
branch 1 taken 100%
-: 11:{
#: 12:std::cout << val << std::endl;
call0 never executed
call1 never executed
-: 13:}
-: 14:else
-: 15:{
1: 16:std::cout << "Need one argument!" << std::endl;
call0 returned 100%
call1 returned 100%
#: 17:}
call0 never executed
call1
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek 2012-02-28
12:29:14 UTC ---
But to answer your question, how you can assert it is properly aligned, in gcc
4.7.0 you can write:
__builtin_memcpy (&i, __builtin_assume_aligned (p, sizeof *p), sizeof i);
which will assert that p is sizeof (float) bytes aligned and then you get code
without the stack frame. Or you can use a union instead of memcpy:
union U { float f; int i; } u;
u.f = *p;
return u.i;
[Bug rtl-optimization/52417] New: [4.7 Regression] Infinite recursion in DSE/alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52417 Bug #: 52417 Summary: [4.7 Regression] Infinite recursion in DSE/alias.c Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org Target: avr alias.c enters an infinite recurson for the following testcases from GCC testsuite: gcc.c-torture/compile/pr37669-2.c for any compilation with -O* and without -fno-dse Target: avr Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2 --enable-checking=yes,rtl target_alias=avr --enable-languages=c,c++ Thread model: single gcc version 4.7.0 20120228 (experimental) (GCC) GNU C (GCC) version 4.7.0 20120228 (experimental) (avr) compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
[Bug rtl-optimization/52417] [4.7 Regression] Infinite recursion in DSE/alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52417 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-02-28 CC||eric.weddington at atmel ||dot com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug rtl-optimization/52417] [4.7 Regression] Infinite recursion in DSE/alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52417 Georg-Johann Lay changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay 2012-02-28 12:48:10 UTC --- CCing Alexandre, presumably this is caused by the last changes for PR52001.
[Bug c/52410] BUG gcc 4.6.2 Illegal Instruction (core dumped)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52410 --- Comment #2 from evrinoma at gmail dot com 2012-02-28 12:51:05 UTC --- gcc-4.7-20120225/configure --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux posix gcc 4.7.0 20120225 (experimental) (GCC) similar problem
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-02-28 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-02-28 12:57:30 UTC --- Please look at what the illegal instruction is and make sure your CPU has all features required by your compile. Also nobody is going to download tarballs, so you need to provide us with a testcase.
[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52415 --- Comment #5 from Jay Foad 2012-02-28 13:03:50 UTC --- > But to answer your question, how you can assert it is properly aligned, in gcc > 4.7.0 you can write: > __builtin_memcpy (&i, __builtin_assume_aligned (p, sizeof *p), sizeof i); Thanks! Better: __builtin_assume_aligned (p, __alignof__ *p)
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #3 from evrinoma at gmail dot com 2012-02-28 13:07:14 UTC --- gcc-4.7-20120225/configure --disable-cloog-version-check --enable-cloog-backend=isl --enable-lto --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++ --disable-dssi --enable-libgcj-multifile --without-ppl --without-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux posix gcc 4.7.0 20120225 (experimental) (GCC) similar problem
[Bug lto/52405] undefined references in shared library when linking the shared library with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Matthias Klose 2012-02-28 13:35:17 UTC --- binutils from the 2.22 release branch is used. yes, using the linker plugin. options to build the shared library (see build.sh) -m64 -fpic -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden -m64 -flto -flto-partition=none -g -O3 -fno-strict-aliasing -fno-omit-frame-pointer -Xlinker -O1 -Wl,-Bsymbolic-functions -Xlinker -z -Xlinker noexecstack -shared -Xlinker --version-script=mapfile_reorder -Xlinker -soname=libjvm.so -o libjvm.so reducing these to -m64 -fpic -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden -flto -flto-partition=none -g -O3 -fno-strict-aliasing -fno-omit-frame-pointer -Wl,-Bsymbolic-functions -Xlinker -z -shared -Xlinker -soname=libjvm.so -o libjvm.so doesn't change things. -fno-use-linker-plugin doesn't change things. -flto-partition=none doesn't change things.
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #4 from evrinoma at gmail dot com 2012-02-28 13:38:29 UTC --- (gdb) r -vvvc Starting program: /home/nikolns/bld/aster/gcc-4.7/asterisk-1.8.9.2/main/asterisk -vvvc [Thread debugging using libthread_db enabled] [New Thread 0x77fd9700 (LWP 15132)] Program received signal SIGILL, Illegal instruction. 0x0053e80f in tzload (name=, sp=0x82bd40, doextend=1) at stdtime/localtime.c:657 657 static int tzload(const char *name, struct state * const sp, const int doextend)
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #5 from evrinoma at gmail dot com 2012-02-28 13:45:16 UTC --- cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Celeron(R) CPU 3.06GHz stepping: 9 cpu MHz : 3066.590 cache size : 256 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc up pebs bts pni dtes64 monitor ds_cpl tm2 cid cx16 xtpr lahf_lm bogomips: 6118.58 clflush size: 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: uname -a Linux IT0917 2.6.32-220.4.2.el6.x86_64 #1 SMP Tue Feb 14 04:00:16 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux free total used free sharedbuffers cached Mem: 20444161971600 72816 0 606361615176 -/+ buffers/cache: 2957881748628 Swap: 252 0252
[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 Richard Guenther changed: What|Removed |Added Blocks||50067 --- Comment #6 from Richard Guenther 2012-02-28 14:32:58 UTC --- The issue is that we want to disambiguate a[i].f1 and a[i].f2, so for the "base object" we zero out all known indices, resulting in a[0].f1 and a[0].f2 which we then disambiguate (and conclude that for all i there cannot be a dependence). Now, when we mix pointer accesses with array accesses most of the index analysis falls apart (which is what the fix for PR50067 tries to make work more reliably - see its comment #13 on the dr_may_alias_p issue ...) So, it's really wrong to try to fixup DR_BASE_OBJECT to make dr_may_alias_p work, and it is equally wrong to use DR_BASE_OBJECT in dr_may_alias_p. Using DR_REF (a safe bet) falls foul of failing a load of testcases, for example gcc.dg/vect/pr37027.c which is no longer vectorized because (compute_affine_dependence stmt_a: D.1722_7 = a[i_24].f1; stmt_b: D.1725_11 = a[i_24].f2; ) -> dependence analysis failed previously we'd have used a[0].f1 and a[0].f2 in the disambiguation in dr_may_alias_p and disambiguated the accesses. We can try a similar trick as with REALPART/IMAGPART_EXPR to recover this. Add a constant access function for outer COMPONENT_REFs (those we can strip off the base object).
[Bug lto/52405] undefined references in shared library when linking the shared library with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52405 Richard Guenther changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Richard Guenther 2012-02-28 14:36:47 UTC --- We do have known issues with linker options not being reflected correctly in the resolution file. As it is inlines and you use -fvisibility=hidden I expect that the -Xlinker --version-script=mapfile_reorder is not re-applied after final link optimization but only to the (fat) object file result from compile. So some functions may not be catched by the version script globbing (or they are renamed as comdats are brought local, and thus may no longer match any of the globs)? Please help reducing this on your side.
[Bug c/52411] BUG gcc 4.6.2 Illegal Instruction (core dumped) asterisk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52411 --- Comment #6 from Richard Guenther 2012-02-28 14:41:29 UTC --- (In reply to comment #4) > (gdb) r -vvvc > Starting program: > /home/nikolns/bld/aster/gcc-4.7/asterisk-1.8.9.2/main/asterisk -vvvc > [Thread debugging using libthread_db enabled] > [New Thread 0x77fd9700 (LWP 15132)] > > Program received signal SIGILL, Illegal instruction. > 0x0053e80f in tzload (name=, sp=0x82bd40, > doextend=1) at stdtime/localtime.c:657 > 657 static int tzload(const char *name, struct state * const sp, const int > doextend) That does not show the instuction. Do (gdb) disassemble 0x0053e800,+32 (assuming the crash is still at 0x0053e80f when you re-try)
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org --- Comment #9 from Ramana Radhakrishnan 2012-02-28 14:41:56 UTC --- I ran into this failure today when upgrading my copy of (e)glibc in my cross-environment. What's the best way of progressing this further ? Doesn't this mean that trunk is broken for building with anything later than glibc-2.15 ? Ramana
[Bug fortran/48820] TR 29113: Implement parts needed for MPI 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus 2012-02-28 14:46:10 UTC --- For assumed type, see early draft patch at http://gcc.gnu.org/ml/fortran/2012-02/msg00111.html (and, in the thread, for a MPIv3-related discussion) Latest TS29113 draft: http://j3-fortran.org/doc/meeting/197/12-119r1.pdf
[Bug target/50181] insn does not satisfy constraints for 481.wrf when generating profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181
--- Comment #1 from Peter Bergner 2012-02-28
14:53:57 UTC ---
Created attachment 26769
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26769
Smaller C test case
Here is a smaller C test case that doesn't require -fprofile-generate to ICE:
bergner@igoo:~/gcc/BUGS/pr50181>
/home/bergner/gcc/build/gcc-fsf-4_6-base/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-4_6-base/gcc -O3 -mcpu=power7 -S pr50181.c
pr50181.c: In function ‘testcase’:
pr50181.c:29:1: error: insn does not satisfy its constraints:
(insn 69 7 68 2 (set (reg:V4SI 10 10)
(const_vector:V4SI [
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
(const_int 1 [0x1])
])) pr50181.c:17 789 {*vsx_movv4si}
(nil))
pr50181.c:29:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #10 from joseph at codesourcery dot com 2012-02-28 15:23:38 UTC --- If the libstdc++ people are going to do something for 4.7, it really needs to be done very soon. Let's assume glibc should at least get a further change for the sake of older GCC versions - changing !defined __USE_GNU to (!defined __USE_GNU || (defined __GNUC__ && !__GNUC_PREREQ (4, 7))). But if this isn't fixed for 4.7, that conditional in stdio.h would need to use __GNUC_PREREQ (4, 8) instead.
[Bug target/49448] arm-tab-linux-gnu-eabi enableds big endian when it should not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49448 --- Comment #3 from Richard Earnshaw 2012-02-28 15:26:13 UTC --- Author: rearnsha Date: Tue Feb 28 15:26:02 2012 New Revision: 184626 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184626 Log: PR target/49448 * config.gcc (arm*-*-linux*): Use an unambiguous pattern for detecting big-endian triplets. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug target/52407] [4.7 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 --- Comment #6 from Richard Guenther 2012-02-28 15:28:39 UTC --- Author: rguenth Date: Tue Feb 28 15:28:32 2012 New Revision: 184627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184627 Log: 2012-02-28 Richard Guenther PR target/52407 * config/i386/i386.c (ix86_expand_vector_set): Fix element ordering for the VEC_CONCAT for two element vectors for V2SFmode, V2SImode and V2DImode. * gcc.dg/torture/pr52407.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52407.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/52407] [4.6 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Richard Guenther changed: What|Removed |Added Known to work||4.7.0 Target Milestone|4.7.0 |4.6.4 Summary|[4.7 Regression] sse2 simd |[4.6 Regression] sse2 simd |uint32_t and int64_t and|uint32_t and int64_t and |stack variable |stack variable |initialization |initialization --- Comment #7 from Richard Guenther 2012-02-28 15:29:53 UTC --- Fixed on trunk. I'll backport it for 4.6.4 as it is latent on the branches.
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #11 from Paolo Carlini 2012-02-28 15:35:59 UTC --- If the release managers agree, I would be in favor of a quick fix per Comment 3, with a huge comment in the code explaining the issue. But I can't test it right now.
[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48299 --- Comment #22 from pmarlier at gcc dot gnu.org 2012-02-28 15:37:57 UTC --- Author: pmarlier Date: Tue Feb 28 15:37:41 2012 New Revision: 184628 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184628 Log: 2012-02-27 Jack Howarth Patrick Marlier PR boehm-gc/48299 testsuite/boehm-gc.c/thread_leak_test.c: Merge upstream changes. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/testsuite/boehm-gc.c/thread_leak_test.c
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 --- Comment #7 from Jakub Jelinek 2012-02-28 15:40:40 UTC --- Ok, with additional -fno-inline -gnatpg I can reproduce even with the commands I tried. The dead_debug* stuff doesn't handle this probably because the hard reg isn't ever becoming REG_DEAD or REG_UNUSED etc. in the IL, it is just unused altogether plus set on entry. I wonder if df_reg_chain_unlink/df_install_ref shouldn't just ignore DEBUG_INSN refs when updating df->hard_regs_live_count array, do we care at all when testing regs_ever_live if something is live in debug insns?
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #12 from Marc Glisse 2012-02-28 15:47:04 UTC --- (In reply to comment #10) > If the libstdc++ people are going to do something for 4.7, it really needs > to be done very soon. The question is: what do the glibc people want? By removing the gets prototype, they are explicitly going against the C++ standard. Seems to me that libstdc++ should respect that choice (add a test in configure to see if gets is provided, and protect "using ::gets;" with #ifdef) and not provide gets. The alternative is to disagree with the glibc developers and fixinclude stdio.h.
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #13 from Jakub Jelinek 2012-02-28 15:49:26 UTC --- I'm ok with #c3 patch + comment if it works, using special configure macro instead of __GLIBC_PREREQ is IMHO undesirable, because then if you build gcc against glibc 2.14 and afterwards upgrade glibc to 2.15, it will suddenly break.
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 --- Comment #4 from Robert Hayward 2012-02-28 15:53:05 UTC --- Created attachment 26770 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26770 test program to reproduce bug
[Bug fortran/52418] New: (unnecessary) automatic reallocation of lhs causes segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52418 Bug #: 52418 Summary: (unnecessary) automatic reallocation of lhs causes segfault Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: therob...@gmail.com Created attachment 26771 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26771 program to reproduce bug The following program causes a segfault: PROGRAM reshape_test IMPLICIT NONE REAL, DIMENSION(:,:), ALLOCATABLE :: m2 REAL, DIMENSION(:,:,:), ALLOCATABLE :: m3 ALLOCATE( m2( 6, 1 ), m3( 2, 3, 1 ) ) m2 = -1 m3 = RESHAPE( m2, SHAPE(m3) ) m3 = 2 WRITE(*,*) 'm3(1,1,1) = ', m3(1,1,1) END PROGRAM reshape_test If compiled with -fno-realloc-lhs, the code runs as expected. There really shouldn't be any reallocation here, so this shouldn't make a difference. Either way it should not cause a segfault. Side note: I love all of the work on f2003/2008! The OO features make fortran fun again. Thanks!
[Bug libfortran/52413] Incorrect behavior of FRACTION when applied to a constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-02-28
CC||kargl at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |kargl at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
Known to fail||4.2.5, 4.3.6, 4.4.7, 4.5.4,
||4.6.3, 4.7.0
--- Comment #1 from kargl at gcc dot gnu.org 2012-02-28 16:11:10 UTC ---
Confirmed. This fails on all versions of gfortran 4.2 and up.
I don't have a 4.1 version for testing. I have a patch, but
as this is not a regression, I will not apply it until after
4.7.0 is released.
Tentative patch. Not regression tested, yet.
Index: simplify.c
===
--- simplify.c (revision 184485)
+++ simplify.c (working copy)
@@ -2331,35 +2331,16 @@ gfc_expr *
gfc_simplify_fraction (gfc_expr *x)
{
gfc_expr *result;
- mpfr_t absv, exp, pow2;
+ mpfr_exp_t e;
if (x->expr_type != EXPR_CONSTANT)
return NULL;
result = gfc_get_constant_expr (BT_REAL, x->ts.kind, &x->where);
- if (mpfr_sgn (x->value.real) == 0)
-{
- mpfr_set_ui (result->value.real, 0, GFC_RND_MODE);
- return result;
-}
-
gfc_set_model_kind (x->ts.kind);
- mpfr_init (exp);
- mpfr_init (absv);
- mpfr_init (pow2);
-
- mpfr_abs (absv, x->value.real, GFC_RND_MODE);
- mpfr_log2 (exp, absv, GFC_RND_MODE);
-
- mpfr_trunc (exp, exp);
- mpfr_add_ui (exp, exp, 1, GFC_RND_MODE);
-
- mpfr_ui_pow (pow2, 2, exp, GFC_RND_MODE);
-
- mpfr_div (result->value.real, absv, pow2, GFC_RND_MODE);
- mpfr_clears (exp, absv, pow2, NULL);
+ mpfr_frexp (&e, result->value.real, x->value.real, GFC_RND_MODE);
return range_check (result, "FRACTION");
}
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||therobbot at gmail dot com --- Comment #5 from Tobias Burnus 2012-02-28 16:11:08 UTC --- Robert Hayward wrote in comment #4: > Created attachment 26770 [details] > test program to reproduce bug Please do not attach test cases to random bugreports! But create a new bug report and put more information in the report. -- Except that both issues are related to Fortran 2003's (re)allocation on intrinsic assignment, they do not have anything in common. The issue of comment 4 / Robert Hayward's issue is a bug in gfortran 4.6/4.7, which has been been reported in PR 52012 and fixed around 2012-01-31. Please try a newer version of GCC 4.6/4.7 - or use -fno-realloc-lhs as work around. (The issue in comment 0 is a bug in the original reporter's program for Fortran 90/95: The shape on the right and on the left have to be the same. The proper assignment should have been one of the following: ivec(1:2) = [1,2] ivec(2:3) = [1,2] ivec(1:2:2) = [1,2] ! or ivec([1,3]) = [1,2] With Fortran 2003, the program became valid - as the compiler reallocated "ivec" with the shape of the right side. With -std=f95 or if the left-hand side weren't allocatable, -fcheck=bounds had given a run-time error.)
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785
--- Comment #14 from Ramana Radhakrishnan
2012-02-28 16:09:52 UTC ---
I can confirm that a build for arm-linux-gnueabi completes and do some
cross-testing on qemu if that's deemed to be enough.
Any other ideas for testing.
Ramana
Here's a suggestion for the comments in this patch.
diff --git a/libstdc++-v3/include/c_global/cstdio
b/libstdc++-v3/include/c_global/cstdio
index 049704d..76755ac 100644
--- a/libstdc++-v3/include/c_global/cstdio
+++ b/libstdc++-v3/include/c_global/cstdio
@@ -89,6 +89,17 @@
#undef vprintf
#undef vsprintf
+/* glibc 2.15 and later do not declare gets anymore for
+ ISO C11 mode and if __GNU_SOURCE is defined. See
+ http://gcc.gnu.org/PR51785 for more on this topic. If
+ this is being changed an equivalent change has to be made
+ in include/c_std/c_stdio. */
+#if __GLIBC_PREREQ (2,15)
+extern "C" {
+ extern char *gets (char *__s) __attribute__((deprecated));
+}
+#endif
+
namespace std
{
using ::FILE;
diff --git a/libstdc++-v3/include/c_std/cstdio
b/libstdc++-v3/include/c_std/cstdio
index 510f599..29142bb 100644
--- a/libstdc++-v3/include/c_std/cstdio
+++ b/libstdc++-v3/include/c_std/cstdio
@@ -88,6 +88,17 @@
#undef vprintf
#undef vsprintf
+/* glibc 2.15 and later do not declare gets anymore for
+ ISO C11 mode and if __GNU_SOURCE is defined. See
+ http://gcc.gnu.org/PR51785 for more on this topic. If
+ this hunk below is being changed please also investigate
+ the change for include/c_global/cstdio. */
+#if __GLIBC_PREREQ (2,15)
+extern "C" {
+ extern char *gets (char *__s) __attribute__((deprecated));
+}
+#endif
+
namespace std
{
using ::FILE;
[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534 --- Comment #3 from mgretton at gcc dot gnu.org 2012-02-28 16:14:03 UTC --- Author: mgretton Date: Tue Feb 28 16:13:52 2012 New Revision: 184629 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184629 Log: PR target/51534 * gcc/config/arm/arm.c (neon_builtin_data): Add entries for vcgeu and vcgtu. * gcc/config/arm/arm_neon.h: Regenerate. * gcc/config/arm/neon.md (unspec): Add UNSPEC_VCGEU, and UNSPEC_VCGTU. (neon_vcgeu): New insn. (neon_vcgtu): Likewise. * gcc/config/arm/neon.ml (s_8_32, u_8_32): New lists. (ops): Unsigned comparison intrinsics call a different builtin. * gcc/testsuite/gcc.target/arm/neon/pr51534.c: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon.md trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-02-28 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #8 from Jakub Jelinek 2012-02-28 16:14:52 UTC --- Created attachment 26772 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26772 gcc47-pr52397.patch Untested fix. Not sure if that is the way we want to solve this though.
[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534 --- Comment #4 from mgretton at gcc dot gnu.org 2012-02-28 16:17:44 UTC --- Author: mgretton Date: Tue Feb 28 16:17:36 2012 New Revision: 184630 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184630 Log: PR target/51534 Add testcase forgotten in last commit, ChangeLog entry already present. Added: trunk/gcc/testsuite/gcc.target/arm/neon/pr51534.c
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #15 from Jakub Jelinek 2012-02-28 16:18:30 UTC --- Ideally, when using #define _GNU_SOURCE #include in a C++ program ::gets wouldn't be available (the _GNU_SOURCE requests GNU namespace rather than standard C++ one), but when using #include #include it would provide it (with deprecated attribute), because then the user didn't request _GNU_SOURCE. But for that we'd need some new macro to request additional prototype for STL needs.
[Bug fortran/52151] Segfault with realloc on assignment and RESHAPE to unallocated LHS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52151 Tobias Burnus changed: What|Removed |Added CC||therobbot at gmail dot com --- Comment #7 from Tobias Burnus 2012-02-28 16:25:26 UTC --- *** Bug 52418 has been marked as a duplicate of this bug. ***
[Bug fortran/52418] (unnecessary) automatic reallocation of lhs causes segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52418 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Tobias Burnus 2012-02-28 16:25:26 UTC --- Aha, that's the bug report to the spurious attachment at PR 48058 comment 4. Thanks for the bug report and sorry for the breakage! As written there, that's a known bug affecting both GCC 4.6 and GCC 4.7. It has been reported on 2012-01-26 and fixed on 2012-01-31 for GCC 4.7 and on 2012-02-03 for GCC 4.7 [See PR 52151 for details.] A follow up fix (for RESHAPE when a reallocation is required) has been committed on 2012-02-08 for both GCC's 4.6 branch and the 4.7 trunk, cf. PR 52151. (For some reasons, no one has reported the bug for one year, but now there were two reports within a week and this one a month after the first report.) As written in PR 52117, you have the following options: > Unless you provide me with a time machine [...] > The only solutions, I see, which do not require code changes are: > > - Use any GCC version before GCC 4.6.0; for instance GCC 4.5.x > - Use GCC 4.6 older than 2010-11-28 > - Use a GCC (any version) newer than 2012-02-03 > - Use -fno-realloc-lhs (caveat: Flag not supported before GCC 4.6) > - Use -std=f95 (caveat: Requires that the code compiles without error with > -std=f95) > For completeness, also the following code changes are possible; except for > the first one, they are not recommended: > > - Use an array spec for allocatable LHS, e.g. "B(:,:,:) = " [And some more nonseriously meant variants] *** This bug has been marked as a duplicate of bug 52151 ***
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 --- Comment #9 from Eric Botcazou 2012-02-28 16:33:42 UTC --- > I wonder if df_reg_chain_unlink/df_install_ref shouldn't just ignore > DEBUG_INSN > refs when updating df->hard_regs_live_count array, do we care at all when > testing regs_ever_live if something is live in debug insns? Probably not. Moreover, hard_regs_live_count isn't used outside of df-scan.c as both df_hard_reg_used_p and df_hard_reg_used_count are only used there (in fact the latter isn't used at all and could be eliminated altogether).
[Bug fortran/48058] [4.6 Regression] reallocation of array during constructor assignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48058 --- Comment #6 from Robert Hayward 2012-02-28 16:36:52 UTC --- 48058(In reply to comment #4) > Created attachment 26770 [details] > test program to reproduce bug Sorry about that, attached to the wrong bug. It was meant for 52151.
[Bug bootstrap/52397] [4.7 regression] comparison failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52397 --- Comment #10 from Eric Botcazou 2012-02-28 16:41:04 UTC --- > Untested fix. Not sure if that is the way we want to solve this though. You might want to adjust the comment in df.h because it will be totally off.
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #16 from Paolo Carlini 2012-02-28 16:42:55 UTC --- I suppose that post 4.7.0 we have to revisit this issue anyway, because C++11 definitely wants to declare std::gets, irrespective of C11. I'm wondering if it would be possible to just take this into account in , I seem to remember that the glibc headers in a few places already use __cplusplus, right? We also have the __CORRECT_ISO_CPP_STRING_H_PROTO story as an example of interaction between glibc and C++. That said, for 4.7.0, I think that in any case we want: 1- To fully run the testsuite on a GNU/Linux system using glibc2.15; 2- Convince ourselves that whatever we do in the C++ library is not going to interact badly with further tweaks at the glibc level..
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #17 from joseph at codesourcery dot com 2012-02-28 17:05:50 UTC --- 2.15 has the gets prototype. It's 2.16 where it has been removed (but the version in the headers only changes from 2.15 to 2.16 when the final 2.16 release is made so you can't distinguish 2.15 from 2.16 development versions simply by examining preprocessor macros).
[Bug middle-end/52419] New: Wrong expansion of misaligned vector store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52419
Bug #: 52419
Summary: Wrong expansion of misaligned vector store
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamb...@gcc.gnu.org
CC: rgue...@gcc.gnu.org
Host: x86_64linux-gnu
Target: x86_64linux-gnu
Created attachment 26773
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26773
Testcase
When I compile the attached testcase, even at -O0, the resulting
binary aborts because the vector value is {5,3} instead of expected
{3,5}. When I remove the aligned and packed attributes, the testcase
works as expected.
[Bug target/52407] [4.6 Regression] sse2 simd uint32_t and int64_t and stack variable initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52407 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #8 from Martin Jambor 2012-02-28 18:09:48 UTC --- *** Bug 52419 has been marked as a duplicate of this bug. ***
[Bug middle-end/52419] Wrong expansion of misaligned vector store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52419 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Martin Jambor 2012-02-28 18:09:48 UTC --- Jakub pointed out on IRC that the problem was elsewhere. *** This bug has been marked as a duplicate of bug 52407 ***
[Bug libstdc++/51785] gets not anymore declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 --- Comment #18 from Paolo Carlini 2012-02-28 18:25:54 UTC --- Ah, thanks Joseph. Thus, to repeat, anything we do in terms of macros has to be for *2.16* and later.
[Bug ada/52420] New: ada build failure with -gdwarf-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52420 Bug #: 52420 Summary: ada build failure with -gdwarf-4 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: p...@mandriva.com.br Recently in mandriva it was added -gdwarf-4 as well as some other options, to rpm optflags, but to successfully build gcc 4.7.0 it is required to remove it from CFLAGS to avoid this build failure: [...] ../../xgcc -B../../ -c -g -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -fPIC -W -Wall -gnatpg -gnata -I- -I../rts -I. -I/home/pcpa/rpmbuild/BUILD/gcc-4.7-20120225/gcc/ada /home/pcpa/rpmbuild/BUILD/gcc-4.7-20120225/gcc/ada/mlib-prj.adb -o mlib-prj.o [...] ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. -I/home/pcpa/rpmbuild/BUILD/gcc-4.7-20120225/gcc/ada -DIN_GCC -g -O2 -Wa,--compress-debug-sections -gdwarf-4 -fvar-tracking-assignments -frecord-gcc-switches -Wstrict-aliasing=2 -fPIC -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o makeutl.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-tgt-specific.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-attr-pm.o prj-com.o prj-dect.o prj-env.o prj-conf.o prj-pp.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o urealp.o usage.o widechar.o \ targext.o link.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a ../../../libiberty/libiberty.a mlib-prj.o:(.debug_types[wt.d60ca0c82bc70253]+0x8a): undefined reference to `.LLST479' mlib-prj.o:(.debug_types[wt.41905a5a6a523ee9]+0x8f): undefined reference to `.LLST479' mlib-prj.o:(.debug_types[wt.0a43032d5d4a580b]+0x8a): undefined reference to `.LLST473' mlib-prj.o:(.debug_types[wt.36d40966de25ea99]+0x8f): undefined reference to `.LLST473' mlib-prj.o:(.debug_types[wt.5347ec71460dc53e]+0x8a): undefined reference to `.LLST455' mlib-prj.o:(.debug_types[wt.3096742ee216922d]+0x8f): undefined reference to `.LLST455' mlib-prj.o:(.debug_types[wt.d1642ddc76250466]+0x8a): undefined reference to `.LLST449' mlib-prj.o:(.debug_types[wt.0976701503715b70]+0x8f): undefined reference to `.LLST449' collect2: error: ld returned 1 exit status
[Bug target/52421] New: SH Target: -fnon-call-exceptions prevents delay slot filling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52421
Bug #: 52421
Summary: SH Target: -fnon-call-exceptions prevents delay slot
filling
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
When the -fnon-call-exceptions option is used delay slots might not be filled,
although they could.
int test (int x, int y)
{
return x == y;
}
compiled with -Os:
cmp/eqr5,r4! 7cmpeqsi_t/3[length = 2]
rts! 22*return_i[length = 2]
movtr0! 13movsi_i/8[length = 2]
compiled with -Os -fnon-call-exceptions
cmp/eqr5,r4! 7cmpeqsi_t/3[length = 2]
movtr0! 14movsi_i/8[length = 2]
rts
nop! 24*return_i[length = 4]
It seems this happens for all SH variants.
When compiled for SH2A the no-delay-slot-rts insn is picked:
cmp/eqr5,r4! 7cmpeqsi_t/3[length = 2]
movtr0! 14movsi_ie/10[length = 2]
rts/n! 28*return_i[length = 4]
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20120227 (experimental) (GCC)
[Bug c++/52422] New: [C++11][SFINAE] Hard errors with void or arithmetic expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52422
Bug #: 52422
Summary: [C++11][SFINAE] Hard errors with void or arithmetic
expressions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.7.0 20120225 (experimental) in C++11 mode produces a hard compiler error
during a sfinae-conforming situation involving function-like or pointer-like
expressions:
//---
template
struct add_rval_ref
{
typedef T&& type;
};
template<>
struct add_rval_ref
{
typedef void type;
};
template
typename add_rval_ref::type create();
template()()) // line 17
>
auto f(int) -> char(&)[1];
template
auto f(...) -> char(&)[2];
static_assert(sizeof(f(0)) != 1, "");
//---
"16|error: void value not ignored as it ought to be"
Here some further variations of the theme:
a) Replace line 17 by
class = decltype(*create()) // line 17
b) Replace above test by
//---
template
struct add_rval_ref
{
typedef T&& type;
};
template<>
struct add_rval_ref
{
typedef void type;
};
template
typename add_rval_ref::type create();
template().*create())() ) // line 17
>
auto f(int) -> char(&)[1];
template
auto f(...) -> char(&)[2];
static_assert(sizeof(f(0)) != 1, ""); // line 24
//---
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'add_rval_ref::type {aka void}'"
c) Replace in the test (b) line 24 by the following line:
static_assert(sizeof(f(0)) != 1, ""); // line 24
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'int'"
d) Replace line 17 in the test (b) by the following line and use either of
"void, void" or "int, int" as template arguments in line 24:
class = decltype( create().*create() )
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'add_rval_ref::type {aka void}'"
or
"17|error: 'create()' cannot be used as a member pointer, since it is of
type 'int'"
respectively.
[Bug middle-end/51752] trans-mem: publication safety violated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752 --- Comment #7 from Aldy Hernandez 2012-02-28 20:08:44 UTC --- Author: aldyh Date: Tue Feb 28 20:08:39 2012 New Revision: 184638 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184638 Log: PR middle-end/51752 * gimple.h (gimple_in_transaction): New. (gimple_set_in_transaction): New. (struct gimple_statement_base): Add in_transaction field. * tree-ssa-loop-im.c: (movement_possibility): Restrict movement of transaction loads. (tree_ssa_lim_initialize): Compute transaction bits. * tree.h (compute_transaction_bits): Protoize. * trans-mem.c (tm_region_init): Use the heap to store BB auxilliary data. (compute_transaction_bits): New. Added: trunk/gcc/testsuite/gcc.dg/tm/pub-safety-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.h trunk/gcc/trans-mem.c trunk/gcc/tree-ssa-loop-im.c
[Bug target/50946] ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW CC||doko at gcc dot gnu.org Known to work||4.5.3 Known to fail||4.6.3, 4.7.0 --- Comment #5 from Matthias Klose 2012-02-28 20:07:20 UTC --- works with 4.5 branch and trunk, still ftbfs with 4.6.
[Bug c++/51214] [4.7 Regression] [C++11] name lookup issue with c++11 enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51214
fabien at gcc dot gnu.org changed:
What|Removed |Added
Summary|[C++11] name lookup issue |[4.7 Regression] [C++11]
|with c++11 enums|name lookup issue with
||c++11 enums
--- Comment #2 from fabien at gcc dot gnu.org 2012-02-28 20:19:23 UTC ---
We can manage to mark this bug as a 4.7 Regression, evidence below (to be
compiled with -std=c++11 obviously).
struct Base
{
int b1, b2, b3;
};
struct T : Base
{
int t1, t2, t3;
using Base::b1;
using Base::b2;
using Base::b3;
enum E2 : int;
};
enum T::E2 : int { A1 = 23 };
int i = T::A1;
I have a patch for it.
[Bug libstdc++/52191] abi_check should flag additions to released versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52191 --- Comment #2 from Benjamin Kosnik 2012-02-28 20:21:13 UTC --- Created attachment 26774 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26774 patch to check new symbols are in new version names
[Bug libstdc++/52191] abi_check should flag additions to released versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52191 Benjamin Kosnik changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Benjamin Kosnik 2012-02-28 20:23:50 UTC --- Hey Ranier. This is as you requested. I expect you'll notice the new symbols now on solaris. I believe the new symbols should be conditionalized such that they are added in linux in the older version names, and on solaris in the new symbol names. Working on that now but prompt testresults from solaris with this patch (and the new fail) will be appreciated. -benjamin
