[Bug middle-end/48432] New: -Wstrict-overflow incorrectly warns for Emacs src/font.c

[eggert at gnu dot org]

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

   Summary: -Wstrict-overflow incorrectly warns for Emacs
src/font.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: egg...@gnu.org


When compiling the GNU Emacs trunk with a GCC 4.6.0 that I built on
RHEL 5.6 (x86-64), I ran into a problem when compiling src/font.c that
I narrowed down to the following stripped-down test case.  When I
compile this test case with

  gcc -S -Wstrict-overflow -O2 f.c

the output is:

  f.c: In function 'font_list_entities':
  f.c:38:35: warning: assuming signed overflow does not occur when simplifying
co
nditional to constant [-Wstrict-overflow]

The warning is incorrect, since signed overflow is impossible here.
There are two 'int' variables, one of which is assigned only 0 or 1,
and the other which is assigned only values ranging from 6 through 12.
Changing either 'int' variable to 'unsigned' makes the warning go away.

I'm not sure whether this bug is the same as earlier bug reports I
filed in this area (PR48228, PR48267), but it's not obviously the same
so I figured I should be safe and file it.  It did take some time to
track down.

-

extern unsigned foo0 (void);
extern unsigned foo2 (unsigned, unsigned);

static unsigned
font_delete_unmatched (unsigned vec, unsigned spec, unsigned int size)
{
  unsigned val = 0;

  while (1)
{
  if (spec)
{
  val = foo2 (vec, val);
  continue;
}
}
  return val;
}

unsigned
font_list_entities (unsigned frame, unsigned spec)
{
  unsigned val = 0;
  int need_filtering = 0;
  int i;

  for (i = 6; i < 13; i++)
{
  if (foo0 ())
need_filtering = 1;
  if (i == 10)
i++;
}

  while (foo0 ())
if (need_filtering)
  val = font_delete_unmatched (val, need_filtering ? spec : 0, 0);
  return 0;
}

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres  
2011-04-04 06:32:26 UTC ---
With the patch in comment #26 on top of revision 171916, bootstrap proceeded up
to pr48403.

