[Bug tree-optimization/51356] [4.7 Regression] FAIL: gfortran.dg/anyallcount_1.f90 -O3 (internal compiler error) on powerpc-apple-darwin9 with -m32

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  2011-12-01 08:31:57 
UTC ---
works for me on top of 181853 (powerpc-darwin9).

[Bug tree-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  
2011-12-01 08:51:07 UTC ---
On Sat, 12 Nov 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
> 
> Eric Botcazou  changed:
> 
>What|Removed |Added
> 
>  Status|ASSIGNED|NEW
>  CC||rguenth at gcc dot gnu.org
>   Component|rtl-optimization|tree-optimization
>  AssignedTo|ebotcazou at gcc dot|unassigned at gcc dot
>|gnu.org |gnu.org
> 
> --- Comment #15 from Eric Botcazou  2011-11-12 
> 16:45:13 UTC ---
> > I don't see why RTL invariant motion should move the one variant but not
> > the other.  Of course this also shows that we should, after loop unrolling
> > on the tree level, also perform loop invariant motion again ...
> 
> AFAICS we already do that (lim3 is run after cunroll).  The problem is that
> lim3 considers that the loads cannot be hoisted because they are "dependent". 
> And it looks like a ccp pass is missing after cunroll as there is a lot of
> cruft...

lim3 was added as a "hack", now yes, cunroll needs ccp after it (but it's
there in the form of DOM and VRP).  It's a pass ordering issue that we
cannot ever solve.

> Recategorizing, at least temporarily, for further investigation.  If nothing
> can be done at the Tree level, we could consider applying the RTL patch.

Please - it seems like a missed optimization there, too.

Richard.

[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244

[g...@denis-excoffier.org]

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

--- Comment #1 from Denis Excoffier  2011-12-01 
09:04:00 UTC ---
Configure line was:

/tmp/lcl/tmp/gcc/gcc-4.7-2019/configure
--prefix=/tmp/lcl/uxl/gcc-4.7-2026 --with-local-prefix=/usr/local/here
--enable-languages=c,c++ --disable-sjlj-exceptions

[Bug other/51375] New: different prefix for (s)libdir and bindir, gcc searches for as in wrong directories

[pjodrr at gmail dot com]

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

 Bug #: 51375
   Summary: different prefix for (s)libdir and bindir, gcc
searches for as in wrong directories
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pjo...@gmail.com


Hello,

I've setup the source directory to include symbolic links:

bfd -> ../../../binutils/S510-sparcv9/binutils-2.21.1/bfd/
binutils -> ../../../binutils/S510-sparcv9/binutils-2.21.1/binutils/
gas -> ../../../binutils/S510-sparcv9/binutils-2.21.1/gas/
gprof -> ../../../binutils/S510-sparcv9/binutils-2.21.1/gprof/
opcodes -> ../../../binutils/S510-sparcv9/binutils-2.21.1/opcodes/

please not especially that gas is included, so the bootstrap should
build and then also use it after installation.

when I run configure under Solaris 10 / Sparc with these options:

--prefix=%(prefix)s
-q --enable-languages=c,c++
--without-ppl
--without-cloog
--with-mpc=%(prefix)s
--with-mpfr=%(prefix)s
--with-gmp=%(prefix)s
--with-pkgversion="%(packager)s %(packager_version)s"
--with-bugurl=%(packager_bug_reports)s
--with-slibdir=/apps/prod/%(cc_prefix)s/lib
--libdir=/apps/prod/%(cc_prefix)s/lib
--bindir=%(prefix)s/bin
--libexecdir=%(prefix)s/libexec
--includedir=%(prefix)s/include
--datarootdir=%(prefix)s/share
--with-ld=/usr/ccs/bin/ld
--with-gnu-ld=no

I include all options for completeness, but it is important to
note that (s)libdir should be /apps/prod/gcc/4.6.2/lib while
all other directories should start with /apps/local/gcc/4.6.2.

%(prefix)s is /apps/local/gcc/4.6.2 and
%(cc_prefix)s is gcc/4.6.2

The bootstrap and installation works as expected,
but when I then call gcc to compile a simple program like this:

gcc -c -g -I/apps/local/gcc/4.6.2/include -I/apps/prod/gcc/4.6.2/include
conftest.c

I get errors:

/usr/ccs/bin/as: "/var/tmp//cc2wHEMg.s", line 10: error: quoted-string operand
required   
/usr/ccs/bin/as: "/var/tmp//cc2wHEMg.s", line 10: error: statement syntax  
/usr/ccs/bin/as: "/var/tmp//cc2wHEMg.s", line 11: error: unknown opcode ".loc" 
/usr/ccs/bin/as: "/var/tmp//cc2wHEMg.s", line 11: error: statement syntax 
...

please note that /usr/ccs/bin/as is reporting this error although gcc
should have used as from the gcc installation directory.
Indeed if I run the gcc command with truss I see where gcc is
searching for as:

922:   
stat64("/apps/local/gcc/4.6.2/libexec/gcc/sparc-sun-solaris2.10/4.6.2/as",
0xFFBFE238) Err#2 ENOENT
922:   
stat64("/apps/local/gcc/4.6.2/libexec/gcc/sparc-sun-solaris2.10/4.6.2/as",
0xFFBFE238) Err#2 ENOENT
922:stat64("/apps/local/gcc/4.6.2/libexec/gcc/sparc-sun-solaris2.10/as",
0xFFBFE238) Err#2 ENOENT
922:stat64("/apps/prod/gcc/4.6.2/lib/gcc/sparc-sun-solaris2.10/4.6.2/as",
0xFFBFE238) Err#2 ENOENT
922:stat64("/apps/prod/gcc/4.6.2/lib/gcc/sparc-sun-solaris2.10/as",
0xFFBFE238) Err#2 ENOENT
922:   
stat64("/apps/prod/gcc/4.6.2/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../../../../../sparc-sun-solaris2.10/bin/sparc-sun-solaris2.10/4.6.2/as",
0xFFBFE238) Err#2 ENOENT
922:   
stat64("/apps/prod/gcc/4.6.2/lib/gcc/sparc-sun-solaris2.10/4.6.2/../../../../../../../../sparc-sun-solaris2.10/bin/as",
0xFFBFE238) Err#2 ENOENT
922:stat64("/usr/ccs/bin/sparc-sun-solaris2.10/4.6.2/as", 0xFFBFE238) Err#2
ENOENT
922:stat64("/usr/ccs/bin/as", 0xFFBFE238)   = 0

but it does not look where it is actually installed, namely:

/apps/local/gcc/4.6.2/sparc-sun-solaris2.10/bin/as

this looks like a bug to me, or am I doing something wrong?
What can I do to make this work?

thanks,

  Peter

[Bug c++/51373] [C++0x] ICE for static pointer to member initialized in-class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-01
Summary|ICE for static pointer to   |[C++0x] ICE for static
   |member initialized in-class |pointer to member
   ||initialized in-class
 Ever Confirmed|0   |1

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  
2011-12-01 09:22:19 UTC ---
On Thu, 17 Nov 2011, krebbel at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
> 
> --- Comment #14 from Andreas Krebbel  2011-11-17 
> 15:23:26 UTC ---
> As the tests from Ian Sandoe and Dominique d'Humieres show, the Darwin/AIX
> regressions disappear when limiting the extract_bit_field invocation to
> fieldmode == BLKmode (as it was in the "Experimental fix" attached to the
> bugzilla).
> 
> But I'm not sure this is the right fix. In general also the other modes need
> correct handling here. If the correct extraction of the source operand really
> depends on things like function arg padding the handling in store_bit_field is
> doomed to be incomplete.
> 
> Richard, could you please have a look!

Well, store_bit_field is supposed to do generic memory fiddling,
dependency on function arg padding is unwanted - and thus such
dependency has to be reflected by argument adjustments in the
caller.

[I can smell some weirdness we might have here though,
but surely latent - if you have such argument (small C testcase
I can look at with a cross?), take its address and perform
aggregate assignment through a pointer - does that still
work?  Thus, does the memory layout of s and q in

foo (struct S s)
{
  struct S q;
}

really differ?

[Bug libgomp/51376] libgomp taskwait failure

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Target||powerpc-linux
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-12-01
 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Alan Modra  2011-12-01 09:23:38 
UTC ---
Investigating possible fix

[Bug libgomp/51376] New: libgomp taskwait failure

[amodra at gmail dot com]

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

 Bug #: 51376
   Summary: libgomp taskwait failure
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com


libgomp.c++/task-6 occasionally aborts on power7 with symptoms that indicate
"#pragma omp taskwait" is failing to wait for a child thread.  On replacing the
abort() with an asm illegal insn to get a core with the register state at the
failure point, you see "a" or "n" has been loaded to regs with their original
value.  By the time the core dump is written, the memory value for "a" and "n"
is correct.

[Bug tree-optimization/51315] gcc 4.6.2 miscompilation with -ftree-sra (included in -O2) on Debian/sparc

[jurij at wooyd dot org]

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

--- Comment #4 from Jurij Smakov  2011-12-01 09:26:54 
UTC ---
So, how do we convince someone to fix it? As Mikael points out, the same or
very similar problem has already been reported multiple times, and it appears
that other PRs have the offending commits identified.

This does cause problems for Debian, as we are adopting gcc-4.6 for the next
release, and if this bug remains unfixed, we will have to do something ugly,
like use -fno-tree-sra by default at least on sparc.

[Bug ada/50294] ICE in output_constructor_regular_field

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  
2011-12-01 09:34:31 UTC ---
On Sat, 19 Nov 2011, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50294
> 
> --- Comment #9 from Eric Botcazou  2011-11-19 
> 21:35:48 UTC ---
> > Thus the question - what should stor-layout do with domain types
> > that wrap the wrong way around (i.e. are of wrong type because Ada
> > turns everything into sizetype instead of [s]sizetype dependent on
> > the Ada type "signedness")?
> 
> What do you mean by "Ada turns everything into sizetype" here?  AFAIK the Ada
> compiler behaves like the other compilers, i.e. domain types are built with
> 
> /* Create a type of integers to be the TYPE_DOMAIN of an ARRAY_TYPE.
>MAXVAL should be the maximum value in the domain
>(one less than the length of the array).
> 
>The maximum value that MAXVAL can have is INT_MAX for a HOST_WIDE_INT.
>We don't enforce this limit, that is up to caller (e.g. language front 
> end).
>The limit exists because the result is a signed type and we don't handle
>sizes that use more than one HOST_WIDE_INT.  */
> 
> tree
> build_index_type (tree maxval)
> {
>   return build_range_type (sizetype, size_zero_node, maxval);
> }
> 
> so are all subtypes of sizetype (gigi has create_index_type instead because it
> needs to have non-shared range types and lower bounds, but it's equivalent).

Sure, but only Ada allows user specified index types (AFAIK).  At least
for the C family domains are always unsigned and fit in sizetype.  The
middle-end / stor-layout code should get a "proper" domain type from the
frontends - either they canonicalize it to one that fits sizetype or
they provide a different typed domain (not sure which one is best,
but both are probably managable).

Richard.

[Bug c++/51367] [4.7 Regression] Broken diagnostic: 'pointer_type' not supported by dump_expr

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2011-12-01 09:34:47 UTC ---
Author: paolo
Date: Thu Dec  1 09:34:43 2011
New Revision: 181876

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181876
Log:
/cp
2011-12-01  Paolo Carlini  

PR c++/51367
* pt.c (unify_inconsistency): Use either %qT or %qE depending on
whether parm is a type or non-type parameter.

/cp
2011-12-01  Paolo Carlini  

PR c++/51367
* g++.dg/template/error47.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/error47.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51367] [4.7 Regression] Broken diagnostic: 'pointer_type' not supported by dump_expr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2011-12-01 
09:35:46 UTC ---
Fixed.

[Bug bootstrap/51201] [4.7 regression] build error without Ada compiler installed

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-12-01 
09:37:03 UTC ---
Author: jakub
Date: Thu Dec  1 09:36:59 2011
New Revision: 181877

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181877
Log:
PR bootstrap/51201
* gcc-interface/Make-lang.in: Initialize RTS_DIR with = instead of :=.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Make-lang.in

[Bug bootstrap/51201] [4.7 regression] build error without Ada compiler installed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-12-01 
09:38:52 UTC ---
Fixed.

[Bug tree-optimization/50452] [4.7 Regression] Internal compiler error: verify_flow_info failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #6 from Jakub Jelinek  2011-12-01 
09:39:57 UTC ---
Indeed, http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179967

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

[Bug tree-optimization/50723] [4.6/4.7 regression] internal compiler error: verify_ssa failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||d.g.gorbachev at gmail dot
   ||com

--- Comment #7 from Jakub Jelinek  2011-12-01 
09:39:57 UTC ---
*** Bug 50452 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.7.0
   Keywords||wrong-code
   Last reconfirmed||2011-12-01
  Component|c   |rtl-optimization
 CC||gjl at gcc dot gnu.org
   Host|i386-redhat-linux   |
 Ever Confirmed|0   |1
Summary|Volatile access reordered.  |[avr] insn combine reorders
   ||volatile memory accesses
   Target Milestone|--- |4.6.3
  Known to fail||4.6.2

--- Comment #1 from Georg-Johann Lay  2011-12-01 
09:57:16 UTC ---
Please, supply informations that are needed to reproduce bugs like explained in
http://gcc.gnu.org/bugs.html/#need when you report bugs like compiler switches
applied. Thanks.

To reprodoce, optimization must be turned on:

$ avr-gcc-4.6.2 test.c -Os -dp -S

__vector_18:
in r24,44-0x20 ;  8*movqi/4[length = 1]
sbis 43-0x20,4 ;  12*sbix_branch[length = 2]
rjmp .L1
lds r24,slot.1198 ;  14*movhi/2[length = 4]
lds r25,slot.1198+1
ldi r18,hi8(-2) ;  15*cmphi/5[length = 3]
cpi r24,lo8(-2)
cpc r25,r18
brne .L1 ;  16branch[length = 1]
ldi r24,lo8(-1) ;  18*movhi/4[length = 2]
ldi r25,hi8(-1)
sts slot.1198+1,r25 ;  19*movhi/3[length = 4]
sts slot.1198,r24
.L1:
ret ;  29return[length = 1]


avr-gcc-4.7.0 (trunk 181838) compiles correct with -O1/2/s/3, here with -Os:

__vector_18:
in r24,0xb ;  6movqi_insn/4[length = 1]
in r25,0xc ;  8movqi_insn/4[length = 1]
sbrs r24,4 ;  11*sbrx_branchqi[length = 2]
rjmp .L1
lds r24,slot.1321 ;  13*movhi/3[length = 4]
lds r25,slot.1321+1
adiw r24,2 ;  14*cmphi/7[length = 1]
brne .L1 ;  15branch[length = 1]
ldi r24,lo8(-1) ;  17*movhi/5[length = 2]
ldi r25,lo8(-1)
sts slot.1321+1,r25 ;  18*movhi/4[length = 4]
sts slot.1321,r24
.L1:
ret ;  35return[length = 1]

[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

  Attachment #25964|0   |1
is obsolete||

--- Comment #2 from Georg-Johann Lay  2011-12-01 
09:59:24 UTC ---
Created attachment 25965
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25965
pr51374.c

Use MIME text/plain

[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2011-12-01 
10:08:05 UTC ---
ALso notice, that with the following test case that reads status *after* data

typedef unsigned char uint8_t;

void __vector_18(void)
{
unsigned char data = (*(volatile uint8_t *)((0x0C) + 0x20));
unsigned char status = (*(volatile uint8_t *)((0x0B) + 0x20));
static int slot;

if (status & 0x10)
{
if (slot == (-2))
{
slot ++;
}
}
}


then *no* SBIS/SBIC instruction is produced:

__vector_18:
in r24,0xc ;  6movqi_insn/4[length = 1]
in r24,0xb ;  8movqi_insn/4[length = 1]
sbrs r24,4 ;  11*sbrx_branchqi[length = 2]
rjmp .L1
...

and combine says:

Trying 9, 10 -> 11:
Successfully matched this instruction:
(set (pc)
(if_then_else (eq (zero_extract:QI (reg/v:QI 44 [ status ])
(const_int 1 [0x1])
(const_int 4 [0x4]))
(const_int 0 [0]))
(label_ref:HI 21)
(pc)))
deferring deletion of insn with uid = 10.
deferring deletion of insn with uid = 9.
modifying insn i311 pc={(zero_extract(r44:QI,0x1,0x4)==0)?L21:pc}
  REG_DEAD: r44:QI
  REG_BR_PROB: 0xf3c
deferring rescan insn with uid = 11.

Trying 8 -> 11:
Failed to match this instruction:
(set (pc)
(if_then_else (eq (zero_extract:QI (mem/v:QI (const_int 43 [0x2b]) [0
MEM[(volatile uint8_t *)43B]+0 S1 A8])
(const_int 1 [0x1])
(const_int 4 [0x4]))
(const_int 0 [0]))
(label_ref:HI 21)
(pc)))

[Bug c++/51326] [4.7 Regression] ICE with invalid override

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #2 from Paolo Carlini  2011-12-01 
10:07:48 UTC ---
On it.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe  2011-12-01 10:10:10 
UTC ---
there is nothing in the ABI doc:

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/100-32-bit_PowerPC_Function_Calling_Conventions/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438-SW20

that would suggest a different layout of bitfields in the two cases you cite.  

For varargs and K&R style function calls - it can be that double/vect values
end up with a 4 byte alignment on the stack, when they are also passed in regs.
(see PR 34311) - but I doubt that is relevant to this case.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe  2011-12-01 10:25:33 
UTC ---
well.. sorry, that might be a bogus comment 
- it depends on whether the following can be interpreted to allow a different
layout on the stack from 'normal' memory.

Since the embedding alignment of bitfields doesn't seem to be specifically
referenced in the struct. layout section (pp10 in the pdf) - other than saying
that it's 'natural' if the first element and 4 bytes otherwise.

but page14 in the pdf of the ABI doc has:

1. All nonvector parameters are aligned on 4-byte boundaries. 
2. Vector parameters are aligned on 16-byte boundaries. 
3. Noncomposite parameters (that is, parameters that are not arrays or data
structures) smaller than 4 bytes 
occupy the high-order bytes of their 4-byte area. 
4. Composite parameters (arrays, structures, and unions) 1 or 2 bytes in size
occupy the low-order bytes 
of their 4-byte area. They are preceded by padding to 4 bytes. 
This rule is inconsistent with other 32-bit PowerPC binary inter faces. In AIX
and Mac OS 9 (and earlier), 
padding bytes always follow the data structure even in the case of composite
parameters smaller than 
4 bytes. 
5. Composite parameters 3 bytes or larger in size occupy the high-order bytes
of their 4-byte area. They 
are followed by padding to make a multiple of 4 bytes, with the padding bytes
being undefined. 

again no specific mention of bitfields ...

[Bug middle-end/49945] [4.7 Regression] gcc.dg/guality/vla-1.c FAILs with -flto

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  
2011-12-01 10:32:45 UTC ---
On Fri, 25 Nov 2011, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49945
> 
> --- Comment #3 from Jakub Jelinek  2011-11-25 
> 09:59:31 UTC ---
> This is a bug in lto-streamer-out.c.  TYPE_MAXVAL of the ARRAY_TYPE's
> TYPE_DOMAIN e.g. in f1 is a VAR_DECL (DECL_NAME is NULL, DECL_ARTIFICIAL, but
> !DECL_IGNORED_P).  It is first encountered in a GIMPLE_DEBUG's first operand,
> it hasn't been seen yet, so that VAR_DECL is output.  But, later on
> write_global_stream calls lto_output_tree on the VLA ARRAY_TYPE, with ref_p 
> set
> to false, and this eventually calls lto_output_tree on that VAR_DECL again.
> But this doesn't find it in ob->writer_cache, because the cache has been
> destroyed in between, from output_function -> destroy_output_block ->
> lto_streamer_cache_delete.
> I guess VLA types need to be emitted immediately in the containing function,
> rather than being deferred to be written much later on globally.

Yes, I remember running into this issue as well.  And I have some
patches somewhere that try to do this (but more generally, for all
function-local types IIRC).

[Bug debug/51377] New: ICE when generating debug info for targets with multiple pointer sizes

[nickc at redhat dot com]

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

 Bug #: 51377
   Summary: ICE when generating debug info for targets with
multiple pointer sizes
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ni...@redhat.com


Created attachment 25966
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25966
Source for test case

This is a follow up to a problem first reported here:

http://gcc.gnu.org/ml/gcc/2011-11/msg00397.html

[Bug fortran/51378] New: [OOP] Structure constructor wrongly rejects parent components if only child has PRIVATE comps

[burnus at gcc dot gnu.org]

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

 Bug #: 51378
   Summary: [OOP] Structure constructor wrongly rejects parent
components if only child has PRIVATE comps
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Found in Reinhold Bader's testsuite (partial_construct_01_pos.f90). The
following program is rejected by crayftn and gfortran with:

  Derived type "L_VEC" has private components, therefore a structure
constructor must not be defined for this type.

and with 

  o_l_vec = l_vec(comp=(/1.0, 2.0, 3.0/),len=3)
1
  Error: Component 'comp' at (1) is a PRIVATE component of 'l_vec'

The program is accepted by ifort 12. The question is whether "COMP" and "LEN"
are private or not. If they are not and only "label" is private, the program is
valid as the following is not violated (quote from F2008):

"C495 (R455) The type name and all components of the type for which a
component-spec appears shall be accessible in the scoping unit containing the
structure constructor."

And the following guarantees that they remain accessible even if the extension
uses a "PRIVATE" statement:

"4.5.7.2 Inheritance
An extended type includes all of the type parameters, all of the components,
and the nonoverridden (4.5.7.3) type-bound procedures of its parent type. These
are inherited by the extended type from the parent type. They retain all of the
attributes that they had in the parent type."


module type_ext
  type :: vec
 real, dimension(3) :: comp
 integer :: len
  end type vec
  type, extends(vec) :: l_vec
 private
 character(len=20) :: label = '01234567890123456789'
  end type l_vec
end module type_ext
program test_ext
  use type_ext
  implicit none
  type(vec) :: o_vec, oo_vec
  type(l_vec) :: o_l_vec
  integer :: i
!
  o_vec = vec((/1.0, 2.0, 3.0/),3)
!  write(*,*) o_vec%comp, o_vec%len
  o_l_vec = l_vec(comp=(/1.0, 2.0, 3.0/),len=3)
! partial constr. not accepted by ifort 11.1, fixed in 12.0 (issue 562240)
!  write(*,*) o_l_vec%comp, o_l_vec%len
!  write(*,*) o_l_vec%vec
  oo_vec = o_l_vec%vec
  do i=1, 3
if (abs(oo_vec%comp(i) - o_vec%comp(i)) > 1.0E-5) then
   write(*, *) 'FAIL'
   stop
end if
  end do
  write(*, *) 'OK'
end program

[Bug debug/51377] ICE when generating debug info for targets with multiple pointer sizes

[nickc at redhat dot com]

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

--- Comment #1 from Nick Clifton  2011-12-01 10:44:57 
UTC ---
Created attachment 25967
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25967
Test for mixed pointer modes in the assertion.

[Bug debug/51377] ICE when generating debug info for targets with multiple pointer sizes

[nickc at redhat dot com]

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

--- Comment #2 from Nick Clifton  2011-12-01 10:54:35 
UTC ---
[Darn - hit return too early].

When compiling for a target that supports multiple pointer sizes (eg s390)
generating debug information can trigger an ICE in the compiler:

  % s390-gcc -c -g -O2 -m64 fred.i
  fred.i: In function 'bar':
  fred.i:37:1: internal compiler error: in expand_debug_locations, at
cfgexpand.c:3687

The insn looks like this:

  (debug_insn 6 5 7 2 (var_location:SI temp$union_field$ptr_field (scratch))
fred.i:31 -1 (nil))

but the debug expression associated with it looks like this:

  (debug_expr:DI D#1)

The problem, I believe, is in the assertion at line 3687, not the debug
expression itself.  The expression has been created by converting the gimple
for the right hand side of the assignment on line 31 of fred.i:

   & arg_1(D)->bytes

into tree form.  This conversion chooses DImode since that is the default
pointer mode on this particular target.  The fact that this expression is then
cast to an SImode pointer is irrelevant - the expression itself is a DImode
pointer expression.

I have uploaded a proposed patch for this problem, based on an original patch
created by DJ, but tweaked a little bit by me.  It extends the assetion in
expand_debug_locations() to allow for the fact that pointer expressions might
use multiple modes.

Cheers
  Nick

[Bug debug/51358] missing location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-12-01 
11:07:44 UTC ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801#c2

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

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

--- Comment #25 from Iain Sandoe  2011-12-01 11:08:28 
UTC ---
the following tried using the vendor's gcc-4.2:

typedef struct
{
  unsigned short flda:9;
  float b;
  unsigned int fldc:17;
  float d;
  unsigned long long flde:33;
  float f;
} Struct;

extern float __attribute__((noinline)) foo (Struct s);

int main ()
{
  Struct q = {0x1fd, 1.0F, 0x1fffd, 2.0F, 0x1fffdLL, 3.0F};

  /* Is layed out thus xx = space directives:
 0xfe 0x80 xx xx
 0x3F80
 0xff fe 80 xx
 0x4000
 ff ff ff fe 80 xx xx xx
 0x4040

 i.e. all ms aligned...
 */

  /* It is passed in r3..r9 in 32 bit chunks with the same organization as
memory
 - no shuffling at that stage.  */
  return (int) foo (q);
}

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rguenther at suse dot de]

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

--- Comment #26 from rguenther at suse dot de  
2011-12-01 11:23:41 UTC ---
On Thu, 1 Dec 2011, iains at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
> 
> --- Comment #23 from Iain Sandoe  2011-12-01 
> 10:10:10 UTC ---
> there is nothing in the ABI doc:
> 
> http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/100-32-bit_PowerPC_Function_Calling_Conventions/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438-SW20
> 
> that would suggest a different layout of bitfields in the two cases you cite. 
>  
> 
> For varargs and K&R style function calls - it can be that double/vect values
> end up with a 4 byte alignment on the stack, when they are also passed in 
> regs.
> (see PR 34311) - but I doubt that is relevant to this case.

store_bit_field/extract_bit_field are not about bitfields in the C
sense (despite their names).  They are for setting/extracting a
subset of bits.  Any structure layout issue wrt bitfields has to be
taken into account by the caller (so have any function-argument
layout specialities).

Richard.

[Bug middle-end/37165] [4.4/4.5/4.6/4.7 Regression] FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times matrix-reorg "Flattened 3 dimensions" 1

[eric.weddington at atmel dot com]

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

Eric Weddington  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME
   Target Milestone|4.4.7   |4.7.0

--- Comment #10 from Eric Weddington  
2011-12-01 12:30:17 UTC ---
Failure is no longer showing up in 4.7 trunk.
http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00955.html

Closing bug.

[Bug target/51050] [AVR, attiny26] ICE: invalid rtl sharing found in the insn

[eric.weddington at atmel dot com]

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

--- Comment #2 from Eric Weddington  
2011-12-01 12:36:23 UTC ---
Johann,

Is this a duplicate of your bug #51345?

[Bug target/50733] avr-gcc 4.3.5 generates incorrect code when using PROGMEM macro

[eric.weddington at atmel dot com]

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

Eric Weddington  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||eric.weddington at atmel
   ||dot com
 Resolution||WONTFIX

--- Comment #3 from Eric Weddington  
2011-12-01 12:43:35 UTC ---
This issue should go away when address spaces are done for the avr target (in
future 4.7). The PROGMEM macro equates to a GCC attribute for that variable to
place that into the Flash (Program Memory). It is up to the user to know this
and to use the related macros in avr-libc to correctly retrieve the data from
Flash. The AVR is a Harvard architecture chip and until Address Spaces were
added to GCC it didn't have a good way of knowing these address spaces and able
to generate a warning.

I'm marking this bug as WONTFIX, but I suggest that the bug reporter add their
email address to the CC field of bug #49868 (address spaces on the avr).

[Bug target/51050] [AVR, attiny26] ICE: invalid rtl sharing found in the insn

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2011-12-01 
12:46:42 UTC ---
(In reply to comment #2)
> Johann,
> 
> Is this a duplicate of your bug #51345?

No, PR51345 is different and independent, that PR is related to PR51002.

At the moment I cannot get the compiler to work because it fails to configure
with --enable-lto and to call the linker with any -flto test case fails.

So I am stuck at the moment an cannot proceed fixing things or test them.

[Bug target/49857] Put constant switch-tables into flash

[eric.weddington at atmel dot com]

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

Eric Weddington  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2011-07-27 00:00:00 |2011-12-01
 Ever Confirmed|0   |1

[Bug rtl-optimization/48715] CASE_VALUES_THRESHOLD should be settable with --param

[eric.weddington at atmel dot com]

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

Eric Weddington  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #1 from Eric Weddington  
2011-12-01 12:53:46 UTC ---
Hi Mike,

Were you planning on getting this patch in for 4.7?

[Bug c++/51379] New: reinterpret_cast is not particularly useful

[piotr.wyderski at gmail dot com]

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

 Bug #: 51379
   Summary: reinterpret_cast is not particularly useful
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com


The following code:

int main() {

unsigned long t1 = 0;
unsigned long t2 = 1;
t1 = reinterpret_cast(t2);
return 0;
}

compiled using GCC 4.6.2 on Linux/x64:

g++ test.cpp

fails displaying:

test.cpp:5:44: error: invalid cast from type 'long unsigned int' to type 'long
unsigned int'

IMHO this is a rather urgent issue.

[Bug c++/51379] reinterpret_cast is not particularly useful

[piotr.wyderski at gmail dot com]

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

--- Comment #1 from Piotr Wyderski  2011-12-01 
12:58:16 UTC ---
Both static_cast and C-type cast work as expected.

[Bug c++/51379] reinterpret_cast is not particularly useful

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Jonathan Wakely  2011-12-01 
13:20:16 UTC ---
This is required by the standard.

[expr.reinterpret.cast] explicitly lists all the conversion allowed by
reinterpret_cast

You'll get the same result from http://llvm.org/demo/ and
http://www.comeaucomputing.com/tryitout/

If GCC, EDG and Clang all reject your code then your code is probably wrong.

[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses

[andyw at pobox dot com]

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

--- Comment #4 from andyw at pobox dot com 2011-12-01 13:22:44 UTC ---
Compiler command line & -v output showing configure options (thought I had
pasted this in the initial report - apparently not.) Do not know what happened
to the attachment, the box said text/plain...

$ avr-gcc -mmcu=atmega128 -Wall -O2 -g -c -save-temps -v test.c
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/avr/4.6.2/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --enable-languages=c,c++
--disable-nls --disable-libssp --with-dwarf2 : (reconfigured) ../configure
--target=avr --enable-languages=c,c++ --disable-nls --disable-libssp
--with-dwarf2 --with-gmp=/usr/local --with-mpc=/usr/local
--with-mpfr=/usr/local
Thread model: single
gcc version 4.6.2 (GCC) 
COLLECT_GCC_OPTIONS='-mmcu=atmega128' '-Wall' '-O2' '-g' '-c' '-save-temps'
'-v'
 /usr/local/libexec/gcc/avr/4.6.2/cc1 -E -quiet -v -imultilib avr51 test.c
-mmcu=atmega128 -Wall -g -fworking-directory -O2 -fpch-preprocess -o test.i
ignoring nonexistent directory
"/usr/local/lib/gcc/avr/4.6.2/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/avr/4.6.2/include
 /usr/local/lib/gcc/avr/4.6.2/include-fixed
 /usr/local/lib/gcc/avr/4.6.2/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-mmcu=atmega128' '-Wall' '-O2' '-g' '-c' '-save-temps'
'-v'
 /usr/local/libexec/gcc/avr/4.6.2/cc1 -fpreprocessed test.i -quiet -dumpbase
test.c -mmcu=atmega128 -auxbase test -g -O2 -Wall -version -o test.s
GNU C (GCC) version 4.6.2 (avr)
compiled by GNU C version 4.1.2 20070925 (Red Hat 4.1.2-33), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.2 (avr)
compiled by GNU C version 4.1.2 20070925 (Red Hat 4.1.2-33), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8445704570d64b6b795b8847e7060bc6
test.c: In function '__vector_18':
test.c:10:16: warning: unused variable 'data' [-Wunused-variable]
COLLECT_GCC_OPTIONS='-mmcu=atmega128' '-Wall' '-O2' '-g' '-c' '-save-temps'
'-v'
 /usr/local/lib/gcc/avr/4.6.2/../../../../avr/bin/as -mmcu=atmega128 -o test.o
test.s
COMPILER_PATH=/usr/local/libexec/gcc/avr/4.6.2/:/usr/local/libexec/gcc/avr/4.6.2/:/usr/local/libexec/gcc/avr/:/usr/local/lib/gcc/avr/4.6.2/:/usr/local/lib/gcc/avr/:/usr/local/lib/gcc/avr/4.6.2/../../../../avr/bin/
LIBRARY_PATH=/usr/local/lib/gcc/avr/4.6.2/avr51/:/usr/local/lib/gcc/avr/4.6.2/../../../../avr/lib/avr51/:/usr/local/lib/gcc/avr/4.6.2/:/usr/local/lib/gcc/avr/4.6.2/../../../../avr/lib/
COLLECT_GCC_OPTIONS='-mmcu=atmega128' '-Wall' '-O2' '-g' '-c' '-save-temps'
'-v'
$

[Bug c++/51379] reinterpret_cast is not particularly useful

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-12-01 
13:58:29 UTC ---
I wonder about the C++11 wording though, in C++03 it said:
"The reinterpret_cast operator shall not cast away constness. [Note: see 5.2.11
for the definition of ‘‘casting away constness’’. Subject to the restrictions
in this section, an expression may be cast to its own type using a
reinterpret_cast operator. ]"
but in C++11:
"The reinterpret_cast operator shall not cast away constness (5.2.11). An
expression of integral, enumeration, pointer, or pointer-to-member type can be
explicitly converted to its own type; such a cast yields the
value of its operand."
For the latter wording it isn't obvious if the second sentence is subject to
the other restrictions or not.

[Bug c++/51379] reinterpret_cast is not particularly useful

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
   Last reconfirmed||2011-12-01
 Resolution|INVALID |
 Ever Confirmed|0   |1

--- Comment #4 from Jonathan Wakely  2011-12-01 
14:06:47 UTC ---
Ah good point, I didn't realise DR 799 changed that
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#799

[Bug fortran/25708] Module loading is not good at all

[jb at gcc dot gnu.org]

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

--- Comment #19 from Janne Blomqvist  2011-12-01 
14:12:45 UTC ---
Author: jb
Date: Thu Dec  1 14:12:37 2011
New Revision: 181879

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181879
Log:
PR 25708 Avoid seeking when parsing strings and when peeking.

2011-12-01  Janne Blomqvist  

PR fortran/25708
* module.c (parse_string): Read string into resizable array
instead of parsing twice and seeking.
(peek_atom): New implementation avoiding seeks.
(require_atom): Save and set column and line explicitly for error
handling.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c

[Bug lto/51355] [4.7 Regression] cgraph_add_edge_to_call_site_hash, at cgraph.c:765

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #1 from Markus Trippelsdorf  
2011-12-01 14:17:13 UTC ---
Looks like Bug 51346.

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-01
 CC||iains at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[amylaar at gcc dot gnu.org]

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

--- Comment #19 from Jorn Wolfgang Rennecke  
2011-12-01 14:25:52 UTC ---
Author: amylaar
Date: Thu Dec  1 14:25:24 2011
New Revision: 181880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181880
Log:
PR tree-optimization/50802
* tree-vrp.c (simplify_conversion_using_ranges): Rewrite test
considering what happens to ranges during sign changes and/or
intermediate narrowing conversions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c

[Bug c++/51239] ICE with variadic template alias

[dodji at gcc dot gnu.org]

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

--- Comment #1 from Dodji Seketeli  2011-12-01 
14:44:10 UTC ---
Here is my understanding of what is happening here.

When we first build the type head, we don't yet know the actual
number of arguments for the 'head' template.  So we should build a
representation of head in which we don't yet try to substitute
Ts... for the parameters of 'head'.

That substitution would happen when 'x' is instantiated with a real
argument pack.  That argument pack would be substituted for Ts... and
yield a real list of arguments that would in turn be applied to 'head'.

Instead, we proceed as if we knew the number of arguments,
and try to apply Ts... to head directly.  And from there on, bad
things happen.

I am currently testing a patch for this.

[Bug fortran/51380] New: ASSIGNMENT(=): Reject ALLOCATABLE/POINTER dummy argument

[burnus at gcc dot gnu.org]

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

 Bug #: 51380
   Summary: ASSIGNMENT(=): Reject ALLOCATABLE/POINTER dummy
argument
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


The following program is invalid as the call to the assignment function should
act as if the "from" argument is enclosed in parentheses. That directly implies
that the actual argument cannot be allocatable or a pointer.

For the topic and the standard, cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/13ac0c0e52339468

Note: Strictly speaking, only the call to the function is invalid while the
declaration is valid (but may not be used).


>From the standard (F2003, found by Richard Maine):
  "A defined assignment is treated as a reference to the subroutine,
   with the left-hand side as the first argument and the right-hand-side
   enclosed in parentheses as the second argument." (12.3.2.1.2, paragraph 2)


Possibilities:
* Error for the usage
* Error for the declaration (even if valid, it may not be used)
* Warning for the declaration, error for using it

The following program is compiled without any error/(default) warning in
gfortran.

While the IBM compiler prints the error (as stated in c.l.f):
  (S) Dummy argument sets of procedure or binding assign_set_i4_2_pv must
  not be specified with the ALLOCATABLE attribute. assign_set_i4_2_pv
  will not be included in the ASSIGNMENT(=) generic interface.


module m
  type t1
integer :: i
  end type t1
  type t2
real :: r
  end type t2
  interface assignment(=)
module procedure assign1
module procedure assign2
  end interface
contains
  subroutine assign1 (a, b)
type(t1), intent(out) :: a
type(t1), intent(in), ALLOCATABLE :: b ! valid but questionable
a%i = b%i
  end subroutine assign1
  subroutine assign2 (a, b)
type(t2), intent(out) :: a
type(t2), intent(in), POINTER :: b ! valid but questionable
a%r = b%r
  end subroutine assign2
end module m

use m
type(t1), allocatable :: x1
type(t2), pointer :: x2
allocate(x1, x2)
x1 = x1   ! << Invalid, equivalent to: call assign1(x1, (x1))
  ! and (x1) is not allocatable
x1 = (x1) ! << Similarly invalid, but with explicit (.)
x2 = x2   ! << Invalid, equivalent to: call assign2(x1, (x1))
  ! and (x2) is not a pointer
x2 = (x2) ! << Similarly invalid, but with explicit (.)
end

[Bug tree-optimization/51356] [4.7 Regression] FAIL: gfortran.dg/anyallcount_1.f90 -O3 (internal compiler error) on powerpc-apple-darwin9 with -m32

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2011-12-01 
14:57:13 UTC ---
> works for me on top of 181853 (powerpc-darwin9).

For me too on top of 181782 (powerpc-darwin9, regtested gcc and gfortran) and
181863 (x86_64-apple-darwin10, full regtest).

> ... I doubt we could actually vectorize it anyway.

The test was not vectorized before the patch nor after it.

[Bug c++/51381] New: Internal compiler error for arm target

[eric.valette at free dot fr]

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

 Bug #: 51381
   Summary: Internal compiler error for arm target
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.vale...@free.fr
  Host: Linux trimslice armv7l GNU/Linux arm-linux-gnueabihf
Target: arm-linux-gnueabihf


Internal compiler error 

GUIInfoManager.cpp: In member function ‘CStdString
CGUIInfoManager::GetMusicLabel(int)’:
GUIInfoManager.cpp:3349:1: internal compiler error: in fp_immediate_constant,
at config/arm/arm.c:12546

[Bug bootstrap/51346] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #4 from Markus Trippelsdorf  
2011-12-01 15:06:11 UTC ---
With the assert in cgraph_add_edge_to_call_site_hash commented out I get:

../../gcc/gcc/c-parser.c: In function ‘c_parser_declaration_or_fndef’:
../../gcc/gcc/c-parser.c:1449:48: internal compiler error: Segmentation fault

[Bug lto/51355] [4.7 Regression] cgraph_add_edge_to_call_site_hash, at cgraph.c:765

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Joost VandeVondele  
2011-12-01 15:10:24 UTC ---
yes this is very likely a dup. I'll check again as soon as 51346 is resolved.

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

[Bug bootstrap/51346] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat
   ||dot ethz.ch

--- Comment #5 from Joost VandeVondele  
2011-12-01 15:10:25 UTC ---
*** Bug 51355 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/48715] CASE_VALUES_THRESHOLD should be settable with --param

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  2011-12-01 
15:12:42 UTC ---
Patch was checked in July 5th, 2011.

[Bug c++/51382] New: Incorrect diagnostic "cannot appear in a constant-expression"

[dnovillo at gcc dot gnu.org]

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

 Bug #: 51382
   Summary: Incorrect diagnostic "cannot appear in a
constant-expression"
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dnovi...@gcc.gnu.org
CC: cr...@google.com, fabien.ch...@gmail.com,
ja...@redhat.com


$ cat a.cc
template< int Value >
struct Base
{
   enum { b_e = Value };
};

template< typename Type >
struct Derived : Type
{
   Type::b_e;
   enum { d_e = b_e };
};

int v = (int)Derived< Base< 3 > >::d_e;

$ ./g++ -c a.cc
a.cc: In instantiation of 'struct Derived >':
a.cc:14:34:   required from here
a.cc:11:9: error: 'using Base<3>::b_e' cannot appear in a constant-expression

$ ./g++ --version
g++ (GCC) 4.7.0 2028 (experimental)
Copyright (C) 2011 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.

There is an additional, possibly related, bug in the diagnostic.  This is not
exposed in this test case, but it shows up in the original source.
In another line of the same file, the following diagnostic is emitted:


file.h:1061:6: error: no match for 'operator*' in '2 * #'using_decl' not
supported by dump_expr#'.  The code reads:

template
char Set::fbs_[2 * k];


it's not clear to me whether the code is well-formed or not, but the diagnostic
should certainly not get all confused like that.

Lawrence, could you get a reproducer for this diagnostic?


Thanks.  Diego.

[Bug rtl-optimization/51014] [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops

[howarth at nitro dot med.uc.edu]

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

--- Comment #5 from Jack Howarth  2011-12-01 
15:31:37 UTC ---
(In reply to comment #4)
> Created attachment 25939 [details]
> gcc47-pr51014.patch
> 
> Untested fix.

This fix solved the problem with the reduced testcase on x86_64-apple-darwin11
without regressions...

http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02982.html

Is there a problem on other targets preventing the commit?

[Bug rtl-optimization/48715] CASE_VALUES_THRESHOLD should be settable with --param

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  2011-12-01 
15:36:01 UTC ---
The commit is r175878:

http://gcc.gnu.org/viewcvs?view=revision&revision=175878

There is no link-back to here because the ChangeLog does not mention the PR and
there is no commit message mentioning it.

[Bug c++/51381] Internal compiler error for arm target

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  2011-12-01 
15:57:08 UTC ---
Please provide preprocessed source for the test case, the options used to
compile it, and how the compiler was configured.

[Bug tree-optimization/50622] [4.7 Regression] ICE: verify_gimple failed for std::complex

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  2011-12-01 
16:20:02 UTC ---
Patch posted to mailing list:

http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00080.html

[Bug rtl-optimization/51014] [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-12-01 
16:57:13 UTC ---
Author: jakub
Date: Thu Dec  1 16:57:07 2011
New Revision: 181883

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181883
Log:
PR rtl-optimization/51014
* loop-unroll.c (apply_opt_in_copies): Ignore label DEBUG_INSNs
both from bb and orig_bb.

* g++.dg/opt/pr51014.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr51014.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-unroll.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/51014] [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-12-01 
17:04:45 UTC ---
Fixed.

[Bug tree-optimization/51246] [4.7 Regression] ICE in replace_ref_with, at tree-predcom.c:1309

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-12-01 
17:03:40 UTC ---
Author: jakub
Date: Thu Dec  1 17:03:33 2011
New Revision: 181884

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181884
Log:
PR tree-optimization/51246
* tree-predcom.c (replace_ref_with): Handle also clobber on the
rhs.

* gcc.c-torture/compile/pr51246.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr51246.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug tree-optimization/51246] [4.7 Regression] ICE in replace_ref_with, at tree-predcom.c:1309

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-12-01 
17:07:25 UTC ---
Fixed.

[Bug c++/51381] Internal compiler error for arm target

[eric.valette at free dot fr]

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

--- Comment #2 from eric.valette at free dot fr 2011-12-01 17:08:49 UTC ---
I cannot attach the preprocessed file directly because its too biig. Will try
to zip it. I already attached it but get no error first time.

[Bug c++/51381] Internal compiler error for arm target

[eric.valette at free dot fr]

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

--- Comment #3 from eric.valette at free dot fr 2011-12-01 17:10:15 UTC ---
Created attachment 25968
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25968
bziped preprocessed file

[Bug lto/51198] [c++0x] [4.7 Regression] ICE with -flto and non-static data member initializers

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  2011-12-01 
17:13:10 UTC ---
Author: pinskia
Date: Thu Dec  1 17:13:05 2011
New Revision: 181886

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181886
Log:
2011-12-01  Andrew Pinski  

PR lto/51198
* tree.c (free_lang_data_in_decl): Clear FIELD_DECL's
DECL_INITIAL also.

2011-12-01  Andrew Pinski  

PR lto/51198
* g++.dg/torture/pr51198.C: New testcase.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr51198.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug lto/51198] [c++0x] [4.7 Regression] ICE with -flto and non-static data member initializers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Andrew Pinski  2011-12-01 
17:13:41 UTC ---
Fixed.

[Bug c++/51381] Internal compiler error for arm target

[eric.valette at free dot fr]

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

--- Comment #4 from eric.valette at free dot fr 2011-12-01 17:20:38 UTC ---
Compilation option for the file

-g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -DPIC -D_REENTRANT
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -D_DEBUG -Wall -O2
-mfloat-abi=hard -mno-apcs-stack-check -Wno-psabi -Wa,-march=armv7a
-mtune=cortex-a9 -mfpu=vfpv3-d16 -mthumb-interwork

[Bug c++/51381] Internal compiler error for arm target

[eric.valette at free dot fr]

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

--- Comment #5 from eric.valette at free dot fr 2011-12-01 17:25:15 UTC ---
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--disable-sjlj-exceptions --with-arch=armv7-a --with-float=hard
--with-fpu=vfpv3-d16 --with-mode=thumb --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.6.2 (Debian 4.6.2-5)

[Bug target/51381] Internal compiler error for arm target

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target
   Severity|major   |normal

[Bug c++/22238] Awful error messages with virtual functions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||jason at gcc dot gnu.org,
   ||manu at gcc dot gnu.org
 AssignedTo|gdr at gcc dot gnu.org  |unassigned at gcc dot
   ||gnu.org

--- Comment #16 from Manuel López-Ibáñez  2011-12-01 
17:27:01 UTC ---
I think this is a duplicate of another PR I cannot find, but everything boils
down to "please kill %qE and stop pretty-printing expressions". Behold the
beauty of clang:

pr22238.cc:8:20: error: value of type 'void' is not contextually convertible to
'bool'
  void bar() { if (foo()) ; }
   ^
1 error generated. 

(it looks even prettier with the default colors!)

[Bug c++/22238] Awful error messages with virtual functions

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  2011-12-01 
17:39:24 UTC ---
(In reply to comment #16)
> I think this is a duplicate of another PR I cannot find

PR 50817 ?

[Bug middle-end/51273] ICE: vector VEC(inline_summary_t,base) index domain error, in inline_summary at ipa-inline.h:193 with -O -fgnu-tm, transaction_safe and overloaded contructor

[rth at gcc dot gnu.org]

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

--- Comment #2 from Richard Henderson  2011-12-01 
17:46:35 UTC ---
Author: rth
Date: Thu Dec  1 17:46:32 2011
New Revision: 181887

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181887
Log:
PR middle-end/51273
* cgraph.h (cgraph_call_node_duplication_hooks): Declare.
* cgraph.c (cgraph_call_node_duplication_hooks): Make global.
* cgraphunit.c (cgraph_copy_node_for_versioning): Call it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cgraphunit.c

[Bug c++/50817] G++ emits errors containing lowered vtable references

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #7 from Manuel López-Ibáñez  2011-12-01 
17:50:25 UTC ---
Duplicate.

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

[Bug c++/22238] Awful error messages with virtual functions

[manu at gcc dot gnu.org]

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

--- Comment #18 from Manuel López-Ibáñez  2011-12-01 
17:50:25 UTC ---
*** Bug 50817 has been marked as a duplicate of this bug. ***

[Bug bootstrap/51346] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #6 from Jack Howarth  2011-12-01 
18:12:35 UTC ---
On x86_64-apple-darwin11, this failure occurs for a simple lto-bootstrap and
doesn't require bootstrap-profiled to trigger the problem.

[Bug bootstrap/51346] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[dnovillo at google dot com]

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

--- Comment #7 from dnovillo at google dot com  
2011-12-01 18:20:37 UTC ---
On Thu, Dec 1, 2011 at 13:12, howarth at nitro dot med.uc.edu
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51346
>
> Jack Howarth  changed:
>
>           What    |Removed                     |Added
> 
>                 CC|                            |howarth at nitro dot
>                   |                            |med.uc.edu
>
> --- Comment #6 from Jack Howarth  2011-12-01 
> 18:12:35 UTC ---
> On x86_64-apple-darwin11, this failure occurs for a simple lto-bootstrap and
> doesn't require bootstrap-profiled to trigger the problem.

I'm about to commit a patch that should fix this bug.


Diego.

[Bug c++/51381] Internal compiler error for arm target

[eric.valette at free dot fr]

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

eric.valette at free dot fr changed:

   What|Removed |Added

  Component|target  |c++
   Severity|normal  |major

--- Comment #6 from eric.valette at free dot fr 2011-12-01 18:39:56 UTC ---
I guess I've been hit by the Emit-conditions-in-push_multi problem. I applied
the patch below after verifying ist upstream but have not yet rebuild gcc

http://old.nabble.com/ARM%3A-Emit-conditions-in-push_multi-td32379089.html#a32386142

[Bug target/51381] Internal compiler error for arm target

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target
   Severity|major   |normal

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  2011-12-01 
19:12:58 UTC ---
Author: jakub
Date: Thu Dec  1 19:12:54 2011
New Revision: 181890

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181890
Log:
PR debug/50317
* tree-ssa-dce.c (remove_dead_stmt): Add a debug stmt when removing
as unnecessary a store to a variable with gimple reg type.
* tree-ssa-live.c (remove_unused_locals): Clear TREE_ADDRESSABLE bit
on local unreferenced variables.
* cfgexpand.c (expand_gimple_basic_block): Don't emit DEBUG_INSNs
for !target_for_debug_bind variables.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/tree-ssa-dce.c
trunk/gcc/tree-ssa-live.c

[Bug tree-optimization/51356] [4.7 Regression] FAIL: gfortran.dg/anyallcount_1.f90 -O3 (internal compiler error) on powerpc-apple-darwin9 with -m32

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-12-01 
19:14:06 UTC ---
Author: jakub
Date: Thu Dec  1 19:14:03 2011
New Revision: 181891

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181891
Log:
PR tree-optimization/51356
* tree-vect-patterns.c (vect_recog_bool_pattern): Give up if
vectype doesn't have VECTOR_MODE_P.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #14 from Jakub Jelinek  2011-12-01 
19:16:20 UTC ---
Fixed.

[Bug tree-optimization/51356] [4.7 Regression] FAIL: gfortran.dg/anyallcount_1.f90 -O3 (internal compiler error) on powerpc-apple-darwin9 with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2011-12-01 
19:16:53 UTC ---
Fixed.

[Bug c++/51180] [C++0x] inner class alias-definition variadic template error

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-12-01
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Dodji Seketeli  2011-12-01 
19:25:02 UTC ---
This is somewhat related to PR c++/51239.  I think at some point
during the substituting of t2 in to m, we should leave t2
"unbound" instead of trying to substitute B... into it.

The proper substituting of t2 would happen later when B... has a
proper matching argument pack.

I am working on a joint patch for this and PR c++/51239.

[Bug c++/51180] [C++0x] inner class alias-definition variadic template error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  2011-12-01 
19:41:33 UTC ---
(In reply to comment #2)
> This is somewhat related to PR c++/51239.  I think at some point
> during the substituting of t2 in to m, we should leave t2
> "unbound" instead of trying to substitute B... into it.

I'm surprised that it doesn't just work already; writing t2 already
works, doing the substitution ought to work the same way.

[Bug rtl-optimization/50904] [4.7 regression] pessimization when -fno-protect-parens is enabled by -Ofast

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ebotcazou at gcc dot|
   |gnu.org |
  Component|tree-optimization   |rtl-optimization
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org

--- Comment #19 from Eric Botcazou  2011-12-01 
19:53:15 UTC ---
> lim3 was added as a "hack", now yes, cunroll needs ccp after it (but it's
> there in the form of DOM and VRP).  It's a pass ordering issue that we
> cannot ever solve.

OK, but that doesn't explain why LIM isn't able to hoist the loads...

> Please - it seems like a missed optimization there, too.

More of an acknowledged limitation I'd say.  And RTL passes aren't supposed to
be enhanced to plug holes in the Tree passes, but let's try anyway.

[Bug target/48183] ICE [arm] immed_double_const at emit-rtl.c (-mfpu=neon -g -O1)

[havard.graff at gmail dot com]

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

Havard Graff  changed:

   What|Removed |Added

 CC||havard.graff at gmail dot
   ||com

--- Comment #1 from Havard Graff  2011-12-01 
19:58:11 UTC ---
I have some additional info related to this bug:

If I compile the following:

#include "arm_neon.h"
#include "stdlib.h"

int main ()
{
   float r [] = {0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f};
   float32x4x2_t d;
   d = vld2q_f32 (r);
   vst2q_f32 (r, d);
   return 0;
}

using: arm-linux-androideabi-gcc test.c -mfloat-abi=softfp -mfpu=neon -g -O1

I get:
test.c: In function 'main':
test.c:4:5: internal compiler error: in immed_double_const, at emit-rtl.c:550
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

However, if I comment out vst2q_f32 (r, d);, the problem goes away. Also by not
using -g or -O1.

$ arm-linux-androideabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-androideabi-gcc
COLLECT_LTO_WRAPPER=/Users/havard.graff/Code/android-ndk-r7/toolchains/arm-linux-androideabi-4.6.2/prebuilt/darwin-x86/libexec/gcc/arm-linux-androideabi/4.6.2/lto-wrapper
Target: arm-linux-androideabi
Configured with:
/Users/havard.graff/Code/selfbuilt_android_toolchain/build/../gcc/gcc-4.6.2/configure
--prefix=/Users/havard.graff/Code/android-ndk-r7/toolchains/arm-linux-androideabi-4.6.2/prebuilt/darwin-x86
--target=arm-linux-androideabi --host=i686-apple-darwin
--build=i686-apple-darwin --with-gnu-as --with-gnu-ld
--enable-languages=c,c++,objc
--with-gmp=/tmp/ndk-havard.graff/build/toolchain/temp-install
--with-mpfr=/tmp/ndk-havard.graff/build/toolchain/temp-install
--with-mpc=/tmp/ndk-havard.graff/build/toolchain/temp-install --disable-libssp
--enable-threads --disable-nls --disable-libmudflap --disable-libgomp
--disable-sjlj-exceptions --disable-shared --disable-tls --with-float=soft
--with-fpu=vfp --with-arch=armv5te --enable-target-optspace
--disable-hosted-libstdcxx --enable-cxx-flags='-fexceptions -frtti'
--enable-initfini-array --disable-nls
--prefix=/Users/havard.graff/Code/android-ndk-r7/toolchains/arm-linux-androideabi-4.6.2/prebuilt/darwin-x86
--with-sysroot=/Users/havard.graff/Code/android-ndk-r7/toolchains/arm-linux-androideabi-4.6.2/prebuilt/darwin-x86/sysroot
--with-binutils-version=2.22.51 --with-mpfr-version=2.4.1
--with-gmp-version=4.2.4 --with-gcc-version=4.6.2 --with-gdb-version=6.6
--with-arch=armv5te --program-transform-name='s,^,arm-linux-androideabi-,'
Thread model: posix
gcc version 4.6.2 (GCC)

[Bug gcov-profile/51113] [4.7 regression] rev. 181105 causes Firefox profiledbuild failure

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell  2011-12-01 
19:58:55 UTC ---
Author: nathan
Date: Thu Dec  1 19:58:51 2011
New Revision: 181892

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181892
Log:
PR gcov-profile/51113
* coverage.c (build_var): Keep coverage variables static.

testsuite/
* lib/gcov.exp (verify-lines): Add support for xfailing.
(run-gcov): Likewise.
* gcc.misc-tests/gcov-13.c: Xfail weak function.
* gcc.misc-tests/gcov-16.c: Remove.
* gcc.misc-tests/gcov-17.c: Remove.
* g++.dg/gcov-8.C: Remove.
* g++.dg/gcov-9.C: Remove.
* g++.dg/gcovpart-12b.C: New.
* g++.dg/gcov-12.C: New.

Added:
trunk/gcc/testsuite/g++.dg/gcov/gcov-12.C
trunk/gcc/testsuite/g++.dg/gcov/gcovpart-12b.C
Removed:
trunk/gcc/testsuite/g++.dg/gcov/gcov-8.C
trunk/gcc/testsuite/g++.dg/gcov/gcov-9.C
trunk/gcc/testsuite/gcc.misc-tests/gcov-16.c
trunk/gcc/testsuite/gcc.misc-tests/gcov-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/coverage.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.misc-tests/gcov-13.c
trunk/gcc/testsuite/lib/gcov.exp

[Bug fortran/51383] New: arrays of extended types interact break associations with arrays

[kaiserkarl31 at yahoo dot com]

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

 Bug #: 51383
   Summary: arrays of extended types interact break associations
with arrays
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kaiserkar...@yahoo.com


An ASSOCIATE block that associates a name with an array of derived types causes
a compiler error.

It is easily reproduced with the following short program:

program extend
   type :: a
  integer :: i
   end type a
   type, extends (a) :: b
  integer :: j
   end type b
   type (a) :: x(2)
   type (b) :: y(2)
   associate (x1 => x, y1 => y)
  x1(1)%i = 1
  ! Commenting out the following line will avoid the error
  y1(1)%i = 2
   end associate
end program extend

In my version, I get the following error:
## start error message ##
associate.f90:1.14:

program extend
  1
Internal Error at (1):
find_array_spec(): Component not found
## end error message ##

This example is trivial, of course (just use y instead of y1 and all is well),
but if the association is something like
  associate (y1 => really_long%complicated(3)%variable(2)%array)
it becomes more than a triviality

As can be seen from the example above, this bug does not occur for "normal"
derived types, only ones created with the EXTENDS key word.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[ebotcazou at gcc dot gnu.org]

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

--- Comment #31 from Eric Botcazou  2011-12-01 
20:25:27 UTC ---
> Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
> either.

Right, I'd apply the patch in any case, this is a gratuitous portability issue.

[Bug c++/51384] New: seg fault in tsubst_copy_and_build

[dcb314 at hotmail dot com]

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

 Bug #: 51384
   Summary: seg fault in tsubst_copy_and_build
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


I just tried to compile the package eigen3-3.0.0
on latest trunk snapshot 2026 on an AMD x86_64 box.

The compiler said

/home/dcb/rpmbuild/BUILD/eigen-eigen-65ee2328342f/Eigen/src/Core/DenseBase.h:247:137:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Here is valgrind helping out with a stack bracktrace

==13212== Invalid read of size 2
==13212==at 0x55AC74: tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) (pt.c:13374)
==13212==by 0x559F36: tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) (pt.c:13889)
==13212==by 0x5591BA: tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) (pt.c:13367)
==13212==by 0x559DB3: tsubst_copy_and_build(tree_node*, tree_node*, int,
tree_node*, bool, bool) (pt.c:13519)
==13212==by 0x54A350: tsubst_expr(tree_node*, tree_node*, int, tree_node*,
bool) (pt.c:13245)
==13212==by 0x56517D: tsubst_template_arg(tree_node*, tree_node*, int,
tree_node*) (pt.c:9187)
==13212==by 0x56DF3E: coerce_template_parms(tree_node*, tree_node*,
tree_node*, int, bool, bool) (pt.c:6846)
==13212==by 0x552A4E: lookup_template_class(tree_node*, tree_node*,
tree_node*, tree_node*, int, int) (pt.c:7375)
==13212==by 0x658332: finish_template_type(tree_node*, tree_node*, int)
(semantics.c:2760)
==13212==by 0x5EFD18: cp_parser_template_id(cp_parser*, bool, bool, bool)
(parser.c:12445)
==13212==by 0x5F01AF: cp_parser_class_name(cp_parser*, bool, bool,
tag_types, bool, bool, bool) (parser.c:17876)
==13212==by 0x5EA699: cp_parser_nested_name_specifier_opt(cp_parser*, bool,
bool, bool, bool) (parser.c:5249)
==13212==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==13212==

Preprocessed source code attached. Flag -march=native required.

[Bug c++/51384] seg fault in tsubst_copy_and_build

[dcb314 at hotmail dot com]

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

--- Comment #1 from dcb  2011-12-01 21:01:48 UTC ---
Created attachment 25969
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25969
gzipped C++ source code

[Bug bootstrap/51346] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[dnovillo at gcc dot gnu.org]

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

--- Comment #8 from Diego Novillo  2011-12-01 
21:05:14 UTC ---
Author: dnovillo
Date: Thu Dec  1 21:05:10 2011
New Revision: 181894

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181894
Log:
PR bootstrap/51346
* ipa-inline.c (can_inline_edge_p): If the edge E has a
statement, use the statement's inline indicator instead
of E's.
Remove consistency check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c

[Bug bootstrap/51346] [4.7 Regression] LTO bootstrap failed with bootstrap-profiled

[dnovillo at gcc dot gnu.org]

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

Diego Novillo  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Diego Novillo  2011-12-01 
21:11:22 UTC ---
Fixed.  http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00107.html.

[Bug c++/51318] [4.7 Regression] segfault on Eigen3

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-12-01 
21:31:58 UTC ---
Marc, do you have a feeling PR51384 is a duplicate?

[Bug c++/51318] [4.7 Regression] segfault on Eigen3

[marc.glisse at normalesup dot org]

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

--- Comment #3 from Marc Glisse  2011-12-01 
21:42:35 UTC ---
(In reply to comment #2)
> Marc, do you have a feeling PR51384 is a duplicate?

At least I produced this testcase starting from the one-liner:
#include 
that made g++ segfault and applying delta. So yes, I'd say it's a dup (although
there could in principle be several g++ bugs and delta would highlight one that
may not be the one giving the backtrace in PR51384).

[Bug c++/51384] seg fault in tsubst_copy_and_build

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-12-01 
21:55:09 UTC ---
Likely dup of PR51318

[Bug c++/51318] [4.7 Regression] segfault on Eigen3

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-12-01 
22:11:11 UTC ---
Thanks. I just had a look to the backtrace and seems the same.

[Bug c++/51326] [4.7 Regression] ICE with invalid override

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-12-01 22:13:25 UTC ---
Author: paolo
Date: Thu Dec  1 22:13:19 2011
New Revision: 181895

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181895
Log:
/cp
2011-12-01  Paolo Carlini  

PR c++/51326
* call.c (build_user_type_conversion_1): Early return NULL if
expr is NULL_TREE.

/testsuite
2011-12-01  Paolo Carlini  

PR c++/51326
* g++.dg/inherit/crash3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/inherit/crash3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51318] [4.7 Regression] segfault on Eigen3

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2011-12-01 
22:14:51 UTC ---
Let's add Jason in CC, it seems an annoying regression.