[Bug c++/53226] New: memory consumption for heavy template instantiations increased massively

[mario-baumann at web dot de]

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

 Bug #: 53226
   Summary: memory consumption for heavy template instantiations
increased massively
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mario-baum...@web.de


Hi All,

i noticed that memory consumption for heavy template instantiations increased
massively between gcc revision 187034 and 187074. If a compile my current
project (unfortunately closed source) i got e.g.

> top
top - 08:58:08 up 1 day, 30 min, 11 users,  load average: 28.83, 19.13, 13.36
Mem:  24607424k total, 24464568k used,   142856k free,  752k buffers
Swap: 52436120k total,  6650108k used, 45786012k free,  4174408k cached
  PID PR  NI  VIRT  RES  SHR S %CPU %MEM   TIME+   COMMAND
14825 20   0 24.5g  18g  496 R 89.1 79.0   3:48.75 cc1plus

Mario.

---

> uname -a
Linux ahsoka.intec.dom 2.6.32-220.13.1.el6.x86_64 #1 SMP Thu Mar 29 11:46:40
EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

> rpm -qa "glibc*" | grep -e 'glibc-[0-9]' | sort -u
glibc-2.12-1.47.el6_2.9.i686
glibc-2.12-1.47.el6_2.9.x86_64

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/app2/gcc/4.8.0-20120503-svn187074/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/app2/gcc/4.8.0-20120503-svn187074/x86_64
--enable-languages=c,c++,fortran --disable-nls
--with-gmp=/app2/gcc/4.8.0-20120503-svn187074/x86_64/aux
--with-mpfr=/app2/gcc/4.8.0-20120503-svn187074/x86_64/aux
--with-mpc=/app2/gcc/4.8.0-20120503-svn187074/x86_64/aux
--with-ppl=/app2/gcc/4.8.0-20120503-svn187074/x86_64/aux
--with-cloog=/app2/gcc/4.8.0-20120503-svn187074/x86_64/aux
Thread model: posix
gcc version 4.8.0 20120503 (experimental) (GCC) 

> ld -v
GNU ld (GNU Binutils) 2.22.52.20120503

