[Bug middle-end/55259] plus_constant doesn't handle zero-extended address properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55259
--- Comment #1 from H.J. Lu 2012-11-10 04:13:32
UTC ---
A potential fix:
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 95bbfa7..d7c454c 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2109,6 +2109,12 @@ adjust_address_1 (rtx memref, enum machine_mode mode,
HOS
T_WIDE_INT offset,
addr = gen_rtx_LO_SUM (address_mode, XEXP (addr, 0),
plus_constant (address_mode,
XEXP (addr, 1), offset));
+ else if (GET_CODE (addr) == ZERO_EXTEND)
+{
+ addr = XEXP (addr, 0);
+ addr = plus_constant (GET_MODE (addr), addr, offset);
+ addr = gen_rtx_ZERO_EXTEND (address_mode, addr);
+}
else
addr = plus_constant (address_mode, addr, offset);
}
[Bug c++/55249] [4.6/4.7/4.8 Regression] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Andrew Pinski changed: What|Removed |Added Known to work||4.4.5 Target Milestone|--- |4.6.4 Known to fail||4.7.0 --- Comment #7 from Andrew Pinski 2012-11-10 03:59:08 UTC --- Note with the reduced testcase to compile in C++98 mode, you have to do s/>>/> >/.
[Bug middle-end/55259] New: plus_constant doesn't handle zero-extended address properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55259 Bug #: 55259 Summary: plus_constant doesn't handle zero-extended address properly Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com For address, #0 plus_constant (mode=SImode, x=0x70fadf40, c=8) at /export/gnu/import/git/gcc/gcc/explow.c:211 #1 0x006f9b04 in adjust_address_1 (memref=0x70fff2e8, mode=DImode, offset=8, validate=1, adjust_address=1, adjust_object=0) at /export/gnu/import/git/gcc/gcc/emit-rtl.c:2113 #2 0x00cdd259 in split_double_mode (mode=TImode, operands=0x7fffd828, num=0, lo_half=0x7fffd8f0, hi_half=0x7fffd8f8) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:14721 #3 0x00ceafe7 in ix86_split_to_parts (operand=0x70fff2e8, parts=0x7fffd8f0, mode=TImode) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:20695 #4 0x00ceb4ad in ix86_split_long_move ( operands=0x17a5fa0 ) at /export/gnu/import/git/gcc/gcc/config/i386/i386.c:20794 Breakpoint 2, plus_constant (mode=DImode, x=0x70fadf30, c=8) at /export/gnu/import/git/gcc/gcc/explow.c:96 96 zero_extend_mode = GET_MODE (x); (gdb) call debug_rtx (x) (zero_extend:DI (reg:SI 0 ax [82])) (gdb) it should generate (gdb) call debug_rtx (x) (zero_extend:DI (plus:SI (reg:SI 0 ax [82]) (const_int 8 [0x8]))) (gdb) Instead, plus_constant generates (gdb) call debug_rtx (addr) (plus:DI (zero_extend:DI (reg:SI 0 ax [82])) (const_int 8 [0x8]))
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #6 from H.J. Lu 2012-11-10 02:30:16
UTC ---
Something like this:
diff --git a/gcc/explow.c b/gcc/explow.c
index 6109832..9ec38f9 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -84,12 +84,22 @@ plus_constant (enum machine_mode mode, rtx x, HOST_WIDE_INT
c)
rtx y;
rtx tem;
int all_constant = 0;
+ enum machine_mode zero_extend_mode;
gcc_assert (GET_MODE (x) == VOIDmode || GET_MODE (x) == mode);
if (c == 0)
return x;
+ if (GET_CODE (x) == ZERO_EXTEND)
+{
+ zero_extend_mode = GET_MODE (x);
+ x = XEXP (x, 0);
+ mode = GET_MODE (x);
+}
+ else
+zero_extend_mode = VOIDmode;
+
restart:
code = GET_CODE (x);
@@ -195,7 +205,11 @@ plus_constant (enum machine_mode mode, rtx x,
HOST_WIDE_INT
c)
else if (all_constant)
return gen_rtx_CONST (mode, x);
else
-return x;
+{
+ if (zero_extend_mode != VOIDmode)
+x = gen_rtx_ZERO_EXTEND (zero_extend_mode, x);
+ return x;
+}
}
^L
/* If X is a sum, return a new sum like X but lacking any constant terms.
diff --git a/gcc/recog.c b/gcc/recog.c
index ee68e30..d3dd591 100644
--- a/gcc/recog.c
+++ b/gcc/recog.c
@@ -1934,15 +1934,21 @@ int
offsettable_address_addr_space_p (int strictp, enum machine_mode mode, rtx y,
addr_space_t as)
{
- enum rtx_code ycode = GET_CODE (y);
+ enum rtx_code ycode;
rtx z;
- rtx y1 = y;
+ rtx y1;
rtx *y2;
int (*addressp) (enum machine_mode, rtx, addr_space_t) =
(strictp ? strict_memory_address_addr_space_p
: memory_address_addr_space_p);
unsigned int mode_sz = GET_MODE_SIZE (mode);
+ if (GET_CODE (y) == ZERO_EXTEND)
+y = XEXP (y, 0);
+
+ ycode = GET_CODE (y);
+ y1 = y;
+
if (CONSTANT_ADDRESS_P (y))
return 1;
[Bug target/55258] New: SSE register isn't used for 16byte copy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55258
Bug #: 55258
Summary: SSE register isn't used for 16byte copy
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
[hjl@gnu-tools-1 pr55247]$ cat x.i
typedef unsigned int uint32_t;
typedef uint32_t Elf32_Word;
typedef uint32_t Elf32_Addr;
typedef struct {
Elf32_Word st_name;
Elf32_Addr st_value;
Elf32_Word st_size;
unsigned char st_other;
} Elf32_Sym;
typedef struct {
Elf32_Word r_info;
}
Elf32_Rela;
typedef struct {
union {
Elf32_Addr d_ptr;
}
d_un;
} Elf32_Dyn;
struct link_map {
Elf32_Dyn *l_info[34];
};
extern void symbind32 (Elf32_Sym *);
void
_dl_profile_fixup (struct link_map *l, Elf32_Word reloc_arg)
{
const Elf32_Sym *const symtab = (const void *) l->l_info[6]->d_un.d_ptr;
const Elf32_Rela *const reloc = (const void *) (l->l_info[23]->d_un.d_ptr +
reloc_arg * sizeof (Elf32_Rela));
Elf32_Sym sym = symtab[(reloc->r_info) >> 8];
symbind32 (&sym);
}
[hjl@gnu-tools-1 pr55247]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -Wall -mx32
-maddress-mode=short -S x.i -o short.asm
[hjl@gnu-tools-1 pr55247]$ cat short.asm
.file"x.i"
.text
.globl_dl_profile_fixup
.type_dl_profile_fixup, @function
_dl_profile_fixup:
.LFB0:
.cfi_startproc
subl$24, %esp
.cfi_def_cfa_offset 32
movl24(%edi), %edx
movl92(%edi), %eax
movl(%eax), %eax
movl(%eax,%esi,4), %eax
shrl$8, %eax
sall$4, %eax
addl(%edx), %eax
movq8(%eax), %rdx
movq(%eax), %rax
movq%rax, (%esp)
movq%rdx, 8(%esp)
movl%esp, %edi
callsymbind32
addl$24, %esp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size_dl_profile_fixup, .-_dl_profile_fixup
.ident"GCC: (GNU) 4.8.0 20121110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 pr55247]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O -Wall -mx32
-maddress-mode=long -S x.i -o long.asm
[hjl@gnu-tools-1 pr55247]$ cat long.asm
.file"x.i"
.text
.globl_dl_profile_fixup
.type_dl_profile_fixup, @function
_dl_profile_fixup:
.LFB0:
.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movl24(%rdi), %edx
movl92(%rdi), %eax
movl(%rax), %eax
movl(%eax,%esi,4), %eax
shrl$8, %eax
sall$4, %eax
addl(%rdx), %eax
movdqu(%eax), %xmm0
movdqa%xmm0, (%rsp)
movq(%rsp), %rax
movq8(%rsp), %rdx
movq%rax, 16(%rsp)
movq%rdx, 24(%rsp)
leaq16(%rsp), %rdi
callsymbind32
addq$40, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size_dl_profile_fixup, .-_dl_profile_fixup
.ident"GCC: (GNU) 4.8.0 20121110 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tools-1 pr55247]$
For TARGET_SSE_UNALIGNED_LOAD_OPTIMAL/TARGET_SSE_UNALIGNED_STORE_OPTIMAL,
we should always generate
movdqu(%eax), %xmm0
movdqa%xmm0, (%rsp)
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #5 from H.J. Lu 2012-11-10 01:58:31 UTC --- We fail to see (mem:TI (zero_extend:DI (reg:SI 82))) is offsettable.
[Bug debug/55257] New: [4.8 Regression]: g++.dg/debug/dwarf2/non-virtual-thunk.C scan-assembler thunk.C:30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55257 Bug #: 55257 Summary: [4.8 Regression]: g++.dg/debug/dwarf2/non-virtual-thunk.C scan-assembler thunk.C:30 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: ja...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf Created attachment 28649 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28649 non-virtual-thunk.s This test previously passed, now it fails. A patch in the revision range (last_known_working:first_known_failing) 19:193342 exposed or caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2.exp ... FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 scan-assembler thunk.C:30 FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++11 scan-assembler thunk.C:30 No extra clue in g++.log. Executing on host: /tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../g++ -B/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../ /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/debug/dwarf2/non-virtual-thunk.C -fno-diagnostics-show-caret -nostdinc++ -I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/libsupc++ -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/include/backward -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -g2 -dA -ffat-lto-objects -S -isystem /tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc0/gcc/newlib/libc/include -o non-virtual-thunk.s (timeout = 300) PASS: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/debug/dwarf2/non-virtual-thunk.C -std=gnu++98 scan-assembler thunk.C:30 (same for -std=gnu++11) There's no "thunk.C:30" in the assembly file, just lots of: ";# /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/debug/dwarf2/non-virtual-thunk.C:33" See the attached non-virtual-thunk.s. Author of suspect patch in revision range CC:ed.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
--- Comment #4 from H.J. Lu 2012-11-10 01:39:16
UTC ---
We don't properly handle memory operand in
(insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
(mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
{*movti_internal_rex64}
(expr_list:REG_DEAD (reg:SI 82)
(expr_list:REG_EQUIV (mem/c:TI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [0 sym+0 S16 A64])
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247 --- Comment #3 from H.J. Lu 2012-11-10 01:32:06 UTC --- There are 2 issues here: 1. Should we use movdqu(%eax), %xmm0# 19*movti_internal_rex64/4[length = 5] movdqa%xmm0, (%rsp)# 29*movti_internal_rex64/5[length = 5] to copy 16 bytes? 2. Should we split *movti_internal_rex64 if -mno-sse is used?
[Bug target/29206] [4.6/4.7/4.8 regression] gcj-dbtool segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 --- Comment #22 from dave.anglin at bell dot net 2012-11-10 01:28:52 UTC --- If possible, I think SJLJ support should go. I can't remember the exact status of SJLJ for HP-UX 10 but a comment in hpux-unwind.h suggests that I tested dwarf2 support. I can check but it will take time. Dave -- John David Anglindave.ang...@bell.net
[Bug rtl-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54942 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Steven Bosscher 2012-11-09 23:42:48 UTC --- Fixed along the way, probably by one of Honza's many patches in this area.
[Bug rtl-optimization/54993] [4.8 regression] PIC register not marked as live
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54993 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Steven Bosscher 2012-11-09 23:40:48 UTC --- Fixed by revert.
[Bug middle-end/21953] [4.6/4.7/4.8 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #20 from Steven Bosscher 2012-11-09 23:34:39 UTC --- Tru64 v5.1 is no longer supported as of GCC 4.8.
[Bug middle-end/34226] [4.6/4.7/4.8 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||steven at gcc dot gnu.org Resolution||WORKSFORME --- Comment #21 from Steven Bosscher 2012-11-09 23:32:29 UTC --- Doesn't ice for me at trunk r193358.
[Bug other/51937] [meta-bug] GCC 4.8 pending patches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51937 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Steven Bosscher 2012-11-09 23:27:19 UTC --- Nothing is pending anymore.
[Bug preprocessor/55256] New: Out of memory preprocessing nested tgmath.h functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55256
Bug #: 55256
Summary: Out of memory preprocessing nested tgmath.h functions
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: net...@gmail.com
#include
int main(void) { sqrt(sqrt(sqrt(sqrt(1; }
cc1 runs out of memory. This problem has been observed with GCC 4.7.2 on Arch
Linux 32-bit and Linaro GCC 4.7.2 on Ubuntu 12.10 32-bit. It was started
occurring from around GCC 4.7.0.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.2 (GCC)
[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #9 from Steven Bosscher 2012-11-09 23:26:36 UTC --- .
[Bug java/42143] [4.6/4.7/4.8 Regression] gcj creates "dummy" variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42143 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID Known to fail|| --- Comment #12 from Steven Bosscher 2012-11-09 23:21:27 UTC --- If it comes from ecj, it's not a gcc bug. (see bug 43302)
[Bug java/43302] [Regression] gcc creates "dummy" resources in object files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43302 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Steven Bosscher 2012-11-09 23:21:02 UTC --- If it comes from ecj, it's not a gcc bug.
[Bug libgcj/40180] [4.6/4.7/4.8 regression] regressions in libjava testsuite on ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED Known to fail|| --- Comment #3 from Steven Bosscher 2012-11-09 23:18:57 UTC --- Fixed somewhere along the way. http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00811.html
[Bug target/38642] [4.6/4.7/4.8 Regression] Code with -fPIC results in segfault on ARM (old ABI)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642 Steven Bosscher changed: What|Removed |Added Status|WAITING |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #11 from Steven Bosscher 2012-11-09 23:17:01 UTC --- Old ABI is no longer supported
[Bug tree-optimization/32306] [4.6/4.7/4.8 Regression] redundant && || not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306 --- Comment #22 from Steven Bosscher 2012-11-09 23:13:53 UTC --- (In reply to comment #19) > Shorter testcase, compilable and to the point. We are not able to CSE > the b1 && ... && b8 sequence because we produce control-flow for it > during gimplification. Do you know why that is so?
[Bug testsuite/55229] [4.8 Regression] FAIL: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunroll "Unrolled loop 1 completely"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55229 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson 2012-11-09 23:09:58 UTC --- Universal; at least i686-, x86_64-linux and cris-elf too. I wonder where this passes...
[Bug target/29206] [4.6/4.7/4.8 regression] gcj-dbtool segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206 Steven Bosscher changed: What|Removed |Added Status|WAITING |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID --- Comment #21 from Steven Bosscher 2012-11-09 23:07:43 UTC --- No response.
[Bug target/27855] [4.5/4.7/4.8 regression] reassociation causes the RA to be confused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855 --- Comment #42 from Steven Bosscher 2012-11-09 23:06:18 UTC --- It'd be interesting to get some new timings, with the new register-pressure aware scheduling and with LRA. Oh, and maybe with the patch to restrain the reassoc pass a bit (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02122.html).
[Bug java/24698] [4.6/4.7/4.8 regression] SIGABRT when using ResourceBundle.getBundle with a nonexistant key
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24698 Steven Bosscher changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #26 from Steven Bosscher 2012-11-09 22:52:39 UTC --- No feedback since January on this really old bug -> resolved (as INVALID for lack of a better option).
[Bug target/24334] [4.6/4.7/4.8 regression] IRIX 6.5 bootstrap failure with SGI 7.4.6/4.7/4.8m ld: GOT overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24334 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #16 from Steven Bosscher 2012-11-09 22:49:09 UTC --- IRIX support has been removed for GCC 4.8, and will not be fixed on the open release branches.
[Bug tree-optimization/23835] [4.6/4.7/4.8 Regression] -O3 compile takes two times longer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #35 from Steven Bosscher 2012-11-09 22:46:30 UTC --- This bug is no longer relevant, the IA64 scheduler at -O3 has been replaced completely (by the selective scheduler) and the remaining non-scheduler slowdowns are all due to inherently non-linear algorithms, downsides that you just get along with the benefits of SSA. So WONTFIX.
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
--- Comment #27 from Oleg Endo 2012-11-09
22:41:15 UTC ---
(In reply to comment #26)
Another way that fixes the problem mentioned above is to not allow non-float
mode operands in the first place. The patch below also fixes the failure, but
requires some more work to be complete.
A strange thing I've noticed:
(define_expand "addsf3"
[(set (match_operand:SF 0 "arith_reg_operand" "")
(plus:SF (match_operand:SF 1 "arith_reg_operand" "")
(match_operand:SF 2 "arith_reg_operand" "")))]
"TARGET_SH2E || TARGET_SHMEDIA_FPU"
It seems there should be a prefix "fp_" in the operand predicate names.
Anyway ..
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md(revision 193342)
+++ gcc/config/sh/predicates.md(working copy)
@@ -319,16 +319,23 @@
if (register_operand (op, mode))
{
int regno;
+ machine_mode m;
if (REG_P (op))
-regno = REGNO (op);
+{
+ regno = REGNO (op);
+ m = GET_MODE (op);
+}
else if (GET_CODE (op) == SUBREG && REG_P (SUBREG_REG (op)))
-regno = REGNO (SUBREG_REG (op));
+{
+ regno = REGNO (SUBREG_REG (op));
+ m = GET_MODE (SUBREG_REG (op));
+}
else
return 1;
- return (regno >= FIRST_PSEUDO_REGISTER
- || FP_REGISTER_P (regno));
+ return (regno >= FIRST_PSEUDO_REGISTER || FP_REGISTER_P (regno))
+ && GET_MODE_CLASS (m) == MODE_FLOAT;
}
return 0;
})
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 193342)
+++ gcc/config/sh/sh.c(working copy)
@@ -876,7 +876,7 @@
if ((flag_pic && ! TARGET_PREFERGOT)
|| (TARGET_SHMEDIA && !TARGET_PT_FIXED))
flag_no_function_cse = 1;
-
+#if 0
if (targetm.small_register_classes_for_mode_p (VOIDmode))\
{
/* Never run scheduling before reload, since that can
@@ -903,6 +903,7 @@
&& !global_options_set.x_flag_schedule_insns)
flag_schedule_insns = 0;
}
+#endif
/* Unwind info is not correct around the CFG unless either a frame
pointer is present or M_A_O_A is set. Fixing this requires rewriting
@@ -10069,6 +10070,9 @@
void
expand_sf_binop (rtx (*fun) (rtx, rtx, rtx, rtx), rtx *operands)
{
+ operands[0] = force_reg (SFmode, operands[0]);
+ operands[1] = force_reg (SFmode, operands[1]);
+ operands[2] = force_reg (SFmode, operands[2]);
emit_sf_insn ((*fun) (operands[0], operands[1], operands[2],
get_fpscr_rtx ()));
}
[Bug c++/22488] [4.6/4.7/4.8 Regression] push_fields_onto_fieldstack calculates offset incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488 Steven Bosscher changed: What|Removed |Added Keywords||alias Status|ASSIGNED|WAITING CC|dberlin at gcc dot gnu.org, | |gcc-bugs at gcc dot | |gnu.org, mark at| |codesourcery dot com| --- Comment #55 from Steven Bosscher 2012-11-09 22:37:34 UTC --- -ENOPROGRESS What is the status of this bug, Jason?
[Bug libgcj/21714] [4.6/4.7/4.8 Regression] libjava bootstrap failure in java/lang/natConcreteProcess.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21714 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||WONTFIX --- Comment #16 from Steven Bosscher 2012-11-09 22:34:33 UTC --- Let's be realistic about this: WONTFIX.
[Bug target/15184] [4.6/4.7/4.8 Regression] Direct access to byte inside word not working with -march=pentiumpro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184 Steven Bosscher changed: What|Removed |Added Priority|P5 |P3 Last reconfirmed|2005-05-28 18:17:13 |2012-11-09 18:17:13 CC||steven at gcc dot gnu.org Known to fail|| --- Comment #20 from Steven Bosscher 2012-11-09 22:32:30 UTC --- (In reply to comment #13) This is indeed pretty bad. Works with GCC 4.1, fails with GCC 4.3 and with current top-of-trunk, and for all i686 variants including relatively new CPUs based on the P6 micro-architecture, like core2 and atom. I disagree with comment #10, and I don't think this problem is minor. The code of the test case is common idiom that should be optimized properly. Please can the RMs have a new look at this.
[Bug bootstrap/15212] [4.6/4.7/4.8 Regression] bootstrap fails on interix3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212 Steven Bosscher changed: What|Removed |Added CC||rupp at gnat dot com Known to fail|| --- Comment #44 from Steven Bosscher 2012-11-09 22:22:35 UTC --- Douglas, could you, as the de facto interix maintainer, please have a look at the patches in comment #31, comment #36, and comment #37?
[Bug target/28968] gcc/config/i386/winnt-stubs.c is not linked in -> build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28968 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Steven Bosscher 2012-11-09 22:17:30 UTC --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00011.html
[Bug middle-end/54961] FAIL: gfortran.dg/pr48757.f -O (internal compiler error) after revision 192440
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54961 Steven Bosscher changed: What|Removed |Added Target Milestone|4.8.0 |--- Summary|[4.8 Regression] FAIL: |FAIL: gfortran.dg/pr48757.f |gfortran.dg/pr48757.f -O | -O (internal compiler |(internal compiler error) |error) after revision |after revision 192440 |192440
[Bug fortran/55255] [4.6 Regression] Compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55255 --- Comment #2 from janus at gcc dot gnu.org 2012-11-09 22:05:20 UTC --- Slightly reduced test case: MODULE MY_ARRAY TYPE ARRAY REAL, ALLOCATABLE :: VALS END TYPE CONTAINS TYPE(ARRAY) FUNCTION MAKE_ARRAY() END FUNCTION SUBROUTINE PRINT_ARRAY(Y) TYPE(ARRAY) :: Y END SUBROUTINE END MODULE PROGRAM MAIN USE MY_ARRAY CALL PRINT_ARRAY(MAKE_ARRAY()) END PROGRAM MAIN
[Bug testsuite/55229] UNRESOLVED: gcc.dg/tree-ssa/cunroll-1.c scan-tree-dump cunroll "Unrolled loop 1 completely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55229 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 Ever Confirmed|0 |1 --- Comment #3 from Steven Bosscher 2012-11-09 22:03:51 UTC --- Fails on powerpc64 too.
[Bug target/22553] [4.6/4.7/4.8 regression] ICE building libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
--- Comment #26 from Oleg Endo 2012-11-09
21:44:16 UTC ---
I've tried enabling sched1 on rev 193341 and ran the test suite with
make -k -j4 check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
I got one failure for -m2a, -m4 -m4a (both, -ml and -mb):
FAIL: gcc.dg/pr42475.c (internal compiler error)
The error is:
sh_tmp.cpp: In function 'baz':
sh_tmp.cpp:25:1: error: unable to find a register to spill in class 'R0_REGS'
}
^
sh_tmp.cpp:25:1: error: this is the insn:
(insn 18 31 42 2 (parallel [
(set (subreg:SF (reg:SI 1 r1 [orig:174 D.1383+4 ] [174]) 0)
(mult:SF (reg:SF 171)
(reg:SF 65 fr1 [orig:170 p.c.z ] [170])))
(use (reg/v:PSI 151 ))
]) sh_tmp.cpp:24 426 {mulsf3_i}
(expr_list:REG_DEAD (reg:SF 171)
(expr_list:REG_DEAD (reg:SF 65 fr1 [orig:170 p.c.z ] [170])
(expr_list:REG_DEAD (reg/v:PSI 151 )
(nil)
sh_tmp.cpp:25:1: internal compiler error: in spill_failure, at reload1.c:2124
A GP reg is supposed to receive the result of an FP operation, which the SH
actually can't do. It has to go through FPUL.
The error occurs because sched1 hoists a load of r0 (part of the return value)
before the failing insn:
(insn 31 15 18 2 (set (reg:SI 0 r0)
(const_int 0 [0])) sh_tmp.cpp:25 244 {movsi_ie}
(nil))
(insn 18 31 42 2 (parallel [
(set (subreg:SF (reg:SI 174 [ D.1383+4 ]) 0)
(mult:SF (reg:SF 170 [ p.c.z ])
(reg:SF 171)))
The result value transfer from FP reg to GP reg (through FPUL) seems to go a
long way during reload, and one the insns that reload checks has a R0 clobber
(not sure which one, but there are a couple of reload insns with a =&z
constraint).
On option to fix this is to split such insns. The patch below fixes the test
case failure, but I haven't re-tested it completely.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md(revision 193342)
+++ gcc/config/sh/sh.md(working copy)
@@ -12077,6 +12077,32 @@
[(set_attr "type" "fp")
(set_attr "fp_mode" "single")])
+;; If the output of a floating-point operation is to be stored in a GP reg
+;; the target GP output reg might be propagated as a subreg into floating-
+;; point insns. If we split the operation and the GP reg store
+;; (through FPUL) into separate insns before reload some trouble can be
+;; avoided during reload.
+(define_split
+ [(set (match_operand:SF 0 "fp_arith_reg_operand")
+(match_operator:SF 1 "float_operator"
+ [(match_operand:SF 2 "fp_arith_reg_operand")
+ (match_operand:SF 3 "fp_arith_reg_operand")]))
+ (use (match_operand:PSI 4 "fpscr_operand"))]
+ "TARGET_SH2E
+ && can_create_pseudo_p () && GET_CODE (operands[0]) == SUBREG
+ && REG_P (SUBREG_REG (operands[0]))
+ && GET_MODE (SUBREG_REG (operands[0])) != SFmode"
+ [(parallel [(set (match_dup 5) (match_dup 6))
+ (use (match_dup 4))])
+ (parallel [(set (match_dup 0) (match_dup 5))
+ (use (match_dup 4))
+ (clobber (reg:SI FPUL_REG))])]
+{
+ operands[5] = gen_reg_rtx (SFmode);
+ operands[6] = gen_rtx_fmt_ee (GET_CODE (operands[1]), SFmode, operands[2],
+operands[3]);
+})
+
;; FMA (fused multiply-add) patterns
(define_expand "fmasf4"
[(set (match_operand:SF 0 "fp_arith_reg_operand" "")
Index: gcc/config/sh/predicates.md
===
--- gcc/config/sh/predicates.md(revision 193342)
+++ gcc/config/sh/predicates.md(working copy)
@@ -1156,3 +1156,9 @@
return false;
})
+
+(define_predicate "float_operator"
+ (ior (match_operand 0 "binary_float_operator")
+ (match_operand 0 "commutative_float_operator")
+ (match_operand 0 "noncommutative_float_operator")
+ (match_operand 0 "unary_float_operator")))
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 193342)
+++ gcc/config/sh/sh.c(working copy)
@@ -877,6 +877,7 @@
|| (TARGET_SHMEDIA && !TARGET_PT_FIXED))
flag_no_function_cse = 1;
+#if 0
if (targetm.small_register_classes_for_mode_p (VOIDmode))\
{
/* Never run scheduling before reload, since that can
@@ -903,6 +904,7 @@
&& !global_options_set.x_flag_schedule_insns)
flag_schedule_insns = 0;
}
+#endif
/* Unwind info is not correct around the CFG unless either a frame
pointer is present or M_A_O_A is set. Fixing this requires rewriting
[Bug other/52438] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 --- Comment #7 from Eric Botcazou 2012-11-09 21:42:25 UTC --- Author: ebotcazou Date: Fri Nov 9 21:42:21 2012 New Revision: 193376 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193376 Log: PR other/52438 * s-taspri-lynxos.ads: Delete. * s-osinte-kfreebsd-gnu.ads: Change license to GPL V3+. * s-tpopsp-rtems.adb: Likewise. * s-osinte-rtems.adb: Likewise. Removed: branches/gcc-4_7-branch/gcc/ada/s-taspri-lynxos.ads Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/s-osinte-kfreebsd-gnu.ads branches/gcc-4_7-branch/gcc/ada/s-osinte-rtems.adb branches/gcc-4_7-branch/gcc/ada/s-tpopsp-rtems.adb
[Bug other/52438] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 --- Comment #6 from Eric Botcazou 2012-11-09 21:42:06 UTC --- Author: ebotcazou Date: Fri Nov 9 21:42:02 2012 New Revision: 193375 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193375 Log: PR other/52438 * s-taspri-lynxos.ads: Delete. * s-osinte-kfreebsd-gnu.ads: Change license to GPL V3+. * s-tpopsp-rtems.adb: Likewise. * s-osinte-rtems.adb: Likewise. Removed: trunk/gcc/ada/s-taspri-lynxos.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-rtems.adb trunk/gcc/ada/s-tpopsp-rtems.adb
[Bug middle-end/41004] missed merge of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004
Steven Bosscher changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
Target Milestone|--- |4.8.0
Known to fail||4.8.0
--- Comment #10 from Steven Bosscher 2012-11-09
21:38:39 UTC ---
Resulting code from trunk r193358
primal_update_flow:
push{r4, r5, lr}
mov r3, #1
mov r4, #0
.L2:
cmp r0, r2
beq .L11
ldr r5, [r0]
cmp r5, #0
beq .L3
str r4, [r0, #8]
b .L4
.L3:
str r3, [r0, #8]
.L4:
ldr r0, [r0, #4]
b .L2
.L11:
mov r0, #1
.L6:
cmp r1, r2
beq .L12
ldr r3, [r1]
cmp r3, #0
beq .L7
str r0, [r1, #8]
b .L8
.L7:
str r3, [r1, #8]
.L8:
ldr r1, [r1, #4]
b .L6
.L12:
@ sp needed
pop {r4, r5, pc}
So the issue of comment #0 is fixed.
With "-march=armv7 -mthumb" the stores to "[r0,#8]" and "[r0,#8]" are
properly if-converted, I don't see anything that could be improved
further. So, fixed.
[Bug fortran/55255] [4.6 Regression] Compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55255 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||janus at gcc dot gnu.org Summary|Compiler segmentation fault |[4.6 Regression] Compiler ||segmentation fault Ever Confirmed|0 |1 Severity|critical|normal --- Comment #1 from janus at gcc dot gnu.org 2012-11-09 21:19:45 UTC --- I can confirm the error with: gcc version 4.6.0 20110505 [gcc-4_6-branch revision 173419] (SUSE Linux) However, all other versions I tried compile the test case correctly (including 4.3, 4.5, 4.7 and trunk).
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||dodji at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez 2012-11-09 21:02:20 UTC --- I think this his how the macro expansion was designed to work: It shows the location of the token that triggered the error. I also agree that the clang way makes more sense in this case.
[Bug testsuite/55230] UNSUPPORTED: g++.dg/mv1.C -std=gnu++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55230
--- Comment #1 from Sriraman Tallam 2012-11-09
20:31:41 UTC ---
(In reply to comment #0)
> Caused by:
> http://gcc.gnu.org/viewcvs?view=revision&revision=193204
>
> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
> /* { dg-require-ifunc "" } */
>
> If these tests are x86-x86_64 specific, they should be in the target-specific
> directory presumably?
>
> Thanks,
> Kyrill
I dont see any C++ tests in gcc.target. I also see other C++ tests doing the
same thing in g++.dg, example:
testsuite/g++.dg/pr45788.C:// { dg-do compile { target x86_64-*-* } }
Alright?
[Bug preprocessor/55242] continued lines not always merged into one long line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55242 --- Comment #1 from Dmitry Gorbachev 2012-11-09 20:23:47 UTC --- It's a "feature", not a bug (see PR41748, PR45696, and PR48383). Perhaps it should be mentioned in the preprocessor documentation.
[Bug fortran/55255] New: Compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55255 Bug #: 55255 Summary: Compiler segmentation fault Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: everettyou.inter...@gmail.com * version: 4.6.2 20111019 (prerelease) (GCC) * system type: Mac OS 10.7.4 * built command: gfortran -o BUG BUG.f90 -save-temps -J ./build * bug behavior: compiler throws internal compiler error: Segmentation fault * source files: BUG.f90 ! --- MODULE MY_ARRAY TYPE ARRAY REAL, ALLOCATABLE :: VALS(:) END TYPE ARRAY CONTAINS FUNCTION MAKE_ARRAY(X) RESULT(Y) REAL, INTENT(IN) :: X(:) TYPE(ARRAY) :: Y Y%VALS = X END FUNCTION MAKE_ARRAY SUBROUTINE PRINT_ARRAY(Y) TYPE(ARRAY), INTENT(IN) :: Y PRINT *, Y%VALS END SUBROUTINE PRINT_ARRAY END MODULE MY_ARRAY PROGRAM MAIN USE MY_ARRAY CALL PRINT_ARRAY(MAKE_ARRAY((/1.,2./))) END PROGRAM MAIN ! --
[Bug tree-optimization/54916] [4.8 Regression] wrong code with -O2 -funroll-loops -fno-rerun-cse-after-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54916 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Steven Bosscher 2012-11-09 19:43:43 UTC --- The issue here was a bad REG_EQUAL note. This was fixed some time ago.
[Bug rtl-optimization/55247] [4.8 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55247
Vladimir Makarov changed:
What|Removed |Added
CC||ubizjak at gmail dot com
--- Comment #2 from Vladimir Makarov 2012-11-09
19:42:30 UTC ---
Here is the insn in question:
(insn 26 25 27 2 (set (reg:TI 115 [orig:100 *defsym_17 ] [100])
(mem:TI (zero_extend:DI (reg:SI 98)) [7 *defsym_17+0 S16 A32])) h.i:54
61 {*movti_internal_rex64}
As I understand the first alternative has ! to strongly encourage to use SSE
instead of GENERAL registers.
(define_insn "*movti_internal_rex64"
[(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,o ,x,x ,m")
(match_operand:TI 1 "general_operand" "riFo,riF,C,xm,x"))]
"TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
For some reasons, the second alternative does not have !. I don't know why it
is different from the first alternative.
For reload it works as it already substituted hard register for the first
operand and in this case it rejects
the 2nd alternative.
(insn 26 25 27 2 (set (reg:TI 0 ax [orig:100 *defsym_17 ] [100])
(mem:TI (zero_extend:DI (reg:SI 2 cx [98])) [7 *defsym_17+0 S16 A32]))
h.i:54 61 {*movti_internal_rex64}
Adding ! for the second alternative (as I believe it should be) solves the
problem.
(define_insn "*movti_internal_rex64"
[(set (match_operand:TI 0 "nonimmediate_operand" "=!r ,!o ,x,x ,m")
(match_operand:TI 1 "general_operand" "riFo,riF,C,xm,x"))]
"TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
Uros, is this change ok for you? If it is ok I can commit the patch only on
Wednesday (I'll be away for a few days).
[Bug other/52438] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Steven Bosscher 2012-11-09 19:38:36 UTC --- (In reply to comment #2) > > FSF not (only) copyright holder (so can't change license?): > > * gcc/ada/s-osinte-kfreebsd-gnu.ads > > * gcc/ada/s-osinte-rtems.adb > > * gcc/ada/s-taspri-lynxos.ads > > * gcc/ada/s-tpopsp-rtems.adb > > Pure oversight, all other similar files were changed. These files still have the GPLv2 header, but with "or later". All other files have the GPLv3 header now, so this is FIXED.
[Bug c/46480] [trans-mem] Uninstrumented code path is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46480 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Aldy Hernandez 2012-11-09 18:50:02 UTC --- Implemented on mainline. Yay yay!
[Bug c++/55254] New: Warn for implicit conversion from int to char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55254
Bug #: 55254
Summary: Warn for implicit conversion from int to char
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@doublewise.net
I sometimes want to construct a string with n copies of a char c. However, I
frequently get the order of elements in the constructor mixed up. Rather than
saying std::string(80, '='), I accidentally call std::string('=', 80).
To me, it seems like the underlying issue here is that gcc does not warn for
implicit conversion from int to char. Whenever I assign a literal to a char, I
always assign something wrapped in single quotes, never an integer literal.
However, I would suggest that perhaps this warning should have two levels. The
first level would only warn for char. The second level would warn for char,
signed char, and unsigned char. The reason for this separation is that int8_t
is a typedef for signed char and uint8_t is a typedef for unsigned char (on
most platforms), and those are regularly used as "small integers" (I use them
extensively in space-sensitive code). My experience is that when people use a
signed / unsigned char explicitly, or one of the typedefs in cstdint /
stdint.h, they are not used as actual characters, but bytes / small numbers,
and in that case, assigning from an integer wouldn't be incorrect.
[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|jason at gcc dot gnu.org| Resolution||FIXED --- Comment #5 from Paolo Carlini 2012-11-09 18:23:57 UTC --- This is fixed then.
[Bug tree-optimization/55253] New: [4.8 Regression] Revision 193298 miscompiles sqlite with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55253 Bug #: 55253 Summary: [4.8 Regression] Revision 193298 miscompiles sqlite with -Os Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de r193298 miscompiles sqlite with -Os (and thereby crashes Firefox during startup): Program received signal SIGSEGV, Segmentation fault. sqlite3DbRealloc (db=0x0, p=p@entry=0x0, n=n@entry=9) at sqlite3.c:19120 (gdb) bt #0 sqlite3DbRealloc (db=0x0, p=p@entry=0x0, n=n@entry=9) at sqlite3.c:19120 #1 0x77f908e5 in sqlite3StrAccumAppend (p=0x7fffcdb8, z=0x4082e9 "sqlite> ", N=8) at sqlite3.c:19966 #2 0x77f909d9 in sqlite3VXPrintf (pAccum=0x7fffcdb8, useExtended=0, fmt=0x4082f1 "", ap=0x7fffcdf8) at sqlite3.c:19449 #3 0x77f91754 in sqlite3_vsnprintf (n=0, zBuf=0x0, zFormat=0x9 , ap=ap@entry=0x7fffcdf8) at sqlite3.c:20140 #4 0x77f917e8 in sqlite3_snprintf (n=n@entry=20, zBuf=zBuf@entry=0x40b4a0 "", zFormat=zFormat@entry=0x4082e9 "sqlite> ") at sqlite3.c:20147 #5 0x004063f5 in main_init (data=0x7fffcef8) at shell.c:2845 #6 main (argc=2, argv=0x7fffe558) at shell.c:2864 -O2 or -O3 are fine.
[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Jonathan Wakely changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Jonathan Wakely 2012-11-09 18:08:40 UTC --- clang++ gets this right, printing the same thing with or without the system_header pragma, and swapping the locations of the error and the note: In file included from test.cc:2: ./header.h:1:5: error: expected unqualified-id int bar = 0; ^ test.cc:1:13: note: expanded from macro 'bar' #define bar 1 ^ 1 error generated. This makes much more sense.
[Bug c++/55252] New: Caret diagnostic doesn't show useful location when macro clashes with name in system header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 Bug #: 55252 Summary: Caret diagnostic doesn't show useful location when macro clashes with name in system header Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org (preprocessed source doesn't show the error due to the system_header pragma) $ cat test.cc #define bar 1 #include "header.h" $ cat header.h #pragma GCC system_header int bar = 0; $ g++ test.cc test.cc:1:13: error: expected unqualified-id before numeric constant #define bar 1 ^ This is no help because it doesn't point you to the line in header.h that clashes with 'bar' Without the system_header pragma you get test.cc:1:13: error: expected unqualified-id before numeric constant #define bar 1 ^ header.h:2:5: note: in expansion of macro 'bar' int bar = 0; ^ Which at least shows both locations, although the first diagnostic is still confusing ... are the two locations backwards? The "expected unqualified-id before numeric constant" should point to "int bar = 0;"
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #9 from Jan Hubicka 2012-11-09 16:38:16 UTC --- OK, I applied it to our autotester and we will see tomorrow if it fixes the segfaults. If so, can I go ahead and commit it? Honza
[Bug libgomp/55251] New: inconsistent OpenMP tasks scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55251
Bug #: 55251
Summary: inconsistent OpenMP tasks scheduling
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: alfredo.butt...@gmail.com
I have problems when executing a standard OpenMP tasks example from the OpenMP
3.1 API document (Example A.15.2c):
struct node {
struct node *left;
struct node *right;
};
extern void process(struct node *);
void postorder_traverse( struct node *p ) {
if (p->left)
#pragma omp task
// p is firstprivate by default
postorder_traverse(p->left);
if (p->right)
#pragma omp task
// p is firstprivate by default
postorder_traverse(p->right);
#pragma omp taskwait
process(p);
}
int main(){
...
#pragma omp parallel
{
#pragma omp master
{
postorder_traverse(root);
}
}
...
The problem is related to the scheduling of tasks. I want to count the number
of tasks executed by each OpenMP thread to check whether the workload
distribution is balanced. Now, if I use two threads then the tasks are pretty
much equally distributed. If I use 3 or 4 threads, the master thread always
executes only one task (corresponding to the root, topmost node of the tree).
With more than 4 threads the behavior is inconsistent in the sense that
sometimes the tasks are well distributed, sometimes the master does only one
task. Is this a bug? This happens with different versions of gcc from 4.4 up to
4.7 but not with the intel compiler.
Thanks
Alfredo
[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 --- Comment #4 from Jason Merrill 2012-11-09 16:14:56 UTC --- Author: jason Date: Fri Nov 9 16:14:48 2012 New Revision: 193368 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193368 Log: PR c++/54859 * pt.c (check_instantiated_arg): Don't complain about dependent args. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54859] [4.8 Regression] constexpr in template alias rejected as non-constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54859 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug rtl-optimization/55154] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55154 --- Comment #4 from Vladimir Makarov 2012-11-09 15:33:27 UTC --- Author: vmakarov Date: Fri Nov 9 15:33:19 2012 New Revision: 193364 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193364 Log: 2012-11-09 Vladimir Makarov PR tree-optimization/55154 * lra-int.h (LRA_LOSER_COST_FACTOR, LRA_MAX_REJECT): New macros. * lra.c (setup_operand_alternative): Use them. * lra-constraints.c (LOSER_COST_FACTOR, MAX_OVERALL_COST_BOUND): Remove. (process_alt_operands): Use LRA_LOSER_COST_FACTOR and LRA_MAX_REJECT. Accumulate reject instead of setting for non-const. (curr_insn_transform): Initialize best_losers and best_overall by INT_MAX. 2012-11-09 Vladimir Makarov PR rtl-optimization/55154 * gcc.target/i386/pr55154.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55154.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra-int.h trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 --- Comment #8 from Gary Funck 2012-11-09 15:26:46 UTC --- (In reply to comment #5) > Completely untested patch for someone else to foster-parent: > + } > + } > f = find_fallthru_edge (last_bb->succs); > if (f && f->probability * 100 / REG_BR_PROB_BASE >= > PARAM_VALUE (PARAM_SCHED_STATE_EDGE_PROB_CUTOFF)) I could not apply the patch cleanly. Perhaps it was garbled by line wraps, etc. Can you post the patch as an attachment?
[Bug target/55139] __atomic store does not support __ATOMIC_HLE_RELEASE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139 --- Comment #5 from ak at gcc dot gnu.org 2012-11-09 15:24:32 UTC --- Author: ak Date: Fri Nov 9 15:24:25 2012 New Revision: 193363 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193363 Log: Handle target specific memory models in C frontend get_atomic_generic_size would error out for __atomic_store(...,__ATOMIC_HLE_RELEASE) Just mask it out. All the memory orders are checked completely in builtins.c anyways. I'm not sure what that check is for, it could be removed in theory. Passed bootstrap and test suite on x86-64 gcc/c-family/: 2012-11-09 Andi Kleen PR 55139 * c-common.c (get_atomic_generic_size): Mask with MEMMODEL_MASK Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c
[Bug target/54546] SH: Enable -fshrink-wrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54546 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.7.0 |4.8.0 Resolution||FIXED --- Comment #5 from chrbr at gcc dot gnu.org 2012-11-09 14:40:15 UTC --- Remaining partitioning issue fixed with http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00630.html. Fixed in 4.8
[Bug rtl-optimization/55151] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1217 with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55151 --- Comment #6 from Vladimir Makarov 2012-11-09 14:28:49 UTC --- Author: vmakarov Date: Fri Nov 9 14:28:40 2012 New Revision: 193361 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193361 Log: 2012-11-09 Vladimir Makarov PR rtl-optimization/55151 * gcc.dg/pr55151.c: Move ... * gcc.target/i386/pr55151.c: ... here. Added: trunk/gcc/testsuite/gcc.target/i386/pr55151.c - copied unchanged from r193349, trunk/gcc/testsuite/gcc.dg/pr55151.c Removed: trunk/gcc/testsuite/gcc.dg/pr55151.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55158] [4.8 Regression] [IA64] ICE: segv in schedule_region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55158 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka 2012-11-09 14:22:55 UTC --- Hmm, this bug currently breaks half IA-64 bencharking in our autotester. http://gcc.opensuse.org/ (terbium) Bernd, you seem to be last who touched this area. Does the patch look OK for you? (probably these structures should be turned into VECtors). Honza
[Bug target/55139] __atomic store does not support __ATOMIC_HLE_RELEASE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139 --- Comment #4 from Andi Kleen 2012-11-09 14:06:20 UTC --- My earlier analysis was not correct. I was chasing the wrong warning. Rather the problem is in c-common.c, where the atomic models are checked again. I'm sending a patch for that.
[Bug c++/55249] [4.6/4.7/4.8 Regression] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Paolo Carlini changed: What|Removed |Added Summary|Multiple copy constructors |[4.6/4.7/4.8 Regression] |for template class lead to |Multiple copy constructors |link errors |for template class lead to ||link errors --- Comment #6 from Paolo Carlini 2012-11-09 13:42:14 UTC --- Ah! 4.5 was fine.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #27 from Jorn Wolfgang Rennecke
2012-11-09 13:29:10 UTC ---
(In reply to comment #26)
> (In reply to comment #25)
> > Maybe the better solution would indeed be to add a
> > arith -> logical shift conversion pass before combine, or try to convert
> > arith
> > shifts in the split pass after combine by looking at the data flow of the
> > shifted values.
FWIW, while the ARC600/700 have a full set up static and dynamic shifts,
the ARC 601 with the swap option has similar issues with shifts that should
be stitched together from multiple instructions, and preferences of unsigned
over signed shifts.
> Another idea would be to extend the combine pass, so that whenever it
> internally converts arith -> logical shifts, it always checks the costs of the
> shift op, and if the logical shift is cheaper, always split out the logical
> shift.
Indeed, combine's insistence that a computation has just one canonical
form, which depends on how much it known about the input/output data,
is in want of some correction. We got define_split for things that
should become multiple instructions, but nothing for things that should
just be differently-shaped instructions, and there are no predicates available
to get to know about the (non)zero / signbits that combine knows about.
E.g. the following peephole in arc.md is only necessary because combine
does some unwanted 'simplifications' with known-zero bits:
;; -
;; Pattern 1 : r0 = r1 << {i}
;; r3 = r4/INT + r0 ;;and commutative
;; ||
;; \/
;; add{i} r3,r4/INT,r1
;; -
;; ??? This should be covered by combine, alas, at times combine gets
;; too clever for it's own good: when the shifted input is known to be
;; either 0 or 1, the operation will be made into an if-then-else, and
;; thus fail to match the add_n pattern. Example: _mktm_r, line 85 in
;; newlib/libc/time/mktm_r.c .
(define_peephole2
[(set (match_operand:SI 0 "dest_reg_operand" "")
(ashift:SI (match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "const_int_operand" "")))
(set (match_operand:SI 3 "dest_reg_operand" "")
(plus:SI (match_operand:SI 4 "nonmemory_operand" "")
(match_operand:SI 5 "nonmemory_operand" "")))]
"(INTVAL (operands[2]) == 1
|| INTVAL (operands[2]) == 2
|| INTVAL (operands[2]) == 3)
&& (true_regnum (operands[4]) == true_regnum (operands[0])
|| true_regnum (operands[5]) == true_regnum (operands[0]))
&& (peep2_reg_dead_p (2, operands[0]) || (true_regnum (operands[3]) ==
true_regnum (operands[0])))"
;; the preparation statements take care to put proper operand in operands[4]
;; operands[4] will always contain the correct operand. This is added to
satisfy commutativity
[(set (match_dup 3)
(plus:SI (mult:SI (match_dup 1)
(match_dup 2))
(match_dup 4)))]
"if (true_regnum (operands[4]) == true_regnum (operands[0]))
operands[4] = operands[5];
operands[2] = GEN_INT (1 << INTVAL (operands[2]));"
)
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Paolo Carlini changed: What|Removed |Added Status|WAITING |NEW CC||jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini 2012-11-09 12:54:17 UTC --- Thanks Markus, the issue doesn't seem a regression but seems interesting enough to add Jason in CC.
[Bug c++/55250] [C++0x][constexpr] enum declarations within constexpr function are allowed, constexpr declarations are not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-11-09 12:51:52 UTC --- (In reply to comment #0) > Now, reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf > , it is not entirely unambiguous which behavior is correct. That paper is five years old, so not relevant to what C++11 allows. The standard says: The definition of a constexpr function shall satisfy the following constraints: [...] — its function-body shall be = delete, = default, or a compound-statement that contains only — null statements, — static_assert-declarations — typedef declarations and alias-declarations that do not define classes or enumerations, [...] so it's ill-formed to declare an enumeration.
[Bug rtl-optimization/54472] ICE (spill_failure): unable to find a register to spill in class 'AREG' with -O -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54472 --- Comment #9 from Andrey Belevantsev 2012-11-09 12:33:33 UTC --- Fixed on trunk, backports to 4.7/4.6 are needed.
[Bug middle-end/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Steven Bosscher 2012-11-09 12:33:08 UTC --- .
[Bug middle-end/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54385 --- Comment #4 from Steven Bosscher 2012-11-09 12:31:40 UTC --- Author: steven Date: Fri Nov 9 12:31:32 2012 New Revision: 193359 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193359 Log: PR middle-end/54385 * postreload.c (reload_cse_simplify): Return a bool indicating whether the CFG was changed. (reload_cse_regs_1): Traverse the CFG instead of the insns chain. Cleanup the CFG if edges may have been removed. (reload_cse_regs): Update. Modified: trunk/gcc/ChangeLog trunk/gcc/postreload.c
[Bug rtl-optimization/54472] ICE (spill_failure): unable to find a register to spill in class 'AREG' with -O -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54472 --- Comment #8 from Andrey Belevantsev 2012-11-09 12:28:30 UTC --- Author: abel Date: Fri Nov 9 12:28:21 2012 New Revision: 193358 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193358 Log: PR rtl-optimization/54472 * sel-sched-ir.c (has_dependence_note_reg_set): Handle implicit sets. (has_dependence_note_reg_clobber, has_dependence_note_reg_use): Likewise. * gcc.dg/pr54472.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr54472.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 --- Comment #4 from Antony Polukhin 2012-11-09 12:28:11 UTC --- (In reply to comment #3) Yes, thanks. `output.txt` will be the same. Also, reproduced this bug on GCC 4.7.2: [cc@ontos-soa-01 ~]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/cc/dev/gcc-4.7.2/libexec/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../downloads/gcc-4.7.2/configure --prefix=/home/cc/dev/gcc-4.7.2 --disable-multilib --enable-languages=c,c++ Thread model: posix gcc version 4.7.2 (GCC)
[Bug c++/55250] New: [C++0x][constexpr] enum declarations within constexpr function are allowed, constexpr declarations are not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250
Bug #: 55250
Summary: [C++0x][constexpr] enum declarations within constexpr
function are allowed, constexpr declarations are not
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bisq...@iki.fi
The following code compiles in GCC without warnings on -Wall -W -pedantic:
constexpr int Test1(int x) { enum { y = 1 }; return x+y; }
The following one does not:
constexpr int Test2(int x) { constexpr int y = 1; return x+y; }
For the second code, GCC gives "error: body of constexpr function 'constexpr
int Test2(int)' not a return-statement"
In comparison, Clang++ gives an error for Test1: "error: types cannot be
defined in a constexpr function", and for Test2: "error: variables cannot be
declared in a constexpr function" for Test2.
Now, reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf
, it is not entirely unambiguous which behavior is correct.
While I would like that both samples worked without warnings, I suggest that
attempting to declare an enum within a constexpr function will be made a
-pedantic warning.
[Tested on GCC 4.6.3 through 4.7.2. On GCC 4.5.3, both functions compiled
without warnings.]
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #3 from Markus Trippelsdorf
2012-11-09 12:21:20 UTC ---
template struct A
{
typedef _Tp value_type;
value_type _M_instance[1];
};
template struct inner_type
{
inner_type () {}
inner_type (inner_type &);
inner_type (const inner_type &) {}
};
int
main ()
{
A > a, b = a;
}
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek 2012-11-09 12:19:52 UTC --- Why is this marked [4.8 Regression]? From what I can see, gcc has been using OImode in this testcase since it was changed to pass 32-byte vectors in ymm registers (somewhen during 4.4 development, and 4.3 didn't have avx support at all). Thus this doesn't look any kind of regression to me. We risk ABI regressions if we change this though.
[Bug lto/54966] Does LTO requires a larger inline-unit-growth?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966 --- Comment #10 from vincenzo Innocente 2012-11-09 11:33:37 UTC --- I've repeated the tests again on a different machine and the result are the same gcc version 4.8.0 20121108 (experimental) [trunk revision 19] (GCC) at O3 lto degrades the performances in two cases, improves in another… at O2 lto just degrades performance for two cases (different than O3) and does not improve for the others with Ofast the differences are even more dramatic [innocent@vinavx0 bugs48]$ c++ -Ofast smatrix.ii -march=native -flto ; taskset -c 2 ./a.out size 5. v1: time in cycles 14255.6 size 5. v2: time in cycles 3699.28 size 5. v3: time in cycles 3715.55 size 6. v1: time in cycles 9179.85 size 6. v2: time in cycles 1906.91 size 6. v3: time in cycles 1812.73 [innocent@vinavx0 bugs48]$ c++ -Ofast smatrix.ii -march=native ; taskset -c 2 ./a.out size 5. v1: time in cycles 13933.9 size 5. v2: time in cycles 2125.56 size 5. v3: time in cycles 1028.43 size 6. v1: time in cycles 28168 size 6. v2: time in cycles 3528.72 size 6. v3: time in cycles 2533.5 c++ -O3 smatrix.ii -march=native; taskset -c 2 ./a.out size 5. v1: time in cycles 13896.1 size 5. v2: time in cycles 2107.25 size 5. v3: time in cycles 1647.42 size 6. v1: time in cycles 31095.6 size 6. v2: time in cycles 3862.43 size 6. v3: time in cycles 3510.14 c++ -O3 smatrix.ii -march=native -flto; ./a.out size 5. v1: time in cycles 16183.5 size 5. v2: time in cycles 3696.15 size 5. v3: time in cycles 3698.27 size 6. v1: time in cycles 36323.5 size 6. v2: time in cycles 2799.47 size 6. v3: time in cycles 2705.73 [innocent@vinavx0 bugs48]$ taskset -c 2 ./a.out size 5. v1: time in cycles 16150.1 size 5. v2: time in cycles 3718.54 size 5. v3: time in cycles 3784.38 size 6. v1: time in cycles 36326.3 size 6. v2: time in cycles 2785.33 size 6. v3: time in cycles 2714.69 c++ -O2 smatrix.ii -march=native -flto ; taskset -c 2 ./a.out size 5. v1: time in cycles 13809.2 size 5. v2: time in cycles 3999.39 size 5. v3: time in cycles 4186.2 size 6. v1: time in cycles 35057.3 size 6. v2: time in cycles 4657.59 size 6. v3: time in cycles 4766.62 c++ -O2 smatrix.ii -march=native; taskset -c 2 ./a.out size 5. v1: time in cycles 11300.6 size 5. v2: time in cycles 2877.27 size 5. v3: time in cycles 2947.01 size 6. v1: time in cycles 30520 size 6. v2: time in cycles 4623.54 size 6. v3: time in cycles 5287.95
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-09 CC|antoshkka at gmail dot com | Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2012-11-09 10:53:06 UTC --- We need a self contained reduced testcase for this.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #26 from Oleg Endo 2012-11-09 10:48:17 UTC --- (In reply to comment #25) > Maybe the better solution would indeed be to add a > arith -> logical shift conversion pass before combine, or try to convert arith > shifts in the split pass after combine by looking at the data flow of the > shifted values. Another idea would be to extend the combine pass, so that whenever it internally converts arith -> logical shifts, it always checks the costs of the shift op, and if the logical shift is cheaper, always split out the logical shift.
[Bug rtl-optimization/55221] [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221
--- Comment #3 from Anton Shterenlikht 2012-11-09
10:47:22 UTC ---
forgot to add, all these builds are with
a patch to unwind-ia64.h. For example, for 4.8
branch, the patch is (credit to ger...@freebsd.org):
Index: libgcc/config/ia64/unwind-ia64.h
===
--- libgcc/config/ia64/unwind-ia64.h
+++ libgcc/config/ia64/unwind-ia64.h(working copy)
@@ -49,4 +49,7 @@
extern struct unw_table_entry *
_Unwind_FindTableEntry (void *pc, unw_word *segment_base,
unw_word *gp, struct unw_table_entry *ent)
- __attribute__ ((__visibility__ ("hidden")));
+#ifndef __FreeBSD__
+ __attribute__ ((__visibility__ ("hidden")))
+#endif
+ ;
[Bug rtl-optimization/55221] [regression] gcc-4.6-20121102/gcc/rtl.h:2105: error: 'FIRST_PSEUDO_REGISTER' undeclared here (not in a fnction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221 --- Comment #2 from Anton Shterenlikht 2012-11-09 10:40:41 UTC --- On the same system I can build gcc-4.8.0.20121014
[Bug c++/55249] Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249 --- Comment #1 from Antony Polukhin 2012-11-09 10:24:49 UTC --- Created attachment 28648 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28648 Preprocessed file that triggers the bug
[Bug c++/55249] New: Multiple copy constructors for template class lead to link errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55249
Bug #: 55249
Summary: Multiple copy constructors for template class lead to
link errors
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antosh...@gmail.com
Created attachment 28647
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28647
gcc -v -save-temps -std=c++0x -Wall -Wextra main.cpp 1>output.txt 2>&1
Following code leads to linker errors in C++11 mode and in default mode
(requires replacement of std::array with boost::array):
#include
#include
template
struct inner_type {
inner_type() {}
inner_type(inner_type& ) {}
inner_type(const inner_type& ) {}
~inner_type() {}
};
// Uncomment typedef to get undefined reference to
// __uninitialized_copyILb0EE13__uninit_copy
// Can be workaround by marking inner_type copy constructors with noexcept
//typedef std::vector, 3> > type;
// Uncomment typedef to get undefined reference to
// `inner_type::inner_type(inner_type const&)'
//typedef std::array, 3> type;
int main()
{
type t1;
type t2 = t1;
return 0;
}
[Bug target/55246] Define a macro for 16*1024*1024
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55246 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-11-09 10:07:01 UTC --- This occurred to me as well.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #32 from Joost VandeVondele 2012-11-09 10:05:18 UTC --- > If you can use the additional free time to walk over to my > brother's office, then please say 'Hi' to him. Otherwise the faculty meeting > will have to do :-) Let's call it a small world... I will meet him next week.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #31 from Tobias Schlüter 2012-11-09 09:43:56 UTC --- (In reply to comment #30) > (In reply to comment #29) > > I committed the C-only version of the patch as the issues mentioned in > > comment > > #27 couldn't be addressed before stage3. > > Thanks Tobi! > > I have been using your C-only patch for a couple of weeks now for the 4.7 > branch, and it is greatly improving our edit/compile-cycles. For one of my > students, it yields an effective 10x speedup in building CP2K after a typical > code change, greatly facilitating the programming project he is on. I would > suggest that after a couple of weeks on trunk, this should be reconsidered > again for backporting to 4.7. Good to hear that. If you can use the additional free time to walk over to my brother's office, then please say 'Hi' to him. Otherwise the faculty meeting will have to do :-) As for the backport, I think the patch is absolutely risk-free, and it should have been approved for 4.7 even though it doesn't fulfill the formal requirements. I think it's worth another try once it's not only saved ethz.ch a lot of electricity but also survived for some time on the 4.8 branch. Please ping the patch in a few weeks so it's not forgotten. I also put a note into my calendar.
[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling the small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-09 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|Compiler segfault when |[4.6/4.7/4.8 Regression] |compiling the small test|Compiler segfault when |case|compiling the small test ||case Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek 2012-11-09 09:06:25 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170853 aka PR48029 fix.
[Bug middle-end/54242] [4.8 Regression] FAIL: gcc.target/i386/pad-10.c scan-assembler-not nop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54242 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Jakub Jelinek 2012-11-09 08:43:00 UTC --- Fixed by 2012-09-30 Uros Bizjak * gcc.target/i386/pad-10.c (foo2): Return x - z.
