[Bug c++/45964] The compiler does not complain about a required template keyword.

[mschulze at ivs dot cs.ovgu.de]

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

--- Comment #14 from Michael Schulze  
2010-10-12 07:08:16 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > Should I write two bug reports about the found problems?
> 
> Sure.

Bug #45975 and Bug #45976 describe both problems.

[Bug c/45977] New: "warning: 'i' initialized and declared 'extern'" is spurious

[konrad.schwarz at siemens dot com]

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

   Summary: "warning: 'i' initialized and declared 'extern'" is
spurious
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konrad.schw...@siemens.com


Created attachment 22020
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22020
file "external.c", a short test case exhibiting the problem

Given the attached source file, GCC (powerpc-eabi-gcc.exe (Sourcery G++ Lite
4.4-79) 4.4.1), invoked as:
powerpc-eabi-gcc -te500v1 -mcall-sysv-noeabi -MMD -Wno-parentheses  -c -o
ex
ternal.o external.c

reports:
external.c:3: warning: 'i' initialized and declared 'extern'

The relevant lines in the file are:

# if1
static int i;
# endif

extern int i = 3; 

The warning occurs irrespectively whether the # if 1 is changed to # if 0.

Standard C gives the above code a well defined meaning.  The following
reference is from the C89 specification:

6.1.2.2, Linkage of Identifiers:
If the declaration of an identifier for an object or a function contains the
storage-class specifier extern, the identifier has the same linkage as
any visible declaration of the identifier with file scope.  If there is no
visible declaration with file scope, the identifier has external linkage.

Thus, the primary meaning of "extern" for external definitions (that is,
definitions with file scope) is to use whatever linkage specification is
already in force.  Only if no linkage specification has been specified
previously does "extern" mean assign external linkage.

This is in contrast with "static", which means assign internal linkage, and no
storage-class specifier, which means external linkage for objects (but means
the same thing as "extern" for functions, i.e., use existing linkage if
possible).

6.1.2.2 goes on to specify that only one type of linkage may be specified for a
n identifier in a translation unit.

Consider a code generation scenario using the C preprocessor (include
directives), where a generic code generation component is being employed. 
Standard C allows a design where the (documented) definitions supplied by the
component are marked "extern", giving the user of the component the ability to
override the linkage by providing a tentative definition marked "static" before
including the component's header file.

The warning emitted by GCC undermines this design.

So what I'd like is for:
* this warning to be turned off by default
* (possibly) enable this warning with -Wextra

[Bug middle-end/45978] New: bogus "array subscript is above array bounds" warning in extremely simple code with no loops

[miles at gnu dot org]

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

   Summary: bogus "array subscript is above array bounds" warning
in extremely simple code with no loops
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org


Created attachment 22021
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22021
C++ source file illustrating bug

[I don't know if the "component:" field is correct, but there doesn't seem to
be a "I don't know" option]

There are many bugs in gcc's bugzilla related to bogus array-bounds warnings,
but most of them seem to involve loops and other situations that may need
non-trivial analysis by the compiler.

However the attached C++ source file ("tt.cc") seems to be almost trivial; it
contains no loops at all, and all array references use a constant (and valid)
index, but it nonetheless elicits an "array subscript is above array bounds"
warning from the compiler.  As far as I can figure, the warning is bogus.

Compilation looks like:

   $ g++-snapshot -O3 -S -Wall -Wextra tt.cc
   tt.cc: In function 'Z test()':
   tt.cc:15:21: warning: array subscript is above array bounds [-Warray-bounds]

Version info:

   $ g++-snapshot --version
   g++ (Debian 20101009-1) 4.6.0 20101009 (experimental) [trunk revision
165234]
   Copyright (C) 2010 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

"g++-snapshot" just invokes g++ from Debian's gcc-snapshot package, which is a
somewhat recent trunk snapshot.

["tt.cc" is as minimal as I can get it -- moving, eliminating, or changing any
field in any of the structures seems to silence the warning.]

Thanks,

-Miles

[Bug testsuite/45974] [4.6 Regression] make check RUNTESTFLAGS="--target_board 'unix{-m32,}'" doesn't check -m32

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2010-10-12 
08:15:40 UTC ---
I have also been hit by this pr, but only for gcc, g++, and gfortran. All the
other tests have accepted RUNTESTFLAGS="--target_board 'unix{-m32,}'".

>  What is SHELL set to in gcc/Makefile?  

I don't know if this answer the question, but I call make from tcsh.

> Does it work on your system to
> use this instead (in a tree with the patch not reverted):
>  make -k check RUNTESTFLAGS='--target_board=unix"{-m32,-m64}"'

As advised on IRC, RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}' works.

[Bug c++/45975] template keyword is not allowed, however, accepted by g++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.12 08:20:14
 Ever Confirmed|0   |1

[Bug pch/45979] New: precompiled headers breakage on 2.6.36-rc Linux/ARM kernels

[mikpe at it dot uu.se]

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

   Summary: precompiled headers breakage on 2.6.36-rc Linux/ARM
kernels
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se


Recently I've started seeing massive pch test suite failures with gcc,
both trunk and 4.4, on armv5tel-linux-gnueabi:

FAIL: gcc.dg/pch/common-1.c  -O2  -I. (test for excess errors)
FAIL: gcc.dg/pch/common-1.c  -O2  assembly comparison
FAIL: gcc.dg/pch/common-1.c  -O3 -fomit-frame-pointer  -I. (test for excess
errors)
FAIL: gcc.dg/pch/common-1.c  -O3 -fomit-frame-pointer  assembly comparison
FAIL: gcc.dg/pch/counter-1.c -O0 -g -I. (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c -O0 -g assembly comparison
FAIL: gcc.dg/pch/counter-1.c  -O3 -g  -I. (test for excess errors)
FAIL: gcc.dg/pch/counter-1.c  -O3 -g  assembly comparison
FAIL: gcc.dg/pch/cpp-1.c -O0 -g -I. (test for excess errors)
FAIL: gcc.dg/pch/cpp-1.c -O0 -g assembly comparison
...(many many more)

These failures started after I did a major update of the Linux distro
I run on my ARM boxes.  I reverted a few likely suspects (glibc and
the system gcc) to their earlier known-good versions, without effect,
but in the end the failures were traced to the Linux kernel:

- running linux-2.6.36-rc6 causes these PCH failures
- reverting to linux-2.6.35 (similar .config) makes PCH tests pass again
- pre-2.6.35 kernels are also known good

The PCH test suite failures come from ICEs in cc1.  I saved a core dump
of which gdb says the following:

Core was generated by `/home/mikpe/objdir/gcc/cc1 -quiet -I. -I. -iprefix
/home/mikpe/temp/lib/gcc/arm'.
Program terminated with signal 11, Segmentation fault.
#0  linemap_lookup (set=0x40215000, line=73) at
/home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284
284   if (line >= cached->start_location)
Missing separate debuginfos, use: debuginfo-install glibc-2.10.2-1.bl8.armv5tel
gmp-4.3.2-1.bl11.armv5tel mpfr-2.4.2-2.bl11.armv5tel
(gdb) bt
#0  linemap_lookup (set=0x40215000, line=73) at
/home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284
#1  0x000cbed0 in diagnostic_report_current_module (context=0x790888)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:236
#2  0x000cbffc in diagnostic_report_current_function (context=0xa4680042,
diagnostic=0x49)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:218
#3  0x000cc240 in default_diagnostic_starter (context=0xa4680042,
diagnostic=0x49)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:263
#4  0x000cb6c4 in diagnostic_report_diagnostic (context=0x790888,
diagnostic=0xbe88b8e0)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:403
#5  0x000cb940 in internal_error (gmsgid=0x6ecd70 "%s")
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:658
#6  0x00261cec in crash_signal (signo=-1098336032) at
/home/mikpe/gcc-4.4-20100921/gcc/toplev.c:601
#7  
#8  linemap_lookup (set=0x40215000, line=73) at
/home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284
#9  0x000cbed0 in diagnostic_report_current_module (context=0x790888)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:236
#10 0x000cbffc in diagnostic_report_current_function (context=0xa4680042,
diagnostic=0x49)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:218
#11 0x000cc240 in default_diagnostic_starter (context=0xa4680042,
diagnostic=0x49)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:263
#12 0x000cb6c4 in diagnostic_report_diagnostic (context=0x790888,
diagnostic=0xbe88bcf8)
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:403
#13 0x000cbab0 in fatal_error (gmsgid=0x5ca9f0 "had to relocate PCH")
at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:640
#14 0x0015da80 in gt_pch_restore (f=0xbe88bcf8) at
/home/mikpe/gcc-4.4-20100921/gcc/ggc-common.c:576
#15 0x00054608 in c_common_read_pch (pfile=0x134f170, name=0x1347a68
"./valid-6.h.gch", 
fd=, orig_name=)
at /home/mikpe/gcc-4.4-20100921/gcc/c-pch.c:420
#16 0x00574a8c in should_stack_file (import=, file=, 
pfile=) at
/home/mikpe/gcc-4.4-20100921/libcpp/files.c:710
#17 _cpp_stack_file (import=, file=, 
pfile=) at
/home/mikpe/gcc-4.4-20100921/libcpp/files.c:795
#18 0x0056c168 in do_include_common (pfile=0x134f170, type=IT_INCLUDE)
at /home/mikpe/gcc-4.4-20100921/libcpp/directives.c:784
#19 0x0056d028 in _cpp_handle_directive (pfile=0x134f170, indented=)
at /home/mikpe/gcc-4.4-20100921/libcpp/directives.c:488
#20 0x00579d60 in _cpp_lex_token (pfile=0x134f170) at
/home/mikpe/gcc-4.4-20100921/libcpp/lex.c:1265
#21 0x0057d3bc in cpp_get_token (pfile=0x134f170) at
/home/mikpe/gcc-4.4-20100921/libcpp/macro.c:1235
#22 0x0057d620 in cpp_get_token_with_location (pfile=0x5ca9f0, loc=0xa1000)
at /home/mikpe/gcc-4.4-20100921/libcpp/macro.c:1347
#23 0xc750 in c_lex_with_flags (value=0xbe88bf20, loc=0xbe88bf24,
cpp_flags=0x0, lex_flags=0)
at 

[Bug pch/45979] precompiled headers breakage on 2.6.36-rc Linux/ARM kernels

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-12 
08:35:52 UTC ---
Most likely when the linux arm kernel decided to randomize the heap.

[Bug target/45980] New: Use not in stead of add to generate new constant

[carrot at google dot com]

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

   Summary: Use not in stead of add to generate new constant
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
CC: car...@google.com
  Host: i686-linux
Target: arm-eabi
 Build: i686-linux


Compile the following code:

typedef struct {
  unsigned long state[5];
  unsigned long count[2];
} SHA1_CTX;

void SHA1Init(SHA1_CTX* context)
{
  /* SHA1 initialization constants */
  context->state[0] = 0x67452301;
  context->state[1] = 0xEFCDAB89;
  context->state[2] = 0x98BADCFE;
  context->state[3] = 0x10325476;
  context->state[4] = 0xC3D2E1F0;
  context->count[0] = context->count[1] = 0;
}

With options -march=armv7-a -mthumb -Os, gcc generates:

SHA1Init:
ldr r3, .L2
str r3, [r0, #0]
add r3, r3, #-2004318072
str r3, [r0, #4]
ldr r3, .L2+4
str r3, [r0, #8]
sub r3, r3, #-2004318072 
str r3, [r0, #12]
ldr r3, .L2+8
str r3, [r0, #16]
movsr3, #0
str r3, [r0, #24]
str r3, [r0, #20]
bx  lr
.L3:
.align  2
.L2:
.word   1732584193
.word   -1732584194
.word   -1009589776

This function needs to store 5 large constants to memory. Instead of load the 5
constants from constant pool, gcc found two of them can be computed out by a
single add/sub constant instruction. But we can do better, notice that

0x67452301 + 0x98BADCFE = 0x
0xEFCDAB89 + 0x10325476 = 0x

So if we have one such constant, the other one can be computed out by bitwise
not. So a shorter result could be:

SHA1Init:
ldr r3, .L2
str r3, [r0, #0]
add r2, r3, #-2004318072
str r2, [r0, #4]
movns r3, r3
str r3, [r0, #8]
movns r2, r2
str r2, [r0, #12]
ldr r3, .L2+4
str r3, [r0, #16]
movsr3, #0
str r3, [r0, #24]
str r3, [r0, #20]
bx  lr
.L3:
.align  2
.L2:
.word   1732584193
.word   -1009589776

[Bug lto/44950] ICE in dwarf2out_finish, at dwarf2out.c:22271

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #6 from Richard Guenther  2010-10-12 
09:00:32 UTC ---
Mine anyway.

[Bug c++/45964] The compiler does not complain about a required template keyword.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #15 from Jonathan Wakely  2010-10-12 
09:25:46 UTC ---
Thanks, let's close this one again, your new reports are more concise and
accurate

[Bug c++/45976] optional template keyword is not accepted by g++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.12 09:27:05
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2010-10-12 
09:27:05 UTC ---
confirmed by Jason in PR 45964 comment 11

[Bug web/45981] New: bugzilla doesn't allow linking to specific comment

[redi at gcc dot gnu.org]

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

   Summary: bugzilla doesn't allow linking to specific comment
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: lpso...@netscape.net


Didn't the old bugzilla allow linking to specific comments using e.g.
PR 45964 comment 11
?

That now forms two separate links

[Bug tree-optimization/45978] [4.6 Regression] bogus "array subscript is above array bounds" warning in extremely simple code with no loops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2010.10.12 09:44:10
  Component|middle-end  |tree-optimization
 Ever Confirmed|0   |1
Summary|bogus "array subscript is   |[4.6 Regression] bogus
   |above array bounds" warning |"array subscript is above
   |in extremely simple code|array bounds" warning in
   |with no loops   |extremely simple code with
   ||no loops
   Target Milestone|--- |4.6.0

--- Comment #1 from Richard Guenther  2010-10-12 
09:44:10 UTC ---
Confirmed.  The vectorizer uses &MEM[(struct Y *)&].ar[4]; as the
base address for the store to .c.x, .c.y, .c.z, .d.

[Bug testsuite/45974] [4.6 Regression] make check RUNTESTFLAGS="--target_board 'unix{-m32,}'" doesn't check -m32

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2010-10-12 
09:45:26 UTC ---
I use RUNTESTFLAGS="--target_board=unix/\{,-m32\}" which also works.

[Bug testsuite/45974] [4.6 Regression] make check RUNTESTFLAGS="--target_board 'unix{-m32,}'" doesn't check -m32

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  2010-10-12 
10:25:57 UTC ---
> Does it work on your system to
> use this instead (in a tree with the patch not reverted):
>  make -k check RUNTESTFLAGS='--target_board=unix"{-m32,-m64}"'

This also works for me (x86_64-apple-darwin10.4):

[macbook] build_w/gcc% make -k check-g++
RUNTESTFLAGS='--target_board=unix"{-m32,-m64}"'
...
=== g++ tests ===

Schedule of variations:
unix/-m32
unix/-m64

Running target unix/-m32
Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/work/gcc/testsuite/g++.dg/bprob/bprob.exp ...
...

[Bug pch/45979] precompiled headers breakage on 2.6.36-rc Linux/ARM kernels

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  2010-10-12 
10:56:39 UTC ---
I assume other Linux archs already randomize the heap.  If so, why would that
cause PCH failures on ARM?  Could it be because there's no TRY_EMPTY_VM_SPACE
definition in gcc/config/host-linux.c for ARM?

[Bug target/45912] [4.6 regression] Patch for PR tree-optimization/44972 caused 2500+ FAILs on Solaris 2/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|rtl-optimization|target

--- Comment #4 from Eric Botcazou  2010-10-12 
11:11:44 UTC ---
Long-standing latent bug in the SPARC back-end.

[Bug c/45977] "warning: 'i' initialized and declared 'extern'" is spurious

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2010-10-12 11:32:10 UTC ---
This is a coding style warning - the code is valid, but extremely 
unidiomatic for C since "extern" is generally expected to mean that the 
declaration is not providing a definition of the object.  Following static 
by extern, though valid, is also a C feature of doubtful value.

[Bug tree-optimization/45982] New: [4.3/4.4/4.5/4.6 Regression] PTA does not track integers

[rguenth at gcc dot gnu.org]

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

   Summary: [4.3/4.4/4.5/4.6 Regression] PTA does not track
integers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


#include 

extern void abort (void);

uintptr_t __attribute__((pure,noinline,noclone))
foo (int *a)
{
  return (uintptr_t) a;
}

void __attribute__((noinline,noclone))
bar (uintptr_t a)
{
  int *p = (int *)a;
  *p = 1;
}

int main()
{
  int t = 0;
  bar (foo (&t));
  if (t != 1)
abort ();
  return 0;
}


Related to PR45967.

[Bug tree-optimization/45982] [4.3/4.4/4.5/4.6 Regression] PTA does not track integers

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.12 11:42:03
  Known to work||4.1.2
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.3.6
 Ever Confirmed|0   |1
  Known to fail||4.2.4, 4.3.5, 4.4.3, 4.5.1,
   ||4.6.0

--- Comment #1 from Richard Guenther  2010-10-12 
11:42:03 UTC ---
Mine.

[Bug tree-optimization/45982] [4.3/4.4/4.5/4.6 Regression] PTA does not track integers

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-10-12 
11:55:02 UTC ---
Which means, gcc.dg/tree-ssa/pr24287{,-2}.c are bogus.

[Bug testsuite/45851] FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2010-10-12 12:06:22 UTC 
---
Author: ro
Date: Tue Oct 12 12:06:18 2010
New Revision: 165366

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165366
Log:
gcc/testsuite:
PR testsuite/45851
* lib/lto.exp (lto-get-options-main): Support optional target
selector for dg-extra-ld-options.

gcc:
PR testsuite/45851
* doc/sourcebuild.texi (LTO Testing, dg-extra-ld-options):
Document optional target selector.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/lto.exp

[Bug testsuite/45851] FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #5 from Rainer Orth  2010-10-12 12:08:10 UTC 
---
Fixed for 4.6.0.

[Bug testsuite/45851] FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #6 from Dave Korn  2010-10-12 12:09:53 
UTC ---
Verified at http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00997.html

[Bug c++/45983] New: ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[tbptbp at gmail dot com]

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

   Summary: ICE: tree code 'template_parm_index' is not supported
in gimple streams with -lto
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tbp...@gmail.com


Created attachment 22022
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22022
refrigeration

Hello,

in the vein of PR45947, PR45959 and others, i'm still having issues in LTO
mode:
$ /usr/local/gcc-4.6-20101012/bin/g++ -flto -std=c++0x -c synth.ii
src/audio/synth.cc:96:1: internal compiler error: tree code
'template_parm_index' is not supported in gimple streams
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Sorry for the ugly test-case.

PS: initially i also suffered a 'template_type_parm' ICE somewhere else and
contacted R. Guenther, about PR45947, and he provided a patch that fixed
everything.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[aanisimov at inbox dot ru]

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

--- Comment #8 from Artem Anisimov  2010-10-12 
12:25:10 UTC ---
(In reply to comment #7)
> I have run 'make profiledbootstrap' of today's checkout of the 4.5
> branc (revision 165315) on i686 and it finished without any problems
> for me.  I believe I configured it much like it is in the summary,
> except that I used "yes" checking.
> 
> Can you please check whether the problem persists for you on the
> current branch?  Thanks.

 Doing profiledbootstrap with r165350 gives the following error (configuration
options are the same as in the initial report):

/home/artem/testing/gcc-build/./prev-gcc/xgcc
-B/home/artem/testing/gcc-build/./prev-gcc/
-B/home/artem/testing/gcc45/i686-slackware-linux/bin/
-B/home/artem/testing/gcc45/i686-slackware-linux/bin/
-B/home/artem/testing/gcc45/i686-slackware-linux/lib/ -isystem
/home/artem/testing/gcc45/i686-slackware-linux/include -isystem
/home/artem/testing/gcc45/i686-slackware-linux/sys-include-c
-DHAVE_CONFIG_H -g -O2 -fomit-frame-pointer -fprofile-use  -I.
-I../../gcc-current/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic  ../../gcc-current/libiberty/fibheap.c -o
fibheap.o
../../gcc-current/libiberty/fibheap.c: In function
'fibheap_replace_key_data.part.5':
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
profile data is not flow-consistent
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 15-11 thought to be 21911
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 15-16 thought to be -18020
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 17-19 thought to be -8519
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 17-18 thought to be 15215
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 19-20 thought to be 14201
../../gcc-current/libiberty/fibheap.c:486:1: error: corrupted profile info:
number of executions for edge 19-21 thought to be -6112
make[3]: *** [fibheap.o] Erreur 1

 I tried running compilation twice and always had this result.

[Bug middle-end/45874] [4.6 Regression] ICE in verify_flow_info failed

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Martin Jambor  2010-10-12 
12:27:23 UTC ---
Something in the ipa-cp/ipa-inline transform machinery leaves stray eh
cfg edges.  Calling gimple_purge_dead_eh_edges() unconditionally in
ipa-transform makes the ICE go away.  For example the following patch
does:

Index: gcc/tree-optimize.c
===
--- gcc/tree-optimize.c(revision 165301)
+++ gcc/tree-optimize.c(working copy)
@@ -283,8 +283,8 @@ execute_fixup_cfg (void)
 todo |= TODO_cleanup_cfg;
  }

-  if (maybe_clean_eh_stmt (stmt)
-  && gimple_purge_dead_eh_edges (bb))
+  maybe_clean_eh_stmt (stmt);
+  if (gimple_purge_dead_eh_edges (bb))
 todo |= TODO_cleanup_cfg;
 }


Nevertheless, I'd like to find out where we either call
maybe_clean_eh_stmt or do something equivalent without removing the
cfg edges before deciding where we should do it.

[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV

[aanisimov at inbox dot ru]

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

--- Comment #9 from Artem Anisimov  2010-10-12 
12:28:10 UTC ---
(In reply to comment #7)

 It's interesting to note that profiledbootstrap break amd64 build too, though
for different reason:

/home/artem/testing/gcc-build/./prev-gcc/xgcc
-B/home/artem/testing/gcc-build/./prev-gcc/
-B/home/artem/testing/gcc46/x86_64-slackware-linux/bin/
-B/home/artem/testing/gcc46/x86_64-slackware-linux/bin/
-B/home/artem/testing/gcc46/x86_64-slackware-linux/lib/ -isystem
/home/artem/testing/gcc46/x86_64-slackware-linux/include -isystem
/home/artem/testing/gcc46/x86_64-slackware-linux/sys-include-c 
-DIN_GCC_FRONTEND -g -O2 -gtoggle -fprofile-generate -DIN_GCC   -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat  
-DHAVE_CONFIG_H -I. -I. -I../../gcc-current/gcc -I../../gcc-current/gcc/.
-I../../gcc-current/gcc/../include -I../../gcc-current/gcc/../libcpp/include 
-I../../gcc-current/gcc/../libdecnumber
-I../../gcc-current/gcc/../libdecnumber/bid -I../libdecnumber  
-I/usr/include/libelf  ../../gcc-current/gcc/c-parser.c -o c-parser.o
../../gcc-current/gcc/c-parser.c: In function 'c_parser_for_statement':
../../gcc-current/gcc/c-parser.c:4672:19: error: 'incr' may be used
uninitialized in this function [-Werror=uninitialized]
cc1: all warnings being treated as errors

  For amd64 I configured with these settings:

../gcc-current/configure --prefix=/home/artem/testing/gcc46 --enable-shared
--enable-bootstrap --enable-languages=c,c++ --enable-threads=posix
--enable-checking=release --with-system-zlib --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --with-lto --disable-nls
--verbose --with-arch=athlon64 --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux --disable-multilib
--enable-checking=release

  Doing normal (not profiled) build with these settings succeeds for me.

[Bug middle-end/45874] [4.6 Regression] ICE in verify_flow_info failed

[rmansfield at qnx dot com]

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

--- Comment #3 from Ryan Mansfield  2010-10-12 
12:30:41 UTC ---
I am out of the office until October 28th,2010. I will have periodic access to
email in the meantime. For urgent issues please contact Fred Plante

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 CC||jason at gcc dot gnu.org
  Component|lto |c++

--- Comment #1 from Richard Guenther  2010-10-12 
13:10:02 UTC ---
With the attached testcase I instead see

> ./cc1plus -quiet -std=c++0x /tmp/synth.ii -msse4 -flto
In file included from src/audio/synth.h:20:0,
 from src/audio/synth.cc:41:
src/audio/synth_filters.h: In member function 'void
synth::filter::freeverb_stereo_t::process(const chunk_array_stereo_t&,
synth::chunk_array_stereo_t&)':
src/audio/synth_filters.h:683:25: internal compiler error: canonical types
differ for identical types const chunk_array_stereo_t and const
synth::chunk_array_t<2ul>
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

you probably built GCC with release checking?

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-10-12 
13:22:33 UTC ---
Older GCC for some reason complain about

> g++-4.5 -S -std=c++0x synth.cpp -msse4
In file included from src/audio/synth_params.h:12:0,
 from src/audio/synth.h:18,
 from src/audio/synth.cc:41:
src/core/sys_log.h: In function ‘void sys::log(const char*, ...)’:
src/core/sys_log.h:95:40: error: invalid use of ‘__builtin_va_arg_pack ()’

reducing the canonical type error now.

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[tbptbp at gmail dot com]

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

--- Comment #3 from tbp  2010-10-12 13:27:24 UTC ---
(In reply to comment #2)
> Older GCC for some reason complain about
> src/core/sys_log.h:95:40: error: invalid use of ‘__builtin_va_arg_pack ()’
There's code to handle that, but that's not obvious in preprocessed form :)
Besides that, that thing compiles with g++ 4.4.4, 4.5 and used to with 4.6
until around, hmm, revision 165246.

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[tbptbp at gmail dot com]

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

--- Comment #4 from tbp  2010-10-12 13:31:07 UTC ---
(In reply to comment #1)
> you probably built GCC with release checking?
Oh. Worse,
$ /usr/local/gcc-4.6-20101012/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.6-20101012/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6-20101012/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc-4.6.0
--enable-languages=c,c++ --enable-threads=posix --disable-checking
--disable-nls --with-system-zlib --disable-bootstrap --enable-checking=none
--enable-mpfr --enable-gold --enable-lto --with-ppl --with-cloog
--with-arch=native
Thread model: posix
gcc version 4.6.0 20101012 (experimental) (GCC) 

I should have stipulated that somewhere in the initial report, my bad.

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=>expr)

[domob at gcc dot gnu.org]

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

--- Comment #17 from Daniel Kraft  2010-10-12 
13:30:57 UTC ---
Author: domob
Date: Tue Oct 12 13:30:53 2010
New Revision: 165378

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165378
Log:
2010-10-12  Daniel Kraft  

PR fortran/38936
* parse.c (parse_associate): Set typespec of associate-name if that of
the target is already available.

2010-10-12  Daniel Kraft  

PR fortran/38936
* gfortran.dg/associate_1.f03: More tests with derived-types.
* gfortran.dg/associate_9.f03: New test (XFAIL for now).
* gfortran.dg/associate_8.f03: Fix typo.
* gfortran.dg/initialization_27.f90: Fix typo.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/associate_1.f03
trunk/gcc/testsuite/gfortran.dg/associate_8.f03
trunk/gcc/testsuite/gfortran.dg/initialization_27.f90

[Bug fortran/38936] F2003: ASSOCIATE construct / improved SELECT TYPE (a=>expr)

[domob at gcc dot gnu.org]

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

--- Comment #18 from Daniel Kraft  2010-10-12 
13:37:44 UTC ---
This commit did implement better handling for association to derived-types, but
some cases are still not handled (see the XFAIL of associate_9.f03).  I wanted
to test with the code of PR 45369, but that also uses CLASS(*) so I was not
able to compile it still.

See http://gcc.gnu.org/ml/fortran/2010-10/msg00126.html for some discussion
about what's still missing for derived-types, and in addition there's still
proper handling of strings open (as in the commented-out section of
associate_1.f03).

[Bug c++/45984] New: [4.6 Regression] ICE: canonical types differ for identical types

[rguenth at gcc dot gnu.org]

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

   Summary: [4.6 Regression] ICE: canonical types differ for
identical types
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


> ./cc1plus -quiet -std=c++0x synth.3.ii 
synth.3.ii: In member function 'void freeverb_stereo_t::process(const
chunk_array_stereo_t&, chunk_array_stereo_t&)':
synth.3.ii:31:23: internal compiler error: canonical types differ for identical
types const chunk_array_stereo_t and const chunk_array_t<2ul>
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

typedef __SIZE_TYPE__ size_t;
enum { chunk_size = 16 };
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
struct __attribute__((aligned((16 float4_t {
typedef float scalar_t;
typedef __m128 type_t;
typedef float4_t return_type_t;
type_t m;
inline __attribute__((artificial, gnu_inline, always_inline)) explicit
float4_t(scalar_t a) : m(((__m128) (__v4sf) { (a), (a), (a), (a) })) { }
inline __attribute__((artificial, gnu_inline, always_inline, pure)) friend
return_type_t operator+(float4_t lhs, float4_t rhs) { }
};
template  class __attribute__((aligned((16 chunk_array_t {
public:
typedef float4_t value_type_t;
typedef value_type_t value_array_t[chunk_size/4];
enum { num_scalars = chunk_size,num_values = num_scalars/4  };
const value_array_t &chan(size_t c) const { }
value_type_t operator[](size_t i) const { }
};
typedef chunk_array_t<1> chunk_array_mono_t;
typedef chunk_array_t<2> chunk_array_stereo_t;
class freeverb_stereo_t {
void process(const chunk_array_stereo_t & __restrict__ src,
 chunk_array_stereo_t & __restrict__ dst) {
enum { chunk_size = chunk_array_t<1>::num_values };
chunk_array_mono_t mix;
for (size_t i=0; i

[Bug c++/45984] [4.6 Regression] ICE: canonical types differ for identical types

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-valid-code
  Known to work||4.5.1
   Target Milestone|--- |4.6.0

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2010-10-12 
13:49:09 UTC ---
canonical type error -> PR45984.

[Bug c/45985] New: [trans-mem] internal compiler error: verify_cgraph_node failed

[patrick.marlier at gmail dot com]

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

   Summary: [trans-mem] internal compiler error:
verify_cgraph_node failed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: r...@gcc.gnu.org, al...@gcc.gnu.org


Created attachment 22023
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22023
source file that shows up the bug.

Just a little email to report you a bug inside trans-mem branch.

The complete command line to compile is :
$ gcc -Wall -fgnu-tm callable.c echo.c -o callable -litm

But this is enough to trigger the bug :
$ gcc -Wall -fgnu-tm callable.c -o callable 
callable.c:18:1: error: caller edge frequency 0 does not match BB freqency 1000
__builtin__ITM_changeTransactionMode/5(-1) @0x7fda62f8baf8
availability:not_available
  called by: main/0 
  calls: 
callable.c:18:1: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Patrick Marlier.

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[tbptbp at gmail dot com]

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

--- Comment #6 from tbp  2010-10-12 13:56:50 UTC ---
(In reply to comment #5)
> canonical type error -> PR45984.
Ah. So, both the current error and your previous patch fixing it all were
nothing but side-effects.
Tuning into the other channel. And thanks.

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.12 14:24:28
 CC||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #7 from Richard Guenther  2010-10-12 
14:24:28 UTC ---
Reduced testcase for the LTO problem:

typedef long unsigned int size_t;
enum { chunk_size = 16,max_channels = 16  };
struct float4_t { };
template  class chunk_array_t {
typedef float4_t value_type_t;
typedef float scalar_type_t;
typedef value_type_t value_array_t[chunk_size/4];
typedef scalar_type_t scalar_array_t[chunk_size];
value_array_t m[NumChans];
const scalar_array_t &decay(size_t c) const;
};
template struct bitboard_t {
struct scanner_t {
scanner_t(const bitboard_t &b);
size_t index() const;
};
};
enum params_enum_t { PRM_VOL = 0,   PRM_PAN,   PRM_BND,   PRM_MOD  };
class midi_channels_params_t {
float vals[4][max_channels];
public:
template float get_value(size_t cha) const {
return vals[p][cha];
}
};
class synth_t {
typedef bitboard_t bb_channels_t;
struct states_t {
bb_channels_t mask_active_channels;
};
midi_channels_params_t &channel_params;
states_t &states;
void output_audio(void);
};
void synth_t::output_audio(void) {
const bb_channels_t m(states.mask_active_channels);
bb_channels_t::scanner_t cscan(m);
const size_t chan = cscan.index();
float chan_vol = channel_params.get_value(chan);
}

[Bug c++/45983] ICE: tree code 'template_parm_index' is not supported in gimple streams with -lto

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2010-10-12 
14:54:58 UTC ---
We have an array type with a TYPE_DOMAIN with TYPE_MAXVAL being
template_parm_index - 1.  The array is field 'm' in chunk_array_t
which is the DECL_CONTEXT of scalar_type_t which is referenced by
the statement

  D.1506_3 = this_1(D)->vals[0][cha_2(D)];

as the type of the reference.

I wonder why this uses chunk_array_t::scalar_type_t at all.  Hmm.

We build that array-ref in the frontend:

#1  0x006839ef in cp_build_array_ref (loc=2910, array=0x75b11480, 
idx=0x75b10198, complain=3)
at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:3039
3039  rval = build4 (ARRAY_REF, type, array, idx, NULL_TREE,
NULL_TREE);

and the array has element type scalar_type_t already.  It's array type
is already built with that element type by

0x007056f8 in build_cplus_array_type (elt_type=0x75b011f8, 
index_type=0x75aeebd0)
at /space/rguenther/src/svn/trunk/gcc/cp/tree.c:665
665 t = build_array_type (elt_type, index_type);
(gdb) up
#1  0x007064d7 in cp_build_qualified_type_real (type=0x75aeef18, 
type_quals=1, complain=7)
at /space/rguenther/src/svn/trunk/gcc/cp/tree.c:822
822   t = build_cplus_array_type (element_type, TYPE_DOMAIN
(type));
(gdb) up
#2  0x004fb789 in grokdeclarator (declarator=0x1aa2330, 
declspecs=0x7fffd5d0, decl_context=FIELD, initialized=0, 
attrlist=0x7fffd380)
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:8322
8322  type = cp_build_qualified_type_real

which is ultimately derived from

#1  0x004f9956 in create_array_type_for_decl (name=0x75afad68, 
type=0x75aee690, size=0x75ae28c0)
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:7640
7640  return build_cplus_array_type (type, itype);
(gdb) up
#2  0x004fc05c in grokdeclarator (declarator=0x1aa2130, 
declspecs=0x7fffd5d0, decl_context=FIELD, initialized=0, 
attrlist=0x7fffd380)
at /space/rguenther/src/svn/trunk/gcc/cp/decl.c:8525
8525  type = create_array_type_for_decl (dname, type,

which has type of scalar_type_t already.

So - I have no idea how scalar_type_t leaks there ...

Jason?

[Bug c/45977] "warning: 'i' initialized and declared 'extern'" is spurious

[konrad.schwarz at siemens dot com]

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

--- Comment #2 from Konrad Schwarz  
2010-10-12 15:27:15 UTC ---
(In reply to comment #1)
> This is a coding style warning - the code is valid, but extremely 
> unidiomatic for C since "extern" is generally expected to mean that the 
> declaration is not providing a definition of the object.  Following static 
> by extern, though valid, is also a C feature of doubtful value.

I see the value of following static by extern -- the bug report provides an
example.  To restate, using extern in a definition allows overriding an
object's or function's linkage, which can be useful in a translation unit
consisting of files a user can change and files a user cannot.

Whether or not this is idiomatic usage, or corresponds to what is generally
expected, is not sufficient grounds for a warning.

To the contrary, this warning promulgates incorrect assumptions about "extern". 

At the very least, there must be a way of turning this warning off.

[Bug rtl-optimization/45912] [4.6 regression] Patch for PR tree-optimization/44972 caused 2500+ FAILs on Solaris 2/SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #5 from Eric Botcazou  2010-10-12 
15:27:27 UTC ---
But there is a much bigger problem upstream.

[Bug c/45977] "warning: 'i' initialized and declared 'extern'" is spurious

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  2010-10-12 15:47:45 UTC ---
On Tue, 12 Oct 2010, konrad.schwarz at siemens dot com wrote:

> Whether or not this is idiomatic usage, or corresponds to what is generally
> expected, is not sufficient grounds for a warning.

That is the whole point of warnings: to diagnose dubious usages that 
cannot be given hard errors because they are formally valid according to 
the standard.

> At the very least, there must be a way of turning this warning off.

That is the only actual bug I see here: all warnings should have options 
controlling them.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  2010-10-12 
15:53:21 UTC ---
Author: rth
Date: Tue Oct 12 15:53:15 2010
New Revision: 165382

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165382
Log:
PR middle-end/45962
* cfgexpand.c (add_stack_var): Ensure every variable has 1 byte.
(expand_stack_vars): Assert large base allocated when used.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson  2010-10-12 
15:55:09 UTC ---
Bah.  Changelog conflict and I wasn't paying attention.  Done now.

[Bug objc/45878] [4.6 Regression] Can't compile even a trivial ObjC program with -fexceptions -O2

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #4 from Iain Sandoe  2010-10-12 16:03:19 
UTC ---
As I understand things, we need objc_msg_send to be able to masquerade as the
method function it proxies.  Thus it must be cast to the appropriate return
type.

If anyone believes that there's a work-around for this in the FE(s) then could
they post sth here -- otherwise I propose that we re-classify this as a ME bug.

At present, we're having to work on NeXT with r164908 backed out - or there's a
huge amount of ObjC* test-suite noise.

[Bug objc/45878] [4.6 Regression] Can't compile even a trivial ObjC program with -fexceptions -O2

[mrs at gcc dot gnu.org]

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

--- Comment #5 from mrs at gcc dot gnu.org  2010-10-12 
16:38:16 UTC ---
I think the patch that broke this should be backed out until the semantics are
sorted out.  I think the middle-end people should decide on which part of the
compiler is wrong, how to make the other-side conform and then change the
documentation to make it clear.  Once that is done, the side that is wrong
should be fixed, once that is done, the patch can then be reenabled.

So far, it sounds like a ME problem to me.

[Bug objc/45878] [4.6 Regression] Can't compile even a trivial ObjC program with -fexceptions -O2

[mrs at gcc dot gnu.org]

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

m...@gcc.gnu.org  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug bootstrap/45958] --with-build-config=bootstrap-lto doesn't work

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  2010-10-12 
16:40:49 UTC ---
Author: hjl
Date: Tue Oct 12 16:40:39 2010
New Revision: 165389

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165389
Log:
Support '-plugin' as the second option to the linker.

2010-10-12  H.J. Lu  

PR bootstrap/45958
* exec-tool.in: Support '-plugin' as the second option to the
linker.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/exec-tool.in

[Bug target/45986] New: gcc.dg/tls/pr45870.c FAILs on Solaris 10/SPARC and x86

[ro at gcc dot gnu.org]

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

   Summary: gcc.dg/tls/pr45870.c FAILs on Solaris 10/SPARC and x86
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
  Host: i386-pc-solaris2.10, sparc-sun-solaris2.10
Target: i386-pc-solaris2.10, sparc-sun-solaris2.10
 Build: i386-pc-solaris2.10, sparc-sun-solaris2.10


The new gcc.dg/tls/pr45870.c test fails on both Solaris 10/SPARC and x86:

* i386-pc-solaris2.10, both 32 and 64-bit:

FAIL: gcc.dg/tls/pr45870.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tls/pr45870.c:10:1: note:
non-delegitimized UNSPEC 5 found in variable location

* sparc-sun-solaris2.10, 32-bit only:

FAIL: gcc.dg/tls/pr45870.c (internal compiler error)
FAIL: gcc.dg/tls/pr45870.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tls/pr45870.c:21:1: internal
compiler error: output_operand: invalid expression as operand

[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap

[laurent at guerby dot net]

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

--- Comment #81 from Laurent GUERBY  2010-10-12 
17:43:19 UTC ---
Now testing r165387 + Paolo patch as this seems to be the last PR preventing
bootstrap on arm-linux.

[Bug target/45987] New: gcc.target/i386/push-1.c XPASSes on Solaris 10+/x86

[ro at gcc dot gnu.org]

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

   Summary: gcc.target/i386/push-1.c XPASSes on Solaris 10+/x86
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: i386-pc-solaris2.1[01]
Target: i386-pc-solaris2.1[01]
 Build: i386-pc-solaris2.1[01]


Sometime between 20100726 and 20100823, gcc.target/i386/push-1.c started to
XPASS
on Solaris 10 and 11/x86 (and, it seems, a couple of other targets):

XPASS: gcc.target/i386/push-1.c scan-assembler-not movups

Either the xfail needs to be removed or adapted.

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #10 from Steve Ellcey  2010-10-12 18:01:02 
UTC ---
These patches work for me on ia64 linux.  Can we get them checked in?

[Bug fortran/45988] New: gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86

[ro at gcc dot gnu.org]

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

   Summary: gfortran.dg/vect/fast-math-pr38968.f90 times out on
32-bit Solaris 10/x86
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
 Build: i386-pc-solaris2.10


The 32-bit gfortran.dg/vect/fast-math-pr38968.f90 execution test regularly
times
out on Solaris 10/x86:

WARNING: program timed out.
FAIL: gfortran.dg/vect/fast-math-pr38968.f90 execution test

at least when run with a make -j16 -k check on a Sun Fire X4450 (4 x Xeon
X7350,
2.93 GHz).

When run on an otherwise idle machine, it takes about 1:31 min, well below the
default dejagnu timeout of 5 minutes.  Perhaps the timeout factor 4.0 that was
present until 4.5 needs to be reinstantiated?

[Bug objc/45989] New: Some objc.dg-struct-layout-encoding-1 tests XPASS

[ro at gcc dot gnu.org]

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

   Summary: Some objc.dg-struct-layout-encoding-1 tests XPASS
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


Some of the objc.dg-struct-layout-encoding-1 test currently XPASS on several
platforms:

* i386-pc-solaris2.*, 32 and 64-bit:

XPASS: objc.dg-struct-layout-encoding-1/t026_main.m execution test

* sparc-sun-solaris2.*, 32 and 64-bit, alpha-dec-osf5.1b, mips-sgi-irix6.5:

XPASS: objc.dg-struct-layout-encoding-1/t025_main.m execution test
XPASS: objc.dg-struct-layout-encoding-1/t026_main.m execution test
XPASS: objc.dg-struct-layout-encoding-1/t027_main.m execution test
XPASS: objc.dg-struct-layout-encoding-1/t028_main.m execution test
XPASS: objc.dg-struct-layout-encoding-1/t029_main.m execution test
XPASS: objc.dg-struct-layout-encoding-1/t030_main.m execution test
XPASS: objc.dg-struct-layout-encoding-1/t031_main.m execution test

This just adds noise to the testsuite reports, so the xfails need to be
adjusted.

[Bug libstdc++/45990] New: 28_regex/07_traits/char/isctype.cc XPASSes on Solaris 2/IRIX 6

[ro at gcc dot gnu.org]

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

   Summary: 28_regex/07_traits/char/isctype.cc XPASSes on Solaris
2/IRIX 6
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: stephen.w...@cybersafe.com
  Host: i386-pc-solaris2.*, sparc-sun-solaris2.*,
mips-sgi-irix6.5
Target: i386-pc-solaris2.*, sparc-sun-solaris2.*,
mips-sgi-irix6.5
 Build: i386-pc-solaris2.*, sparc-sun-solaris2.*,
mips-sgi-irix6.5


The new 28_regex/07_traits/char/isctype.cc test XPASSes on at least Solaris
2/x86
and SPARC and IRIX 6.5 (as well as on cygwin, it seems from the mailing list
archives):

XPASS: 28_regex/07_traits/char/isctype.cc execution test

This is just unnecessary testsuite noise and should be avoided.

[Bug pch/45979] precompiled headers breakage on 2.6.36-rc Linux/ARM kernels

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2010-10-12 
19:05:53 UTC ---
(In reply to comment #2)
> I assume other Linux archs already randomize the heap. 
 Could it be because there's no TRY_EMPTY_VM_SPACE definition in
gcc/config/host-linux.c for ARM?

yes, a definition for TRY_EMPTY_VM_SPACE is needed for ARM.  I just went
through this for MIPS but I have not pushed it because I don't currently have a
correct copyright assignment on file.

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #11 from Richard Henderson  2010-10-12 
19:10:32 UTC ---
The (revised) cmpsf-1 patches appear to be identical.
Michael, please check in your two fixes.

[Bug tree-optimization/45991] New: [4.6 Regression] ICE: verify_stmts failed: Invalid address operand in in TARGET_MEM_REF. with -fstrict-overflow

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: verify_stmts failed: Invalid
address operand in in TARGET_MEM_REF. with
-fstrict-overflow
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22024
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22024
reduced testcase

Command line:
$ gcc -O -fstrict-overflow pr45991.c

Compiler output:
$ gcc -O -fstrict-overflow pr45991.c 
pr45991.c: In function 'foo':
pr45991.c:8:6: error: Invalid address operand in in TARGET_MEM_REF.
# VUSE <.MEM_25>
b_10 = MEM[symbol: A[20], index: ivtmp.9_20, offset: 0B];

pr45991.c:8:6: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165354 - crash
r163636 - OK
4.5 r163761 - OK

[Bug pch/45979] precompiled headers breakage on 2.6.36-rc Linux/ARM kernels

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson  2010-10-12 
19:26:17 UTC ---
Ok.  I'll cook something up for TRY_EMPTY_VM_SPACE on ARM.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #8 from Hans-Peter Nilsson  2010-10-12 
19:30:20 UTC ---
I have to reopen this: the SEGV ICE is gone, but no regressions were fixed;
it's all execution errors now, at r165383.  I'll see which of the test codes is
the best to show the miscompilation.

[Bug target/45987] gcc.target/i386/push-1.c XPASSes on Solaris 10+/x86

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #1 from Uros Bizjak  2010-10-12 19:32:09 
UTC ---
This test was introduced as part of the fix for PR37049. The fix was later
reverted, since it caused PR39445. However, as said in [1], we can't properly
calculate function argument boundary, so we can't use aligned loads.

So, it is not clear to me, what are we testing with the test... I propose to
remove the test entirely.

[1] http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00603.html

[Bug libstdc++/45990] 28_regex/07_traits/char/isctype.cc XPASSes on Solaris 2/IRIX 6

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2010-10-12 
19:53:18 UTC ---
Interesting ... lookup_classname isn't implemented and just returns 0

I'll look into it or ask Stephen to check

[Bug libstdc++/45990] 28_regex/07_traits/char/isctype.cc XPASSes on Solaris 2/IRIX 6

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.12 19:55:39
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely  2010-10-12 
19:55:39 UTC ---
think I see the problem

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[eager at eagercon dot com]

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

--- Comment #12 from Michael Eager  2010-10-12 
20:07:13 UTC ---
Patches checked in.

[Bug libstdc++/45990] 28_regex/07_traits/char/isctype.cc XPASSes on Solaris 2/IRIX 6

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2010-10-12 
20:12:54 UTC ---
This is DR 1337
http://open-std.org/JTC1/SC22/WG21/docs/lwg-active.html#1337

Rainer, could you test this 1337 hax0r patch?

Index: include/bits/regex.h
===
--- include/bits/regex.h(revision 165394)
+++ include/bits/regex.h(working copy)
@@ -287,7 +287,7 @@ namespace std
   const ctype<_Ch_type>& __ctype(use_facet<
 ctype<_Ch_type> >(_M_locale));

-  if (__ctype.is(__c, __f))
+  if (__ctype.is(__f, __c))
return true;

   // special case of underscore in [[:w:]]

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson  2010-10-12 
20:23:26 UTC ---
I think I'm going to use gcc.c-torture/execute/simd-5.c at -O0.
I'll compare r165239 to (r165240 plus your commit at r165382), ok?

Looking at r165240, I have a hunch that we're going to find a function call to
a libgcc function with the stack-pointer at an...awkward state.

cris.h:
#define BIGGEST_ALIGNMENT 8
#define STACK_BOUNDARY \
 (TARGET_STACK_ALIGN ? (TARGET_ALIGN_BY_32 ? 32 : 16) : 8)
(i.e. 8 for cris-elf default.)

[Bug other/45992] New: MULTIOSSUBDIR in Makefile for /libgcc missing quotes on 'test'

[phantall at gmail dot com]

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

   Summary: MULTIOSSUBDIR in Makefile for /libgcc missing
quotes on 'test'
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phant...@gmail.com


During a 'make clean' in this directory (eg, sparcv9-sun-solaris2.10/libgcc),
an error occurs:

/bin/bash: line 0: test: !=: unary operator expected

... where presumably the variable MULTIOSDIR is blank.  Adding double-quotes
around this variable in the script fixes it, eg:


MULTIOSSUBDIR := $(shell  if test $(MULTIOSDIR) != .; then echo /$(MULTIOSDIR);
fi)

... becomes:

MULTIOSSUBDIR := $(shell  if test "$(MULTIOSDIR)" != .; then echo
/$(MULTIOSDIR); fi)

-Brian

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson  2010-10-12 
21:31:00 UTC ---
(In reply to comment #8)
> I have to reopen this: the SEGV ICE is gone, but no regressions were fixed...

These aren't technically regressions; these tests were never run previously.
I'm certain you'll find that ...

(In reply to comment #9)
> I think I'm going to use gcc.c-torture/execute/simd-5.c at -O0.
> I'll compare r165239 to (r165240 plus your commit at r165382), ok?

... these tests fail with r165239 too, if you run them by hand.  If you
just compare gcc.sum files of course they'll appear as new failures.

> #define STACK_BOUNDARY \
>  (TARGET_STACK_ALIGN ? (TARGET_ALIGN_BY_32 ? 32 : 16) : 8)
> (i.e. 8 for cris-elf default.)

This is definitely wrong, according to the documentation in the opt file.

You'd either have to multilib on this option, or implement the full stack
re-alignment scheme supported by i386.  Unless you multilib:

STACK_BOUNDARY should be BITS_PER_UNIT always.

PREFERRED_STACK_BOUNDARY may vary depending on those options.

INCOMING_STACK_BOUNDARY ... I dunno, may need to be set to S_B;
the default is P_S_B, which seems wrong when P_S_B actually
varies.  Of course, i386 redefines this anyway, and no one else
currently varies.

MAX_STACK_ALIGNMENT should be MAX_OFILE_ALIGNMENT if you support
the full stack re-alignment scheme.

[Bug c++/45993] New: ICE in uses_template_parms, at cp/pt.c:7064

[gcc at abeckmann dot de]

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

   Summary: ICE in uses_template_parms, at cp/pt.c:7064
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@abeckmann.de


The following piece of invalid code results in an internal compiler error in
4.5.2 and 4.6 while 4.4.6 reports proper errors.

= 8< =
template < int >
struct S ;
template < int /* 'typename' fails, too */ >
S < [ ]
= >8 =

$ g++-4.5.x -std=c++0x -c ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii
ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii:4:7:
internal compiler error: in uses_template_parms, at cp/pt.c:7064

$ g++-trunk -std=c++0x -c ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii
ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii:4:7:
internal compiler error: in uses_template_parms, at cp/pt.c:7111

If I remove -std=c++0x, I get a warning first:
warning: lambda expressions only available with -std=c++0x or ...
internal compiler error: in uses_template_parms, at cp/pt.c:7064

$ g++-4.4.x -std=c++0x -c ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii
ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii:4:
error: an array reference cannot appear in a constant-expression
ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii:4:
error: template argument 1 is invalid
ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii:4:
error: expected unqualified-id at end of input

Verbose output from 4.5.2:

$ g++-4.5.x -v -std=c++0x -c ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii
Using built-in specs.
COLLECT_GCC=/opt/software/x86_64/gcc-4.5.x/bin/g++-4.5.x
COLLECT_LTO_WRAPPER=/opt/software/x86_64/gcc-4.5.x/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_5-branch/configure
--prefix=/opt/software/x86_64/gcc-4.5.x --program-suffix=-4.5.x
--enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.5.2 20101011 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'

/opt/software/x86_64/gcc-4.5.x/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/cc1plus
-fpreprocessed ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii -quiet -dumpbase
ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii -mtune=generic -march=x86-64
-auxbase ice-uses_template_parms-cp_pt-c-7064.hIM.min -std=c++0x -version -o
/tmp/cc0RnXAH.s
GNU C++ (GCC) version 4.5.2 20101011 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.2 20101011 (prerelease), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.5.2 20101011 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.2 20101011 (prerelease), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e08c6991e75f2f1fa9ef4bafb4a73eec
ice-uses_template_parms-cp_pt-c-7064.hIM.min.ii:4:7: internal compiler error:
in uses_template_parms, at cp/pt.c:7064
Please submit a full bug report,

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson  2010-10-12 
21:55:26 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > I have to reopen this: the SEGV ICE is gone, but no regressions were 
> > fixed...
> 
> These aren't technically regressions; these tests were never run previously.
> I'm certain you'll find that ...
> 
> (In reply to comment #9)
> > I think I'm going to use gcc.c-torture/execute/simd-5.c at -O0.
> > I'll compare r165239 to (r165240 plus your commit at r165382), ok?
> 
> ... these tests fail with r165239 too, if you run them by hand.  If you
> just compare gcc.sum files of course they'll appear as new failures.

Incorrect.  I don't see what makes you say that.

> > #define STACK_BOUNDARY \
> >  (TARGET_STACK_ALIGN ? (TARGET_ALIGN_BY_32 ? 32 : 16) : 8)
> > (i.e. 8 for cris-elf default.)
> 
> This is definitely wrong, according to the documentation in the opt file.

Uh... what?  Ok, it's been a while since I wrote that part (which you can see
by the comment at the top of that macro!) so I might have to revisit that but
any such observation is incidental, because...

> You'd either have to multilib on this option, or implement the full stack
> re-alignment scheme supported by i386.  Unless you multilib:
> 
> STACK_BOUNDARY should be BITS_PER_UNIT always.

...it is; constant 8, for the purpose of this PR, as none of the options are
active.

Let's see how we can best proceed here.

[Bug debug/45865] [4.6 regression] Failed to build 403.gcc in SPEC CPU 2006

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  2010-10-12 21:59:12 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00800.html

[Bug fortran/45636] Failed to fold simple Fortran string

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2010-10-12 
22:01:07 UTC ---
Author: jakub
Date: Tue Oct 12 22:01:04 2010
New Revision: 165401

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165401
Log:
PR fortran/45636
* tree-ssa-forwprop.c: Include expr.h.
(constant_pointer_difference, simplify_builtin_call): New functions.
(tree_ssa_forward_propagate_single_use_vars): Call
simplify_builtin_call on builtin calls.

* gcc.c-torture/execute/pr45636.c: New test.
* gfortran.dg/pr45636.f90: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr45636.c
trunk/gcc/testsuite/gfortran.dg/pr45636.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[rth at gcc dot gnu.org]

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

--- Comment #12 from Richard Henderson  2010-10-12 
22:05:48 UTC ---
(In reply to comment #11)
> > ... these tests fail with r165239 too, if you run them by hand.  If you
> > just compare gcc.sum files of course they'll appear as new failures.
> 
> Incorrect.  I don't see what makes you say that.

You don't agree they're new tests, or you don't agree that they
will fail when run by hand on the older compiler?

> > STACK_BOUNDARY should be BITS_PER_UNIT always.
> 
> ...it is; constant 8, for the purpose of this PR, as none of the options are
> active.

Fine.  But just so you know that you have a couple of options
that don't do what they say in the documentation, you can 
clean that up separately.

[Bug other/45994] New: During 'make clean', some variables not propagating properly

[phantall at gmail dot com]

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

   Summary: During 'make clean', some variables not propagating
properly
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phant...@gmail.com


During a make clean, when it attempts to execute 'make clean' for
/libgcc, the 'CC' variable is populated with 'CC_FOR_TARGET' which may
not be populated during a 'clean'.  This cascades into another problem on a few
different lines in /libgcc/Makefile.  For example, on (or about) /sparcv9-sun-solaris2.10/libgcc/Makefile:199, the following line is
present:


version := $(shell $(CC) -dumpversion)


$(CC) typically populates this line with something of the form:


/./gcc/xgcc -B -B (and so on)


... when this Makefile is used.  However, at the moment it's populating CC with
the empty string, which results in that 'version' line looking (in effect) like
this:


version := ($shell -B -B  -dumpversion)

... causing bash to exit with the error:

/bin/bash: -/: invalid option
(bash usage info below this line)

Temporary workaround is to enter the /libgcc directory and manually
'make clean', or during 

-Brian

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #13 from Hans-Peter Nilsson  2010-10-12 
22:15:46 UTC ---
(In reply to comment #12)
> You don't agree they're new tests, or you don't agree that they
> will fail when run by hand on the older compiler?

Both. They exist and run and PASS at r165239, like I wrote initially.
Why would they be new tests or fail before?  I don't see that.

FWIW, I'm studying the (differences in) simulator traces right now.
I may have to timeout for Z's...

[Bug tree-optimization/45972] [4.6 Regression] tree check fail in use_pred_not_overlap_with_undef_path_pred

[davidxl at gcc dot gnu.org]

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

davidxl  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from davidxl  2010-10-12 22:34:20 
UTC ---
in r165402.

[Bug middle-end/45962] [4.6 Regression]: many c/c++ failures on cris-elf, in r165236:165242

[hp at gcc dot gnu.org]

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

--- Comment #14 from Hans-Peter Nilsson  2010-10-12 
22:49:23 UTC ---
Created attachment 22025
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22025
tarball with asm files and somewhat readable simulator traces

Just dumping state.  Not expecting anyone to follow it at this time, but then
again it should be possible.

sok.txt: simulator trace using -O0 at r16539.
simd-5.s.ok: ditto generated assembly.
sbad.txt: simulator trace using -O0 at r165240+c165382.  (The assembly file
from gcc.c-torture/execute/simd-5.c was used together with the tree from r16539
to avoid mixing up e.g. miscompilations of libgcc.a or newlib.)
simd-5.s.bad: ditto generated assembly.

The cris-elf src/sim simulator says, for r165240+c165382, generating sbad.txt:
"core: 4 byte misaligned read to address 0x30002b at 0x486"
(where "misaligned" is a misnomer for "access to undefined memory")
On return to func2 register r7 is broken; it was saved on stack in func1, but
the location on stack has been clobbered.

I haven't yet figured out which function's stack-frame is borked / where
exactly the saved value of r7 is clobbered. Tomorrow.

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[howarth at nitro dot med.uc.edu]

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

--- Comment #13 from Jack Howarth  2010-10-12 
23:17:57 UTC ---
(In reply to comment #12)
> Patches checked in.

What revision number? I don't see any commits.

[Bug other/45992] MULTIOSSUBDIR in Makefile for /libgcc missing quotes on 'test'

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  2010-10-12 23:30:30 UTC ---
I don't think MULTIOSDIR should ever be empty, or contain any characters 
that need quoting, so the bug would be that it is empty rather than that 
any change is needed to the "test" command.

[Bug other/45995] New: Building gcc-4.5.1 on SUSE 10.2 failed when configured with --host=x86_64-suse-linux

[wung at synopsys dot com]

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

   Summary: Building gcc-4.5.1 on SUSE 10.2 failed when configured
with --host=x86_64-suse-linux
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w...@synopsys.com


We got the "x86_64-suse-linux-ar: Command not found" error when building
gcc-4.5.1 on SUSE 10.2 with the following configure options:

"--prefix=/remote/depotsrc/depotsrc/suse64-2.6/local_install/gcc-4.5.1
--enable-bootstrap --enable-threads=posix --enable-languages=c,c++,fortran
--enable-checking=release --enable-ssp --disable-libssp --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux"


The Makefile shows:

AS = x86_64-suse-linux-as
AR = x86_64-suse-linux-ar

-Seto

[Bug other/45996] New: -falign-functions=X does not work

[us15 at os dot inf.tu-dresden.de]

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

   Summary: -falign-functions=X does not work
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: u...@os.inf.tu-dresden.de


According to the gcc manpage, specifying -falign-functions=X should align
functions on an X-byte boundary. This works correctly with 4.1.2, 4.2.4, and
4.3.5. It does not work with 4.4.5, 4.5.1, 4.6.0 (svn) and will instead cause
function aligning to be completely disabled. This can be observed both in
generated code and in gcc --help=optimizers

[Bug bootstrap/45958] --with-build-config=bootstrap-lto doesn't work

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #5 from H.J. Lu  2010-10-13 01:01:47 
UTC ---
Fixed.

[Bug other/45995] Building gcc-4.5.1 on SUSE 10.2 failed when configured with --host=x86_64-suse-linux

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2010-10-13 
01:30:41 UTC ---
You should use --host=x86_64-suse-linux --target=x86_64-suse-linux
--build=x86_64-suse-linux so that is building a native (non cross) compiler.

[Bug testsuite/45856] gcc.c-torture/execute/cmpsf-1.c/cmpsi-2.c failed on x86-64

[eager at gcc dot gnu.org]

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

--- Comment #14 from eager at gcc dot gnu.org 2010-10-13 02:27:45 UTC ---
Author: eager
Date: Wed Oct 13 02:27:42 2010
New Revision: 165410

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165410
Log:
PR 45856

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/cmpsf-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/cmpsi-2.c

[Bug lto/45907] [4.6 Regression] Revision 164995 failed gcc.dg/torture/fp-int-convert-*.c

[hp at gcc dot gnu.org]

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

--- Comment #2 from Hans-Peter Nilsson  2010-10-13 
03:12:27 UTC ---
This was fixed by a commit in the range 165061:165143 (or, from looking at
gcc-testresults, 165092:165096), right?

[Bug tree-optimization/45991] [4.6 Regression] ICE: verify_stmts failed: Invalid address operand in in TARGET_MEM_REF. with -fstrict-overflow

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.13 04:29:26
 CC||spop at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-10-13 04:29:26 
UTC ---
It is caused by revision 164790:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg01089.html

[Bug debug/45997] New: __unknown__ type name for typedef'd int

[dje at google dot com]

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

   Summary: __unknown__ type name for typedef'd int
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@google.com


Earlier versions of gcc (e.g. 4.4.3) would emit a DW_TAG_base_type without a
name.  svn head emits one with name "__unknown__".


typedef int my_int;
typedef const my_int const_my_int;
typedef volatile const_my_int volatile_const_my_int;

my_int v_my_int (0);
const_my_int v_const_my_int (1);
volatile_const_my_int v_volatile_const_my_int (4);

int
main ()
{
  return 0;
}


g++ -g -S -dA foo.cc -o - | grep __unknown__
-->
.long   .LASF3  # DW_AT_name: "__unknown__"
.string "__unknown__"

[Bug middle-end/45874] [4.6 Regression] ICE in verify_flow_info failed

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from H.J. Lu  2010-10-13 05:03:24 
UTC ---
It is triggered by revision 164561:

http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00858.html