[Bug rtl-optimization/53227] New: [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4

[ubizjak at gmail dot com]

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

 Bug #: 53227
   Summary: [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c
scan-assembler-times movbe[ \t] 4
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ra
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
CC: ber...@gcc.gnu.org, uweig...@gcc.gnu.org,
vmaka...@gcc.gnu.org
Target: i686


Split from PR 53176, that changed lower-subreg to not split subregs early on
x86.

Following testcase

--cut here--
extern long long x;

void
foo (long long i)
{
  x = __builtin_bswap64 (i);
}

long long
bar ()
{
  return __builtin_bswap64 (x);
}
--cut here--

compiled with -O2 -mmovbe -m32 on x86 target triggers RA to allocate
non-optimal registers for "foo" (and forcing reload), while it is able to
allocate optimal regs for "bar" case:

bar:
movbe   x+4, %eax
movbe   x, %edx
ret

The situation with foo:

foo:
pushl   %ebx
movl8(%esp), %eax
movl12(%esp), %edx
movl%eax, %ebx
movl%edx, %ecx
bswap   %ebx
bswap   %ecx
movl%ebx, x+4
movl%ecx, x
popl%ebx
ret

Which is a noticeable regression from 4.7:

foo:
movbe   4(%esp), %eax
movbe   8(%esp), %edx
movl%eax, x+4
movl%edx, x
ret

Adding -mregparm=2 does not improve things:

foo:
pushl   %ebx
movl%edx, %ecx
movl%eax, %ebx
bswap   %ecx
bswap   %ebx
movl%ecx, x
movl%ebx, x+4
popl%ebx
ret

while 4.7 generates:

foo:
movbe   %edx, x
movbe   %eax, x+4
ret

[Bug c++/53226] memory consumption for heavy template instantiations increased massively

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-04
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  2012-05-04 
07:22:33 UTC ---
http://gcc.gnu.org/bugs/minimize.html

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #2 from Martin Husemann  2012-05-04 
07:56:48 UTC ---
I double checked: the sigsetjmp/siglonjmp function prototypes are properly
marked as returns_twice and noreturn, so I claim this to be abug in gcc ;-)

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  
2012-05-04 08:17:57 UTC ---
On Thu, 3 May 2012, andi-gcc at firstfloor dot org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
> 
> --- Comment #17 from Andi Kleen  2012-05-03 
> 14:57:13 UTC ---
> Hmm, my assumption was always that this option would be passed through and 
> then
> used by lto1 step. That's true  for other -f* options at least.

No, we do

  /* The following does what the old LTO option code did,
 union all target and a selected set of common options.  */
  for (i = 0; i < fdecoded_options_count; ++i)
{
  struct cl_decoded_option *foption = &fdecoded_options[i];
  switch (foption->opt_index)
{
default:
  if (!(cl_options[foption->opt_index].flags & CL_TARGET))
break;

thus only pass through all target options and the explicitely listed
set of common options.

[Bug rtl-optimization/53176] [4.8 Regression] gcc.dg/lower-subreg-1.c FAILs

[ubizjak at gmail dot com]

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

--- Comment #17 from Uros Bizjak  2012-05-04 08:20:27 
UTC ---
(In reply to comment #16)
> The x86 failure:
> 
> FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4
> 
> is a register allocator/reload problem. I will open new PR for this.

-> PR 53227

[Bug target/53228] New: [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[rguenth at gcc dot gnu.org]

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

 Bug #: 53228
   Summary: [4.6/4.7/4.8 Regression] target attributes in
libcpp/lex.c cause illegal instructions to be used
elsewhere
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


When building libcpp/lex.c for -march=i586 and -mtune=generic on i586-linux-gnu
generic code contains cmov* instructions which will SIGILL on

finger@mtech:~> cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 8
model name  : AMD-K6(tm) 3D processor
stepping: 12
microcode   : 0x8b
cpu MHz : 428.811
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnow k6_mtrr up
bogomips: 857.62
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:

CPUs which are perfectly fine matching -march=i586.

When you remove all target attribute annotated code from lex.c these
instructions disappear.

Thus, a compiler built for i586 does not work.

The bug persists with GCC 4.6, 4.7 and 4.8.

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2012-05-04 
08:33:53 UTC ---
Created attachment 27304
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27304
preprocessed source

Preprocessed lex.c from the 4.6 branch.

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||i?86-*-*
   Target Milestone|--- |4.6.4

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-05-04 
08:43:09 UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49104 ?

[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-05-04 
08:42:31 UTC ---
I'm always relucant in backporting this kind of fixes as the LTO state is
so different on branches.  Can you confirm that backporting this fix fixes
problems for you?  I ask because type-decls do not survive on the 4.6 branch
AFAIK.

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  2012-05-04 
08:48:08 UTC ---
Please provide a test case.  See .

[Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-04
 Ever Confirmed|0   |1

--- Comment #4 from Jonathan Wakely  2012-05-04 
08:54:20 UTC ---
A stackoverflow URL is not a valid bug report, please follow the bug reporting
guidelines as requested when you created this report: http://gcc.gnu.org/bugs/ 

There are several code examples on that page and your original post doesn't
even compile, provide a self-contained testcase here, not as a URL to another
site.

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-05-04 
08:57:44 UTC ---
The revision that supposedly fixed the issue is in reporters sources
(for reference: https://bugzilla.novell.com/show_bug.cgi?id=760210).

Note that I see cmov* instructions in _cpp_clean_line, _cpp_temp_token,
cpp_avoid_paste, cpp_output_line_to_string and more.  _Not_ only in the
SSE marked functions.

[Bug rtl-optimization/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-04
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-05-04 
08:58:36 UTC ---
Confirmed.

[Bug c++/53213] Internal compiler error in math.h

[lbl2007 at gmx dot net]

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

lbl2007 at gmx dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #3 from lbl2007 at gmx dot net 2012-05-04 08:59:28 UTC ---
The error occurs in mpfr_set_str() when using an unpatched version of MPFR 3.1.
Applying the latest cumulative patch
(http://www.mpfr.org/mpfr-current/allpatches) appears to solve the problem.

[Bug c++/53226] memory consumption for heavy template instantiations increased massively

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-05-04 
09:01:32 UTC ---
Can you bi-sect to an exact revision causing the regression?

What compile options do you use?

[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.6.3
   Target Milestone|4.8.0   |4.7.1
  Known to fail||4.7.0, 4.8.0

[Bug c/53216] fmaf() alters rounding mode of sse2 FPU

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2012-05-04 
09:04:33 UTC ---
Indeed.

[Bug lto/53195] ICE seg fault in lto

[vincenzo.innocente at cern dot ch]

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

--- Comment #1 from vincenzo Innocente  
2012-05-04 09:22:30 UTC ---
does not happen with latest version of
gcc version 4.7.1 20120504 (prerelease) (GCC)

[Bug c++/53226] memory consumption for heavy template instantiations increased massively

[mario-baumann at web dot de]

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

--- Comment #3 from Mario Baumann  2012-05-04 
09:33:07 UTC ---
Hi Richard,

compile options are: -m32 -msse -msse2 -mfpmath=sse -fPIC -pipe -Wall -Wunused
-Werror -O2 -g

bi-sect: in progress ...

Mario.

[Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-05-04 
09:44:13 UTC ---
(In reply to comment #3)
> > I don't think this is valid as the memory which is done after the operator 
> > new
> is considered as unitialized.
> 
> The code does not use any uninitialized memory.  It does not read the memory. 
> However, it accesses the _type_  and the type exists before an instance of 
> that
> type is made.  

No, it accesses the memory before the constructor begins:

  this_type *new_pt = (this_type *)malloc(total_size);
  new_pt->count = count;

That accesses uninitialized memory before the object's lifetime begins.  And it
accesses it through a pointer of type "this_type*" so will use the offset of
this_type::count, for whatever type this_type is in that scope (which depends
on which of the examples on the stackoverflow page you're claiming is a
compiler bug, in some of them this_type is an alias for A, in others it's a
template parameter instantiated as type B, that's why you need to provide code
here, not vageuly refer to some other site with several code examples.)

> Part of the type information is the layout inside the class. The operator,
> which has been copied into the child via inheritance, 

No, inheritance doesn't mean anything is copied into the child, it means the
function is visible in the scope of the child.

> i.e. the child's version
> of the operator should be seeing the type of the child, not the type of the
> parent.

No, the function "A::operator new" is a member of A and when it uses this_type
it refers to whichever this_type is in scope.  There is no "B::operator new",
there is no child's version ofthe function, it sees the same version i.e.
"A::operator new"

>  The parent is irrelevant once its type is constructed - i.e. after the
> inheritance operation - which occurs before any instances are instantiated.

That's not how C++ works. Inheritance is not an operation.

[Bug lto/53214] [lto]: ICE: munmap_chunk(): invalid pointer

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-05-04 
10:05:02 UTC ---
Reduced C testcase:

double a(double) __attribute__ ((optimize(3), used));
double a(double r)   
{ 
  return r;
}
int main () { }

ICEs this way with

gcc -flto t.c

but not with -flto-partition=none or when the optimization level selected
in the attribute matches that of the compile.

[Bug lto/53214] [lto]: ICE: munmap_chunk(): invalid pointer

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2012-05-04 
10:19:52 UTC ---
The issue is that -fltrans and -fwpa are saved in the optimization node because
they are marked as "Optimization" in the .opt file.  Likewise -flto-report is.
So at wpa time we stream the optimization node into the ltrans section,
_unsetting_ -fltrans ... which of course confuses things.

Duh.

Mine.

[Bug lto/53195] [4.8 Regression] ICE seg fault in lto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-04
   Target Milestone|--- |4.8.0
Summary|ICE seg fault in lto|[4.8 Regression] ICE seg
   ||fault in lto
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-05-04 
10:34:52 UTC ---
I cannot reproduce it with trunk rev. 187148.  Can you re-check?

[Bug target/52908] xop-mul-1:f9 miscompiled on bulldozer (-mxop)

[venkataramanan.kumar at amd dot com]

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

Venkataramanan  changed:

   What|Removed |Added

 CC||venkataramanan.kumar at amd
   ||dot com

--- Comment #4 from Venkataramanan  
2012-05-04 10:42:43 UTC ---
Hi Uros,

I have not yet explored the patches.

A Quick make check on i386.exp result is shown below: 

sh compare_tests  ../../build_186236 ../../build_186236_patch/
# Comparing directories
## Dir1=../../build_186236: 7 sum files
## Dir2=../../build_186236_patch/: 7 sum files

# Comparing 7 common sum files
## /bin/sh compare_tests  /tmp/gxx-sum1.21222 /tmp/gxx-sum2.21222
Tests that now fail, but worked before:

gcc.target/i386/xop-imul32widen-vector.c scan-assembler vpmacsdql

Tests that now work, but didn't before:

gcc.target/i386/xop-mul-1.c execution test

## Differences found:
# 1 differences in 7 common sum files found

[Bug c++/53152] In "no match for operatorXX" error message gives the wrong column info

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||lopezibanez at gmail dot
   ||com

--- Comment #3 from Paolo Carlini  2012-05-04 
10:57:11 UTC ---
How could we in principle fix this? Pass down from cp_parser_binary_expression
the location of the operator token, through build_x_binary_op -> build_new_op
-> build_new_op_1 -> op_error? Boring but straightforward. Or something else
entirely? I'm just guessing, really.

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther  2012-05-04 
11:00:36 UTC ---
Patch I am testing:

Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 187148)
+++ gcc/lto-wrapper.c   (working copy)
@@ -414,6 +414,16 @@ merge_and_complain (struct cl_decoded_op
  if (j == *decoded_options_count)
append_option (decoded_options, decoded_options_count, foption);
  break;
+
+   case OPT_freg_struct_return:
+   case OPT_fpcc_struct_return:
+ for (j = 0; j < *decoded_options_count; ++j)
+   if ((*decoded_options)[j].opt_index == foption->opt_index)
+ break;
+ if (j == *decoded_options_count)
+   fatal ("Option %s not used consistently in all LTO input files",
+  foption->orig_option_with_args_text);
+ break;
}
 }
 }
@@ -558,6 +568,8 @@ run_gcc (unsigned argc, char *argv[])
case OPT_fcommon:
case OPT_fexceptions:
case OPT_fgnu_tm:
+   case OPT_freg_struct_return:
+   case OPT_fpcc_struct_return:
  break;

default:
@@ -619,6 +631,12 @@ run_gcc (unsigned argc, char *argv[])
  /* We've handled these LTO options, do not pass them on.  */
  continue;

+   case OPT_freg_struct_return:
+   case OPT_fpcc_struct_return:
+ /* Ignore these, they are determined by the input files.
+???  We fail to diagnose a possible mismatch here.  */
+ continue;
+
default:
  break;
}

[Bug target/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload

[ebotcazou at gcc dot gnu.org]

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

--- Comment #24 from Eric Botcazou  2012-05-04 
11:01:39 UTC ---
Author: ebotcazou
Date: Fri May  4 11:01:34 2012
New Revision: 187150

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187150
Log:
PR target/48496
* recog.c (constrain_operands): If extra constraints are present, also
accept pseudo-registers with equivalent memory locations during reload.

Added:
trunk/gcc/testsuite/gcc.target/ia64/pr48496.c
trunk/gcc/testsuite/gcc.target/ia64/pr52657.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/recog.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/53195] [4.8 Regression] ICE seg fault in lto

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #3 from vincenzo Innocente  
2012-05-04 11:06:14 UTC ---
effectively…  (verified before doing svn update, was still crashing!)

c++ -O2 -flto -std=c++0x -shared -fPIC -o bha.so ltobug1/*.cc
[innocent@vinavx0 ~/w3]$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/user/i/innocent/w2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/afs/cern.ch/user/i/innocent/w2
--enable-languages=c,c++,fortran -enable-gold=yes --enable-lto
--with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64
--with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64
--enable-cloog-backend=isl --with-cloog=/usr/local
--with-ppl-lib=/usr/local/lib64 CFLAGS='-O2 -ftree-vectorize -fPIC'
CXXFLAGS='-O2 -fPIC -ftree-vectorize -fvisibility-inlines-hidden -march=native'
-enable-libitm -disable-multilib
Thread model: posix
gcc version 4.8.0 20120504 (experimental) [trunk revision 187149] (GCC)

[Bug target/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload

[ebotcazou at gcc dot gnu.org]

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

--- Comment #25 from Eric Botcazou  2012-05-04 
11:13:26 UTC ---
Author: ebotcazou
Date: Fri May  4 11:13:20 2012
New Revision: 187152

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187152
Log:
PR target/48496
* recog.c (constrain_operands): If extra constraints are present, also
accept pseudo-registers with equivalent memory locations during reload.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/ia64/pr48496.c
  - copied unchanged from r187150,
trunk/gcc/testsuite/gcc.target/ia64/pr48496.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/ia64/pr52657.c
  - copied unchanged from r187150,
trunk/gcc/testsuite/gcc.target/ia64/pr52657.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/recog.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug target/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #26 from Eric Botcazou  2012-05-04 
11:21:17 UTC ---
At long last.

[Bug c++/53152] In "no match for operatorXX" error message gives the wrong column info

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC|lopezibanez at gmail dot|manu at gcc dot gnu.org
   |com |

--- Comment #4 from Manuel López-Ibáñez  2012-05-04 
11:27:15 UTC ---
(In reply to comment #3)
> How could we in principle fix this? Pass down from cp_parser_binary_expression
> the location of the operator token, through build_x_binary_op -> build_new_op
> -> build_new_op_1 -> op_error? Boring but straightforward. Or something else
> entirely? I'm just guessing, really.

Since we don't pass down the expression itself, I don't see any other way than
passing down the location. In general almost all build_* function should be
build_*(location_t loc,...). Thanks for doing this, it will improve the caret a
lot (and perhaps the debugging experience).

[Bug tree-optimization/53168] ICE in find_or_generate_expression, at tree-ssa-pre.c:3053

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-05-04 
11:30:39 UTC ---
Author: rguenth
Date: Fri May  4 11:30:35 2012
New Revision: 187153

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187153
Log:
2012-05-04  Richard Guenther  

PR tree-optimization/53168
* tree-ssa-pre.c (phi_translate_1): Only handle type-punned
memory reads when the result is a constant we can pun.

* gcc.dg/torture/pr53168.c: New testcase.
* gcc.dg/tree-ssa/ssa-pre-30.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr53168.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-30.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug lto/53214] [lto]: ICE: munmap_chunk(): invalid pointer

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Guenther  2012-05-04 
11:34:31 UTC ---
Fixed for 4.7.1.

[Bug tree-optimization/53168] ICE in find_or_generate_expression, at tree-ssa-pre.c:3053

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Richard Guenther  2012-05-04 
11:35:25 UTC ---
Fixed.

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-04
 AssignedTo|unassigned at gcc dot   |ubizjak at gmail dot com
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #4 from Uros Bizjak  2012-05-04 11:37:48 
UTC ---
Created attachment 27305
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27305
Proposed patch

Untested patch that changes TARGET_CMOVE test.

[Bug preprocessor/53229] New: macro unwinder for preprocessing errors

[manu at gcc dot gnu.org]

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

 Bug #: 53229
   Summary: macro unwinder for preprocessing errors
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


struct x {
  int i;
};
struct x x;

#define TEST(X) x.##X

void foo (void)
{
  TEST(i) = 0;
}

manuel@gcc12:~$ ~/trunk/187148M/build/gcc/cc1 test.c
 foo
test.c: In function ‘foo’:
test.c:10:1: error: pasting "." and "i" does not give a valid preprocessing
token
   TEST(i) = 0;
 ^

manuel@gcc12:~$ clang test.c
test.c:10:3: error: pasting formed '.i', an invalid preprocessing token
  TEST(i) = 0;
  ^
test.c:6:19: note: expanded from macro 'TEST'
#define TEST(X) x.##X
  ^

GCC should say:

test.c:6:19: error: pasting "." and "i" does not give a valid preprocessing
token (did you mean 'x.X'?)
#define TEST(X) x.##X
  ^
test.c:10:3: note: in expansion of macro 'TEST' requested here
  TEST(i) = 0;
  ^

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-05-04 
11:44:02 UTC ---
I can confirm the patch works though I don't trivially see how it fixes the
interaction with the option save/restore code ;)

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Guenther  2012-05-04 
11:47:10 UTC ---
Author: rguenth
Date: Fri May  4 11:47:06 2012
New Revision: 187155

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187155
Log:
2012-05-04  Richard Guenther  

PR lto/50602
* lto-wrapper.c (merge_and_complain): Complain about mismatches
of -freg-struct-return and -fpcc-struct-return.
(run_gcc): Pass through -freg-struct-return and -fpcc-struct-return
from the input file options and ignore those from the link
command line.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-wrapper.c

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Severity|normal  |enhancement

--- Comment #21 from Richard Guenther  2012-05-04 
11:47:55 UTC ---
Fixed on trunk.

[Bug ada/53230] New: s-fileio.adb:308:10: warning: ‘Errno’ may be used uninitialized in this function

[danglin at gcc dot gnu.org]

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

 Bug #: 53230
   Summary: s-fileio.adb:308:10: warning: ‘Errno’ may be used
uninitialized in this function
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu


/home/dave/gnu/gcc/objdir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/
dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.7.
0/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/i
nclude -isystem /home/dave/opt/gnu/gcc/gcc-4.7.0/hppa-linux-gnu/sys-include   
-
c -g -O2   -W -Wall -gnatpg -nostdinc   s-fishfl.ads -o s-fishfl.o
s-fileio.adb: In function ‘System.File_Io.Close’:
s-fileio.adb:308:10: warning: ‘Errno’ may be used uninitialized in this
function
 [-Wmaybe-uninitialized]
  Raise_Device_Error (null, Errno);
  ^

[Bug other/53231] New: libatomic/tas_n.c:100:10: error: 'ret' undeclared (first use in this function)

[danglin at gcc dot gnu.org]

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

 Bug #: 53231
   Summary: libatomic/tas_n.c:100:10: error: 'ret' undeclared
(first use in this function)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu


/bin/bash ./libtool --tag=CC   --mode=compile
/home/dave/gnu/gcc/objdir/./gcc/xg
cc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-li
nux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/lib/ -isystem
/ho
me/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/include -isystem
/home/dave/opt/gnu
/gcc/gcc-4.8.0/hppa-linux-gnu/sys-include-DHAVE_CONFIG_H
-I../../../gcc/liba
tomic/config/posix -I../../../gcc/libatomic -I.-Wall -Werror  -pthread -g
-O
2 -MT tas_1_.lo -MD -MP -MF .deps/tas_1_.lo.Ppo -DN=1  -c -o tas_1_.lo
../../../
gcc/libatomic/tas_n.c
yes
checking for struct stat.st_blocks... libtool: compile: 
/home/dave/gnu/gcc/objd
ir/./gcc/xgcc -B/home/dave/gnu/gcc/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.
8.0/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/lib/
-
isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/include -isystem
/home/d
ave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/sys-include -DHAVE_CONFIG_H
-I../../../
gcc/libatomic/config/posix -I../../../gcc/libatomic -I. -Wall -Werror -pthread
-
g -O2 -MT tas_1_.lo -MD -MP -MF .deps/tas_1_.lo.Ppo -DN=1 -c
../../../gcc/libato
mic/tas_n.c  -fPIC -DPIC -o .libs/tas_1_.o
../../../gcc/libatomic/tas_n.c: In function 'libat_test_and_set_1':
../../../gcc/libatomic/tas_n.c:100:10: error: 'ret' undeclared (first use in
thi
s function)
   return ret != 0;
  ^
../../../gcc/libatomic/tas_n.c:100:10: note: each undeclared identifier is
repor
ted only once for each function it appears in
   return ret != 0;
  ^
../../../gcc/libatomic/tas_n.c:88:17: error: unused variable 'newval'
[-Werror=unused-variable]
   UTYPE oldval, newval;
 ^
../../../gcc/libatomic/tas_n.c:88:9: error: variable 'oldval' set but not used
[-Werror=unused-but-set-variable]
   UTYPE oldval, newval;
 ^
../../../gcc/libatomic/tas_n.c:101:1: error: control reaches end of non-void
function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
make[4]: *** [tas_1_.lo] Error 1
make[4]: Leaving directory `/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic'
make[1]: *** [all-target-libatomic] Error 2
make[1]: *** Waiting for unfinished jobs

[Bug other/53231] libatomic/tas_n.c:100:10: error: 'ret' undeclared (first use in this function)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  2012-05-04 
12:10:17 UTC ---
Also occurs on hppa64-hp-hpux11.11.

[Bug c++/53152] In "no match for operatorXX" error message gives the wrong column info

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  2012-05-04 
12:30:37 UTC ---
Ok, let's do this. I'm attaching a proof-of-concept patch.

[Bug c++/53152] In "no match for operatorXX" error message gives the wrong column info

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2012-05-04 
12:31:23 UTC ---
Created attachment 27306
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27306
POC

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[ubizjak at gmail dot com]

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

--- Comment #6 from Uros Bizjak  2012-05-04 12:46:24 
UTC ---
(In reply to comment #5)
> I can confirm the patch works though I don't trivially see how it fixes the
> interaction with the option save/restore code ;)

It doesn't "fix" anything in option processing code, the patch avoids changing
ix86_arch_features behind option processing back.

[Bug tree-optimization/52633] [4.7/4.8 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)

[uweigand at gcc dot gnu.org]

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

--- Comment #3 from Ulrich Weigand  2012-05-04 
12:46:14 UTC ---
Author: uweigand
Date: Fri May  4 12:46:04 2012
New Revision: 187158

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187158
Log:
gcc/
PR tree-optimization/52633
* tree-vect-patterns.c (vect_vect_recog_func_ptrs): Swap order of
vect_recog_widen_shift_pattern and vect_recog_over_widening_pattern.
(vect_recog_over_widening_pattern): Remove handling of code that was
already detected as over-widening pattern.  Remove special handling
of "unsigned" cases.  Instead, support general case of conversion
of the shift result to another type.

gcc/testsuite/
PR tree-optimization/52633
* gcc.dg/vect/vect-over-widen-1.c: Two patterns should now be
recognized as widening shifts instead of over-widening.
* gcc.dg/vect/vect-over-widen-1-big-array.c: Likewise.
* gcc.dg/vect/vect-over-widen-4.c: Likewise.
* gcc.dg/vect/vect-over-widen-4-big-array.c: Likewise.
* gcc.target/arm/pr52633.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr52633.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-1-big-array.c
trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-4-big-array.c
trunk/gcc/testsuite/gcc.dg/vect/vect-over-widen-4.c
trunk/gcc/tree-vect-patterns.c

[Bug tree-optimization/52633] [4.7/4.8 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Ulrich Weigand  2012-05-04 
12:49:02 UTC ---
Fixed.

[Bug target/52908] xop-mul-1:f9 miscompiled on bulldozer (-mxop)

[ubizjak at gmail dot com]

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

--- Comment #5 from Uros Bizjak  2012-05-04 12:51:49 
UTC ---
(In reply to comment #4)

> A Quick make check on i386.exp result is shown below: 
> 
> Tests that now fail, but worked before:
> 
> gcc.target/i386/xop-imul32widen-vector.c scan-assembler vpmacsdql

This is expected, there is no need to emit vpmacsdql, IMO vpmuldq works as good
(if not even better, since we don't have to preload accumulator with zero). The
test should be either changed to really emit vpmacsdql, or asm scan should be
adjusted.

> Tests that now work, but didn't before:
> 
> gcc.target/i386/xop-mul-1.c execution test

Yes this one should be fixed with the patch.

If the change vmpacsdql -> vpmuldq is OK with you, I can commit the patch, but
I'd ask you for full bootstrap/regression test.

[Bug c/53232] New: No warning for main() without a return statement with -std=c99

[vincent-gcc at vinc17 dot net]

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

 Bug #: 53232
   Summary: No warning for main() without a return statement with
-std=c99
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincent-...@vinc17.net


On the following program, GCC (4.4 to 4.7 at least) invoked with -std=c99
-Wreturn-type doesn't give a warning about the missing return statement.

#include 

static int i = 0;

int main (void)
{
  if (i++ == 0)
printf ("%d\n", main ());
}

According to the C99 rules, it seems that the return statement is optional only
for program termination. Though this is ambiguous, someone else at least has
the same interpretation as me:

  http://groups.google.com/group/comp.std.c/msg/c2f56fecfb699952

Before seeing this message, I posted

 
http://groups.google.com/group/comp.std.c/browse_thread/thread/0187ef7b23bedf16

to comp.std.c (Subject: main function without a return statement in C99/C11).

Also, I think that the warning should be given in every case for the following
reasons:
* A missing return statement may be unintentional (I think that implicit values
like here should be discouraged in general, and that the C99 rule is there more
to avoid undefined behavior than to save space).
* Compatibility with C90 and with freestanding environments.
* It is difficult to guarantee that main() will not be called from another C
file.

[Bug lto/42613] -save-temps doesn't work completely for -fwhopr

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-05-04 
13:07:05 UTC ---
-save-temps will only send files to /tmp if you do not provide a linker output
name.  Otherwise the ltrans files are named after that output.

So I belive this is fixed, no?

[Bug tree-optimization/52633] [4.7/4.8 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to work||4.8.0
 Resolution|FIXED   |
  Known to fail||4.7.0

--- Comment #5 from Richard Guenther  2012-05-04 
13:11:53 UTC ---
Please also fix the 4.7 branch.

[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin  2012-05-04 
13:19:07 UTC ---
Compiler does not simply see such code, it happens after some analysis, right?
For example, after work of infer_loop_bounds_from_undefined which makes some
assumptions and I believe can produce some information for user.

Again, I'm worrying about all this from user-perspective and especially after
discovering 2 such things in spec2006 sources(PR53086 and PR53073).

Interesting, could people have problems with SPEC results reporting since they
have to modify sources for this?

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #4 from Martin Husemann  2012-05-04 
13:27:37 UTC ---
Created attachment 27307
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27307
intermediate file when compiling regcomp.c

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #5 from Martin Husemann  2012-05-04 
13:29:45 UTC ---
Using built-in specs.
COLLECT_GCC=cc
Target: sparc64--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=sparc64--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/Misc/send-pr.html --with-pkgversion='NetBSD
nb2 20111202' --enable-__cxa_atexit
--with-mpc=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr
--with-mpfr=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr
--with-gmp=/var/obj/mknative/sparc64/usr/src/destdir.sparc64/usr --enable-tls
--disable-multilib --disable-symvers --disable-libstdcxx-pch
--build=x86_64-unknown-netbsd6.0 --host=sparc64--netbsd
Thread model: posix
gcc version 4.5.3 (NetBSD nb2 20110806) 

NetBSD thirdstage.duskware.de 6.99.6 NetBSD 6.99.6 (MODULAR) #37: Thu May  3
10:33:30 CEST 2012 
mar...@night-porter.duskware.de:/usr/src/sys/arch/sparc64/compile/MODULAR
sparc64

Command line used:
gcc -DPERL_CORE -c -O2 -pipe -pthread -g -O2 -I/usr/include
-fno-strict-aliasing -fstack-protector -I/usr/pkg/include  -std=c89 -O2 -pipe 
-pthread  -g -O2 -I/usr/include  -Wall -ansi -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wc++-compat -Wwrite-strings 


I will try to create a smaller test case to reproduce it, but is not easy.

[Bug middle-end/53217] [4.8 Regression] internal compiler error: verify_ssa failed

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |wschmidt at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from William J. Schmidt  2012-05-04 
13:35:32 UTC ---
Investigating.

[Bug lto/53195] [4.8 Regression] ICE seg fault in lto

[vincenzo.innocente at cern dot ch]

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

vincenzo Innocente  changed:

   What|Removed |Added

  Attachment #27289|0   |1
is obsolete||

--- Comment #4 from vincenzo Innocente  
2012-05-04 13:44:14 UTC ---
Created attachment 27308
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27308
directory with three source files from real-life code after pre-processor

[Bug c/53232] No warning for main() without a return statement with -std=c99

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  2012-05-04 
13:44:02 UTC ---
Neither -Wmain warns about this... I think it is a bug, at least in the case of
-Wmain.

[Bug lto/53214] [lto]: ICE: munmap_chunk(): invalid pointer

[vincenzo.innocente at cern dot ch]

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

--- Comment #5 from vincenzo Innocente  
2012-05-04 14:12:39 UTC ---
confirmed solved.

for the records:  
gcc version 4.7.1 20120504 (prerelease) [gcc-4_7-branch revision 187154] (GCC) 
with lto 
we are left  now with just one ice (PR53195) on about 800 shared-libs from
~400MB of source code (w/o external includes)


On 4 May, 2012, at 1:34 PM, rguenth at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53214
> 
> Richard Guenther  changed:
> 
>   What|Removed |Added
> 
> Status|ASSIGNED|RESOLVED
> Resolution||FIXED
>   Target Milestone|--- |4.7.1
> 
> --- Comment #4 from Richard Guenther  2012-05-04 
> 11:34:31 UTC ---
> Fixed for 4.7.1.
> 
> --

[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Target|i686-pc-linux-gnu   |
 CC||dseketel at redhat dot com
  Component|target  |c++
Summary|[4.8 Regression] tree check |[4.7/4.8 Regression] tree
   |ICE: expected tree_vec, |check ICE: expected
   |have error_mark in  |tree_vec, have error_mark
   |comp_template_args_with_inf |in
   |o, at cp/pt.c:7038  |comp_template_args_with_inf
   ||o, at cp/pt.c:7038

--- Comment #3 from H.J. Lu  2012-05-04 14:32:12 
UTC ---
The failure is the same as

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53177#c4

and also happens on 4.7.  It is caused by revision 181118:

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

[Bug c/53232] No warning for main() without a return statement with -std=c99

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-05-04 
14:33:53 UTC ---
(In reply to comment #1)
> Neither -Wmain warns about this... I think it is a bug, at least in the case 
> of
> -Wmain.

Why? -Wmain checks the type of main, not whether it has a redundant 'return 0;'
as the last statement.

[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-05-04 
14:38:17 UTC ---
Hey HJ, is your regression hunting machine back to life?

[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2012-05-04 14:42:08 
UTC ---
(In reply to comment #4)
> Hey HJ, is your regression hunting machine back to life?

Yes.

[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  2012-05-04 
14:55:49 UTC ---
It seems to me that Alexandre has posted a patch to address this
issue:

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

Hm, it does seem far more probable that the problem is caused by
revision 181118 rather than 186789 as I stated in the bug summary, but
I have double checked that yesterday (on gcc45 on compile farm).
Strange.

[Bug tree-optimization/52633] [4.7/4.8 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)

[uweigand at gcc dot gnu.org]

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

--- Comment #6 from Ulrich Weigand  2012-05-04 
14:56:52 UTC ---
Author: uweigand
Date: Fri May  4 14:56:48 2012
New Revision: 187162

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187162
Log:
2012-05-04  Ulrich Weigand  

 Backport from mainline:

 2012-05-04  Ulrich Weigand  

 PR tree-optimization/52633
 * tree-vect-patterns.c (vect_vect_recog_func_ptrs): Swap order of
 vect_recog_widen_shift_pattern and vect_recog_over_widening_pattern.
 (vect_recog_over_widening_pattern): Remove handling of code that was
 already detected as over-widening pattern.  Remove special handling
 of "unsigned" cases.  Instead, support general case of conversion
 of the shift result to another type.

 2012-05-04  Ulrich Weigand  

 * tree-vect-patterns.c (vect_single_imm_use): New function.
 (vect_recog_widen_mult_pattern): Use it instead of open-coding loop.
 (vect_recog_over_widening_pattern): Likewise.
 (vect_recog_widen_shift_pattern): Likewise.

 2012-04-10  Ulrich Weigand  

 PR tree-optimization/52870
 * tree-vect-patterns.c (vect_recog_widen_mult_pattern): Verify that
 presumed pattern statement is within the same loop or basic block.

2012-05-04  Ulrich Weigand  

 Backport from mainline:

 2012-05-04  Ulrich Weigand  

 PR tree-optimization/52633
 * gcc.dg/vect/vect-over-widen-1.c: Two patterns should now be
 recognized as widening shifts instead of over-widening.
 * gcc.dg/vect/vect-over-widen-1-big-array.c: Likewise.
 * gcc.dg/vect/vect-over-widen-4.c: Likewise.
 * gcc.dg/vect/vect-over-widen-4-big-array.c: Likewise.
 * gcc.target/arm/pr52633.c: New test.

 2012-04-10  Ulrich Weigand  

 PR tree-optimization/52870
 * gcc.dg/vect/pr52870.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/pr52870.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/arm/pr52633.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
   
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-1-big-array.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-1.c
   
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-4-big-array.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-4.c
branches/gcc-4_7-branch/gcc/tree-vect-patterns.c

[Bug tree-optimization/52870] ICE during SLP pattern matching

[uweigand at gcc dot gnu.org]

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

--- Comment #6 from Ulrich Weigand  2012-05-04 
14:56:52 UTC ---
Author: uweigand
Date: Fri May  4 14:56:48 2012
New Revision: 187162

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187162
Log:
2012-05-04  Ulrich Weigand  

 Backport from mainline:

 2012-05-04  Ulrich Weigand  

 PR tree-optimization/52633
 * tree-vect-patterns.c (vect_vect_recog_func_ptrs): Swap order of
 vect_recog_widen_shift_pattern and vect_recog_over_widening_pattern.
 (vect_recog_over_widening_pattern): Remove handling of code that was
 already detected as over-widening pattern.  Remove special handling
 of "unsigned" cases.  Instead, support general case of conversion
 of the shift result to another type.

 2012-05-04  Ulrich Weigand  

 * tree-vect-patterns.c (vect_single_imm_use): New function.
 (vect_recog_widen_mult_pattern): Use it instead of open-coding loop.
 (vect_recog_over_widening_pattern): Likewise.
 (vect_recog_widen_shift_pattern): Likewise.

 2012-04-10  Ulrich Weigand  

 PR tree-optimization/52870
 * tree-vect-patterns.c (vect_recog_widen_mult_pattern): Verify that
 presumed pattern statement is within the same loop or basic block.

2012-05-04  Ulrich Weigand  

 Backport from mainline:

 2012-05-04  Ulrich Weigand  

 PR tree-optimization/52633
 * gcc.dg/vect/vect-over-widen-1.c: Two patterns should now be
 recognized as widening shifts instead of over-widening.
 * gcc.dg/vect/vect-over-widen-1-big-array.c: Likewise.
 * gcc.dg/vect/vect-over-widen-4.c: Likewise.
 * gcc.dg/vect/vect-over-widen-4-big-array.c: Likewise.
 * gcc.target/arm/pr52633.c: New test.

 2012-04-10  Ulrich Weigand  

 PR tree-optimization/52870
 * gcc.dg/vect/pr52870.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/pr52870.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/arm/pr52633.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
   
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-1-big-array.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-1.c
   
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-4-big-array.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/vect/vect-over-widen-4.c
branches/gcc-4_7-branch/gcc/tree-vect-patterns.c

[Bug tree-optimization/52633] [4.7/4.8 Regression] Compiler ICE in vect_is_simple_use_1 (ARM)

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Ulrich Weigand  2012-05-04 
14:59:23 UTC ---
Backported to 4.7.  (This incidentally also fixes PR 52870, even though we
don't have a test case exposing that problem on 4.7 ...)

[Bug c++/53166] static_assert produces bogus warning

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2012-05-04 15:02:10 UTC ---
Author: paolo
Date: Fri May  4 15:02:05 2012
New Revision: 187165

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187165
Log:
/cp
2012-05-04  Paolo Carlini  

PR c++/53166
* pt.c (instantiate_class_template_1): Increase / decrease
c_inhibit_evaluation_warnings around the tsubst_expr call
for STATIC_ASSERT_CONDITION.
(tsubst_expr, case STATIC_ASSERT): Likewise.
* typeck.c (cp_build_binary_op, case EQ_EXPR/NE_EXPR): Check
c_inhibit_evaluation_warnings in the OPT_Waddress warnings.

/testsuite
2012-05-04  Paolo Carlini  

PR c++/53166
* g++.dg/cpp0x/static_assert7.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/static_assert7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/53166] static_assert produces bogus warning

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2012-05-04 
15:03:17 UTC ---
Fixed for 4.8.0.

[Bug c/53232] No warning for main() without a return statement with -std=c99

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2012-05-04 
15:28:55 UTC ---
(In reply to comment #2)
> Why? -Wmain checks the type of main, not whether it has a redundant 'return 
> 0;'
> as the last statement.

You are right, I misread the description. 

So this is not a bug because Wreturn-type says that it specifically does not
check main?

[Bug c/53232] No warning for main() without a return statement with -std=c99

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-05-04 
15:38:22 UTC ---
I think -Wreturn-type says in C++ it doesn't warn about declaring:
   main() {}
with no return type.  That only applies to C++, so isn't relevant here.

IMHO this isn't a bug because in C99 it's well-defined what happens if you fall
off the end of main, so it would annoy people to issue a warning on perfectly
valid code whenever -Wall is enabled.

But then I rarely use C99 so I don't really care.   If anyone suggested warning
for C++ programs that fall off the end of main I would be upset :)
The fact people might call main() from other functions is a sort-of-convincing
argument to warn about it (calling main isn't allowed in C++).

[Bug c/53232] No warning for main() without a return statement with -std=c99

[vincent-gcc at vinc17 dot net]

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

--- Comment #5 from Vincent Lefèvre  2012-05-04 
15:44:04 UTC ---
(In reply to comment #4)
> IMHO this isn't a bug because in C99 it's well-defined what happens if you 
> fall
> off the end of main,

Only at program termination (if my interpretation of C99 is correct). Please
read again the bug report and the links.

> so it would annoy people to issue a warning on perfectly valid code
> whenever -Wall is enabled.

Well, GCC has various warnings on perfectly valid code, just because the code
is suspicious. This is the case here too. And there are potential portability
problems (not everyone may use a C99 compiler). So, good reasons to issue a
warning.

[Bug rtl-optimization/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4

[uweigand at gcc dot gnu.org]

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

--- Comment #2 from Ulrich Weigand  2012-05-04 
16:03:35 UTC ---
Why do you consider this a reload/RA problem?  Code before ira looks like:

(insn 2 4 3 2 (set (reg/v:DI 62 [ i ])
(mem/c:DI (reg/f:SI 16 argp) [2 i+0 S8 A32])) test.i:6 63
{*movdi_internal}
 (expr_list:REG_EQUIV (mem/c:DI (reg/f:SI 16 argp) [2 i+0 S8 A32])
(nil)))

(insn 8 7 9 2 (clobber (reg:DI 60 [ D.1367 ])) test.i:7 -1
 (nil))

(insn 9 8 10 2 (set (subreg:SI (reg:DI 60 [ D.1367 ]) 0)
(bswap:SI (subreg:SI (reg/v:DI 62 [ i ]) 4))) test.i:7 719
{*bswapsi2_movbe}
 (nil))

(insn 10 9 11 2 (set (subreg:SI (reg:DI 60 [ D.1367 ]) 4)
(bswap:SI (subreg:SI (reg/v:DI 62 [ i ]) 0))) test.i:7 719
{*bswapsi2_movbe}
 (expr_list:REG_DEAD (reg/v:DI 62 [ i ])
(nil)))

(insn 11 10 0 2 (set (mem/c:DI (symbol_ref:SI ("x") [flags 0x40]  ) [2 x+0 S8 A64])
(reg:DI 60 [ D.1367 ])) test.i:7 63 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 60 [ D.1367 ])
(nil)))

with the memory accesses both in DImode, but the bswap already split into
SImode.  This causes the two DImode registers to be live at the same time, so
RA cannot allocate the same register for both.

Given the limited register availability on i386, which allocation would you
have suggested instead?

[ Note that I'd consider this a case where the moves certainly *ought* to have
been split into SImode, because:
- on i386 the moves will be split later on anyway
- accesses to subregs of the registers being moved already happens elsewhere. ]

[Bug c/53232] No warning for main() without a return statement with -std=c99

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-05-04 
16:09:40 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > IMHO this isn't a bug because in C99 it's well-defined what happens if you 
> > fall
> > off the end of main,
> 
> Only at program termination (if my interpretation of C99 is correct). Please
> read again the bug report and the links.

I did. Please read the last sentence of comment 4.

> > so it would annoy people to issue a warning on perfectly valid code
> > whenever -Wall is enabled.
> 
> Well, GCC has various warnings on perfectly valid code, just because the code
> is suspicious. This is the case here too.

Yes, and in each case some people want it and some don't.  I'm pointing out to
Manu the reasons not everyone wants the warning.  Your opinion isn't the only
valid one.

> And there are potential portability
> problems (not everyone may use a C99 compiler). So, good reasons to issue a
> warning.

Er, if you want to find portability problems for people not using C99 then
don't use -std=c99. Then -Wreturn-type warns about main.

[Bug fortran/47659] -Wconversion[-extra] should emit warning for constant expressions

[david.folkner at gmail dot com]

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

David Folkner  changed:

   What|Removed |Added

 CC||david.folkner at gmail dot
   ||com

--- Comment #8 from David Folkner  2012-05-04 
16:10:58 UTC ---
Would it be possible to generate a warning for the following cases:

Case (1) - Line 2
real(8)::a
a = 0.13

Case (2) - Line 2
real(4)::a
a = 0.13_8

Case (3) - Line 3
real(8)::a,b
a = 0.13_8
b = a/0.13

Case (4) - Line 4
real(8)::a
integer::b
b = 2
a = 0.5_8*b

[Bug c/53232] No warning for main() without a return statement with -std=c99

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|minor   |enhancement

--- Comment #7 from Jonathan Wakely  2012-05-04 
16:11:35 UTC ---
Changing to "enhancement" since the current behaviour is by design, not a bug.

[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  2012-05-04 
16:15:09 UTC ---
(In reply to comment #6)
> Compiler does not simply see such code, it happens after some analysis, right?
> For example, after work of infer_loop_bounds_from_undefined which makes some
> assumptions and I believe can produce some information for user.

My understanding is that this is non-trivial to do from within the current
passes because "undefined" in that context does not mean "this code is wrong"
but "we don't know what happens here but we can assume what doesn't happen". So
perhaps a new pass looking specifically for infinite loops could be more
effective.

In any case, if you know how to do it, please propose a patch, so people can
discuss it. If there is way to warn for this that doesn't generate an awful
number of false positives, I think such patch would be very welcome.

> Again, I'm worrying about all this from user-perspective and especially after
> discovering 2 such things in spec2006 sources(PR53086 and PR53073).

I think there is no discussion about whether GCC would like to have such a
warning. What is not clear is the best way to do it. So please, test your ideas
and send a prototype of your patch for discussion. People are more likely to
give you feedback when there is something concrete to discuss about.

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[andyg1001 at hotmail dot co.uk]

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

--- Comment #3 from andyg1001 at hotmail dot co.uk 2012-05-04 16:22:21 UTC ---
This ICE still occurs in the release version of gcc 4.7.0.

Here is the output from compiling the attached test-case as is:

$ g++-4.7 -std=c++11 ice.cpp
ice.cpp: In instantiation of ‘struct Z’:
ice.cpp:39:33:   required from here
ice.cpp:11:41: internal compiler error: in finish_decltype_type, at
cp/semantics.c:5277
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccPyRnUB.out file, please attach this to
your bugreport.

And if the lines in the test-case marked "ICE" are commented out, then this is
the output:

$ g++-4.7 -std=c++11 ice.cpp
ice.cpp:47:1: error: non-constant condition for static assertion
ice.cpp:47:43: error: expression ‘b<10>’ does not designate a constexpr
function
ice.cpp:48:1: error: non-constant condition for static assertion
ice.cpp:48:43: error: expression ‘b<10>’ does not designate a constexpr
function
ice.cpp:64:1: error: non-constant condition for static assertion
ice.cpp:64:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:65:1: error: non-constant condition for static assertion
ice.cpp:65:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:66:1: error: non-constant condition for static assertion
ice.cpp:66:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:67:1: error: non-constant condition for static assertion
ice.cpp:67:56: error: expression ‘0u’ does not designate a constexpr function
ice.cpp:70:1: error: non-constant condition for static assertion
ice.cpp:70:43: error: expression ‘C::c2’ does not designate a constexpr
function
ice.cpp:71:1: error: non-constant condition for static assertion
ice.cpp:71:43: error: expression ‘C::c2’ does not designate a constexpr
function

The attached test-case compiles and runs successfully under clang with one
small change as shown in this diff (this doesn't affect the test-case under
gcc):

--- ice.cpp
+++ ice.cpp
@@ -53,6 +53,7 @@
 static_assert(Z_>::value() == 10, "oops");// ICE

 constexpr struct C {
+constexpr C() = default;
 constexpr int c1() const { return 10; }
 static constexpr int c2() { return 10; }
 } c;

[Bug rtl-optimization/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak  2012-05-04 16:22:57 
UTC ---
(In reply to comment #2)
> Why do you consider this a reload/RA problem?  Code before ira looks like:

Indeed. The bar case works OK since access to memory is already expanded in a
split way:

(insn 5 4 6 3 (set (reg:SI 65)
(mem/c:SI (symbol_ref:SI ("x") [flags 0x40]  ) [2 x+0 S4 A64])) movbe-2.c:15 -1
 (nil))

(insn 6 5 7 3 (set (reg:SI 64)
(bswap:SI (reg:SI 65))) movbe-2.c:15 -1
 (nil))

(insn 7 6 8 3 (set (reg:SI 67)
(mem/c:SI (const:SI (plus:SI (symbol_ref:SI ("x") [flags 0x40] 
)
(const_int 4 [0x4]))) [2 x+4 S4 A32])) movbe-2.c:15 -1
 (nil))

(insn 8 7 9 3 (set (reg:SI 66)
(bswap:SI (reg:SI 67))) movbe-2.c:15 -1
 (nil))

However, reload should notice that memory could be propagated into bswap. I'm
not sure this would fix the problem.

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  
2012-05-04 16:42:39 UTC ---
(In reply to comment #3)
> This ICE still occurs in the release version of gcc 4.7.0.

And also in 4.8.0 HEAD btw.

> The attached test-case compiles and runs successfully under clang with one
> small change as shown in this diff (this doesn't affect the test-case under
> gcc):
> 
> --- ice.cpp
> +++ ice.cpp
> @@ -53,6 +53,7 @@
>  static_assert(Z_>::value() == 10, "oops");// ICE
> 
>  constexpr struct C {
> +constexpr C() = default;
>  constexpr int c1() const { return 10; }
>  static constexpr int c2() { return 10; }
>  } c;

These changes are necessary for any reasonable comparison.

It seems to me that we have at least two compiler bugs here. 

1) The ICE
2) The incorrect diagnostics of some non-constexpr function.

The latter error reminds me very much of bug 52892 where it became clear that
gcc can loose constexpr information when typedefs and template parameters are
inserted.

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org 2012-05-04 16:42:32 UTC ---
Author: uros
Date: Fri May  4 16:42:23 2012
New Revision: 187168

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187168
Log:
PR target/53228
* config/i386/i386.h (X86_ARCH_CMOV): Rename from X86_ARCH_CMOVE.
(TARGET_CMOV): Rename from TARGET_CMOVE.
(TARGET_CMOVE): New define.
* config/i386/i386.c (ix86_option_override_internal): Use TARGET_CMOV.
Do not set TARGET_CMOVE here.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h

[Bug rtl-optimization/53227] [4.8 Regression] FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4

[uweigand at gcc dot gnu.org]

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

--- Comment #4 from Ulrich Weigand  2012-05-04 
16:56:59 UTC ---
(In reply to comment #3)
> However, reload should notice that memory could be propagated into bswap.

Since register allocation already assigned a hard reg to the pseudo, reload is
happy.  Reload doesn't generally attempt to go back and search for whether the
value is also available in memory (unless it has to ...).

In general, it is preferable for earlier passes to leave an operand as MEM (if
an insn accepts memory operands in some alternative), so that reload can then
make the decision whether to use the MEM or to reload into a register.

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org 2012-05-04 16:58:21 UTC ---
Author: uros
Date: Fri May  4 16:58:16 2012
New Revision: 187169

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187169
Log:
Backport from mainline
2012-05-04  Uros Bizjak  

PR target/53228
* config/i386/i386.h (X86_ARCH_CMOV): Rename from X86_ARCH_CMOVE.
(TARGET_CMOV): Rename from TARGET_CMOVE.
(TARGET_CMOVE): New define.
* config/i386/i386.c (ix86_option_override_internal): Use TARGET_CMOV.
Do not set TARGET_CMOVE here.


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/i386.c
branches/gcc-4_7-branch/gcc/config/i386/i386.h

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org 2012-05-04 17:49:00 UTC ---
Author: uros
Date: Fri May  4 17:48:56 2012
New Revision: 187171

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187171
Log:
Backport from mainline
2012-05-04  Uros Bizjak  

PR target/53228
* config/i386/i386.h (X86_ARCH_CMOV): Rename from X86_ARCH_CMOVE.
(TARGET_CMOV): Rename from TARGET_CMOVE.
(TARGET_CMOVE): New define.
* config/i386/i386.c (ix86_option_override_internal): Use TARGET_CMOV.
Do not set TARGET_CMOVE here.


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

[Bug target/53233] New: ICE in extract_insn, at recog.c:2103

[gseanmcg at gmail dot com]

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

 Bug #: 53233
   Summary: ICE in extract_insn, at recog.c:2103
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gsean...@gmail.com


The following error occurs when attempting to compile LibAV
(http://www.libav.org) with -mcpu=power7 on gcc 4.5.3:

/home/mik/src/fate/src/libavcodec/ppc/float_altivec.c: In function
'vector_fmul_window_altivec':
/home/mik/src/fate/src/libavcodec/ppc/float_altivec.c:123:1: error:
unrecognizable insn:
(insn 65 64 66 5 /home/mik/src/fate/src/libavcodec/ppc/float_altivec.c:115 (set
(reg/v:V4SF 156 [ t0 ])
(neg:V4SF (minus:V4SF (mult:V4SF (reg/v:V4SF 153 [ s1 ])
(reg/v:V4SF 149 [ wi ]))
(reg/v:V4SF 155 [ t0 ] -1 (nil))
/home/mik/src/fate/src/libavcodec/ppc/float_altivec.c:123:1: internal compiler
error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

No ICE is present on 4.6.3 or 4.7.0 with the same options.

[Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class

[dimitrisdad at gmail dot com]

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

--- Comment #6 from Thomas W. Lynch  2012-05-04 
18:12:10 UTC ---
>> Part of the type information is the layout inside the class. The operator,
>> which has been copied into the child via inheritance, 
>
>No, inheritance doesn't mean anything is copied into the child, it means the
>function is visible in the scope of the child.

Data type provides information for offsets into fields and the functions that
work on the data. That is not part of the instance, it is separate and
distinct.  It is 'extrinsic' to an instance.

Before an instance is created the _compiler_ does operations on 'data type'. 
In the case of C++ nonvirtual inheritance the compiler copies the parent type
information (data actually), with modifications into the child *type*.  There
are other ways to do inheritance.  This is done at compile time and only
affects the type, not the instance.

So for example, if an parent class has a method, say increment(), that affects
a value to be found in a field at offset, say, 4.  and then that parent method
is inherited into the child, but the inherited field has moved, say now found
at offset 8,  the method is modified to access offset 8 - or to more
technically accurate its type information is modified, the control flow remains
identical. 

So yes, inheritance means a lot of copying and modifications are done to _type_
at _compile_time_.  After all this work is done at compile time, in static
typing, the type is embedded in the generated code, the unresolved part of type
is embedded as symbols to be linked in the link map, and the rest is thrown
away.  For some reason, this embedding for the inherited operator new is
incorrect.

There are phases in a static type compilation process, first the macro
expansion (templates and statics),  then the calculation of offsets for the
type stuff, then then code generation.  Now way down the line after linking and
loading we are running.  That is when our operator new gets called.  By that
time type issues are supposed to be settled - but as the code example reported
shows, for operator new in multiple inheritance with this version of g++ - it
has not been.

About the access - the original poster noted that uninitialized memory was
being used - uninitialized memory is bad to read, it is not bad to write ..
that is how it gets initialized after all.  And in cases of doing heap
management it is convention to put the size of the block above the allocation. 
This code example does that explicitly.   The standard says that the object
exists after new finishes, and this is true even in this example.  But even the
standard new operator writes to the memory it allocates before returning --
check it out, just walk in the debugger you can see it.

If you are going to outlaw writing to memory in new, then you will have to
outlaw the standard new as well.  That said, this code could be implemented by
calculating an offset from the pointer to the malloced block, just as the heap
code does ..

I apologize for the 'nonstandard' report per the a prior post, I will update
that this evening.

[Bug c++/53234] New: [c++0x] unfriendly error message for missing move constructor

[luto at mit dot edu]

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

 Bug #: 53234
   Summary: [c++0x] unfriendly error message for missing move
constructor
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@mit.edu


This code is correctly rejected by gcc 4.7 and up (4.6 incorrectly accepted
it).  The error message confused me for a while, though.

struct move_only
{
  move_only() = default;
  move_only(move_only&&) = default;
  move_only &operator = (move_only&&) = default;
};

struct is_it_moveable
{
  //is_it_moveable() = default;
  //is_it_moveable(is_it_moveable &&) = default;
  ~is_it_moveable();

  move_only mo;
};

int main()
{
  is_it_moveable j;
  is_it_moveable k = (is_it_moveable&&)j;
}

A recent trunk build says:

move.cc: In function ‘int main()’:
move.cc:20:40: error: use of deleted function
‘is_it_moveable::is_it_moveable(const is_it_moveable&)’
   is_it_moveable k = (is_it_moveable&&)j;
^
move.cc:8:8: note: ‘is_it_moveable::is_it_moveable(const is_it_moveable&)’ is
implicitly deleted because the default definition would be ill-formed:
 struct is_it_moveable
^
move.cc:8:8: error: use of deleted function ‘constexpr
move_only::move_only(const move_only&)’
 struct is_it_moveable
^
move.cc:1:8: note: ‘constexpr move_only::move_only(const move_only&)’ is
implicitly declared as deleted because ‘move_only’ declares a move constructor
or move assignment operator
 struct move_only
^

This is, according to the standard, exactly correct.  [class.copy] paragraph 9
says "If the definition of a class X does not explicitly declare a move
constructor, one will be implicitly declared as defaulted if and only if
[condition that does not apply here]."  The note says "When the move
constructor is not implicitly declared or explicitly supplied, expressions that
otherwise would have invoked the move constructor may instead invoke a copy
constructor."

I think the error message could be improved to help C++11 newbies like myself,
though.  An extra line like:

note: is_it_moveable has no move constructor because it has a user-declared
destructor

would be quite friendly.  I spent a while staring at the error, thinking "of
course the copy constructor would be ill-formed.  That's way I called the
*move* constructor, you dummy!"

(FWIW, this change is missing from the 4.7 release notes.  I think it, or
something related, breaks boost 1.47's shared_ptr quite thoroughly.)

[Bug debug/53235] New: [4.8 Regression] 20120504 broke -fdebug-types-section

[jan.kratochvil at redhat dot com]

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

 Bug #: 53235
   Summary: [4.8 Regression] 20120504 broke -fdebug-types-section
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
Target: x86_64-unknown-linux-gnu


PASS: gcc (GCC) 4.7.1 20120504 (prerelease)
FAIL: gcc (GCC) 4.8.0 20120504 (experimental)
(I do not have it here to verify but apparently 4.8.0 20120503 PASSed.)

There are 338 GDB testsuite regressions due to it, one for all:

 p acp->c1
-$9 = (A *) 0x0
-(gdb) PASS: gdb.cp/class2.exp: p acp->c1
+$9 = (struct A *) 0x0
+(gdb) FAIL: gdb.cp/class2.exp: p acp->c1

PASS:
 <2><1ad>: Abbrev Number: 4 (DW_TAG_member)
<1ae>   DW_AT_name: c1
<1b3>   DW_AT_type: <0x203>
<1b7>   DW_AT_data_member_location: 24
 <1><203>: Abbrev Number: 19 (DW_TAG_pointer_type)
<204>   DW_AT_byte_size   : 8
<205>   DW_AT_type: signature: 9f2338a31cdd67b0

FAIL:
 <2><1aa>: Abbrev Number: 4 (DW_TAG_member)
<1ab>   DW_AT_name: c1
<1b0>   DW_AT_type: <0x200>
<1b4>   DW_AT_data_member_location: 24
 <1><200>: Abbrev Number: 9 (DW_TAG_pointer_type)
<201>   DW_AT_byte_size   : 8
<202>   DW_AT_type: <0x21e>
 <1><21e>: Abbrev Number: 17 (DW_TAG_typedef)
<21f>   DW_AT_type: signature: 9f2338a31cdd67b0

<21e> seems to be excessive/redundant.

[Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2012-05-04 
18:31:31 UTC ---
(In reply to comment #6)
> So for example, if an parent class has a method, say increment(), that affects
> a value to be found in a field at offset, say, 4.  and then that parent method
> is inherited into the child, but the inherited field has moved, say now found
> at offset 8,  the method is modified to access offset 8 - or to more
> technically accurate its type information is modified, the control flow 
> remains
> identical. 

No, that's not how it works. If Base::increment() writes to Base::field then it
is always at the same offset into the Base object. Whether that Base object is
a sub-object of another clas is irrelevant.

In your broken example on stackoverflow the "A::operator new" function always
wrote to offset 4 into the A object. When that A object is 4 bytes into a B
object then it writes 4+4=8, but "A::operator new" knows that A::count is 4
bytes into an A, i.e. this+4 where this has type A*


> So yes, inheritance means a lot of copying and modifications are done to 
> _type_
> at _compile_time_.  After all this work is done at compile time, in static
> typing, the type is embedded in the generated code, the unresolved part of 
> type
> is embedded as symbols to be linked in the link map, and the rest is thrown
> away.  For some reason, this embedding for the inherited operator new is
> incorrect.

No, your understanding of how G++ works is incorrect.  That might be a valid
C++ implementation, but it's not how G++ works, and it's certainly not required
to work like that by the standard.

You seem to think that in "A::operator new" the static type of "this" depends
on whether the dynamic type of the object being allocated is A or B.  That's
incorrect.  The static type of "*this" in "A::operator new" is always A, and
that's why your program doesn't work.  When you use "A::operator new" to
allocate a B, the member B::count will be 8 bytes into the allocated memory,
but you cast the memory to (this_type*) i.e. (A*) and then access A::count,
i.e. 4 bytes into the allocated memory.  When you later construct a B at that
location the B::count member is not at the location you thought it was.

[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-05-04 
18:40:51 UTC ---
The ICEs, all of them, in the extended testcase too, seem easy to fix,
apparently it's just that finish_decltype_type doesn't handle ADDR_EXPR. The
remaining issues are more nasty, some can be fixed/wa with STRIP_NOPS, looks
like we have to handle many NOP_EXPRs, something I don't really understand.

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org 2012-05-04 18:43:16 UTC ---
Author: uros
Date: Fri May  4 18:43:10 2012
New Revision: 187172

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187172
Log:
Backport from mainline
2012-05-04  Uros Bizjak  

PR target/53228
* config/i386/i386.h (X86_ARCH_CMOV): Rename from X86_ARCH_CMOVE.
(TARGET_CMOV): Rename from TARGET_CMOVE.
(TARGET_CMOVE): New define.
* config/i386/i386.c (override_options): Use TARGET_CMOV.
Do not set TARGET_CMOVE here.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.c
branches/gcc-4_5-branch/gcc/config/i386/i386.h

[Bug target/53228] [4.6/4.7/4.8 Regression] target attributes in libcpp/lex.c cause illegal instructions to be used elsewhere

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2012-05/msg00360.htm
   ||l
 Resolution||FIXED
   Target Milestone|4.6.4   |4.5.4

--- Comment #11 from Uros Bizjak  2012-05-04 18:45:58 
UTC ---
Fixed everywhere.

[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals

[xinliangli at gmail dot com]

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

davidxl  changed:

   What|Removed |Added

 CC||xinliangli at gmail dot com

--- Comment #3 from davidxl  2012-05-04 18:52:21 
UTC ---
What is the right scope for the compound literals? Is the clobber correctly
added or the program is ill formed?

David

[Bug fortran/53111] [4.7/4.8 Regression] Derived types cannot be USE-associated again with -std=f95

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-05-04 
18:53:23 UTC ---
Author: burnus
Date: Fri May  4 18:53:17 2012
New Revision: 187174

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187174
Log:
2012-05-04  Tobias Burnus  

PR fortran/53111
* resolve.c (resolve_fl_derived): Fix -std=f95
diagnostic for generic vs. DT names.

2012-05-04  Tobias Burnus  

PR fortran/53111
* gfortran.dg/constructor_7.f90: New.
* gfortran.dg/constructor_8.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/constructor_7.f90
trunk/gcc/testsuite/gfortran.dg/constructor_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/53175] [4.8 Regression] link failure for private module variables used in function specification

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-05-04 
18:54:33 UTC ---
Author: burnus
Date: Fri May  4 18:54:25 2012
New Revision: 187175

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187175
Log:
2012-05-04  Tobias Burnus  

PR fortran/53175
* resolve.c (resolve_variable): Set public_used
if a private module variable is used in a (public)
specification expression.
* trans-decl.c (gfc_finish_var_decl): Mark those
TREE_PUBLIC.

2012-05-04  Tobias Burnus  

PR fortran/53175
gfortran.dg/public_private_module_5.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/public_private_module_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class

[dimitrisdad at gmail dot com]

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

--- Comment #8 from Thomas W. Lynch  2012-05-04 
18:57:40 UTC ---
>No, that's not how it works. If Base::increment() writes to Base::field then it
>is always at the same offset into the Base object. Whether that Base object is
>a sub-object of another clas is irrelevant.

I apologize, as I don't know how else to put it but in multiple inheritance
that statement is just plain wrong.  Fields move.  You can see it in the debug
output at the link, the field for 'count' moved by 4 bytes from what it was in
the parent to where it is located in the child.

I should note, also, that C++ uses name mangling to accomplish the effect of
the type modifications I mentioned before.  (I was a user of the original that
made expanded macros into an intermediate directory ;-)  So the manifest
problem, if you could look at the macro output ;-) is probably an operator new
mangled to be a child, but the internal type information still as a parent.

The typedef for 'this_type' in the exmaple is simply a short hand that appears
at the top of each of our templated classes so that there is a shorter name to
use in the code.  'this_type' for class A  is 'class A'   for class B it is
'class B' etc.  It does nothing. Look at the compiling example with the debug
output there that shows the wrong offset, please don't quote the work arounds
proposed as we are talking about the problematic case of course.

[Bug c++/53236] New: using declaration and base function template overloading

[fpelliccioni at gmail dot com]

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

 Bug #: 53236
   Summary: using declaration and base function template
overloading
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fpellicci...@gmail.com


Created attachment 27309
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27309
source code

The code in the attached source file must be rejected according to the 

[namespace.udecl] paragraph 15 (n3290)

When a using-declaration brings names from a base class into a derived class
scope, member functions and
member function templates in the derived class override and/or hide member
functions and member function
templates with the same name, parameter-type-list (8.3.5), cv-qualification,
and ref-qualifier (if any) in a
base class (rather than conflicting).



Tested with:

g++ 4.6.3 - Linux 3.2.0-24 x86
g++ 4.7.1 - Windows7 IA-64


Regards,
Fernando Pelliccioni.
fpellicci...@gmail.com

[Bug target/53233] ICE in extract_insn, at recog.c:2103

[gseanmcg at gmail dot com]

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

--- Comment #1 from Sean McGovern  2012-05-04 
19:00:05 UTC ---
The code in question (with line numbers):

  93 static void vector_fmul_window_altivec(float *dst, const float *src0,
const float *src1, const float *win, int len)

  94 {

  95 vector float zero, t0, t1, s0, s1, wi, wj;

  96 const vector unsigned char reverse = vcprm(3,2,1,0);

  97 int i,j;

  98 

  99 dst += len;

 100 win += len;

 101 src0+= len;

 102 

 103 zero = (vector float)vec_splat_u32(0);

 104 

 105 for(i=-len*4, j=len*4-16; i<0; i+=16, j-=16) {

 106 s0 = vec_ld(i, src0);

 107 s1 = vec_ld(j, src1);

 108 wi = vec_ld(i, win);

 109 wj = vec_ld(j, win);

 110 

 111 s1 = vec_perm(s1, s1, reverse);

 112 wj = vec_perm(wj, wj, reverse);

 113 

 114 t0 = vec_madd(s0, wj, zero);

 115 t0 = vec_nmsub(s1, wi, t0);

 116 t1 = vec_madd(s0, wi, zero);

 117 t1 = vec_madd(s1, wj, t1);

 118 t1 = vec_perm(t1, t1, reverse);

 119 

 120 vec_st(t0, i, dst);

 121 vec_st(t1, j, dst);

 122 }

 123 }

[Bug bootstrap/53237] New: Bootstrap fails due to mixed declarations and code (c-lex.c)

[skunk at iskunk dot org]

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

 Bug #: 53237
   Summary: Bootstrap fails due to mixed declarations and code
(c-lex.c)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org


Building 4.7.0 on Solaris using the Sun compiler...

[...]
cc -xarch=v9 -xildoff -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC   
-DHAVE_CONFIG_H -I. -Ic-family -I/home/src/gcc-4.7.0/gcc
-I/home/src/gcc-4.7.0/gcc/c-family -I/home/src/gcc-4.7.0/gcc/../include
-I/home/src/gcc-4.7.0/gcc/../libcpp/include -I/tg/freeport/arch/sunos64/include
-I/tg/freeport/arch/sunos64/include -I/tg/freeport/arch/sunos64/include 
-I/home/src/gcc-4.7.0/gcc/../libdecnumber
-I/home/src/gcc-4.7.0/gcc/../libdecnumber/dpd -I../libdecnumber   
/home/src/gcc-4.7.0/gcc/c-family/c-lex.c -o c-family/c-lex.o
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 353: syntax error before or
at: char
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 354: undefined symbol: str
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 354: cannot dereference
non-pointer type
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 355: syntax error before or
at: literal
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 357: undefined symbol: literal
"/home/src/gcc-4.7.0/gcc/c-family/c-lex.c", line 357: warning: improper
pointer/integer combination: op "="
cc: acomp failed for /home/src/gcc-4.7.0/gcc/c-family/c-lex.c
gmake[3]: *** [c-family/c-lex.o] Error 2
gmake[3]: Leaving directory `/tmp/gcc-build/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/tmp/gcc-build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/tmp/gcc-build'
gmake: *** [bootstrap-lean] Error 2


The relevant portion of c-lex.c is declaring "char *str" in the middle of an
if{} block.