[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres  
2011-04-04 06:30:12 UTC ---
Bootstrap comparison failure!
gcc/c-family/c-ada-spec.o differs
gcc/c-family/c-format.o differs
gcc/c-parser.o differs
gcc/cfgexpand.o differs
gcc/cp/parser.o differs
gcc/cse.o differs
gcc/emit-rtl.o differs
gcc/expmed.o differs
gcc/fortran/parse.o differs
gcc/fortran/trans-intrinsic.o differs
gcc/gimplify.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/ifcvt.o differs
gcc/ipa-inline.o differs
gcc/ipa-prop.o differs
gcc/ira-lives.o differs
gcc/java/jcf-parse.o differs
gcc/lto/lto-object.o differs
gcc/lto-streamer-in.o differs
gcc/lto-streamer-out.o differs
gcc/mcf.o differs
gcc/objc/objc-next-runtime-abi-02.o differs
gcc/objcp/objc-next-runtime-abi-02.o differs
gcc/optabs.o differs
gcc/postreload.o differs
gcc/reload.o differs
gcc/rtlanal.o differs
gcc/tree-ssa-coalesce.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/tree-ssa-loop-niter.o differs
libcpp/directives.o differs
libcpp/traditional.o differs
libiberty/cplus-dem.o differs
libiberty/sha1.o differs

on powerpc-apple-darwin9.

[Bug lto/48431] New: patch to fix a compile error in lto-plugin.c when using older C compilers

[williambader at hotmail dot com]

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

   Summary: patch to fix a compile error in lto-plugin.c when
using older C compilers
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: williamba...@hotmail.com


Created attachment 23867
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23867
patch to fix the problem

The build for gcc-4.6.0 gets a compile error on lto-plugin.c on Red Hat Linux
release 7.1 (Seawolf) with gcc version 2.96 2731 because this compiler does
not allow declarations after the first statement.  The attached patch moves a
declaration a few lines back.

For the build, I ran
/u/gnu/gcc-4.6.0/configure --disable-nls --enable-checking=release
--enable-werror=no --with-system-zlib --disable-multilib --with-gmp=/usr/local
--with-mpfr=/usr/local
make CC=gcc 'CFLAGS=-O0  -g -pipe' 'LIBCFLAGS=-O0 ' 'LIBCXXFLAGS=-O0
-fno-implicit-templates ' 'CXXFLAGS=-O0 -fno-implicit-templates '
'CXXFLAGS_FOR_BUILD=-O0 -fno-implicit-templates ' 'CXXFLAGS_FOR_TARGET=-O0
-fno-implicit-templates ' 'GOCFLAGS_FOR_TARGET=-O0  -g -pipe' 'BOOT_CFLAGS= -O0
 -g -pipe' AS=/usr/bin/as bootstrap-lean
Without all of the -O0's, the stage2 xgcc gets an ICE almost immediately on
almost any input.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[froydnj at codesourcery dot com]

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

--- Comment #66 from froydnj at codesourcery dot com  2011-04-04 01:18:59 UTC ---
On Sun, Apr 03, 2011 at 10:09:06AM +, hubicka at gcc dot gnu.org wrote:
> Kind   Nodes  Bytes
> ---
> decls11502734 1829746088
> types4430124  744260832
> blocks 1 88
> stmts  0  0
> refs8173 485872
> exprs2358594  113315792
> constants2245230   86809013
> identifiers   442742   17709680
> vecs   60267  116915440
> binfos   1107669  110741304
> ssa names309  27192
> constructors  3105459937440
> random kinds 10648367  425935048
> lang_decl kinds0  0
> lang_type kinds0  0
> omp clauses0  0
> ---
> Total33114755 -839083507
> ---

Do folks think it would be useful to include a breakdown by individual
TREE_CODE, similar to what's done for RTXes?

[Bug libstdc++/48430] New: std::hash partial specialization for std::unique_ptr and std::shared_ptr are using unary_function

[flast at flast dot jp]

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

   Summary: std::hash partial specialization for std::unique_ptr
and std::shared_ptr are using unary_function
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp


std::hash partial specialization for std::unique_ptr (in bits/unique_ptr.h) and
std::shared_ptr (in bits/shared_ptr.h) using std::unary_function.
However, you should not use it because std::unary_function is deprecated.

[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #8 from dave at hiauly1 dot hia.nrc.ca 2011-04-04 00:34:48 UTC ---
On Sun, 03 Apr 2011, John David Anglin wrote:

> > I guess that the last patch (for pr48380) I sent should solve the problem 
> > too.
> > Unfortunately, I did not get an approval for the patch yet.
> 
> I'll try it if it isn't install by the time I get to a retest.

../../gcc/gcc/ira-emit.c: In function `emit_move_list':
../../gcc/gcc/ira-emit.c:938:8: error: comparison between signed and unsigned
integer expressions [-Werror=sign-compare]

Dave

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[dominiq at lps dot ens.fr]

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

--- Comment #27 from Dominique d'Humieres  
2011-04-03 21:52:57 UTC ---
With the patch in comment #26 on top of revision 171916, I am now at stage 2,
i.e., past the previous failures. Thanks for the perseverance;-)

[Bug fortran/48426] [patch] Quad precision promotion

[jvdelisle at frontier dot com]

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

--- Comment #5 from jvdelisle at frontier dot com 2011-04-03 21:14:41 UTC ---
On 04/03/2011 12:49 PM, inform at tiker dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426
>
> --- Comment #3 from Andreas Kloeckner  2011-04-03 
> 19:49:51 UTC ---
> (In reply to comment #2)
>> There is already -fdefault-real-8, -fdefault-integer-8, and
>> -fdefault-double-8.  This is already 3 too many hacks.  Adding
>> an additional 7 options is 7 too many.
>
>> From a purist perspective, I absolutely gree with you. Practically however,
> in dealing with legacy codes (*), the value of being able to do this should 
> not
> be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu
> have included these flags?
>

Lets take another perspective, different than Steve's comments. Lets assume 
no-one is blindly using the legacy codes with changes in default kinds without 
at least some understanding of the code and knowing what it is doing.  With 
modern editors or scripts, one could modify declarations to use a 
kind=parameter.  This could be done to change REAL to REAL(kind=wp). wp meaning 
working precision.  One could also update real constants to append _wp to them. 
  Then add a use statement at the beginning of each file that sets wp. Several 
different precision parameters could be set up and used in varying places 
depending on the application.  One gets a finer degree of control.

Now I have presented a simplistic example and I am sure the real code may offer 
some additional challenges. But, the net result would be more flexible code
that 
is more portable and the original issue becomes moot.

If ones knowledge of the code is greater then mine it is likely one could see 
more opportunities for improving it with simple changes like this, especially
in 
the code that is critical to the issue.  Once the changes are made, perhaps
even 
incrementally over time in small parts, they never have to be changed back, 
because the code is standard conforming to do so.

Now, we can make arguments to go in either direction; put the burden of 
resolving the issue on the compiler team or put the burden on the 
user/developers.  I think Steve is saying that we have an obligation on the 
compiler side to protect users who may not be as knowledgeable/experienced from 
doing stupid things, whereas someone such as yourself would probably know what 
to be careful of and could avoid it. Providing the adjustable precision on the 
user/developer side assures that it is done carefully and correctly, specific
to 
the application.

Now the flip side is that the less than 100 lines of code patch on the compiler 
side is a lot less effort then perhaps updating the 100,000 lines of legacy 
code. However, the compiler changes affect thousands of users and thousands of 
applications.  That means there is, lets say, 1000 times more risk to the
change 
on the compiler side.  (With no warranty of course).

I am leaning toward we need to err on the conservative side, and let others 
comment from here. We have had these discussions on this topic many times 
before. I don't think there is an easy answer.  My personal preference would be 
to update the user code. (aka software maintenance).

Regards

Re: [Bug fortran/48426] [patch] Quad precision promotion

[Jerry DeLisle]

On 04/03/2011 12:49 PM, inform at tiker dot net wrote:

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

--- Comment #3 from Andreas Kloeckner  2011-04-03 
19:49:51 UTC ---
(In reply to comment #2)

There is already -fdefault-real-8, -fdefault-integer-8, and
-fdefault-double-8.  This is already 3 too many hacks.  Adding
an additional 7 options is 7 too many.



From a purist perspective, I absolutely gree with you. Practically however,

in dealing with legacy codes (*), the value of being able to do this should not
be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu
have included these flags?



Lets take another perspective, different than Steve's comments. Lets assume 
no-one is blindly using the legacy codes with changes in default kinds without 
at least some understanding of the code and knowing what it is doing.  With 
modern editors or scripts, one could modify declarations to use a 
kind=parameter.  This could be done to change REAL to REAL(kind=wp). wp meaning 
working precision.  One could also update real constants to append _wp to them. 
 Then add a use statement at the beginning of each file that sets wp. Several 
different precision parameters could be set up and used in varying places 
depending on the application.  One gets a finer degree of control.


Now I have presented a simplistic example and I am sure the real code may offer 
some additional challenges. But, the net result would be more flexible code that 
is more portable and the original issue becomes moot.


If ones knowledge of the code is greater then mine it is likely one could see 
more opportunities for improving it with simple changes like this, especially in 
the code that is critical to the issue.  Once the changes are made, perhaps even 
incrementally over time in small parts, they never have to be changed back, 
because the code is standard conforming to do so.


Now, we can make arguments to go in either direction; put the burden of 
resolving the issue on the compiler team or put the burden on the 
user/developers.  I think Steve is saying that we have an obligation on the 
compiler side to protect users who may not be as knowledgeable/experienced from 
doing stupid things, whereas someone such as yourself would probably know what 
to be careful of and could avoid it. Providing the adjustable precision on the 
user/developer side assures that it is done carefully and correctly, specific to 
the application.


Now the flip side is that the less than 100 lines of code patch on the compiler 
side is a lot less effort then perhaps updating the 100,000 lines of legacy 
code. However, the compiler changes affect thousands of users and thousands of 
applications.  That means there is, lets say, 1000 times more risk to the change 
on the compiler side.  (With no warranty of course).


I am leaning toward we need to err on the conservative side, and let others 
comment from here. We have had these discussions on this topic many times 
before. I don't think there is an easy answer.  My personal preference would be 
to update the user code. (aka software maintenance).


Regards

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

  Attachment #23860|0   |1
is obsolete||

--- Comment #26 from Richard Henderson  2011-04-03 
21:03:51 UTC ---
Created attachment 23865
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23865
fourth patch

Relative to head, or whatever you patched last time.

[Bug fortran/48426] [patch] Quad precision promotion

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2011-04-03 20:33:12 UTC ---
On Sun, Apr 03, 2011 at 07:49:53PM +, inform at tiker dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426
> 
> --- Comment #3 from Andreas Kloeckner  2011-04-03 
> 19:49:51 UTC ---
> (In reply to comment #2)
> > There is already -fdefault-real-8, -fdefault-integer-8, and
> > -fdefault-double-8.  This is already 3 too many hacks.  Adding
> > an additional 7 options is 7 too many.
> 
> From a purist perspective, I absolutely gree with you. Practically
> however, in dealing with legacy codes (*), the value of being able
> to do this should not be underestimated.  If this was a useless thing
> to do, why would Lahey/Fujitsu have included these flags?
> 
> (*) Let's face it, a big part of Fortran's relevance stems from legacy codes.

This is the number one reason why these options (including the
current 3 [1]) should not be available in any compiler.  Few people
use these types of options for debugging.  Most have a single
precision algorithm, but want a double (or higher) precision
routine.  Instead of actually trying to understand and implement
a proper double (or higher) precision version, people simply use
these types of options without checking the robustness of the 
algorithm.

In glancing at the patch, there are at least two problems.  First,
this chunk 

+  else if (saw_i8 && gfc_option.flag_integer4_kind == 8 )
+{
+  gfc_default_integer_kind = 8;
+
+  /* Even if the user specified that the default integer kind be 8,
+ the numeric storage size isn't 64.  In this case, a warning will
+ be issued when NUMERIC_STORAGE_SIZE is used.  */
+  gfc_numeric_storage_size = 4 * 8;
+}

is simply a bad idea.  If one changes gfc_default_integer_kind to 8,
then the numeric storage size should be updated to 8 * 8.  I suspect
(but haven't checked) that the above breaks not only EQUIVALENCE
and COMMON but several assumptions within libgfortran.  Second, 
this chunk 

+  if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
+{
+  if( ts->kind == 4 && gfc_option.flag_real4_kind ==  8) ts->kind =  8;
+  if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
+  if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
+  if( ts->kind == 8 && gfc_option.flag_real8_kind ==  4) ts->kind =  4;
+  if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
+  if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;

appears to assume that ts->kind=10 and ts->kind=16 are available. 
This may or may not be true depending on the target and the options
used during execution of configure.  One needs to check if 10 and 16
are available.  

> (As an anecdote, I once worked at an unnamed US national lab, and one of my
> group's main reasons *against* adoption of g77 was the absence of
> -fdefault-real-8.)

Hopefully, the unnamed national lab wasn't using options like these 
with critical software without actually checking the robustness of 
the code.

[1] I'm the person who did the initial clean-up of the poorly implemented
-r8, -i8, and -d8 options (See ChangLog-2005).  Others after me fixed my
fixes.  In rectrospect, I wish I had simply removed these options
because the options probably do not do what a user thinks.

[Bug go/48407] libgo/configure --without-libffi doesn't work

[joel at gcc dot gnu.org]

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

--- Comment #3 from Joel Sherrill  2011-04-03 20:25:18 
UTC ---
Sorry.. it was submitted before I was finished...

I have this in my local tree.  I recall Ian and I discussing that since
Go and GCJ both need libffi, the logic should be smarter.  But this works.

I submitted patches to libffi for m68k and mips.  I recall Go built and worked
on at least i386, sparc, mips, powerpc, and arm.   So libffi is OK to enable. 
If libffi doesn't support a particular architecture, then Go and GCJ are not
available on that architecture.

Index: configure.ac
===
--- configure.ac(revision 170678)
+++ configure.ac(working copy)
@@ -618,7 +618,8 @@
 ;;
   *-*-rtems*)
 skipdirs="${skipdirs} target-libiberty"
-noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
+# noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
+noconfigdirs="$noconfigdirs target-libgloss"
 ;;
 # The tpf target doesn't support gdb yet.
   *-*-tpf*)

[Bug go/48407] libgo/configure --without-libffi doesn't work

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 CC||ian at airs dot com, joel
   ||at gcc dot gnu.org

--- Comment #2 from Joel Sherrill  2011-04-03 20:18:00 
UTC ---
This patch is in my local svn tree.  Ian 

Index: configure.ac
===
--- configure.ac(revision 170678)
+++ configure.ac(working copy)
@@ -618,7 +618,8 @@
 ;;
   *-*-rtems*)
 skipdirs="${skipdirs} target-libiberty"
-noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
+# noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
+noconfigdirs="$noconfigdirs target-libgloss"
 ;;
 # The tpf target doesn't support gdb yet.
   *-*-tpf*)

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from Kai Tietz  2011-04-03 20:10:25 
UTC ---
Fixed.

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[ktietz at gcc dot gnu.org]

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

--- Comment #7 from Kai Tietz  2011-04-03 20:09:52 
UTC ---
Author: ktietz
Date: Sun Apr  3 20:09:46 2011
New Revision: 171916

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171916
Log:
2011-04-03  Kai Tietz  

PR middle-end/48422
* Make-lang.in (f95-lang.o): Add some missing dependencies.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/Make-lang.in

[Bug lto/48423] crash when using lto, linker plugin with bfd ld

[vincenzo.innocente at cern dot ch]

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

--- Comment #4 from vincenzo Innocente  
2011-04-03 20:05:37 UTC ---
thanks for the hint.
the version on

http://www.kernel.org/pub/linux/devel/binutils/binutils-2.21.51.0.7.x86_64.tar.bz2
seems to be ok
it also produces (as the one in your branch) a correct stacktrace
the version of gold (ld -v GNU gold (Linux/GNU Binutils 2.21.51.0.7.20110306)
1.11)
instead produced still a corrupted stack trace as in 2.2.1 (see below)
I submitted a bug report to binutil using a different test case. let's see if
there is any feedback on that

vincenzo

from gdb when using gold
---
 b bhook
Function "bhook" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (bhook) pending.
(gdb) run
…..
Breakpoint 1, 0x77ec90e0 in bhook () from ./plugD.so
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.7.el6_0.4.x86_64
(gdb) where
#0  0x77ec90e0 in bhook () from ./plugD.so
#1  0x77ec9199 in global constructors keyed to
65535_0_ccdzuBFD.o.3947.2223 () from ./plugD.so
#2  0x7fffd348 in ?? ()
#3  0x77ec7778 in ?? () from ./plugD.so
#4  0x77ecab60 in __CTOR_LIST__ () from ./plugD.so
#5  0x7fffd310 in ?? ()
#6  0x00403800 in ?? ()
#7  0x77ec92f5 in __do_global_ctors_aux () from ./plugD.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

same using the "new" ld.bfd
Breakpoint 1, 0x778cbfa0 in bhook () from ./plugD.so
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.7.el6_0.4.x86_64
(gdb) where
#0  0x778cbfa0 in bhook () from ./plugD.so
#1  0x778cb889 in global constructors keyed to
65535_0_ccdhvqmO.o.3947.2223 () from ./plugD.so
#2  0x003ff520e3ff in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#3  0x003ff5212b21 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#4  0x003ff520e016 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#5  0x003ff521236a in _dl_open () from /lib64/ld-linux-x86-64.so.2
#6  0x003ff5a00f66 in dlopen_doit () from /lib64/libdl.so.2
#7  0x003ff520e016 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8  0x003ff5a0129c in _dlerror_run () from /lib64/libdl.so.2
#9  0x003ff5a00ee1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#10 0x0040119d in get ()
#11 0x00400e78 in main ()



On 3 Apr, 2011, at 8:06 PM, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48423
> 
> --- Comment #3 from H.J. Lu  2011-04-03 18:06:23 
> UTC ---
> (In reply to comment #2)
>> thanks hl,
>> it looks promising.
>> the thets runs and
>> nm -C -D libBase.o
>> shows
>> 00201140 V typeinfo for Base
>> 0fb3 V typeinfo name for Base
>> like gold
>> 
>> I will test it more tomorrow.
>> Will you merge this in next binutil snapshot?
>> 
> 
> It isn't up to me. But it is in the latest Linux binutils from:
> 
> http://www.kernel.org/pub/linux/devel/binutils/
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2011-04-03 
20:04:49 UTC ---
(In reply to comment #5)
> Yes, there are. I added the most obvious one now to my patch.
[...]
> ok for apply?

OK. I think there are more (esp. for other files), but I think it should cover
the most important omissions. Thanks for the patch!

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

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

--- Comment #3 from Andreas Kloeckner  2011-04-03 
19:49:51 UTC ---
(In reply to comment #2)
> There is already -fdefault-real-8, -fdefault-integer-8, and
> -fdefault-double-8.  This is already 3 too many hacks.  Adding
> an additional 7 options is 7 too many.

>From a purist perspective, I absolutely gree with you. Practically however, 
in dealing with legacy codes (*), the value of being able to do this should not
be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu
have included these flags?

(*) Let's face it, a big part of Fortran's relevance stems from legacy codes.

(As an anecdote, I once worked at an unnamed US national lab, and one of my
group's main reasons *against* adoption of g77 was the absence of
-fdefault-real-8.)

[Bug fortran/48428] New: gfortran internal error

[kristopher.kuhlman at gmail dot com]

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

   Summary: gfortran internal error
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kristopher.kuhl...@gmail.com


Created attachment 23864
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23864
reduced program fortran code that triggers the internal error

I have reduced a fortran program to the attached test case that triggers the
following internal error:

$ gfortran mio_component_ref_error.f90
mio_component_ref_error.f90:45.41:

use elliptical_elements, only : line 
 1
Internal Error at (1):
mio_component_ref(): Component not found

This happens using gfortran 4.5.1, 4.6.0, and the trunk build from yesterday
(4.7).  

The error goes away if you copy the line() function from the
elliptical_elements module into the the solution_mod module and comment out the
use statement on line 45.

Maybe this bug is related to bug 47601?  I am experiencing this problem in
64-bit Ubuntu Linux.

--

I don't know if the following tidbit helps, but while I was cutting the program
down to this test case, I briefly experienced the following different error at
the same location when I eliminated some of the extends() dependencies of one
type on another in the type_definitions module.  I can't seem to reproduce this
different error anymore, though.

gfortran -c  -o solution.o solution.f90
solution.f90:10.41:

use elliptical_elements, only : line 
 1
Internal Error at (1):
free_pi_tree(): Unresolved fixup

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  
2011-04-03 19:27:08 UTC ---
> I wonder if something is un-initialized in ld64 :(

AFAICT the problem occurs for both -m64 and -m32.

[Bug fortran/48426] [patch] Quad precision promotion

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org 2011-04-03 19:25:39 UTC ---
There is already -fdefault-real-8, -fdefault-integer-8, and
-fdefault-double-8.  This is already 3 too many hacks.  Adding
an additional 7 options is 7 too many.

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe  2011-04-03 19:18:31 
UTC ---
(In reply to comment #23)
> ... and if that works, we'll see how much of the other line info
> additions we can put back in.  Assuming you've a modern debugger
> that might be able to use them ...

:( ... not on i686-darwin9.

I assume that patch 3 applies on top of patch 1 - and that it applies to
r171816...

the remaining difference is setting 

.byte0# DW_LNE_set_address
.byte0x9# uleb128 0x9
.byte0x2
.quadLetext0

which, I take it you believe to be superfluous?
(unfortunately, I don't read DWARF bytecode natively ;) ) 

I wonder if something is un-initialized in ld64 :(

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[ktietz at gcc dot gnu.org]

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

--- Comment #5 from Kai Tietz  2011-04-03 19:01:57 
UTC ---
Yes, there are. I added the most obvious one now to my patch.

Index: Make-lang.in
===
--- Make-lang.in(revision 171910)
+++ Make-lang.in(working copy)
@@ -336,7 +336,8 @@
 fortran/f95-lang.o: $(GFORTRAN_TRANS_DEPS) fortran/mathbuiltins.def \
   gt-fortran-f95-lang.h gtype-fortran.h $(CGRAPH_H) $(TARGET_H) fortran/cpp.h
\
   $(BUILTINS_DEF) fortran/types.def \
-  libfuncs.h expr.h
+  $(TM_H) debug.h langhooks.h $(FLAGS_H) $(EXPR_H) $(LANGHOOKS_DEF_H) \
+  libfuncs.h expr.h $(DIAGNOSTIC_H)
 fortran/scanner.o: toplev.h fortran/cpp.h
 fortran/convert.o: $(GFORTRAN_TRANS_DEPS)
 fortran/frontend-passes.o: $(GFORTRAN_TRANS_DEPS)

ok for apply?

[Bug target/39585] GCC Generates Incorrect Stack Instructins for Interrupts When using -Os

[jpa at gcc dot mail.kapsi.fi]

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

Petteri Aimonen  changed:

   What|Removed |Added

 CC||jpa at gcc dot
   ||mail.kapsi.fi

--- Comment #2 from Petteri Aimonen  2011-04-03 
18:50:47 UTC ---
Still present in gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51).

[Bug fortran/48311] [Quadmath] Documentation - typo, order

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Tobias Burnus  2011-04-03 
18:48:43 UTC ---
FIXED

[Bug fortran/48311] [Quadmath] Documentation - typo, order

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-04-03 
18:45:18 UTC ---
Author: burnus
Date: Sun Apr  3 18:45:16 2011
New Revision: 171914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171914
Log:
2011-04-03  Tobias Burnus  

   PR fortran/48311
   * libquadmath.texi (strtoflt128): Fix typo.
   (quadmath_snprintf): Move note up, make @item.


Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/libquadmath.texi

[Bug lto/47888] [4.6/4.7 Regression] tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6249 / Segmentation fault

[d.g.gorbachev at gmail dot com]

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

--- Comment #2 from Dmitry Gorbachev  
2011-04-03 18:41:45 UTC ---
Created attachment 23863
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23863
Backtrace from GCC 4.7.0 20110402

[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #7 from dave at hiauly1 dot hia.nrc.ca 2011-04-03 18:37:07 UTC ---
> I guess that the last patch (for pr48380) I sent should solve the problem too.
> Unfortunately, I did not get an approval for the patch yet.

I'll try it if it isn't install by the time I get to a retest.

>  But the real reason of the problem is in wrong IRA directions.

The wrong IRA directions have exposed backend problems in handling
reloads for the shift amount register.  I think I have a patch to
correct these issues.  Testing the change now.

Thanks,
Dave

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org
   Severity|enhancement |normal

--- Comment #10 from Jerry DeLisle  2011-04-03 
18:32:40 UTC ---
I would like to promote this one.  I have run into an application that is
taking about 2 to 3 minutes to compile while other compilers can do so in a
matter of seconds.  The delta here is huge.

I would also like to take a crack at it. Paul any progress on your end?

[Bug target/48366] [4.7 Regression] ICE in extract_constrain_insn_cached, at recog.c:2024

[vmakarov at redhat dot com]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #6 from Vladimir Makarov  2011-04-03 
18:18:03 UTC ---
John, thanks for reporting the PR and working on it.

I guess that the last patch (for pr48380) I sent should solve the problem too.
Unfortunately, I did not get an approval for the patch yet.

I'd recommend you to check the patch first because it might save you a lot of
time because the problem occurs in reload and it is hard to analyze the reload.
 But the real reason of the problem is in wrong IRA directions.

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[rth at gcc dot gnu.org]

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

--- Comment #23 from Richard Henderson  2011-04-03 
18:16:04 UTC ---
... and if that works, we'll see how much of the other line info
additions we can put back in.  Assuming you've a modern debugger
that might be able to use them ...

[Bug lto/48427] ICE: tree check: expected array_type, have pointer_type in array_ref_low_bound, at expr.c:6253

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev  
2011-04-03 18:09:54 UTC ---
Created attachment 23862
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23862
Compile with `gcc -r -nostdlib -flto foo.c bar.c'

[Bug lto/48427] New: ICE: tree check: expected array_type, have pointer_type in array_ref_low_bound, at expr.c:6253

[d.g.gorbachev at gmail dot com]

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

   Summary: ICE: tree check: expected array_type, have
pointer_type in array_ref_low_bound, at expr.c:6253
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com


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

With GCC 4.7.0 20110402.

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

  Attachment #23855|0   |1
is obsolete||

--- Comment #22 from Richard Henderson  2011-04-03 
18:08:06 UTC ---
Created attachment 23860
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23860
third proposed patch

One more possibility.

[Bug lto/48423] crash when using lto, linker plugin with bfd ld

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2011-04-03 18:06:23 
UTC ---
(In reply to comment #2)
> thanks hl,
> it looks promising.
> the thets runs and
> nm -C -D libBase.o
> shows
> 00201140 V typeinfo for Base
> 0fb3 V typeinfo name for Base
> like gold
> 
> I will test it more tomorrow.
> Will you merge this in next binutil snapshot?
> 

It isn't up to me. But it is in the latest Linux binutils from:

http://www.kernel.org/pub/linux/devel/binutils/

[Bug fortran/48426] [patch] Quad precision promotion

[inform at tiker dot net]

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

--- Comment #1 from Andreas Kloeckner  2011-04-03 
18:05:10 UTC ---
Created attachment 23859
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23859
patch v1

[Bug fortran/48426] New: [patch] Quad precision promotion

[inform at tiker dot net]

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

   Summary: [patch] Quad precision promotion
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: inf...@tiker.net


The attached patch implements the options

-finteger4-integer-8
-freal-4-real-8
-freal-4-real-10
-freal-4-real-16
-freal-8-real-4
-freal-8-real-10
-freal-8-real-16

to implement a variety of automatic type promotions. (This is particularly
helpful if one wants to quickly check whether a certain code has a bug limiting
its precision away from full machine accuracy.)

A similar promotion feature is available in Fujitsu compilers, see here:

http://www.lahey.com/docs/fujitsu%20compiler%20option%20list.pdf

(e.g. -CcR8R16)

I submitted this patch before, but it seems to have gotten lost in Bugzilla.
The implementation work on this was done by Zydrunas Gimbutas, not by me.
Zydrunas has authorized me to submit this for inclusion in gcc.

[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

[revital.eres at linaro dot org]

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

--- Comment #23 from revital.eres at linaro dot org 2011-04-03 18:01:23 UTC ---
(In reply to comment #22)
> (In reply to comment #0)
> > On Linux/x86, revision 171845 failed to bootstrap:
> There is bootsrap failure also on powerpc64-suse-linux using trunk -r171899

Same error occurs on arm-linux-gnueabi with trunk -r171899 configured with:

../gcc/configure --enable-checking --enable-languages=c --enable-bootstrap
--with-arch=armv7-a --with-mode=thumb

make command:

make bootstrap BOOT_CFLAGS="-O2 "

[Bug libstdc++/48340] Several wchar_t tests FAIL on IRIX 6.5

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-04-03 
17:58:14 UTC ---
Created attachment 23858
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23858
handle ctype::mask values that don't fit in 16bits

this should fix it, but changes the size of ctype on Irix, which would
break the ABI

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  2011-04-03 
17:36:28 UTC ---
> Ok for apply?

Other languages have langhooks.h $(LANGHOOKS_DEF_H) here.  There are other
missing dependencies for this file though.

[Bug lto/48423] crash when using lto, linker plugin with bfd ld

[vincenzo.innocente at cern dot ch]

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

--- Comment #2 from vincenzo Innocente  
2011-04-03 17:34:18 UTC ---
thanks hl,
it looks promising.
the thets runs and
nm -C -D libBase.o
shows
00201140 V typeinfo for Base
0fb3 V typeinfo name for Base
like gold

I will test it more tomorrow.
Will you merge this in next binutil snapshot?

vincenzo

On 3 Apr, 2011, at 7:04 PM, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48423
> 
> H.J. Lu  changed:
> 
>   What|Removed |Added
> 
> CC||hjl.tools at gmail dot com
> 
> --- Comment #1 from H.J. Lu  2011-04-03 17:04:43 
> UTC ---
> You can try hjl/lto-mixed branch from
> 
> http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary
> 
> -- 
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You reported the bug.

[Bug target/48397] gcc.target/i386/pr46419.c FAILs with -fsched2-use-superblocks - mixing FPU and MMX code without emms

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

Summary|gcc.target/i386/pr46419.c   |gcc.target/i386/pr46419.c
   |FAILs with  |FAILs with
   |-fsched2-use-superblocks|-fsched2-use-superblocks -
   |-fno-tree-loop-ivcanon  |mixing FPU and MMX code
   |--param |without emms
   |max-predicted-iterations=1  |
   |-m32|

--- Comment #1 from Zdenek Sojka  2011-04-03 17:30:28 
UTC ---
Another, different set of flags to reproduce the failure:
$ gcc -O -fsched2-use-superblocks -fschedule-insns2 --param
max-jump-thread-duplication-stmts=1 -m32 testcase.c
$ ./a.out 
Aborted

In this case, x87 and MMX and SSE instructions are mixed in the code:

...
.L8:
pxormm0, mm0# tmp148
movqmm1, QWORD PTR [esp+8]# tmp147, %sfp
xorpsxmm0, xmm0# tmp155
punpcklbwmm1, mm0# tmp147, tmp148
pxormm0, mm0# tmp151
fldDWORD PTR .LC1#
fldDWORD PTR [esp+20]# out
fucomipst, st(1)#,
fstpst(0)#
fldDWORD PTR .LC2#
jp.L10#,
movqmm2, mm1# tmp150, D.6008
punpcklwdmm2, mm0# tmp150, tmp151
fldDWORD PTR [esp+24]# out
punpckhwdmm1, mm0# tmp152, tmp151
jne.L11#,
...

[Bug fortran/48412] [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  2011-04-03 
17:28:14 UTC ---
Hi Joost,

the following patch

Index: frontend-passes.c
===
--- frontend-passes.c   (Revision 171913)
+++ frontend-passes.c   (Arbeitskopie)
@@ -279,6 +279,20 @@
   return result;
 }

+/* Warn about function removal, uncontitionally for now.  */
+
+static void
+warn_function_removal(gfc_expr *e)
+{
+  if (e->expr_type != EXPR_FUNCTION)
+return;
+  if (e->value.function.esym)
+gfc_warning ("Removing call to function %s at %L",
+e->value.function.esym->name, &(e->where));
+  else if (e->value.function.isym)
+gfc_warning ("Removing call to function %s at %L",
+e->value.function.isym->name, &(e->where));
+}
 /* Callback function for the code walker for doing common function
elimination.  This builds up the list of functions in the expression
and goes through them to detect duplicates, which it then replaces
@@ -311,6 +325,8 @@
{
  if (newvar == NULL)
newvar = create_var (*(expr_array[i]));
+
+ warn_function_removal (*(expr_array[j]));
  gfc_free (*(expr_array[j]));
  *(expr_array[j]) = gfc_copy_expr (newvar);
}

could maybe help you debug this by showing which functions get removed.

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[ktietz at gcc dot gnu.org]

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

--- Comment #3 from Kai Tietz  2011-04-03 17:10:22 
UTC ---
Yes, a complete rebuild fixed the issue.

The following patch to fortran/Make-lang.in should solve this also for a
partial rebuild:

Index: Make-lang.in
===
--- Make-lang.in(revision 171910)
+++ Make-lang.in(working copy)
@@ -336,7 +336,7 @@
 fortran/f95-lang.o: $(GFORTRAN_TRANS_DEPS) fortran/mathbuiltins.def \
   gt-fortran-f95-lang.h gtype-fortran.h $(CGRAPH_H) $(TARGET_H) fortran/cpp.h
\

   $(BUILTINS_DEF) fortran/types.def \
-  libfuncs.h expr.h
+  libfuncs.h expr.h langhooks.h
 fortran/scanner.o: toplev.h fortran/cpp.h
 fortran/convert.o: $(GFORTRAN_TRANS_DEPS)
 fortran/frontend-passes.o: $(GFORTRAN_TRANS_DEPS)

Ok for apply?

[Bug lto/48423] crash when using lto, linker plugin with bfd ld

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu  2011-04-03 17:04:43 
UTC ---
You can try hjl/lto-mixed branch from

http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  2011-04-03 
16:23:41 UTC ---
> Kai wrote in #gcc that it is due to Rev. 171862.
> 
> http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00054.html

This patch is a no-op except for Ada.  You probably didn't rebuild the entire
compiler, did you?  If no, there are very likely missing dependencies in the
Fortran Makefile fragment, namely:

fortran/f95-lang.o: $(GFORTRAN_TRANS_DEPS) fortran/mathbuiltins.def \
  gt-fortran-f95-lang.h gtype-fortran.h $(CGRAPH_H) $(TARGET_H) fortran/cpp.h \
  $(BUILTINS_DEF) fortran/types.def \
  libfuncs.h expr.h

[Bug go/48408] libgo/configure should be executable

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ian Lance Taylor  2011-04-03 16:15:58 
UTC ---
Fixed.  Thanks.

[Bug java/48417] -ffixed-regs option can't work in mips-elf-gcj compiler

[licheng.1212 at gmail dot com]

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

--- Comment #2 from licheng.1212 at gmail dot com  2011-04-03 15:43:45 UTC ---
(In reply to comment #1)
> You have to build the java runtime with -ffixed-reg also.
The runtime and all my project also have those options

export CFLAGS="-G0 -Wall -mabi=32 -msoft-float -mno-abicalls -march=xcpu
-mtune=xcpu -Wa,-march=xcpu,-mtune=xcpu -mips16 -EL -mexplicit-relocs
-falign-functions=16 -falign-jumps=16 -fweb -frename-registers -mmemcpy
-mmips-tfile -nostartfiles -nostdlib -nodefaultlibs -c -pipe -ffixed-t3
-ffixed-t4 -ffixed-t5 -ffixed-t6 -ffixed-t7 -ffixed-s2 -ffixed-s3 -ffixed-s4
-ffixed-s5 -ffixed-s6 -ffixed-s7 -ffixed-fp -minterlink-mips16
-ffunction-sections -fdata-sections -O0 -g"

export GCJFLAGS=${CFLAGS}

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #1 from Tobias Burnus  2011-04-03 
15:30:55 UTC ---
Kai wrote in #gcc that it is due to Rev. 171862.

http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00054.html

[Bug c++/48424] C++0x parameter packs expansion problem

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  2011-04-03 
15:13:50 UTC ---
It certainly looks reasonable. Jason, should this be accepted?

[Bug plugins/48425] New: installed plugin headers fail to compile, include non-existent files

[boris at kolpackov dot net]

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

   Summary: installed plugin headers fail to compile, include
non-existent files
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bo...@kolpackov.net


Since gcc 4.6.0, installed plugin headers for the C++ language (i.e., those in
/usr/lib/gcc/x86_64-linux-gnu/4.6/plugin/include/cp/) include a number of files
as "c-family/..." (e.g, cp/cp-tree.h includes "c-family/c-common.h"), however,
those headers do not exist in the c-family/ subdirectory. Instead, they all
seem to be installed into the /usr/lib/gcc/x86_64-linux-gnu/4.6/plugin/include/
directory.

Here is the error message I get when trying to build my plugin:

/usr/lib/gcc/x86_64-linux-gnu/4.6.1/plugin/include/cp/cp-tree.h:43:31: fatal
error: c-family/c-common.h: No such file or directory

Manually removing the c-family/ prefix from the include directives in header
files in the cp/ subdirectory fixed the problem for me.

[Bug c++/48424] New: C++0x parameter packs expansion problem

[aiedail92 at gmail dot com]

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

   Summary: C++0x parameter packs expansion problem
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aiedai...@gmail.com


The following testcase, which should be valid (at least I think so), fails to
compile:


#include 
#include 

template
struct test
{
std::tuple t;  // OK
void(*fptr)(int, T..., long);   // Error (1)
std::function f; // Error (2)
};


Since in (1) and (2) T... is not a parameter pack declaration, but a parameter
pack expansion, shouldn't the code be valid? And if it's really not valid, is
there a good explanation for this?


luca@laptop-luca:~$ g++ --version
g++ (GCC) 4.7.0 20110330 (experimental)

luca@laptop-luca:~$ g++ -std=c++0x testcase.cc 
testcase.cc:8:32: error: parameter packs must be at the end of the parameter
list
testcase.cc:9:39: error: parameter packs must be at the end of the parameter
list

[Bug middle-end/48422] [4.7 Regression] bootstrap failure for i686-*-* targets by ICE

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code
 CC||burnus at gcc dot gnu.org
  Component|fortran |middle-end
   Target Milestone|--- |4.7.0
Summary|bootstrap failure for   |[4.7 Regression] bootstrap
   |i686-*-* targets by ICE |failure for i686-*-*
   ||targets by ICE

[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

[revital.eres at linaro dot org]

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

revital.eres at linaro dot org changed:

   What|Removed |Added

 CC||revital.eres at linaro dot
   ||org

--- Comment #22 from revital.eres at linaro dot org 2011-04-03 11:52:47 UTC ---
(In reply to comment #0)
> On Linux/x86, revision 171845 failed to bootstrap:

There is bootsrap failure also on powerpc64-suse-linux using trunk -r171899

 ../gcc/configure --enable-bootstrap --enable-checking
--enable-languages=c,c++,fortran

make bootstrap BOOT_CFLAGS="-O2" 

make[3]: Leaving directory `/home/eres/mainline/build1'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/collect2.o differs
gcc/sel-sched-ir.o differs
gcc/c-decl.o differs
gcc/ira-costs.o differs
gcc/tree-parloops.o differs
gcc/calls.o differs
gcc/fortran/trans-types.o differs
gcc/fortran/resolve.o differs
gcc/fortran/intrinsic.o differs
gcc/fortran/trans-intrinsic.o differs
gcc/fortran/trans-expr.o differs
gcc/fortran/expr.o differs
gcc/fortran/simplify.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/c-parser.o differs
gcc/gimplify.o differs
gcc/tree-vect-loop.o differs
gcc/sel-sched-dump.o differs
gcc/var-tracking.o differs
gcc/bitmap.o differs
gcc/build/genautomata.o differs
gcc/dwarf2out.o differs
gcc/et-forest.o differs
gcc/tree-vect-loop-manip.o differs
gcc/omega.o differs
gcc/pretty-print.o differs
gcc/fold-const.o differs
gcc/df-scan.o differs
gcc/cse.o differs
gcc/tree-ssa-structalias.o differs
gcc/expr.o differs
gcc/c-family/c-format.o differs
gcc/c-family/c-ada-spec.o differs
gcc/tree-into-ssa.o differs
gcc/ggc-common.o differs
gcc/ira-color.o differs
gcc/ira.o differs
gcc/cp/parser.o differs
gcc/cp/call.o differs
gcc/cp/pt.o differs
gcc/df-problems.o differs
gcc/recog.o differs
gmp/mpn/dive_1.o differs
gmp/mpn/sqrmod_bnm1.o differs
gmp/mpn/mod_1_4.o differs
gmp/mpn/toom32_mul.o differs
gmp/mpn/mod_1_3.o differs
gmp/mpn/invertappr.o differs
gmp/mpn/toom42_mul.o differs
gmp/mpn/mod_1_2.o differs
gmp/mpn/get_str.o differs
libcpp/traditional.o differs
libcpp/expr.o differs
libiberty/pic/regex.o differs
libiberty/pic/cplus-dem.o differs
libiberty/pic/md5.o differs
libiberty/pic/sha1.o differs
libiberty/regex.o differs
libiberty/cplus-dem.o differs
libiberty/md5.o differs
libiberty/sha1.o differs
mpfr/vasprintf.o differs
mpfr/zeta_ui.o differs
zlib/libz_a-inffast.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/eres/mainline/build1'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/eres/mainline/build1'

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[iains at gcc dot gnu.org]

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

--- Comment #21 from Iain Sandoe  2011-04-03 11:43:30 
UTC ---
(In reply to comment #19)

on  i686-darwin9
the bootstrap still fails with the bus err.

> What are the changes *after* the second patch?  The first two hunks
> ought to have disappeared.

they have, the remaining difference is:

@@ -847,12 +847,5 @@ LASLTP0:
.byte   0   # uleb128 0
.byte   0   # End file name table
 LELTP0:
-   .byte   0   # DW_LNE_set_address
-   .byte   0x9 # uleb128 0x9
-   .byte   0x2
-   .quad   Letext0
-   .byte   0   # DW_LNE_end_sequence
-   .byte   0x1 # uleb128 0x1
-   .byte   0x1
 LELT0:
.subsections_via_symbols

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[markus at trippelsdorf dot de]

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

--- Comment #65 from Markus Trippelsdorf  
2011-04-03 11:32:08 UTC ---
(In reply to comment #62)
> and since it doesn't fail at link time, this is debug info bug, not LTO, so if
> you get a testcase, please open a new PR.

You're right, it builds fine without "-g" (ac_add_options
--disable-debug-symbols).

But the build now fails early when elfhack is enabled:

with gold:
c++ -o elfhack -fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -Wno-long-long -march=native
-fpermissive -flto=4 -fuse-linker-plugin -fwhole-program -fno-strict-aliasing
-fshort-wchar -pthread -pipe -fexceptions  -DNDEBUG -DTRIMMED -g -O3 -lpthread
-Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory  
-Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/bin
-Wl,-rpath-link,/usr/lib  host_elf.o host_elfhack.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/ccGQbukN.ltrans3.ltrans.o: in function
_ZN8Elf_Ehdr9serializeERSt14basic_ofstreamIcSt11char_traitsIcEEcc.local.402:/var/tmp/mozilla-central/build/unix/elfhack/elfxx.h:239:
error: undefined reference to 'void Elf_Ehdr_Traits::swap >(serializable&,
Elf64_Ehdr&)'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/ccGQbukN.ltrans3.ltrans.o: in function
_ZN8Elf_Ehdr9serializeERSt14basic_ofstreamIcSt11char_traitsIcEEcc.local.402:/var/tmp/mozilla-central/build/unix/elfhack/elfxx.h:228:
error: undefined reference to 'void Elf_Ehdr_Traits::swap >(serializable&,
Elf32_Ehdr&)'
collect2: ld returned 1 exit status
make[7]: *** [elfhack] Error 1

or with gnu-ld:
In function `serialize':
/var/tmp/mozilla-central/build/unix/elfhack/elfxx.h:239: undefined reference to
`void Elf_Ehdr_Traits::swap >(serializable&, Elf64_Ehdr&)'
/var/tmp/mozilla-central/build/unix/elfhack/elfxx.h:228: undefined reference to
`void Elf_Ehdr_Traits::swap >(serializable&, Elf32_Ehdr&)'
collect2: ld returned 1 exit status

see also: https://bugzilla.mozilla.org/show_bug.cgi?id=647458
(but it does look more like a gcc lto bug to me)

[Bug lto/48423] New: crash when using lto, linker plugin with bfd ld

[vincenzo.innocente at cern dot ch]

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

   Summary: crash when using lto, linker plugin with bfd ld
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


I'm continuing my experiments with lto, linker-plugins and visibility.
I've now built a simple example of a typical plugin architecture (similar to
the one in use in my project)
with a base class in one library and derived classes in run-time loadable
libraries.

I get "ld" warnings and a crash in the attached examples when linking with
ld -v
GNU ld (GNU Binutils) 2.21
it compiles, links and runs fine with
ld -v
GNU gold (GNU Binutils 2.21) 1.10

just download it and
source makeLinux
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
and then

gdb exFactory
GNU gdb (GDB) 7.1
...
Get D

Program received signal SIGSEGV, Segmentation fault.
0x00401826 in get (c=) at exFactory.cpp:27
27  (*bp).hi();
(gdb) where
#0  0x00401826 in get (c=) at exFactory.cpp:27
#1  0x00401984 in main () at exFactory.cpp:39


one can activate the construction of a static object in the library that
actually causes the crash to see it
crashing even in the library itself
source makeLinux -DSHELLO
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
ld: warning: type and size of dynamic symbol `typeinfo for Base' are not
defined
[vinavx0] ~/w1/ltoCrash $ gdb exFactory
Get D

break point hook

hello D
who in D

Program received signal SIGSEGV, Segmentation fault.
0x778cce68 in D::who (this=, b=...) at Base.h:19
19return ii();
(gdb) where
#0  0x778cce68 in D::who (this=, b=...) at
Base.h:19
#1  0x778cd150 in __static_initialization_and_destruction_0 () at
helloD.cc:17
#2  global constructors keyed to 65535_0_ccyFVIjt.o () at helloD.cc:25
#3  0x778ccb85 in __do_global_ctors_aux () from ./plugD.so
#4  0x778cc8fb in _init () from ./plugD.so
#5  0x003f in ?? ()
#6  0x003ff520e3b5 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#7  0x003ff5212b21 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#8  0x003ff520e016 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#9  0x003ff521236a in _dl_open () from /lib64/ld-linux-x86-64.so.2
#10 0x003ff5a00f66 in dlopen_doit () from /lib64/libdl.so.2
#11 0x003ff520e016 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#12 0x003ff5a0129c in _dlerror_run () from /lib64/libdl.so.2
#13 0x003ff5a00ee1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#14 0x004017f1 in magic (c=...) at exFactory.cpp:12
#15 get (c=...) at exFactory.cpp:23
#16 0x00401984 in main () at exFactory.cpp:39

(one can use "bhook" to set a breakpoint just before this crash)

as the program runs w/o errors when linked with gold I'm not sure on which side
(gcc or binutil)
the problem is.

Any hint even on how to work-around this issue would be appreciated as gold, at
the moment,
is also not fully usable with linker-plugins as it produces clobbered
stacktrace
(see bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48384)

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |4.7.0

[Bug c/48418] [4.5/4.6/4.7 Regression] Bit shift operator >>=

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  2011-04-03 11:21:27 UTC ---
It's deliberate that folding of references to const variables is now 
delayed - and ideally it would move out of the front end altogether.  
While decl_constant_value_for_optimization still exists it would be easy 
enough to have a second check for this warning in c_fully_fold_internal, 
but in general the alternatives (which are not mutually exclusive) are 
predictable warnings in the front end that may not catch all cases and may 
sometimes warn in unreachable code, and less-predictable middle-end 
warnings if the problem operation is reachable (here, if a shift by an 
out-of-range constant is found after optimization, which could include 
where the variable with the shift amount isn't marked const).

[Bug bootstrap/48403] [4.7 Regression] bootstrap comparison failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug fortran/48412] [4.7 Regression] CP2K miscompiled due to some Fortran frontend pass

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug c/48418] [4.5/4.6/4.7 Regression] Bit shift operator >>=

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Keywords||diagnostic
   Last reconfirmed||2011.04.03 11:09:30
 CC||jsm28 at gcc dot gnu.org
 Resolution|WONTFIX |
 Ever Confirmed|0   |1
Summary|Bit shift operator >>=  |[4.5/4.6/4.7 Regression]
   ||Bit shift operator >>=
   Target Milestone|--- |4.5.3

--- Comment #3 from Richard Guenther  2011-04-03 
11:09:30 UTC ---
I suppose some of the warning code needs to be updated with the C constexpr
changes.  Joseph?

[Bug java/48417] -ffixed-regs option can't work in mips-elf-gcj compiler

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-04-03 
11:06:31 UTC ---
You have to build the java runtime with -ffixed-reg also.

[Bug c++/48421] [4.7 Regression] ICE in build_new_method_call

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #64 from Jan Hubicka  2011-04-03 
10:08:34 UTC ---
Some detailed stats on WPA memory usage.
Before IPA:



ipa-prop.c:2820 (ipa_read_node_info)  0: 0.0%8895232:
1.1%   24998944: 0.7% 395040: 0.1% 558297
tree.c:5898 (decl_priority_info)   12295536: 0.7%  0:
0.0%   27391696: 0.8%  0: 0.0%2480452
tree.c:1567 (build_string) 16376223: 0.9%  0:
0.0%   39728388: 1.2%4876275: 1.1%1227602
lto-section-in.c:435 (lto_new_in_decl_state)   2280: 0.0%  0:
0.0%   44349120: 1.3%  0: 0.0% 369595
ipa-ref.c:54 (ipa_record_reference)   0: 0.0% 
117135752:14.1%   45299512: 1.3%   38560128: 8.5% 488972
lto-streamer-in.c:1875 (lto_materialize_tree)  44134352: 2.5%  0:
0.0%   66615480: 1.9%   4264: 0.0%1107669
ggc-common.c:253 (ggc_cleared_alloc_ptr_array_tw   1480: 0.0% 
250512784:30.1%   67551704: 2.0% 157632: 0.0%   7072
cgraph.c:1015 (cgraph_create_edge_1)  0: 0.0%  0:
0.0%   68064464: 2.0%  0: 0.0% 654466
lto-streamer-in.c:2307 (lto_input_ts_constructor   33062632: 1.9% 
111658560:13.4%  102441008: 3.0%   56848328:12.6% 486571
lto/lto.c:214 (lto_read_in_decl_state) 2288: 0.0%  0:
0.0%  110826912: 3.2%   21320304: 4.7%2587165
tree.c:1257 (build_int_cst_wide)  143425600: 8.1%  0:
0.0%  199678728: 5.8%  113095664:25.0%  60257
cgraph.c:459 (cgraph_allocate_node)   0: 0.0%  0:
0.0%  236635872: 6.9%  0: 0.0% 672261
toplev.c:1027 (realloc_for_line_map)  0: 0.0% 
335593472:40.4%  335550464: 9.8%  134297600:29.7% 15
lto-streamer-in.c:1881 (lto_materialize_tree)1302081688:73.2%  0:
0.0% 1968493840:57.3%   74550688:16.5%   29259517
Total1777935767831048528   
   3436852692452441891 49428016
source location GarbageFreed   
 Leak OverheadTimes
---

after IPA
stringpool.c:75 (alloc_node)  0: 0.0%  0:
0.0%   17709680: 0.5%  0: 0.0% 442742
stringpool.c:58 (stringpool_ggc_alloc)0: 0.0%  0:
0.0%   22641304: 0.7%1646320: 0.3% 442742
tree.c:1297 (build_int_cst_wide)   10611640: 0.6%  0:
0.0%   21902960: 0.6%  0: 0.0% 812865
tree.c:5898 (decl_priority_info)   12376576: 0.7%  0:
0.0%   27310672: 0.8%  0: 0.0%2480453
lto-section-in.c:435 (lto_new_in_decl_state) 162720: 0.0%  0:
0.0%   44188680: 1.3%  0: 0.0% 369595
tree.c:1567 (build_string) 17659049: 1.0%  0:
0.0%   38445562: 1.1%4876275: 1.0%1227602
cgraph.c:1015 (cgraph_create_edge_1)  0: 0.0%  0:
0.0%   68064464: 2.0%  0: 0.0% 654466
ggc-common.c:253 (ggc_cleared_alloc_ptr_array_tw  26888: 0.0% 
258338128:27.6%   75336800: 2.2% 171272: 0.0%   7667
gimple.c:4187 (iterative_hash_gimple_type) 78311648: 4.3%  0:
0.0% 260960: 0.0%  0: 0.0%4910788
ipa-ref.c:54 (ipa_record_reference)   0: 0.0% 
156312592:16.7%   82529352: 2.4%   63464176:13.2% 506799
lto-streamer-in.c:1875 (lto_materialize_tree)  49735872: 2.8%  0:
0.0%   61013960: 1.8%   4264: 0.0%1107669
lto/lto.c:214 (lto_read_in_decl_state)   315616: 0.0%  0:
0.0%  110513584: 3.2%   21320304: 4.4%2587165
lto-symtab.c:156 (lto_symtab_register_decl)   130991616: 7.3%  0:
0.0%2900408: 0.1%  0: 0.0%2390929
lto-streamer-in.c:2307 (lto_input_ts_constructor   33062632: 1.8% 
111658560:12.0%  102441008: 3.0%   56848328:11.8% 486571
cgraph.c:459 (cgraph_allocate_node)   0: 0.0%  0:
0.0%  236635872: 6.9%  0: 0.0% 672261
toplev.c:1027 (realloc_for_line_map)  0: 0.0% 
335593472:35.9%  335550464: 9.8%  134297600:28.0% 15
tree.c:1257 (build_int_cst_wide)  144244592: 8.0%  0:
0.0%  198866208: 5.8%  113097680:23.5%  60267
lto-streamer-in.c:1881 (lto_materialize_tree)1319860448:73.1%  0:
0.0% 1950715080:57.0%   74550688:15.5%   29259517
Total1804556313934357752   
   3423228826480284459 49853300
source location GarbageFreed   
 Leak OverheadTimes

Kind   Nodes  Bytes
---
decls11502734 1829746088
types4430124  74

[Bug bootstrap/48400] [4.7 Regression] powerpc-apple-darwin9 fails to bootstrap at revision 171824

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||peter at pogma dot com

--- Comment #20 from Iain Sandoe  2011-04-03 10:03:44 
UTC ---
(In reply to comment #16)
> Created attachment 23855 [details]
> second proposed patch
> 
> The fault is 100% with ld.  GCC is producing valid dwarf2.

:-(

> I hate Apple's linker.

That's understandable, since you don't see the up-side (only the problems).

AFAIK, they intend that it will support the output of GCC - but that will only
apply to the leading edge - and, as Dominique said, leaves Darwin9 (and maybe
even 10, given the timescales) high and dry.

As I see it we have these options (other than the trivial 'give up'):

1. live with the native tool-chain and provide hooks/work-arounds  to let us
fix things up...

2. odcctools -- unfortunately, trunk (159) of odcctools also has this problem,
I just tried to bootstrap ppc with it.  There are up-to-date releases of the
Apple tools - but it depends on someone having time to integrate them.  Also,
more of a tricky business for the end User.

3. finish porting mach-o to binutils (I've made some progress with BFD and GAS
- but not even started to look at LD) ... waiting for the paperwork to come
through to extend my assignments to binutils

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #63 from Jan Hubicka  2011-04-03 
09:09:03 UTC ---
Some stats on size of the compilation unit...
There is 4.5GB of GGC memory, it gets down to 3.9MB after type merging and
3.1MB after cgraph merging.


GIMPLE type table: size 524287, 374001 elements, 4447259 searches, 70070870
collisions (ratio: 15.755968)
GIMPLE type hash table: size 8388593, 3907773 elements, 325621199 searches,
247539125 collisions (ratio: 0.760206)
GIMPLE canonical type table: size 262139, 182719 elements, 655793 searches,
1461075 collisions (ratio: 2.227952)
GIMPLE canonical type hash table: size 2097143, 863737 elements, 30341039
searches, 17653238 collisions (ratio: 0.581827)
GIMPLE type comparison table: size 134217689, 70698639 elements, 153291912
searches, 154719852 collisions (ratio: 1.009315)

[WPA] # of input files: 2721
[WPA] # of input cgraph nodes: 127466
[WPA] # of function bodies: 0
[WPA] GIMPLE type table: size 16381, 55 elements, 55 searches, 2 collisions
(ratio: 0.036364)

there are overall 600K cgraph nodes before merging, 127K from those do have
function bodies.

MMAP pool
[WPA] Compression: 680146043 input bytes, 2436118544 uncompressed bytes (ratio:
3.581758)
[WPA] Size of mmap'd section decls: 421187330 bytes
[WPA] Size of mmap'd section function_body: 232170973 bytes
[WPA] Size of mmap'd section statics: 9978045 bytes
[WPA] Size of mmap'd section cgraph: 6356885 bytes
[WPA] Size of mmap'd section vars: 225276 bytes
[WPA] Size of mmap'd section refs: 1082929 bytes
[WPA] Size of mmap'd section jmpfuncs: 8401591 bytes
[WPA] Size of mmap'd section pureconst: 743014 bytes

[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)

[hubicka at gcc dot gnu.org]

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

--- Comment #15 from Jan Hubicka  2011-04-03 
09:00:04 UTC ---
Sorry, forgot about the division by zero issue. Testing patch.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #62 from Jan Hubicka  2011-04-03 
08:36:47 UTC ---
and since it doesn't fail at link time, this is debug info bug, not LTO, so if
you get a testcase, please open a new PR.

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #61 from Jan Hubicka  2011-04-03 
08:34:01 UTC ---
My tree still builds (this is debug info ICE and I use non-debug info by
default).  Will update tree and try to reproduce it.  Would be handy to have a
testcase.

[Bug go/48407] libgo/configure --without-libffi doesn't work

[dirtyepic at gentoo dot org]

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

Ryan Hill  changed:

   What|Removed |Added

 CC||dirtyepic at gentoo dot org

--- Comment #1 from Ryan Hill  2011-04-03 07:44:52 
UTC ---
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02084.html

[Bug fortran/48422] New: bootstrap failure for i686-*-* targets by ICE

[ktietz at gcc dot gnu.org]

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

   Summary: bootstrap failure for i686-*-* targets by ICE
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kti...@gcc.gnu.org


The following trivial program leads to an ICE.

t_ice.f90:
program main

end

--

$ i686-w64-mingw32-gfortran.exe -c -o t.o t_ice.f90
t_ice.f90: In function 'main':
t_ice.f90:3:0: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.