[Bug preprocessor/53525] Performance regression due to enabling track-macro-expansion

[jimis at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525

jimis  changed:

   What|Removed |Added

  Attachment #27520|0   |1
is obsolete||
  Attachment #27523|0   |1
is obsolete||

--- Comment #13 from jimis  2012-06-04 04:49:13 UTC ---
Created attachment 27550
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27550
Diff of all changes versus the 20120513 snapshot.

I think I'm closing to a final version of this fix. The attached patch contains
all of the above mentioned changes, plus it fixes the memory leaks. This
bootstraps fine and passes tests on x86 with no regression. 

Instruction count has been reduced from 2201M downto 2108M, which is only 30M
higher than having track-macro-expansion (TME) turned off. Unfortunately actual
runtime was improved less, so we gained back almost 50% of what we had lost by
enabling TME. In short running the same test as above, with this (macro5)
patch, gives:

2108 M instr
31692 KB RAM
0.760s

In a few words, I introduced four (!) new obstacks inside struct cpp_reader for
allocating the tokens from macro argument expansion, their virtual locations,
the virtual locations of arguments, and the virtual locations of other macros. 

I'm not sure whether this is an elegant solution but growing obstacks for
nested scopes is much more intuitive than reallocating arrays. I'd appreciate
any comments on my "TODO" notes in this patch, which mostly concern whether I
should move other allocations to obstacks as well.

Finally, my patch still contains the additions to obstacks (obstack_mark,
obstack_release). I'll try submitting them to glibc but since they are in the
obstack.h header file, they work even when using the libc obstacks so I guess
they can be committed in the gcc tree.

[Bug target/53569] mac-OSX idle memory

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53569

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from kargl at gcc dot gnu.org 2012-06-04 03:34:32 UTC ---
Appears to be an OS problem.

[Bug target/53569] mac-OSX idle memory

[jmfriedman7 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53569

--- Comment #2 from jmfriedman7 at gmail dot com 2012-06-04 03:11:22 UTC ---
Thanks,

Maybe I should send a comment there too.

On Mon, Jun 4, 2012 at 11:47 AM, pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53569
>
> Andrew Pinski  changed:
>
>   What|Removed |Added
>
> 
>  Target||*-*-darwin*
>  Component|libfortran  |target
>
> --- Comment #1 from Andrew Pinski  2012-06-04
> 02:47:43 UTC ---
> This sounds more like a bug in the Mac OS X kernel/libc and how it handles
> memory allocation.
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.
>

[Bug target/53569] mac-OSX idle memory

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53569

Andrew Pinski  changed:

   What|Removed |Added

 Target||*-*-darwin*
  Component|libfortran  |target

--- Comment #1 from Andrew Pinski  2012-06-04 
02:47:43 UTC ---
This sounds more like a bug in the Mac OS X kernel/libc and how it handles
memory allocation.

[Bug fortran/53569] New: mac-OSX idle memory

[jmfriedman7 at alum dot mit.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53569

 Bug #: 53569
   Summary: mac-OSX idle memory
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jmfriedm...@alum.mit.edu


Calls to fortran subroutines that use large temporary arrays fill up 'idle
memory' on the MAC-OSX, as can be seen with 'top' or the Mac 'activity
monitor'.  I found that I can get around this by using:

call system('purge')

to evoke the command line 'purge' from within the program before the 'return'
statement for such subroutines to free the idle memory; but I was wondering
whether something could be done more fundamentally at the compiler level to
avoid this problem.

Without such clearing of idle memory I used to hear lots of disk access being
done to get around the small amount of free 'core' memory.  Massive arrays
would eat up  many Gb of core memory by turning it to 'idle memory'.

Maybe there is a compile time option that I do not know about.

[Bug c/53548] allow flexible array members in unions like zero-length arrays

[carlos_odonell at mentor dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548

Carlos O'Donell  changed:

   What|Removed |Added

 CC||carlos_odonell at mentor
   ||dot com

--- Comment #1 from Carlos O'Donell  
2012-06-04 00:49:55 UTC ---
There are several practical cases where it would be nice to support this kind
of construct. Structures that *end* with a variable length arrays are used in
networking to represent a variable length result. In particular the example in
this issue is taken from a recent reworking of tftp.h in glibc which uses a
similar construct.

[Bug target/53511] SH Target: Add support for fma patterns

[kkojima at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511

--- Comment #3 from Kazumoto Kojima  2012-06-03 
22:48:17 UTC ---
(In reply to comment #2)
It would be better to ask these generic issues to the experts
on the gcc list, I think.  About the SH specific one,

> Effectively, the '*macsf3' / 'mac_media' patterns and the -mfused-madd /
> -mno-fused-madd replicate middle-end functionality which is given by the 'fma'
> patterns and the '-ffp-contract=' option.
> Thus I'd like to propose to remove the '*macsf3' / 'mac_media' patterns and
> deprecate the -mfused-madd / -mno-fused-madd options.

Sounds very plausible.

[Bug c++/53567] "ICE: Error reporting routines re-entered" on missing enum entry

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53567

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-06-03
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
 Ever Confirmed|0   |1

[Bug target/53568] New: SH Target: Add support for bswap built-ins

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53568

 Bug #: 53568
   Summary: SH Target: Add support for bswap built-ins
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: olege...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*


Currently using built-in functions such as __builtin_bswap32 results in a
function call.  Instead of that SH's 'swap.b' and 'swap.w' combinations can be
used to implement the bswap patterns.

[Bug c++/53567] ICE: Error reporting routines re-entered on missing enum entry

[lunow at math dot hu-berlin.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53567

--- Comment #2 from Daniel Lunow  2012-06-03 
19:55:11 UTC ---
Created attachment 27549
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27549
the real testcase

I accidently uploaded the wrong file, this is the correct file.

[Bug c++/53567] ICE: Error reporting routines re-entered on missing enum entry

[lunow at math dot hu-berlin.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53567

--- Comment #1 from Daniel Lunow  2012-06-03 
19:53:00 UTC ---
Created attachment 27548
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27548
testcase

[Bug c++/53567] New: ICE: Error reporting routines re-entered on missing enum entry

[lunow at math dot hu-berlin.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53567

 Bug #: 53567
   Summary: ICE: Error reporting routines re-entered on missing
enum entry
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lu...@math.hu-berlin.de


C:\dev\projects\chess>gcc --std=c++11 gcc_test.cpp
'
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I attached a minimal testcase.

I would expect something like:
C:\dev\projects\chess>gcc --std=c++11 gcc_test.cpp
gcc_test.cpp: In instantiation of 'EnumMask operator~(EnumT) [with EnumT
= A; typename IntegerType (EnumT)(0))>::type =
unsigne
d int]':
gcc_test.cpp:26:7:   required from here
gcc_test.cpp:21:57: error: 'maskAll' is not a member of 'A'

[Bug c++/53563] ICE in start_decl, at cp/decl.c:4427

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53563

--- Comment #1 from Paolo Carlini  2012-06-03 
19:28:28 UTC ---
*** Bug 53564 has been marked as a duplicate of this bug. ***

[Bug c++/53564] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'baselink' in check_elaborated_type_specifier, at cp/decl.c:11518

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53564

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||paolo.carlini at oracle dot
   ||com
 Resolution||DUPLICATE

--- Comment #1 from Paolo Carlini  2012-06-03 
19:28:28 UTC ---
Dup

*** This bug has been marked as a duplicate of bug 53563 ***

[Bug target/53511] SH Target: Add support for fma patterns

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511

Oleg Endo  changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu.org

--- Comment #2 from Oleg Endo  2012-06-03 18:29:32 
UTC ---
The proposed patch adds the fmasf4 pattern and seems to be working OK (not
fully tested yet).

However, there are some side effects.
Because the option '-ffp-contract=' is set to 'fast' by default, the middle-end
will automatically convert expressions such as 'a * b + c' to fma patterns,
even without setting '-funsafe-math-optimizations'.  To disable this one has to
set '-ffp-contract=on' (see also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48823#c3 ).

I'm afraid that if the fmasf4 pattern is always enabled, there could be some
issues with expected default behavior (as mentioned in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340#c1 ).
On the other hand, if the fmasf4 pattern is not always enabled, the std C
'fmaf' function can't be expanded to the 'fmac' insn.

Also, according to the discussion in PR 37845, it seems that the default
setting should leave the fma patterns enabled.

Effectively, the '*macsf3' / 'mac_media' patterns and the -mfused-madd /
-mno-fused-madd replicate middle-end functionality which is given by the 'fma'
patterns and the '-ffp-contract=' option.
Thus I'd like to propose to remove the '*macsf3' / 'mac_media' patterns and
deprecate the -mfused-madd / -mno-fused-madd options.

Kaz, what do you think?

[Bug target/53511] SH Target: Add support for fma patterns

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511

--- Comment #1 from Oleg Endo  2012-06-03 18:01:31 
UTC ---
Created attachment 27547
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27547
Propo

[Bug target/53539] Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53539

H.J. Lu  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-05/msg02082.htm
   ||l

--- Comment #1 from H.J. Lu  2012-06-03 17:18:50 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02082.html

[Bug c++/53566] New: void template parameters are accepted if they result from substitution

[M8R-gt1qwe at spamherelots dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53566

 Bug #: 53566
   Summary: void template parameters are accepted if they result
from substitution
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m8r-gt1...@spamherelots.com


GCC incorrectly accepts the following program (-std=c++11 -Wall -Wextra
-pedantic):

#include 

template ::value>::type...>
void f() {}
template ::value>::type...>
void f() {}

int main() {
f();
f();
}

It should not accept it because substitution results in a void... template
parameter pack, which is not allowed.

[Bug target/53511] SH Target: Add support for fma patterns

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-06-03
 AssignedTo|unassigned at gcc dot   |olegendo at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug target/53512] SH Target: Allow fsca and fsrra for non-SH4A

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53512

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Oleg Endo  2012-06-03 16:23:04 
UTC ---
Done.

[Bug c++/53565] [4.8 Regression] FAIL: libgomp.c++/for-7.C

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53565

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-06-03
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

[Bug c++/53565] New: [4.8 Regression] FAIL: libgomp.c++/for-7.C

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53565

 Bug #: 53565
   Summary: [4.8 Regression] FAIL: libgomp.c++/for-7.C
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: hjl.to...@gmail.com, ja...@gcc.gnu.org


Between revisions 188113 (OK, see
http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg00085.html ) and 188118 (see
http://gcc.gnu.org/ml/gcc-testresults/2012-06/msg00094.html ), the test
libgomp.c++/for-7.C has started to fail with:

Executing on host: /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C 
-B/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libgomp/
-B/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libgomp/.libs
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libgomp
-I/opt/gcc/work/libgomp/testsuite/.. -march=i486 -shared-libgcc
-fmessage-length=0 -fno-diagnostics-show-caret -fopenmp  -O0  -std=c++0x
-fopenmp
-B/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libgomp/../libstdc++-v3/src/.libs
  -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libgomp/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libgomp/../libstdc++-v3/src/.libs
-lstdc++ -lm   -m32 -o ./for-7.exe(timeout = 300)
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C: In instantiation of 'void
f2() [with T = int]':
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C:95:12:   required from here
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C:49:3: error: use of 'i'
before deduction of 'auto'
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C: In instantiation of 'void
f5() [with T = const char*]':
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C:104:21:   required from
here
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C:77:3: error: use of 'i'
before deduction of 'auto'
compiler exited with status 1
...

FAIL: libgomp.c++/for-7.C  -O0  (test for excess errors)
Excess errors:
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C:49:3: error: use of 'i'
before deduction of 'auto'
/opt/gcc/work/libgomp/testsuite/libgomp.c++/for-7.C:77:3: error: use of 'i'
before deduction of 'auto'

>From the error it seems that this is caused by r188116.

[Bug fortran/48831] check.c: Constant expression (PARAMETER array element) rejected as nonconstant

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48831

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Tobias Burnus  2012-06-03 
13:29:36 UTC ---
FIXED on the trunk (4.8).

Thanks Alessandro for the patch!

[Bug fortran/48831] check.c: Constant expression (PARAMETER array element) rejected as nonconstant

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48831

--- Comment #1 from Tobias Burnus  2012-06-03 
13:21:55 UTC ---
Author: burnus
Date: Sun Jun  3 13:21:50 2012
New Revision: 188152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188152
Log:
2012-06-03  Alessandro Fanfarillo  
Tobias Burnus  

PR fortran/48831
* gfortran.h (gfc_check_init_expr): Add prototype declaration
of function.
* check.c (kind_check): Change if condition to use
to gfc_check_init_expr.
* expr.c (check_init_expr): Remove forward declaration
and static keyword. Change name in gfc_check_init_expr.

2012-06-03  Alessandro Fanfarillo  

PR fortran/48831
* gfortran.dg/parameter_array_element_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/parameter_array_element_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/testsuite/ChangeLog

[Bug target/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999

--- Comment #17 from John David Anglin  2012-06-03 
12:41:07 UTC ---
Author: danglin
Date: Sun Jun  3 12:41:02 2012
New Revision: 188150

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188150
Log:
PR target/52999
* config/pa/pa.c (TARGET_SECTION_TYPE_FLAGS): Define.
(pa_section_type_flags): New.
* config/pa/pa.h (LEGITIMATE_CONSTANT_P): Revert previous change.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/pa/pa.c
branches/gcc-4_6-branch/gcc/config/pa/pa.h

[Bug target/53512] SH Target: Allow fsca and fsrra for non-SH4A

[olegendo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53512

--- Comment #2 from Oleg Endo  2012-06-03 11:26:58 
UTC ---
Author: olegendo
Date: Sun Jun  3 11:26:54 2012
New Revision: 188149

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188149
Log:
PR target/53512
* sh.opt (mfsca, mfsrra): New options.
* sh.md (rsqrtsf2): Use TARGET_FPU_ANY and TARGET_FSRRAcondition.
(fsca): Use TARGET_FPU_ANY and TARGET_FSCA condition.
(sinssf2, cossf2): Fold expanders to ...
(sincossf3): ... this new expander.  Use TARGET_FPU_ANY and
TARGET_FSCA condition.
* sh.c (sh_option_override): Handle TARGET_FSRRA and TARGET_FSCA.
* doc/invoke.texi (SH Options): Add descriptions for -mfsca,
-mno-fsca, -mfsrra, -mno-fsrra.

PR target/53512
* gcc.target/sh/pr53512-1.c: New.
* gcc.target/sh/pr53512-2.c: New.
* gcc.target/sh/pr53512-3.c: New.
* gcc.target/sh/pr53512-4.c: New.


Added:
trunk/gcc/testsuite/gcc.target/sh/pr53512-1.c
trunk/gcc/testsuite/gcc.target/sh/pr53512-2.c
trunk/gcc/testsuite/gcc.target/sh/pr53512-3.c
trunk/gcc/testsuite/gcc.target/sh/pr53512-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/config/sh/sh.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/53564] New: ICE: tree check: expected tree that contains 'decl minimal' structure, have 'baselink' in check_elaborated_type_specifier, at cp/decl.c:11518

[y121516 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53564

 Bug #: 53564
   Summary: ICE: tree check: expected tree that contains 'decl
minimal' structure, have 'baselink' in
check_elaborated_type_specifier, at cp/decl.c:11518
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y121...@gmail.com


ICE occured.


source:

$ cat a.cpp
template
struct s
{
 template
 s(){}
};

int main() {
 struct s::s a;
}


output:

$ bin/gcc4.8/bin/g++ a.cpp
a.cpp: In function 'int main()':
a.cpp:9:18: error: using typedef-name 's' after 'struct'
  struct s::s a;
  ^
a.cpp:9:18: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'baselink' in check_elaborated_type_specifier,
at cp/decl.c:11518
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


OS: Windows XP
GCC version:

$ bin/gcc4.8/bin/g++ -v
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=C:\cygwin\home\Yuhki\bin\gcc4.8\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/cygwin/home/yuhki/bin/gcc4.8/bin/../libexec/gcc/i686-pc-mingw32/4.8.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.8-20120520-mingw/configure --host=i686-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i686-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.8-20120520
--with-gcc --with-gnu-as --with-gnu-ld --with-host-libstdcxx='-lstdc++ -lsupc++
-lm' --with-ppl=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/ppl
--with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.8-20120520
--disable-shared --disable-nls --disable-tls --disable-win32-registry
--enable-libquadmath-support --enable-libquadmath
--enable-languages=c,c++,fortran --enable-libgomp --enable-threads=win32
--enable-lto --enable-static --enable-shared=lto-plugin --enable-plugins
--enable-ld=yes --enable-cloog-backend=ppl
Thread model: win32
gcc version 4.8.0 20120520 (experimental) (GCC)


note:

Source code is test on GCC 4.8.0 experimental. Same code use at Bug 53563 for
GCC 4.6.3.

[Bug c++/53563] New: ICE in start_decl, at cp/decl.c:4427

[y121516 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53563

 Bug #: 53563
   Summary: ICE in start_decl, at cp/decl.c:4427
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y121...@gmail.com


ICE occured.


source:

$ cat a.cpp
template
struct s
{
 template
 s(){}
};

int main() {
 struct s::s a;
}


output:

$ bin/gcc4.6/bin/g++ a.cpp
a.cpp: In function 'int main()':
a.cpp:9:26: internal compiler error: in start_decl, at cp/decl.c:4427
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


OS: Windows XP
GCC version:

$ bin/gcc4.6/bin/g++ -v
Built by Equation Solution .
Using built-in specs.
COLLECT_GCC=C:\cygwin\home\Yuhki\bin\gcc4.6\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/cygwin/home/yuhki/bin/gcc4.6/bin/../libexec/gcc/i686-pc-mingw32/4.6.3/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.6.3-mingw/configure --host=i686-pc-mingw32
--build=x86_64-unknown-linux-gnu --target=i686-pc-mingw32
--prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.6.3
--with-gcc --with-gnu-as --with-gnu-ld --with-host-libstdcxx='-lstdc++ -lsupc++
-lm' --with-ppl=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/ppl
--with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog
--with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp
--with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr
--with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc
--with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.6.3
--disable-shared --disable-nls --disable-tls --disable-win32-registry
--enable-libquadmath-support --enable-libquadmath
--enable-languages=c,c++,fortran --enable-libgomp --enable-threads=win32
--enable-lto --enable-static --enable-shared=lto-plugin --enable-plugins
--enable-ld=yes --enable-cloog-backend=ppl
Thread model: win32
gcc version 4.6.3 (GCC)

[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124

--- Comment #29 from Eric Botcazou  2012-06-03 
08:22:01 UTC ---
> I have now successfully tested it on i586-suse-linux-gnu,
> powerpc-suse-linux-gnu and powerpc64-suse-linux-gnu.

It looks OK on x86/x86-64/PowerPC/SPARC/SPARC64 on my side.