[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #8 from uros at kss-loka dot si 2006-10-07 06:12 --- Testcase was commited to trunk and 4.1 branch, and now passes everywhere. -- uros at kss-loka dot si changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.0 4.2.0 |4.1.0 Known to work||4.2.0 4.1.2 Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug target/28924] x86 sync builtins fail for char and short memory operands
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug c++/29375] gcc4.0.3 produces code that copies a structure twice
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-07 06:16 --- Yes this is a dup of bug 23372. *** This bug has been marked as a duplicate of 23372 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-10-07 06:16 --- *** Bug 29375 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||deb at pixar dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug middle-end/29376] Internal error: Killed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-07 06:41 --- there is also seems like some compile time problem. In 4.1.2: tree operand scan : 7.11 (16%) usr 0.22 (12%) sys 7.42 (16%) wall 2354 kB ( 2%) ggc Though on the mainline even with checking: tree operand scan : 0.89 ( 1%) usr 0.32 (19%) sys 1.39 ( 1%) wall 3466 kB ( 5%) ggc I don't have a mainline with checking disabled so I can't really compare the times. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29376
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #6 from franke dot daniel at gmail dot com 2006-10-07 07:09 --- Tobi, Actually this is invalid code. The string lengths in the constructor are different, even though they have to be the same. please try the testcase in the orignal PR with idental string lengths. It will crash gfortran as well. OTOH, a(1,1) = x a(1,2) = to_string(1.0) should work even if CHARACTER(len=255), DIMENSION(1,2) :: a and CHARACTER(len=32) FUNCTION to_string(x), so, why is an equivalent assignment through the array constructor invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug c++/28302] [4.0/4.1 regression] ICE with bit-complement for vectors
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-07 07:11 --- Subject: Bug 28302 Author: pinskia Date: Sat Oct 7 07:11:02 2006 New Revision: 117528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117528 Log: 2006-10-06 Andrew Pinski [EMAIL PROTECTED] PR c++/28302 * typeck.c (build_unary_op case BIT_NOT_EXPR:): Don't call perform_integral_promotions for non integral type 2006-10-06 Andrew Pinski [EMAIL PROTECTED] PR C++/28302 * g++.dg/ext/vector3.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/vector3.C - copied unchanged from r116205, trunk/gcc/testsuite/g++.dg/ext/vector3.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28302
[Bug c++/28302] [4.0 regression] ICE with bit-complement for vectors
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-07 07:12 --- Fixed on the 4.1 branch also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.2 4.2.0 Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with bit-complement for |bit-complement for vectors |vectors | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28302
[Bug target/29377] New: Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch
Build for h8300-elf target crashes on 64bit hosts with: ../../gcc-svn/trunk/gcc/libgcc2.c: In function '__muldi3': ../../gcc-svn/trunk/gcc/libgcc2.c:542: error: unrecognizable insn: (insn 234 233 235 2 ../../gcc-svn/trunk/gcc/libgcc2.c:533 (set (reg:HI 3 r3) (const_int 4294967214 [0xffae])) -1 (nil) (nil)) ../../gcc-svn/trunk/gcc/libgcc2.c:542: internal compiler error: in extract_insn, at recog.c:2077 -- Summary: Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uros at kss-loka dot si GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29377
[Bug target/29377] Build for h8300-elf crashes on 64bit hosts due to int/HWI mismatch
--- Comment #1 from uros at kss-loka dot si 2006-10-07 07:51 --- Propsoed patch at http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00337.html -- uros at kss-loka dot si changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||10/msg00337.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29377
[Bug c++/29378] New: The copy constructor is not being called upon return from function calls.
Functions returning objects do not call the copy constructors for permanent
objects. The program below works for the Solaris and Microsoft compilers, but
not for the GCC compiler.
Im using:
-bash-3.00$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
#include stdio.h
struct S
{
S(){ printf( Inside default constructor \n ); }
S( const S ) { printf( Inside copy constructor \n ); }
};
S f( void )
{
S s1;
return s1;
}
int main ( int, char ** )
{
S s1;
S s2( s1 ); // must call the copy constructor
S s3 = f(); // must call the copy constructor
S s4( f() ); // must call the copy constructor
return 0;
}
#if 0
// GCC output is:
Inside default constructor
Inside copy constructor
Inside default constructor
Inside default constructor
// Both Solaris and Microsoft output is:
Inside default constructor
Inside copy constructor
Inside default constructor
Inside copy constructor
Inside default constructor
Inside copy constructor
#endif
--
Summary: The copy constructor is not being called upon return
from function calls.
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: SSacek at appsecinc dot com
GCC build triplet: gcc version 3.4.6
GCC host triplet: Red Hat 3.4.6-3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-07 08:17 --- You want to use -fno-elide-constructors. See http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/C_002b_002b-Dialect-Options.html This is not a bug as this is an allowed optimization by the C++ standard. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #2 from SSacek at appsecinc dot com 2006-10-07 09:19 ---
Ok, I see that GCC has a work-around for this issue, but I must insist that the
GCC compiler is incorrect in its interpretation of the C++ standard for two
reasons.
1) Optimizations should be allowed for temporary objects only, but not for
named (permanent) objects. Example:
struct S{};
S foo()
{
return S; // this is an un-named temporary object
// optimizations allowed
}
S foo2()
{
S s1; // this is a named permanent object
return s1; // optimizations not allowed
}
The object in foo2() is permanent, and lives and dies in the scope of
function foo2(). Therefore, upon return, the copy constructor must be called,
as well as the destructor.
2) The second reason is that if GCC ignores the programmer written copy
constructors, then the program will be misbehaved, and the results
unpredictable, with even the possibility of a crash. Optimizations are
understandable only if they don't leave objects in unknown states.
The key question here is WHAT IS A TEMPORARY OBJECT ?
I am convinced that the GCC compiler has it wrong, and I have the Solaris and
Microsoft compilers to back me up on this.
Just how many C++ Standards are there?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug fortran/26025] Optionally use BLAS for matmul
--- Comment #4 from steven at gcc dot gnu dot org 2006-10-07 10:02 --- New patch. New link. One-oh-one. -- steven at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/fortra|http://gcc.gnu.org/ml/gcc- |n/2006-09/msg00325.html |patches/2006- ||10/msg00343.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26025
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #11 from steven at gcc dot gnu dot org 2006-10-07 10:05 --- Would anyone object if I'd propose to disable reassociation for floating point thingies on x86 for GCC 4.2? We can re-enable it if/when amacleod's new out-of-ssa stuff fixes this for real... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug target/27827] [4.0 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #69 from steven at gcc dot gnu dot org 2006-10-07 10:06 --- The linked-to patch is already on the trunk. -- steven at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2006- | |08/msg00113.html| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug debug/28834] [4.0/4.1/4.2 Regression] -O3 -g crashes sometimes when using may_alias and structs
--- Comment #14 from rsandifo at gcc dot gnu dot org 2006-10-07 12:56 --- The mayalias-2.c failure shows up on MIPS too. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug fortran/16580] gfortran ICE on test g77.f-torture/execute/intrinsic77.f
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-10-07 13:34 --- Subject: Bug 16580 Author: fxcoudert Date: Sat Oct 7 13:34:16 2006 New Revision: 117534 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117534 Log: PR fortran/16580 PR fortran/29288 * gcc/fortran/intrinsic.c (add_sym): Define the actual_ok when a gfc_intrinsic_sym structure is filled. (gfc_intrinsic_actual_ok): New function. (add_sym_0s, add_sym_1s, add_sym_2s, add_sym_3s, add_sym_4s, add_sym_5s): Intrinsic subroutines are not allowed as actual arguments, so we remove argument actual_ok. (add_functions): Correct the values for actual_ok of all intrinsics. (add_subroutines): Remove the actual_ok argument, which was never used. * gcc/fortran/intrinsic.h (gfc_intrinsic_actual_ok): New prototype. * gcc/fortran/gfortran.h (gfc_resolve_index_func): New prototype. * gcc/fortran/resolve.c (resolve_actual_arglist): Check whether an intrinsic used as an argument list is allowed there. * gcc/fortran/iresolve.c (gfc_resolve_index_func): New function. (gfc_resolve_len): Change intrinsic function name to agree with libgfortran. * gcc/fortran/trans-decl.c (gfc_get_extern_function_decl): Add new case, because some specific intrinsics take 3 arguments. * gcc/fortran/intrinsic.texi: DIMAG is a GNU extension. * libgfortran/Makefile.am: Add the new files to the build process, and rules to build them. * libgfortran/Makefile.in: Regenerate. * libgfortran/m4/misc_specifics.m4: New file. * libgfortran/m4/specific.m4: Add new special cases for function with complex argument and real result, like abs_c* and aimag_c*. * libgfortran/intrinsics/f2c_specifics.F90: Add specifics for AIMAG, ASINH, ACOSH and ATANH. * libgfortran/generated/_aimag_c4.F90: New file. * libgfortran/generated/_aimag_c8.F90: New file. * libgfortran/generated/_asinh_r10.F90: New file. * libgfortran/generated/_acosh_r16.F90: New file. * libgfortran/generated/_aimag_c10.F90: New file. * libgfortran/generated/_atanh_r16.F90: New file. * libgfortran/generated/_acosh_r4.F90: New file. * libgfortran/generated/_acosh_r8.F90: New file. * libgfortran/generated/_asinh_r4.F90: New file. * libgfortran/generated/_asinh_r8.F90: New file. * libgfortran/generated/_asinh_r16.F90: New file. * libgfortran/generated/_atanh_r4.F90: New file. * libgfortran/generated/_atanh_r8.F90: New file. * libgfortran/generated/_acosh_r10.F90: New file. * libgfortran/generated/misc_specifics.F90: New file. * libgfortran/generated/_aimag_c16.F90: New file. * libgfortran/generated/_atanh_r10.F90: New file. * gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90: Add tests for using all possible intrinsics as actual arguments. * gcc/testsuite/gfortran.dg/specifics_1.f90: Add tests for using all possible intrinsics as actual arguments. * gcc/testsuite/gfortran.dg/specifics_2.f90: New file. * gcc/testsuite/gfortran.dg/specifics_3.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/specifics_2.f90 trunk/gcc/testsuite/gfortran.dg/specifics_3.f90 trunk/libgfortran/generated/_acosh_r10.F90 trunk/libgfortran/generated/_acosh_r16.F90 trunk/libgfortran/generated/_acosh_r4.F90 trunk/libgfortran/generated/_acosh_r8.F90 trunk/libgfortran/generated/_aimag_c10.F90 trunk/libgfortran/generated/_aimag_c16.F90 trunk/libgfortran/generated/_aimag_c4.F90 trunk/libgfortran/generated/_aimag_c8.F90 trunk/libgfortran/generated/_asinh_r10.F90 trunk/libgfortran/generated/_asinh_r16.F90 trunk/libgfortran/generated/_asinh_r4.F90 trunk/libgfortran/generated/_asinh_r8.F90 trunk/libgfortran/generated/_atanh_r10.F90 trunk/libgfortran/generated/_atanh_r16.F90 trunk/libgfortran/generated/_atanh_r4.F90 trunk/libgfortran/generated/_atanh_r8.F90 trunk/libgfortran/generated/misc_specifics.F90 trunk/libgfortran/m4/misc_specifics.m4 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/specifics_1.f90 trunk/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/intrinsics/f2c_specifics.F90 trunk/libgfortran/m4/specific.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16580
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #8 from ghazi at gcc dot gnu dot org 2006-10-07 14:07 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00360.html Need to decide whether we're including GMP/MPFR in GCC repo or we need configure goo to detect if we have it. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||10/msg00360.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug testsuite/28610] gfortran testsuite failures with sudo
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-07 14:57 --- This was fixed by revision 117533: 2006-08-12 Francois-Xavier Coudert [EMAIL PROTECTED] * gfortran.dg/stat_1.f90: Make test pass when run under sudo. * gfortran.dg/stat_2.f90: Likewise. * gfortran.dg/chmod_1.f90: Likewise. * gfortran.dg/chmod_2.f90: Likewise. * gfortran.dg/chmod_3.f90: Likewise. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28610
[Bug libstdc++/29379] New: bad thousand separator with UTF-8 locales
[forwarded from http://bugs.debian.org/351786]
#include iostream
#include locale
int main()
{
std::cout cout no locale : 1024 '\n';
std::cout.imbue(std::locale());
std::cout cout with locale : 1024 '\n';
}
$ LC_ALL=cs_CZ.UTF-8 ./a.out | od -c
000 c o u t n o l o c a l e :
020 1 0 2 4 \n c o u t w i t h
040 l o c a l e : 1 302 0 2 4 \n
057
Here 302 is the first byte of 0xA0 (no-break-space) in UTF-8
the following C program is OK : it outputs c2 a0 which seems OK. So it
looks like libstdc++ is truncating multibyte thousand sep char to the
first byte.
and indeed :
virtual char std::numpunctchar::do_thousands_sep() const;
#include stdio.h
#include locale.h
int main()
{
printf(%'d\n, 1024);
puts(setlocale(LC_ALL, ));
printf(%'d\n, 1024);
return 0;
}
$ LC_ALL=cs_CZ.UTF-8 ./a.out | od -c
000 1 0 2 4 \n c s _ C Z . U T F - 8
020 \n 1 302 240 0 2 4 \n
--
Summary: bad thousand separator with UTF-8 locales
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29379
[Bug c/29380] New: FAIL: gcc.dg/pr29330.c (test for excess errors)
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c -O -ftree-loop-linear -fno-show- column -S -o pr29330.s(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c: In function 'f': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:10: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:11: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:12: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:13: error: 'for' loop initial d eclaration used outside C99 mode compiler exited with status 1 output is: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c: In function 'f': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:10: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:11: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:12: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:13: error: 'for' loop initial d eclaration used outside C99 mode FAIL: gcc.dg/pr29330.c (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:10: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:11: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:12: error: 'for' loop initial d eclaration used outside C99 mode /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr29330.c:13: error: 'for' loop initial d eclaration used outside C99 mode -- Summary: FAIL: gcc.dg/pr29330.c (test for excess errors) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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=29380
[Bug target/29300] FAIL: gcc.dg/pthread-init-[12].c (test for excess errors)
--- Comment #3 from danglin at gcc dot gnu dot org 2006-10-07 16:35 --- Subject: Bug 29300 Author: danglin Date: Sat Oct 7 16:35:11 2006 New Revision: 117537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117537 Log: PR target/29300 * inclhack.def (hpux_pthread_initializers): New hack. * tests/base/sys/pthread.h: New file. * fixincl.x: Regenerate. Added: trunk/fixincludes/tests/base/sys/pthread.h Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29300
[Bug target/27855] reassociation pass produces ~30% slower matrix multiplication code
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-10-07 16:36 --- (In reply to comment #11) Would anyone object if I'd propose to disable reassociation for floating point thingies on x86 for GCC 4.2? We can re-enable it if/when amacleod's new out-of-ssa stuff fixes this for real... Yes I do because it helps PPC which is why I added in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-07 16:36 --- (In reply to comment #2) Ok, I see that GCC has a work-around for this issue, but I must insist that the GCC compiler is incorrect in its interpretation of the C++ standard for two reasons. The C++ standard is explict. 1) Optimizations should be allowed for temporary objects only, but not for named (permanent) objects. Example: No, because this is a different optimization which is allowed by the C++ standard called return value optimization. 12.8/15 describes this and the second case. 2) The second reason is that if GCC ignores the programmer written copy constructors, then the program will be misbehaved, and the results unpredictable, with even the possibility of a crash. Optimizations are understandable only if they don't leave objects in unknown states. Copy constructor are special for C++. 12.8/15 describes what is going on here. There is only ever one copy of the variable so there is no need to call the copy constructor. The key question here is WHAT IS A TEMPORARY OBJECT ? Yes and the standard is explict that S s3 = f(); might or might not use a temporary object here. 12.2/2 has the example which it explains, the compiler: Also, a temporary might be used to hold the result of f(X(2)) before copying it to b using X's copy-constructer; alternative, f()'s result might be CONSTRUCTED in b. Emphasis is mine. So GCC is correct and so is Sun's compiler and Microsoft's. Just how many C++ Standards are there? Two so far technically but one is just has correction notices from the previous one. Just the C++ standard says is permitted for this case so all three compilers are doing the correct thing according to the standard, just GCC chose to do better optimizations than the other two. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug target/29300] FAIL: gcc.dg/pthread-init-[12].c (test for excess errors)
--- Comment #4 from danglin at gcc dot gnu dot org 2006-10-07 16:42 --- Subject: Bug 29300 Author: danglin Date: Sat Oct 7 16:42:29 2006 New Revision: 117538 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117538 Log: PR target/29300 * gcc.dg/pthread-init-2.c (dg-options): Define _POSIX_C_SOURCE=199506L on hppa*-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pthread-init-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29300
[Bug c/29380] FAIL: gcc.dg/pr29330.c (test for excess errors)
--- Comment #1 from jakub at gcc dot gnu dot org 2006-10-07 16:50 --- Subject: Bug 29380 Author: jakub Date: Sat Oct 7 16:50:23 2006 New Revision: 117539 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117539 Log: PR c/29380 * gcc.dg/pr29330.c: Add -std=gnu99 to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr29330.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29380
[Bug c++/29378] The copy constructor is not being called upon return from function calls.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-07 16:55 --- (In reply to comment #2) 2) The second reason is that if GCC ignores the programmer written copy constructors, then the program will be misbehaved, and the results unpredictable, with even the possibility of a crash. Optimizations are understandable only if they don't leave objects in unknown states. Only one object is ever created and will ever be destoried here. So this is not leaving the object in an unknown state because the state is well defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29378
[Bug c/29380] FAIL: gcc.dg/pr29330.c (test for excess errors)
--- Comment #2 from jakub at gcc dot gnu dot org 2006-10-07 17:02 --- Oops, sorry, not sure how I managed to miss this in the test results. Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29380
[Bug libstdc++/29379] bad thousand separator with UTF-8 locales
--- Comment #1 from pcarlini at suse dot de 2006-10-07 17:03 --- This a well known not a bug (I'm sure similar issues are discussed in the mailing list, also user code implementing char - char conversions via iconv): output to UTF-8 is done by wchar_t streams (thus, for example, wcout not cout), which use a std::codecvtwchar_t, char, mbstate_t to convert from the internal wchar_t representation to an external sequence of UTF-8 chars: note that nothing in the standard mandates the availability in the library of non-trivial conversions char - char. Many examples of proper UTF-8 output in the testsuite. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29379
[Bug target/29300] FAIL: gcc.dg/pthread-init-[12].c (test for excess errors)
--- Comment #5 from danglin at gcc dot gnu dot org 2006-10-07 17:09 --- Fixed by patches. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29300
[Bug libstdc++/29379] bad thousand separator with UTF-8 locales
--- Comment #2 from pcarlini at suse dot de 2006-10-07 17:28 --- Forgot to add: after having properly switched to a wchar_t stream, we must make sure that it actually does the conversion: the clean solution via std::codecvt is used by default only in converting streams (file streams), whereas calling at the outset std::ios::sync_with_stdio(false) is needed for wcout. Alternately, C-style, one can change the global locale and exploit the conversion behind the scenes carried out by the individual underlying putwc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29379
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07
18:56 ---
Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp
testsuites
--- Comment #16 from bkoz at gcc dot gnu dot org 2006-10-06 09:52 ---
When you get to break here this is what your mutex should look like in gdb:
Well, we don't actually get to break here. The program hangs in
xactly the same way as 23591_thread-1:
(gdb) bt
#0 *__GI___pthread_mutex_lock (mutex=0x4010ee00) at mutex.c:99
#1 0x400679e4 in locale (this=0x4010dae4)
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:549
#2 0x40062984 in Init (this=value optimized out)
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/streambuf:462
#3 0x4007ca28 in __static_initialization_and_destruction_0 (
__initialize_p=value optimized out, __priority=0)
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/iostream:77
#4 0x400eb140 in __do_global_ctors_aux ()
from
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
#5 0x40051924 in _init ()
from
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/./libstdc++-v3/src/.libs/libstdc++.so.6
...
(gdb) p *mutex
$9 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__spinlock = {lock = {0, 0, 0, 0}}, __status = 0}}
(gdb) p locale_mutex
$10 = (__gnu_cxx::__mutex *) 0x4010ee00
(gdb) p mutex
$11 = (pthread_mutex_t *) 0x4010ee00
As can be seen, this occurs running constructors from _init (). There
are several other calls to __GI___pthread_mutex_lock with properly
initialized mutexes prior to the one shown above which isn't properly
initialized. A properly initialized mutex looks like:
(gdb) p *mutex
$13 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}
There are two earlier calls to __GI___pthread_mutex_lock from locale.
The first is here:
(gdb) bt
#0 *__GI___pthread_mutex_lock (mutex=0x402e1cb0) at mutex.c:99
#1 0x402ca258 in __pthread_once (once_control=0x4010dff8,
[EMAIL PROTECTED]: 0x40067568 std::locale::_S_initialize_once())
at mutex.c:301
#2 0x40067620 in std::locale::_S_initialize ()
at
/home/dave/gnu/gcc-4.2/objdir/hppa-linux/libstdc++-v3/include/hppa-linux/bits/gthr-default.h:516
#3 0x4006797c in locale (this=0x402e1cb0)
at ../../../../gcc/libstdc++-v3/src/locale_init.cc:209
...
(gdb) info symbol 0x402e1cb0
once_masterlock in section .data
(gdb) p mutex
$14 = (pthread_mutex_t *) 0x402e1cb0
(gdb) p *mutex
$15 = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__spinlock = {lock = {1, 1, 1, 1}}, __status = 0}}
once_masterlock appears to be statically initialized.
From locale_init.cc:
locale::locale() throw() : _M_impl(0)
{
_S_initialize();
__gnu_cxx::__scoped_lock sentry(locale_mutex);
_S_global-_M_add_reference();
_M_impl = _S_global;
}
It appears we hang at the once_masterlock line. We never get to
the next line.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29379] bad thousand separator with UTF-8 locales
--- Comment #3 from pcarlini at suse dot de 2006-10-07 19:47 --- Reopen... -- pcarlini at suse dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29379
[Bug libstdc++/29379] bad thousand separator with UTF-8 locales
--- Comment #4 from pcarlini at suse dot de 2006-10-07 19:48 --- ... to mark it as duplicate. *** This bug has been marked as a duplicate of 16006 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29379
[Bug libstdc++/16006] Conversions of numbers in fi_FI.UTF-8 produces incorrect UTF-8
--- Comment #5 from pcarlini at suse dot de 2006-10-07 19:48 --- *** Bug 29379 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07 19:51 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites When you get to break here this is what your mutex should look like in gdb: Well, we don't actually get to break here. The program hangs in xactly the same way as 23591_thread-1: Single stepping from the entry to locale, it doesn't seem like __mutex() is ever called for locale_mutex. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07 20:02 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites It appears we hang at the once_masterlock line. We never get to the next line. Oops, that should have read _S_initialize();. Although a break on the next line is never hit, I think _S_initialize() completes. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug bootstrap/29382] New: Bootstrap comparison failure!
Platform info: Red Hat Enterprise Linux WS release 3 (Taroon) Linux legless 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 i686 i386 GNU/Linux g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) gcc SVN snapshot: 2006-10-07 10:14 PDT Commands used: ../gcc_trunk/configure --prefix=/some/path --enable-languages=c,c++ make bootstrap End of make bootstrap output: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/net/legless/scratch1/rwgk/gcc_build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/net/legless/scratch1/rwgk/gcc_build' make: *** [bootstrap] Error 2 Comments: I had the same problem with the SVN snapshot from 2006-09-21 22:03 PDT. Both SVN snapshots work without a problem under Fedora Core 5 x86_64. -- Summary: Bootstrap comparison failure! Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwgk at yahoo dot com GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-07 20:07 --- This works for me on i686-linux-gnu. Can you first try compiling 3.4.x and then trying compiling the mainline with that? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #21 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-07 20:11 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites I don't think this is an ordering problem... there are no complicated ordering issues in this code. Something to try might be making test_mutex static, and not in an anonymous namespace. Couldn't the constructor for locale possibly run before the one for the locale_mutex? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug fortran/29371] Coredump when using -fbounds-check with pointer nullify
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-07 21:23 --- Created an attachment (id=12395) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12395action=view) A provisional fix for this PR This comes about because the gfc_evaluate_now is fixing the expression after it has already been used. The better thing to do, as in this patch, is to retain the original expression and to make a new variable for the fixed value. The only thing that is giving me pause is that this fix does not go far enough. I note that gfc_trans_array_bound_check does exactly the same thing. The index = gfc_evaluate_now (index, se-pre); on line 1838 is either unnecessary, or else the l-value should not be index. I will check this out tomorrow morning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug fortran/29371] Coredump when using -fbounds-check with pointer nullify
-- 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 Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-07 21:24:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug fortran/29364] No error given if using a non-defined type in a type definition
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-07 22:37 ---
This addition in resolve.c(resolve_fl_derived):5541
if (c-ts.type == BT_DERIVED c-pointer
c-ts.derived-components == NULL)
{
gfc_error (The pointer component '%s' of '%s' at %L is a type
that has not been declared, c-name, sym-name,
c-loc);
return FAILURE;
}
does the trick.
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|NEW |ASSIGNED
Last reconfirmed|2006-10-06 12:32:55 |2006-10-07 22:37:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
[Bug c++/29002] [4.0/4.1 regression] ICE on array of ptr-to-member or struct containing ptr-to-member of unknown size
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-07 22:54 --- Subject: Bug 29002 Author: pinskia Date: Sat Oct 7 22:54:09 2006 New Revision: 117542 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117542 Log: 2006-10-07 Andrew Pinski [EMAIL PROTECTED] PR C++/29002 * init.c (build_zero_init): If we have an error mark node for the array size, return. 2006-10-07 Andrew Pinski [EMAIL PROTECTED] PR C++/29002 * g++.dg/init/array22.C: New test. * g++.dg/init/array23.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/array22.C - copied unchanged from r116962, trunk/gcc/testsuite/g++.dg/init/array22.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/array23.C - copied unchanged from r116962, trunk/gcc/testsuite/g++.dg/init/array23.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/init.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug c++/29002] [4.0 regression] ICE on array of ptr-to-member or struct containing ptr-to-member of unknown size
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-07 22:55 --- Fixed now on the 4.1 branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.2 4.2.0 Summary|[4.0/4.1 regression] ICE on |[4.0 regression] ICE on |array of ptr-to-member or |array of ptr-to-member or |struct containing ptr-to- |struct containing ptr-to- |member of unknown size |member of unknown size http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29002
[Bug libstdc++/28277] __builtin_alloca with no limit in libstdc++
--- Comment #11 from paolo at gcc dot gnu dot org 2006-10-08 01:13 --- Subject: Bug 28277 Author: paolo Date: Sun Oct 8 01:13:03 2006 New Revision: 117549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117549 Log: 2006-10-07 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/28277 (partial: money_get bits) * include/bits/locale_facets.tcc (money_get::do_get(iter_type, iter_type, bool, ios_base, ios_base::iostate, string_type)): Avoid __builtin_alloca with no limit, do the work in place. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28277
[Bug libstdc++/28278] formatted I/O and calliing width(0)
-- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-10-08 01:17:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28278
[Bug libstdc++/27530] Possible memory leak in std::vectorint::reserve() or std::vectorint::clear()
--- Comment #9 from pcarlini at suse dot de 2006-10-08 01:24 --- Feedback not forthcoming. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
[Bug libstdc++/21072] base allocator change shared object issues
--- Comment #9 from pcarlini at suse dot de 2006-10-08 01:32 --- No open issues. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072
[Bug target/29338] [4.1 regression] ICE on valid C++ code
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-08 02:05 --- Works on [EMAIL PROTECTED] gcc]$ ./xgcc -v Using built-in specs. Target: arm-linux-gnu Configured with: ../configure --target=arm-linux-gnu : (reconfigured) Thread model: posix gcc version 4.2.0 20061007 (experimenta -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.0.4 |4.0.4 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29338
[Bug target/29329] [4.1 regression] internal consistency failure at -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-08 02:10 --- (In reply to comment #0) compilation with -O0: $ gcc -c -fPIC -g -O0 -g tree234.i /tmp/cco6vA7j.s: Assembler messages: /tmp/cco6vA7j.s:172: Error: Rn must not overlap other operands -- `swpb r3,r2,[r3]' That is a bug in the source: asm volatile( # here \n\t swpb %0, %1, [%2] \n\t : =r (val) : r(1), r (lock) : memory ); I don't know how to fix that in the inline-asm. Maybe an early clobber can fix that. I doubt this is related to the ICE anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29329
[Bug target/29338] [4.1 regression] ICE on valid C++ code
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-08 02:13 --- Works with: [EMAIL PROTECTED] gcc]$ ./xgcc -v Using built-in specs. Target: arm-linux-gnu Configured with: ../configure --target=arm-linux-gnu Thread model: posix gcc version 4.1.2 20061007 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29338
[Bug rtl-optimization/29329] [4.1 regression] internal consistency failure at -O2
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-08 02:40 ---
Reduced testcase:
struct node234_Tag
{
int t1;
int kids[4];
void *elems[3];
};
void *add234_internal(struct node234_Tag *n, int ei)
{
int j;
for (j = ei; j 2 n-elems[j+1];)
j++;
n-kids[j+1] = 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.1.2
Known to work||4.2.0
Last reconfirmed|-00-00 00:00:00 |2006-10-08 02:40:57
date||
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29329
[Bug c++/29363] [4.2 regression] ICE throwing undeclared object
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-08 02:44 --- typedecl = TYPE_MAIN_DECL (type); typedecl is NULL here. struct AD.1953 is the type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29363
