[Bug c/41673] New: 4.5.0 20091008 variable-length array dereference inside sizeof gives warning: dereferencing type-punned pointer will break strict-aliasing rules
A variable-length array pointer 'dereference' inside sizeof() is causing GCC to
give an aliasing warning. I can think of no reason why completely
compiletime-static sizeof() activity could create an aliasing violation.
I've included a contrived example showing 4.5.0 producing the warning while
4.4.1 does not complain:
[gmaxw...@floodlamp tmp]$ cat test.c
#include string.h
int main(int argc, char *argv[])
{
float x[argc];
float y[argc];
return NULL == memcpy(y, x, argc * sizeof(*x));
}
[gmaxw...@floodlamp tmp]$ /usr/local/bin/gcc -std=gnu99 -O2 -Wall -o test
test.c
test.c: In function main:
test.c:6:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules
[gmaxw...@floodlamp tmp]$ /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --with-ppl --with-cloog --with-gmp --enable-lto
Thread model: posix
gcc version 4.5.0 20091008 (experimental) (GCC)
[gmaxw...@floodlamp tmp]$ /usr/bin/gcc -std=gnu99 -O2 -Wall -o test test.c
[gmaxw...@floodlamp tmp]$ /usr/bin/gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --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-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--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=i586
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.1 20090725 (Red Hat 4.4.1-2) (GCC)
The -O2 plus sizeof(*x) anywhere where x is a var-array is necessary and
sufficient to trigger this. Switching to a statically sized array avoids the
warning.
The actual use-case where I hit this is where sizeof() is used in this manner
when a type is selected by some compile time configuration and manually
restating the type in sizeof() would require a great many more ifdefs.
--
Summary: 4.5.0 20091008 variable-length array dereference inside
sizeof gives warning: dereferencing type-punned pointer
will break strict-aliasing rules
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gmaxwell at gmail dot com
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41673
[Bug c/41673] [4.5 Regression] variable-length array dereference inside sizeof gives warning: dereferencing type-punned pointer will break strict-aliasing rules
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic Summary|4.5.0 20091008 variable-|[4.5 Regression] variable- |length array dereference|length array dereference |inside sizeof gives |inside sizeof gives |warning: dereferencing |warning: dereferencing |type-punned pointer will|type-punned pointer will |break strict-aliasing rules|break strict-aliasing rules Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41673
[Bug bootstrap/41620] [4.5 regression] Bootstrap failure
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-11 11:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41620
[Bug c++/41545] [4.5 Regression] ICE tree check: expected var_decl or function_decl, have error_mark in grokdeclarator, at cp/decl.c:9305
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-11 11:08 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41545
[Bug tree-optimization/41555] [4.5 regression] possible miscompilation in whole-program mode
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-11 11:22 --- I can't reproduce this failure anymore (with rev. 152638). I'll add a testcase. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41555
[Bug tree-optimization/41555] [4.5 regression] possible miscompilation in whole-program mode
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-11 11:24 --- Subject: Bug 41555 Author: rguenth Date: Sun Oct 11 11:24:10 2009 New Revision: 152639 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152639 Log: 2009-10-11 Richard Guenther rguent...@suse.de PR tree-optimization/41555 * gcc.dg/torture/pr41555.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr41555.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41555
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-11 11:56 ---
The key is IMHO that the inner loop does not have its loop header copied.
This confuses SCEV enough to think that a = (unsigned short)a is always
executed. LIM is necessary to promote all the memory to SSA names, the
interesting CHREC that gets wrong is
bb 3:
..
a_lsm.6_18 = 0x0fff3;
goto bb 5;
bb 4:
...
a.1_2 = a_lsm.6_15;
D.2006_3 = (short unsigned int) a.1_2;
a.2_4 = (unsigned int) D.2006_3;
a_lsm.6_20 = a.2_4;
bb 5:
# a_lsm.6_15 = PHI a_lsm.6_18(3), a_lsm.6_20(4)
...
a.1_1 = a_lsm.6_15;
if (a.1_1 == 0)
goto bb 4;
else
goto bb 6;
bb 6:
...
- # a_lsm.6_27 = PHI a_lsm.6_15(5)
bb 8:
- # a_lsm.6_28 = PHI a_lsm.6_27(6)
- a = a_lsm.6_28;
+ a = 65523;
where interestingly a_lsm.6_15 isn't computed wrong.
Testcase, fails at -Os:
extern void abort (void);
unsigned int a;
int b, c;
void
foo (void)
{
b = 0;
do {
for (a = -13; a == 0; a = (unsigned short)a)
c = 1;
b++;
} while (b == 0);
}
int
main ()
{
foo ();
if (a != -13)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-11 11:56 --- Sebastian, can you have a look? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug tree-optimization/41377] [4.5 Regression] gimple EH rewrite causes ICE with PPRE (enabled at -O3)
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-11 12:05 --- ehcleanup does not deal with the virtual PHI node appearing in BB13: # BLOCK 11 freq:4067 # PRED: 10 [100.0%] (fallthru,exec) D.2166_92 = (int *) D.2165_108; # .MEM_148 = VDEF .MEM_106 D.2148_59 = A::foo (a, D.2166_92); # SUCC: 12 [100.0%] (fallthru,exec) 13 (eh,exec) ... # BLOCK 13 # PRED: 11 (eh,exec) # .MEM_44 = PHI .MEM_148(11) L13: goto bb 27 (L5); # SUCC: 27 [100.0%] (fallthru,exec) ... # BLOCK 27 # PRED: 13 [100.0%] (fallthru,exec) 26 [100.0%] (fallthru,exec) # .MEM_138 = PHI .MEM_44(13), .MEM_60(26) L5: # .MEM_19 = VDEF .MEM_138 operator delete (D.1857_5); resx 3 # SUCC: as the comment suggests this should be easy to fix. Honza? #1 0x0880ed28 in unsplit_eh (lp=0xb7d6c0c0) at /home/richard/src/trunk/gcc/tree-eh.c:3389 3389 gcc_assert (gimple_seq_empty_p (phi_nodes (bb))); (gdb) l 3384 /* ??? I can't imagine there would be PHI nodes, since by nature 3385 of critical edge splitting this block should never have been 3386 a dominance frontier. If cfg cleanups somehow confuse this, 3387 due to single edges in and out we ought to have degenerate PHIs 3388 and can easily propagate the PHI arguments. */ 3389 gcc_assert (gimple_seq_empty_p (phi_nodes (bb))); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41377
[Bug target/41665] Typo in addsi_1_zext?
--- Comment #4 from ubizjak at gmail dot com 2009-10-11 12:13 ---
(In reply to comment #3)
case TYPE_LEA:
operands[2] = SET_SRC (XVECEXP (PATTERN (insn), 0, 0));
return lea{l}\t{%a2, %k0|%k0, %a2};
Won't we get (zero_extend:DI ...) for operands[2]? Don't we
want (plus:SI ...) instead?
You are right here. We need to strip ZERO_EXTEND, otherwise
print_operand_address will choke on it. Care to post a patch?
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-10-11 12:13:16
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41665
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #16 from pault at gcc dot gnu dot org 2009-10-11 12:20 --- Subject: Bug 40440 Author: pault Date: Sun Oct 11 12:20:09 2009 New Revision: 152640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152640 Log: 2009-10-11 Paul Thomas pa...@gcc.gnu.org PR fortran/40440 * decl.c (hash_value): New function. (gfc_match_derived_decl): Call it. 2009-10-11 Paul Thomas pa...@gcc.gnu.org PR fortran/40440 * gfortran.dg/class_4a.f03: New test with class_4b,c and d.f03. * gfortran.dg/class_4b.f03: As above. * gfortran.dg/class_4c.f03: As above. * gfortran.dg/class_4d.f03: As above. Added: trunk/gcc/testsuite/gfortran.dg/class_4a.f03 trunk/gcc/testsuite/gfortran.dg/class_4b.f03 trunk/gcc/testsuite/gfortran.dg/class_4c.f03 trunk/gcc/testsuite/gfortran.dg/class_4d.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug lto/41668] ICE in get_alias_set, at alias.c:698
--- Comment #5 from marcus at jet dot franken dot de 2009-10-11 12:23 --- its gone with current SVN ... not sure if its just dormant or fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41668
[Bug fortran/41583] [OOP] TYPE IS rejected because of way vtable index is implemented
--- Comment #1 from pault at gcc dot gnu dot org 2009-10-11 12:25 --- Subject: Bug 41583 Author: pault Date: Sun Oct 11 12:24:51 2009 New Revision: 152641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152641 Log: 2009-10-11 Paul Thomas pa...@gcc.gnu.org PR fortran/41583 * decl.c (hash_value): New function. (gfc_match_derived_decl): Call it. 2009-10-11 Paul Thomas pa...@gcc.gnu.org PR fortran/41583 * gfortran.dg/class_4a.f03: New test with class_4b,c and d.f03. * gfortran.dg/class_4b.f03: As above. * gfortran.dg/class_4c.f03: As above. * gfortran.dg/class_4d.f03: As above. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41583
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #17 from pault at gcc dot gnu dot org 2009-10-11 12:26 --- (In reply to comment #16) Sorry - that was fingers trouble on my part - wrong PR. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug fortran/41583] [OOP] TYPE IS rejected because of way vtable index is implemented
--- Comment #2 from pault at gcc dot gnu dot org 2009-10-11 12:29 --- Fixed using a hash function. TODO a proper job using vtables. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41583
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #50 from jv244 at cam dot ac dot uk 2009-10-11 12:45 --- As expected, the testcases in comment #40 and comment #42 now also fail at '-O2 -flto' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly
--- Comment #17 from jv244 at cam dot ac dot uk 2009-10-11 12:49 --- FYI, the testcase in comment #8 fails for '-O2 -fwhole-file' but not with '-O2 -flto', even though the latter option implies the first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
[Bug target/41665] Typo in addsi_1_zext?
--- Comment #5 from hjl dot tools at gmail dot com 2009-10-11 14:28 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00693.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||10/msg00693.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41665
[Bug middle-end/41674] New: /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c-O3 -fwhole- program -combine -fipa-type-escape -fprofile-generate -lm -o /test/gnu/gcc/ob jdir/gcc/testsuite/gcc/w_prof_global_array.x01(timeout = 300) /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main (first referenced in /var/tmp//ccC7FsIt.o) (code) collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main (first referenced in /var/tmp//ccC7FsIt.o) (code) collect2: ld returned 1 exit status FAIL: gcc.dg/struct/w_prof_global_array.c compilation, -O3 -fwhole-program -com bine -fipa-type-escape -fprofile-generate Similar fails: FAIL: gcc.dg/struct/w_prof_local_array.c compilation, -O3 -fwhole-program -comb ine -fipa-type-escape -fprofile-generate FAIL: gcc.dg/struct/w_prof_local_var.c compilation, -O3 -fwhole-program -combin e -fipa-type-escape -fprofile-generate FAIL: gcc.dg/struct/w_prof_single_str_global.c compilation, -O3 -fwhole-program -combine -fipa-type-escape -fprofile-generate FAIL: gcc.dg/struct/w_prof_two_strs.c compilation, -O3 -fwhole-program -combine -fipa-type-escape -fprofile-generate FAIL: gcc.dg/struct/w_ratio_cold_str.c compilation, -O3 -fwhole-program -combin e -fipa-type-escape -fprofile-generate _GLOBAL__I_65535_0_main is not global in the assembler output. -- Summary: /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
[Bug lto/41598] bootstrap *using* lto fails
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-10-11 15:13 ---
Ok, so the issue here is that we have
typedef struct VEC_constructor_elt_gc { } VEC_constructor_elt_gc;
vs.
typedef struct VEC_constructor_elt_gcx { } VEC_constructor_elt_gc;
which causes us to not merge the two union tree_node types which are
typedef union tree_node *tree;
union tree_node {
tree * use;
VEC_constructor_elt_gc *elts;
};
And in the end because we look through typedefs here:
static hashval_t
iterative_hash_type_name (tree type, hashval_t v)
{
tree name = TYPE_NAME (TYPE_MAIN_VARIANT (type));
Now this is necessary - we'd want to merge
union tree_node {
tree * use;
struct VEC_constructor_elt_gc *elts;
};
as well.
So - this cannot be fixed by type merging, but instead together with what
we need to fix TBAA issues for non-merged types we have to try to cover
these issues as well.
Now - a C language lawyer could chime in here and tell us if the above
invokes undefined behavior. Short:
typedef struct A {} T;
typedef struct B {} T;
is this valid cross translation-unit if T is used across units?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-10-11 15:13:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598
[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-10-11 15:32 --- Subject: Re: [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main Introduced between 152432 and 152630. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
[Bug lto/41598] bootstrap *using* lto fails
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-10-11 15:33
---
Further reduced testcase:
b.h
---
typedef union tree_node *tree;
union tree_node {
tree * use;
VEC_constructor_elt_gc *elts;
};
t1.c:
-
typedef struct VEC_constructor_elt_gc { } VEC_constructor_elt_gc;
#include b.h
struct stmt_tree_s {
tree x_cur_stmt_list;
};
void *add_stmt (struct stmt_tree_s *x)
{
return x-x_cur_stmt_list;
}
t2.c
typedef struct VEC_constructor_elt_gcx { } VEC_constructor_elt_gc;
#include b.h
struct gcc_target {
void (* builtin_vec_perm) (tree*);
};
extern struct gcc_target targetm;
void dwarf2out_begin_prologue (tree t)
{
(*targetm.builtin_vec_perm) (t);
}
struct die_arg_entry_struct {
tree arg;
};
void *gt_pch_p_20VEC_die_arg_entry_gc (struct die_arg_entry_struct *vec)
{
return (vec-arg);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598
[Bug ada/41675] New: GNAT rejects type with 64 bits, claiming it has 65 bits
Hello everybody, the following piece of code demonstrates the problem. It compiles and prints out T'Size: 63. Thus, with the commented line used instead, the result should be T'Size: 64. But in that case GNAT terminates with the following error message: main.adb:5:04: size required (65) for type t too large, maximum allowed is 64. with Ada.Text_IO; procedure Main is -- T_Delta : constant := 0.1 * (2.0**(-64 + 9)); -- Gnat bug T_Delta : constant := 0.1 * (2.0**(-63 + 9)); type T is delta T_Delta range 0.0 .. 51.1; for T'Small use T_Delta; begin Ada.Text_IO.Put_Line(T'Size:Integer'Image(T'Size)); end Main; One possible reason is, that GNAT counts a sign bit, which is not counted when the 'Size attribute is queried. In any case, I assume that this inconsistency is unintended. Here's the versions that I am using: gnatmake --version GNATMAKE 4.3.4 ... gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-2' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.4 (Debian 4.3.4-2) Friendly regards, Dirk Herrmann -- Summary: GNAT rejects type with 64 bits, claiming it has 65 bits Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dirk dot herrmann-privat at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41675
[Bug libgcj/41676] New: FAIL: PR160 -O3 output - source compiled test
This test fails occasionally because the dynamic loader is passed a NULL file name. Executing on host: /mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/. ./libtool --silent --tag=GCJ --mode=link /mnt/gnu/gcc/objdir/gcc/gcj -B/mnt/gnu/ gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/ -B/mnt/gnu/gcc/objdir/gcc/ --encoding= UTF-8 -B/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/../ /mnt/gnu /gcc/gcc/libjava/testsuite/libjava.lang/PR160.jar -w -no-install --main=PR160 -O3 -g -L/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs -lm -o /mn t/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/PR160.exe(timeout = 300) PASS: PR160 -O3 compilation from source set_ld_library_path_env_vars: ld_library_path=.:/mnt/gnu/gcc/objdir/hppa2.0w-hp- hpux11.11/./libjava/.libs invoke: /mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libjava/testsuite/PR160.exe Setting LD_LIBRARY_PATH to .:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava /.libs:.:/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libjava/.libs /usr/lib/dld.sl: Filename passed is Null. /usr/lib/dld.sl: No such file or directory ok PASS: PR160 -O3 execution - source compiled test FAIL: PR160 -O3 output - source compiled test Similar fail is: FAIL: err14 -findirect-dispatch output - source compiled test -- Summary: FAIL: PR160 -O3 output - source compiled test Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41676
[Bug fortran/41656] [OOP] Unresolved GENERIC
--- Comment #2 from pault at gcc dot gnu dot org 2009-10-11 16:05 --- Created an attachment (id=18783) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18783action=view) Provisional fix for this PR Hi Salvatore, You might like to exercise this patch. It seems to work correctly but I would be interested to know how it works when used in anger. I am unable to commit anything for the next few days and I wish to fix PR41648 at the same time, since it suffers the same problem. Therefore, posting the patch, testcases and so on is a few days away. ciao Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41656
[Bug fortran/41586] Allocatable _scalars_ are never auto-deallocated
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-10-11 16:44 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-11 16:44:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41586
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #5 from hjl dot tools at gmail dot com 2009-10-11 16:59 --- Revision 147714 is OK and revision 147717 is bad. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug fortran/38439] I/O PD edit descriptor inconsistency
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-10-11 17:38 --- Subject: Bug 38439 Author: jvdelisle Date: Sun Oct 11 17:37:50 2009 New Revision: 152644 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152644 Log: 2009-10-11 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/38439 * io/format.c (parse_format_list): Add check for tokens not allowed after P specifier. Fix comments. Remove un-needed code. Fix the default exponent list. Correct pointer assignment error. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
[Bug fortran/38439] I/O PD edit descriptor inconsistency
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-10-11 17:41 --- Subject: Bug 38439 Author: jvdelisle Date: Sun Oct 11 17:41:23 2009 New Revision: 152645 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152645 Log: 2009-10-11 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/38439 * io.c (check_format): Fix locus for error messages and fix a comment. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
Re: [Bug lto/41598] bootstrap *using* lto fails
On Sun, Oct 11, 2009 at 8:13 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: is this valid cross translation-unit if T is used across units? Yes this is valid for C. In C, types are across TUs are not based on names. This is why the code for -combine was complex with respect of type equality. -- Pinski
[Bug lto/41598] bootstrap *using* lto fails
--- Comment #11 from pinskia at gmail dot com 2009-10-11 17:48 --- Subject: Re: bootstrap *using* lto fails On Sun, Oct 11, 2009 at 8:13 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: is this valid cross translation-unit if T is used across units? Yes this is valid for C. In C, types are across TUs are not based on names. This is why the code for -combine was complex with respect of type equality. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598
[Bug fortran/41656] [OOP] Unresolved GENERIC
--- Comment #3 from sfilippone at uniroma2 dot it 2009-10-11 18:19 --- (In reply to comment #2) Hi Paul, Seems to work as advertised, in that it takes out the errors it's supposed to cure. On my full application I now get this: psb_s_mat_mod.f03:1345.45: allocate(altmp, source=mold,stat=info) 1 Error: Using SOURCE= with a class variable at (1) not supported yet psb_s_mat_mod.f03: In function s_sizeof: psb_s_mat_mod.f03:152:0: error: case labels not sorted: case 1: is greater than case 1: but comes before it. psb_s_mat_mod.f03:152:0: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The SOURCE= error is clear enough, but the other is interesting, because it happens in one of the cases that gave rise to PR 41648, line 152 is the end of this function function s_sizeof(a) result(res) implicit none class(psb_s_sparse_mat), intent(in) :: a integer(psb_long_int_k_) :: res res = 0 if (allocated(a%a)) then res = a%a%sizeof() end if end function s_sizeof Since you say you want to take them both do you need access to the full source code? Regards Salvatore -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41656
[Bug fortran/41581] [OOP] Allocation of a CLASS with SOURCE=class does not work
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-11 19:07 --- Mine. The plan: Add a '$size' field to the class container, which will be used at runtime to determine the size of the memory block to be allocated. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-11 19:07:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41581
[Bug fortran/38439] I/O PD edit descriptor inconsistency
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-10-11 19:20 --- Fixed enough I think. Closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #6 from hjl dot tools at gmail dot com 2009-10-11 19:34 --- It is caused by revision 147716: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug target/41665] Typo in addsi_1_zext?
--- Comment #6 from hjl at gcc dot gnu dot org 2009-10-11 19:43 --- Subject: Bug 41665 Author: hjl Date: Sun Oct 11 19:42:54 2009 New Revision: 152647 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152647 Log: 2009-10-11 H.J. Lu hongjiu...@intel.com PR target/41665 * config/i386/i386.md (addsi_1_zext): Get the proper second operand for lea. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41665
[Bug target/41677] New: [4.5 regression] Revision 152642 caused gcc.target/i386/pr33555.c
Revision 152642: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00291.html caused FAIL: gcc.target/i386/pr33555.c scan-assembler sbbl -- Summary: [4.5 regression] Revision 152642 caused gcc.target/i386/pr33555.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41677
[Bug target/33743] unwinding through signal frames
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-10-11 20:06 --- Subject: Bug 33743 Author: ebotcazou Date: Sun Oct 11 20:06:12 2009 New Revision: 152648 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152648 Log: PR target/33743 * config/i386/sol2.h (MD_UNWIND_SUPPORT): Define. * config/i386/sol2-unwind.h: New file. Added: trunk/gcc/config/i386/sol2-unwind.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sol2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33743
[Bug target/33555] x86 missed opportunity for sbb
--- Comment #4 from ubizjak at gmail dot com 2009-10-11 20:18 --- *** Bug 41677 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33555
[Bug target/33743] unwinding through signal frames
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-10-11 20:49 --- Subject: Bug 33743 Author: ebotcazou Date: Sun Oct 11 20:48:46 2009 New Revision: 152649 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152649 Log: PR target/33743 * config/sparc/sol2.h (MD_UNWIND_SUPPORT): Define. * config/sparc/sol2-unwind.h: New file. Added: trunk/gcc/config/sparc/sol2-unwind.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sol2.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33743
[Bug target/33743] unwinding through signal frames
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2009-10-11 20:51 --- This now should work on Solaris 8, 9 and 10. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33743
[Bug c++/41570] [4.5 Regression] [c++0x] ICE with -g and variadic templates
--- Comment #2 from dodji at gcc dot gnu dot org 2009-10-11 21:51 --- Patch sent to http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00720.html . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41570
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #14 from f dot frumento at ngi dot it 2009-10-11 22:52 ---
(In reply to comment #0)
Put this in main.c and build it with a 4.4-branch compiler using recent
binutils:
int main ()
{
return 0;
}
Versions:
GNU assembler (GNU Binutils) 2.19.51.20090611
i686-pc-linux-gnu-gcc (GCC) 4.4.1 20090611 (prerelease)
% i686-pc-linux-gnu-gcc -c main.c; objdump --wide -h main.o | grep ALLOC
0 .text 000a 0034 2**2 CONTENTS,
ALLOC, LOAD, READONLY, CODE
1 .data 0040 2**2 CONTENTS,
ALLOC, LOAD, DATA
2 .bss 0040 2**2 ALLOC
% i686-pc-linux-gnu-gcc -c -g main.c; objdump --wide -h main.o | grep ALLOC
0 .text 000a 0034 2**2 CONTENTS,
ALLOC, LOAD, READONLY, CODE
1 .data 0040 2**2 CONTENTS,
ALLOC, LOAD, DATA
2 .bss 0040 2**2 ALLOC
12 .eh_frame 0034 01c0 2**2 CONTENTS,
ALLOC, LOAD, RELOC, READONLY, DATA
We're using GAS's .cfi_startproc et cetera directives to generate debug
information. But they only generate .eh_frame, not .debug_frame.
I also noticed this problem on an ARM EABI target. ARM EABI does not use
.eh_frame, only .debug_frame and .ARM.exidx.
The easiest fix is to disable use of the CFI directives when we are trying to
generate .debug_frame. I believe GCC used to generate both .debug_frame and
.eh_frame for the same function. If we want both to gain the advantages of
using CFI directives (e.g. potentially accurate across inline asm), then we
need to teach gas to emit .debug_frame/.eh_frame/both as requested.
Hi all,
I've noticed ther behaviour differs for some platform
I've tested a cross compiler Gcc 4.4.1 on Cygwin and on Mac OSX 1.6,I've built
it from vanilla sources (gcc.gnu.org), the final target is M68K/Coldfire
on mac no problem at all while on cygwin i've got a no memory region
...omissis... for .eh_frame error message, i've built the same files just
checked out from svn repository. While i've solved disabling debug options i
can't use this setup for long, I've also modified the linker script as follow:
MEMORY
{
flash : ORIGIN = 0x000, LENGTH = 0x10
dpram : ORIGIN = 0x0FFFE000, LENGTH = 0x1000
}
SECTIONS {
.text : {*(boot) *(text) *(eh_frame)} flash
.data : {} dpram
.bss : {} dpram
eh_frame :{} flash
/DISCARD/ : { *(eh_*)}
}
but it seems that on cygwin the /DISCARD/ special command doesn't work so my
binary files is larger than the mac generated one.
Any idea ?
--
f dot frumento at ngi dot it changed:
What|Removed |Added
CC||f dot frumento at ngi dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug fortran/38439] I/O PD edit descriptor inconsistency
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-10-12 00:53 --- Subject: Bug 38439 Author: jvdelisle Date: Mon Oct 12 00:52:45 2009 New Revision: 152657 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152657 Log: 2009-10-11 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/38439 * io/format.c (parse_format_list): Correct logic for FMT_F reading vs writing. Code clean-up. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
[Bug fortran/38439] I/O PD edit descriptor inconsistency
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-10-12 00:54 --- Subject: Bug 38439 Author: jvdelisle Date: Mon Oct 12 00:54:11 2009 New Revision: 152658 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152658 Log: 2009-10-11 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/38439 * gfortran.dg/fmt_error_9.f: New test. * gfortran.dg/fmt_error_10.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_error_10.f trunk/gcc/testsuite/gfortran.dg/fmt_error_9.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
[Bug fortran/41678] New: Format label as second item in io control list is rejected
The following is rejected by gfortran. I think it is valid. read(unit=2, 100) i 100 format (f10.7) -- Summary: Format label as second item in io control list is rejected Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: jvdelisle at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41678
[Bug target/26515] peephole2 causes unrecognized insn, zero_extending non-general register
--- Comment #1 from hp at gcc dot gnu dot org 2009-10-12 04:10 --- Created an attachment (id=18784) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18784action=view) patch and testcase from PR39765 Patch won't apply cleanly to gcc-4.3; apply s/CRIS_CONST/CONST/. Also, the test-case doesn't trig on gcc-4.3-branch, just 4.4. (Main trunk soon.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26515
[Bug target/36482] ICE in copyprop_hardreg_forward_1, at regrename.c:1613
--- Comment #7 from hp at gcc dot gnu dot org 2009-10-12 04:12 --- (In reply to comment #6) PR39685 also looks related, but with a different instruction kind Huh? That's a different port. (In reply to comment #6) Hm, also see PR23424. Why? Wrong number? HP - time to revisit these? Now *that*'s true! But... this was a duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36482
[Bug target/36482] ICE in copyprop_hardreg_forward_1, at regrename.c:1613
--- Comment #8 from hp at gcc dot gnu dot org 2009-10-12 04:14 --- *** This bug has been marked as a duplicate of 26515 *** -- hp at gcc dot gnu dot org changed: What|Removed |Added CC|hans-peter dot nilsson at | |axis dot com| Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36482
[Bug target/26515] peephole2 causes unrecognized insn, zero_extending non-general register
--- Comment #2 from hp at gcc dot gnu dot org 2009-10-12 04:14 --- *** Bug 36482 has been marked as a duplicate of this bug. *** -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hinko dot kocevar at ||cetrtapot dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26515
[Bug target/41642] Cross-compiling error on cris os while building openwrt
--- Comment #4 from hp at gcc dot gnu dot org 2009-10-12 04:18 --- *** This bug has been marked as a duplicate of 26515 *** -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41642
[Bug target/26515] peephole2 causes unrecognized insn, zero_extending non-general register
--- Comment #3 from hp at gcc dot gnu dot org 2009-10-12 04:18 --- *** Bug 41642 has been marked as a duplicate of this bug. *** -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||bohne-lang at medma dot uni- ||heidelberg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26515
[Bug c++/37204] [c++0x] reinterpret_castT(v) incorrectly yields an lvalue
--- Comment #2 from jason at gcc dot gnu dot org 2009-10-12 04:39 --- Subject: Bug 37204 Author: jason Date: Mon Oct 12 04:39:04 2009 New Revision: 152661 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152661 Log: PR c++/37204 * typeck.c (build_reinterpret_cast_1): Handle rvalue refs properly. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-reinterpret.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37204
[Bug c++/37204] [c++0x] reinterpret_castT(v) incorrectly yields an lvalue
--- Comment #3 from jason at gcc dot gnu dot org 2009-10-12 04:41 --- Fixed for 4.5. I'll also apply the fix for 4.4.3 after the 4.4.2 release goes out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37204
[Bug debug/41616] Variables promoted to Gimple registers by aliasing are not getting debug statements.
--- Comment #3 from aoliva at gcc dot gnu dot org 2009-10-12 05:15 --- Subject: Bug 41616 Author: aoliva Date: Mon Oct 12 05:15:02 2009 New Revision: 152662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152662 Log: gcc/ChangeLog: PR debug/41616 * tree-into-ssa.c (insert_phi_nodes_for): Build debug bind stmts on updates too. (maybe_register_def): Likewise. Take stmt iterator. (rewrite_update_stmt): Take stmt iterator and pass it on. (rewrite_update_enter_block): Pass stmt iterator. gcc/testsuite/ChangeLog: PR debug/41616 * gcc.dg/guality/pr41616-1.c: New. Added: trunk/gcc/testsuite/gcc.dg/guality/pr41616-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-into-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41616
[Bug c++/37766] [C++0x] ICE with function's default reference template parameter
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-24 20:11:48 |2009-10-12 05:34:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37766
[Bug c++/37875] [c++0x] misinterpreted closing angle bracket in decltype operand
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-28 23:08:38 |2009-10-12 05:51:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37875
[Bug c++/38712] [c++0x] can't mangle template-id gN(t)
--- Comment #3 from jason at gcc dot gnu dot org 2009-10-12 05:58 --- This doesn't ICE anymore, it says xxx.C:10:25: sorry, unimplemented: mangling template_id_expr We need to update the ABI to support this. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords|ice-on-valid-code |ABI, rejects-valid Last reconfirmed|2009-01-03 05:42:55 |2009-10-12 05:58:44 date|| Summary|[c++0x] ICE: Segmentation |[c++0x] can't mangle |fault in auto function when |template-id gN(t) |decltype uses parameter pack| |expansion | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38712
