[Bug middle-end/49602] [4.7 Regression] verify_ssa failed (definition does not dominate use) with "-O2 -g"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.01 07:04:56
  Component|tree-optimization   |middle-end
  Known to work||4.6.1
   Target Milestone|--- |4.7.0
Summary|verify_ssa failed   |[4.7 Regression] verify_ssa
   |(definition does not|failed (definition does not
   |dominate use) with "-O2 -g" |dominate use) with "-O2 -g"
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-07-01 
07:04:56 UTC ---
Huh, this is from into-SSA.  Confirmed.

[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.7.0
Summary|ICE at  |[4.7 Regression] ICE at
   |ipa-inline-analysis.c:1188  |ipa-inline-analysis.c:1188

--- Comment #1 from Richard Guenther  2011-07-01 
07:06:31 UTC ---
Doesn't reproduce on x86_64.

[Bug middle-end/49596] [4.7 Regression] FAIL: gcc.dg/torture/pr43879_1.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.01 07:07:56
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-07-01 
07:07:56 UTC ---
Mine.

[Bug c/49595] on amd64, sizeof(__int128_t) > sizeof(intmax_t)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #12 from Richard Guenther  2011-07-01 
07:11:00 UTC ---
Invalid then.

[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  2011-07-01 07:21:26 
UTC ---
(In reply to comment #1)
> darwin_closure.S was touched a while ago:
> 
> http://gcc.gnu.org/ml/gcc-cvs/2010-12/msg00700.html
> 
> by
> 
> http://gcc.gnu.org/ml/gcc-patches/2010-12/txt00045.txt
> 
> Can anyone else test this on powerpc-darwin8?  I'll see what I can figure out.

I'll take a look at this.

As a quick work-around you might try 
"--disable-multilib"  since you appear to be building on a machine that is not
64 bit anyway.

(of course, if you need to build m64 code for other machines that won't help -
but it will get you going for native stuff).

[Bug ada/48835] Porting GNAT to GNU/Linux/m68k

[mikpe at it dot uu.se]

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

--- Comment #17 from Mikael Pettersson  2011-07-01 
07:54:05 UTC ---
4.3.6 w/ gnat rebuilt itself fine with a fairly small patch kit (about 30
wrong-code fixes, almost half of them m68k-specific).  However, 4.4.6 with a
similar small patch kit (essentially the 4.3 kit except the ones that were
already fixed in upstream 4.4, total about 20 fixes) fails with the same
assertion in stage3 I showed before in #c8.

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  2011-07-01 08:40:13 UTC 
---
> Confirmed, we shouldn't be emitting ~B because it's not needed.  Probably
> introduced by r173517,
> 
> 2011-05-06  Jan Hubicka  
> 
> * cgraph.c (cgraph_add_thunk): Create real function node instead
> of alias node; finalize it and mark needed/reachale; arrange 
> visibility
> to be right and add it into the corresponding same comdat group list.
> ...
I believed that thunks always belong to same comdat group as the function they
are associated with.
Perhaps same comdat groups behave differently on HP?

I will check.
Honza

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-01 08:48:07 UTC ---
> --- Comment #4 from Jan Hubicka  2011-07-01 08:40:13 
> UTC ---
[...]
> I believed that thunks always belong to same comdat group as the function they
> are associated with.
> Perhaps same comdat groups behave differently on HP?

This is Tru64 UNIX with ECOFF, no named sections, no COMDAT groups.

Rainer

[Bug libmudflap/49549] Use of --noinhibit-exec is unportable

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2011-07-01 08:59:23 UTC 
---
Author: ro
Date: Fri Jul  1 08:59:20 2011
New Revision: 175749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175749
Log:
libmudflap:
PR libmudflap/49549
* testsuite/lib/libmudflap.exp (load_gcc_lib): Load
target-supports.exp.
* testsuite/libmudflap.cth/cthfrags.exp: Only pass
--noinhibit-exec to GNU ld.

gcc:
PR libmudflap/49549
* doc/sourcebuild.texi (Effective-Target Keywords): Document gld.

gcc/testsuite:
PR libmudflap/49549
* lib/target-supports.exp (check_effective_target_gld): New proc.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/sourcebuild.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/target-supports.exp
trunk/libmudflap/ChangeLog
trunk/libmudflap/testsuite/lib/libmudflap.exp
trunk/libmudflap/testsuite/libmudflap.cth/cthfrags.exp

[Bug libmudflap/49549] Use of --noinhibit-exec is unportable

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-06/msg02378.htm
   ||l
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #2 from Rainer Orth  2011-07-01 09:01:33 UTC 
---
Fixed for 4.7.0.

[Bug c++/49605] New: -Wdelete-non-virtual-dtor is not picky enough

[miles at gnu dot org]

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

   Summary: -Wdelete-non-virtual-dtor is not picky enough
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org


In the following program:

struct X
{
  ~X ();
  virtual void meth ();
};

void d ()
{
  X x;
}

"g++-snapshot -c -O2 -Wall nvdtor.cc" yields a warning:

nvdtor.cc: In function 'void d()':
nvdtor.cc:9:5: warning: deleting object of polymorphic class type 'X' which has
non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]

But it looks to me like the behavior in this case isn't undefined at all -- the
object being destroyed is stack-allocated, so gcc knows exactly what the actual
object type is; it's not possible for it to be a subclass of X.

Thanks,

-miles

[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.01 09:14:48
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-07-01 
09:14:48 UTC ---
more to the point, there's no 'delete' expression!

I added the warning so will try to fix this

[Bug libfortran/48906] Wrong rounding results with -m32

[thenlich at users dot sourceforge.net]

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

--- Comment #38 from Thomas Henlich  
2011-07-01 09:22:48 UTC ---
The Fortran standards committee has voted to edit the standard:

http://j3-fortran.org/doc/meeting/195/11-174r2.txt

This makes our current approach standard compliant (with the corrigendum to be
published)

This also means an additional todo item for this bug is

"If d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee
editing respectively."

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  2011-07-01 09:30:41 UTC 
---
> This is Tru64 UNIX with ECOFF, no named sections, no COMDAT groups.
Yep, I know, but the question is how absence of COMDAT groups changes behaviour
of thunks.

The problem here is that the thunks are
!cgraph_can_remove_if_no_direct_calls_and_refs_p
and thus we don't optimize them out.
The reason is the test:
2902  if (node->local.externally_visible
2903  && (!DECL_COMDAT (node->decl)
2904  || cgraph_used_from_object_file_p (node)))
2905return false;

the decl is not comdat, just weak and thus we think we must keep it in program.

The declaration of the destructor itself do have COMDAT flag.
The following patch should fix the problem:
Index: ipa.c
===
--- ipa.c   (revision 175748)
+++ ipa.c   (working copy)
@@ -871,9 +871,9 @@ function_and_variable_visibility (bool w

 We also need to arrange the thunk into the same comdat group as
 the function it reffers to.  */
+  DECL_COMDAT (node->decl) = DECL_COMDAT (decl_node->decl);
  if (DECL_ONE_ONLY (decl_node->decl))
{
- DECL_COMDAT (node->decl) = DECL_COMDAT (decl_node->decl);
  DECL_COMDAT_GROUP (node->decl) = DECL_COMDAT_GROUP
(decl_node->decl);
  if (DECL_ONE_ONLY (decl_node->decl) && !node->same_comdat_group)
{


Jason, the whole code copying visibilities to thunk decls is just a hack.  Do
you think
you can make C++ FE to put proper visibility flags on thunks and same body
aliases?

Honza

[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |4.7.0

--- Comment #2 from Jonathan Wakely  2011-07-01 
09:42:26 UTC ---
I'm not sure if this its right but it fixes the testcase:

--- init.c.orig 2011-07-01 09:39:20.825997109 +
+++ init.c  2011-07-01 09:39:38.954089615 +
@@ -3421,8 +3421,9 @@
}
  complete_p = false;
}
- else if (warn_delnonvdtor && MAYBE_CLASS_TYPE_P (type)
-  && !CLASSTYPE_FINAL (type) && TYPE_POLYMORPHIC_P (type))
+ else if (warn_delnonvdtor && auto_delete == sfk_deleting_destructor
+   && MAYBE_CLASS_TYPE_P (type) && !CLASSTYPE_FINAL (type)
+   && TYPE_POLYMORPHIC_P (type))
{
  tree dtor;
  dtor = CLASSTYPE_DESTRUCTORS (type);


I'll look into it properly and run the testsuite later today

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-01 10:03:24 UTC ---
> The declaration of the destructor itself do have COMDAT flag.
> The following patch should fix the problem:
> Index: ipa.c
> ===
> --- ipa.c   (revision 175748)
> +++ ipa.c   (working copy)
> @@ -871,9 +871,9 @@ function_and_variable_visibility (bool w
>
>  We also need to arrange the thunk into the same comdat group as
>  the function it reffers to.  */
  ^ typo

> +  DECL_COMDAT (node->decl) = DECL_COMDAT (decl_node->decl);
>   if (DECL_ONE_ONLY (decl_node->decl))
> {
> - DECL_COMDAT (node->decl) = DECL_COMDAT (decl_node->decl);
>   DECL_COMDAT_GROUP (node->decl) = DECL_COMDAT_GROUP
> (decl_node->decl);
>   if (DECL_ONE_ONLY (decl_node->decl) && !node->same_comdat_group)
> {

I can include it in this weekend's bootstrap.

Rainer

[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  2011-07-01 10:09:03 
UTC ---
(In reply to comment #0)
> During build of gcc-4.6.1 on powerpc-darwin8 (after having disabled 
> libquadmath
> from PR 49582), I get a compilation error in libffi on

> hardware: powerpc7400 (dual G4)
> OS: OS X 10.4.11 (powerpc)

what is your configure line, please?

[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

  Attachment #24589|0   |1
is obsolete||

--- Comment #6 from Jan Hubicka  2011-07-01 
10:47:45 UTC ---
Created attachment 24653
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24653
proposed fix II

Hi,
here is fixed version that does not warn.  Can someone try it out, please?

[Bug middle-end/49596] [4.7 Regression] FAIL: gcc.dg/torture/pr43879_1.c

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-07-01 
11:13:17 UTC ---
Author: rguenth
Date: Fri Jul  1 11:13:13 2011
New Revision: 175753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175753
Log:
2011-07-01  Richard Guenther  

PR middle-end/49596
* cgraph.h (varpool_all_refs_explicit_p): Not analyzed nodes
may have unknown refs.

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

[Bug middle-end/49602] [4.7 Regression] verify_ssa failed (definition does not dominate use) with "-O2 -g"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-07-01 
11:16:14 UTC ---
Caused by my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175288
so I'll have a look...

[Bug inline-asm/29357] inline asm %c0 template form not documented

[mschulze at ivs dot cs.ovgu.de]

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

Michael Schulze  changed:

   What|Removed |Added

 CC||mschulze at ivs dot
   ||cs.ovgu.de

--- Comment #2 from Michael Schulze  2011-07-01 
11:56:40 UTC ---
Is it intended to add this documentation patch? Or, is the functionality with
modifiers like %c not in a state that allows the use outside of the compiler
within normal applications?

[Bug target/49606] New: mips64: Unrecognizable insn when one noreturn function calling another noreturn function

[martin at decky dot cz]

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

   Summary: mips64: Unrecognizable insn when one noreturn function
calling another noreturn function
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@decky.cz
Target: mips64


Created attachment 24654
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24654
Preprocessed file

Simple test case:

extern void first(void) __attribute__((noreturn));
extern void second(void) __attribute__((noreturn));

void first(void)
{
second();
}


Output of /usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc -v:

Using built-in specs.
COLLECT_GCC=/usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/cross/mips64/libexec/gcc/mips64el-linux-gnu/4.6.1/lto-wrapper
Target: mips64el-linux-gnu
Configured with: /root/install/cross/mips64/gcc-4.6.1/configure
--target=mips64el-linux-gnu --prefix=/usr/local/cross/mips64
--program-prefix=mips64el-linux-gnu- --with-gnu-as --with-gnu-ld --disable-nls
--disable-threads --enable-languages=c,objc,c++,obj-c++ --disable-multilib
--disable-libgcj --without-headers --disable-shared --enable-lto
Thread model: single
gcc version 4.6.1 (GCC) 


Command line that triggered the bug:

/usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc  -I../../lib/c/include -O3
-imacros ../../../config.h -fexec-charset=UTF-8 -fwide-exec-charset=UTF-32LE
-finput-charset=UTF-8 -ffreestanding -fno-builtin -nostdlib -nostdinc -Wall
-Wextra -Wno-clobbered -Wno-unused-parameter -Wmissing-prototypes -std=gnu99
-Werror-implicit-function-declaration -Wwrite-strings -pipe -g -D__LE__ -Werror
-mips3 -mabi=o64 -mlong64 -Xassembler -64 -I../../srv/loader/include -c
generic/libc.c -o generic/libc.o


Compiler output:

generic/libc.c: In function 'first':
generic/libc.c:7:1: error: unrecognizable insn:
(insn 16 15 18 2 (parallel [
(set (mem/c:DI (plus:DI (reg/f:DI 29 $sp)
(const_int 32 [0x20])) [2 S8 A64])
(unspec:SI [
(const_int 32 [0x20])
(reg:DI 28 $28)
] UNSPEC_POTENTIAL_CPRESTORE))
(clobber (scratch:DI))
]) generic/libc.c:5 -1
 (nil))
generic/libc.c:7:1: internal compiler error: in extract_insn, at recog.c:2109

[Bug target/49606] mips64: Unrecognizable insn when one noreturn function calling another noreturn function

[martin at decky dot cz]

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

--- Comment #1 from Martin Decky  2011-07-01 12:12:47 
UTC ---
A minimal set of GCC command line arguments that still trigger the bug:

/usr/local/cross/mips64/bin/mips64el-linux-gnu-gcc -mabi=o64 -mlong64 -c
generic/libc.c -o generic/libc.o

Leaving out either of the arguments -mabi=o64 and -mlong64 solves the bug,
however I cannot leave them out because this is precisely what I need: To use
the the O64 ABI and have 64-bit pointers. Or is there any better way how to
achieve this?

[Bug bootstrap/49557] make chokes on various Makefile constructs

[arjen.markus895 at gmail dot com]

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

--- Comment #8 from Arjen Markus  2011-07-01 
12:37:06 UTC ---
Hi Eric,

I have run into a problem on a Linux machin with this:

make[3]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc/gcc'
mkdir -p -- x86_64-unknown-linux-gnu/libgcc
Checking multilib configuration for libgcc...
Configuring stage 1 in x86_64-unknown-linux-gnu/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for x86_64-unknown-linux-gnu-ar... ar
checking for x86_64-unknown-linux-gnu-lipo... lipo
checking for x86_64-unknown-linux-gnu-nm...
/u/markus/tmp/gcc4.6.1/build-gcc/./gcc/nm
checking for x86_64-unknown-linux-gnu-ranlib... ranlib
checking for x86_64-unknown-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for x86_64-unknown-linux-gnu-gcc...
/u/markus/tmp/gcc4.6.1/build-gcc/./gcc/xgcc
-B/u/markus/tmp/gcc4.6.1/build-gcc/./gcc/
-B/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/bin/
-B/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/lib/ -isystem
/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/include -isystem
/u/markus/tmp/gcc4.6.1.bin/x86_64-unknown-linux-gnu/sys-include
checking for suffix of object files... configure: error: in
`/u/markus/tmp/gcc4.6.1/build-gcc/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/u/markus/tmp/gcc4.6.1/build-gcc'
make: *** [all] Error 2

configure has run many times before it pops up with this error. The
make utility is GNU Make 3.81
The system is RHEL 5.4, Intel 64 processor.

Regards,

Arjen


2011/6/29 Arjen Markus :
> Hi Eric,
>
> yes, that might be a good idea. Another test I can do, just to make
> sure it is the make version that comes with MInGW is to try this
> on a Linux machine.
>

[Bug bootstrap/49557] make chokes on various Makefile constructs

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2011-07-01 
12:46:22 UTC ---
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.

Do exactly this, that will tell you what happened.

[Bug bootstrap/49557] make chokes on various Makefile constructs

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-07-01 
12:47:16 UTC ---
FAQ: http://gcc.gnu.org/wiki/FAQ#configure_suffix

[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth  2011-07-01 
12:49:45 UTC ---
He is using my proposed fink gcc46 packaging so it should be...

../gcc-4.6.1/configure --prefix=/sw --prefix=/sw/lib/gcc4.6
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-cloog-backend=isl --disable-libjava-multilib
--disable-libquadmath

Note that I don't see any issues with a dual G5 building gcc 4.6.1 on
powerpc-apple-darwin9 under Xcode 3.1.4.

[Bug bootstrap/49557] make chokes on various Makefile constructs

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2011-07-01 
12:50:06 UTC ---
(In reply to comment #0)
> ../gcc-4.6.1-RC-20110620/configure 
> --with-gmp-include=d:/gcc4.6.1.src/gmp-5.0.2
> --with-gmp-lib=d:/gcc4.6.1.src/gmp-5.0.2/.libs
> --with-mpfr-include=d:/gcc4.6.1.src/mpfr-3.0.1
> --with-mpfr-lib=d:/gcc4.6.1.src/mpfr-3.0.1/.libs
> --with-mpc-include=d:/gcc4.6.1.src/mpc-0.9/src
> --with-mpc-lib=d:/gcc4.6.1.src/mpc-0.9/src/.libs


What on earth are you doing here?

You have not installed gmp/mpc/mpfr, you seem to be trying to use
compiled-but-not-installed versions, why?

It's much easier to just put the gmp/mpfr/mpc sources into the gcc source tree
and then everything just works

See http://advogato.org/person/redi/diary/240.html

[Bug middle-end/48016] Inconsistency in non-local goto save area

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  2011-07-01 
12:57:15 UTC ---
Author: hjl
Date: Fri Jul  1 12:57:11 2011
New Revision: 175756

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175756
Log:
Use proper mode for stack save area.

2011-07-01  H.J. Lu  

PR middle-end/48016
* explow.c (update_nonlocal_goto_save_area): Use proper mode
for stack save area.
* function.c (expand_function_start): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/explow.c
trunk/gcc/function.c

[Bug middle-end/48016] Inconsistency in non-local goto save area

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  2011-07-01 13:00:11 
UTC ---
Fixed.

[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  2011-07-01 13:02:38 
UTC ---
(In reply to comment #4)
> He is using my proposed fink gcc46 packaging so it should be...
> 
> ../gcc-4.6.1/configure --prefix=/sw --prefix=/sw/lib/gcc4.6
> --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
> --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
> --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
> --with-system-zlib --x-includes=/usr/X11R6/include 
> --x-libraries=/usr/X11R6/lib
> --program-suffix=-fsf-4.6 --enable-cloog-backend=isl 
> --disable-libjava-multilib
> --disable-libquadmath
> 
> Note that I don't see any issues with a dual G5 building gcc 4.6.1 on
> powerpc-apple-darwin9 under Xcode 3.1.4.

thanks, Jack
I check darwin9 quite often, and that is OK with trunk too.

whilst it would be nice to have m64 to work on D8 - I'm wondering if it is
simply more trouble than value (esp. if the User has only 32bit hardware).   I
wonder how many G5 owners have a reason to use D8.

for now,  trying a build on my remaining d8 box (500M G4, so .. will take 12+
hours)... 
... also will try a X to D8 on my quad G5.

[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough

[miles at gnu dot org]

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

--- Comment #3 from miles at gnu dot org 2011-07-01 13:25:23 UTC ---
Here's another test case which is closer to the real code that prompted this
bug report:

struct X
{
  ~X ();
  virtual void meth () = 0;
};

struct Y : X
{
  ~Y ();
  virtual void meth ();
};

void d ()
{
  Y y;
}

Thanks,

-miles

[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-07-01 
13:34:56 UTC ---
Thanks, that's fixed by my patch too.  I'll submit it to gcc-patches for review
later today.

[Bug c++/49085] Crash with SIGSEGV during compilation.

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-07-01 
13:36:20 UTC ---
Author: jason
Date: Fri Jul  1 13:36:17 2011
New Revision: 175758

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175758
Log:
PR c++/49085
* semantics.c (finish_offsetof): Complain about incomplete type.

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

[Bug libstdc++/49607] New: [4.7 Regression] FAIL: 22_locale/time_get/get_weekday/wchar_t/wrapped_locale.cc

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] FAIL:
22_locale/time_get/get_weekday/wchar_t/wrapped_locale.
cc
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, revision 175755 gave

FAIL: 22_locale/time_get/get_weekday/wchar_t/wrapped_locale.cc (test for excess
errors)

Revision 175752 is OK.

[Bug libstdc++/49607] [4.7 Regression] FAIL: 22_locale/time_get/get_weekday/wchar_t/wrapped_locale.cc

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #1 from H.J. Lu  2011-07-01 14:02:41 
UTC ---
It may be caused by revision 175753:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00017.html

[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-07-01 14:07:55 UTC ---
> --- Comment #7 from Bryan Hundven  2011-06-29 
> 19:30:03 UTC ---
[...]
> So, Yann found that sh4 did not need this option anymore, and he has since
> removed the --enable-symvers option from the build:
>
> http://crosstool-ng.org/hg/crosstool-ng/rev/b24ead1a5947
>
> So now we just let gcc figure it out.

Excellent, thanks for pursuing this.

> As for the inconsistent check in libjava and the previous change to remove
> enable-symvers from ct-ng in mind, this can probably be resolved as invalid
> unless you'd like to just add gnu|sun to the
> libjava_cv_anon_version_script=yes;; case. (attaching patch to give an
> example).

I'll certainly have a look: perhaps this will prompt me to unify the
symbol versioning configure support across all gcc target libraries :-)

> wrt all of the extra configuration options, it would be very appreciated if in
> another thread we could discuss some of them. I'm sure a lot of the options we
> have for building binutils and gcc are ported forward from the older crosstool
> scripts and aren't needed anymore. My theory on that has been: if it ain't
> broke, don't fix it
> ...until now.

We can certainly do this, either in private mail or on some mailing list
(unless I don't have to subscribe to yet another one :-).

Thanks.
Rainer

[Bug middle-end/49602] [4.7 Regression] verify_ssa failed (definition does not dominate use) with "-O2 -g"

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-07-01 
14:52:30 UTC ---
The problem is that for the debug uses before going into SSA we obviously don't
want the uses to affect code generation and thus we don't call
set_livein_block.
Unfortunately that means get_current_def is sometimes incorrect during rewrite_

--- tree-into-ssa.c.jj 22011-06-23 10:13:58.0 +0200
+++ tree-into-ssa.c 2011-07-01 16:23:04.0 +0200
@@ -1343,7 +1343,15 @@ rewrite_debug_stmt_uses (gimple stmt)
 }
 }
   else
-def = get_current_def (var);
+{
+  def = get_current_def (var);
+  if (def
+  && !SSA_NAME_IS_DEFAULT_DEF (def)
+  && gimple_bb (SSA_NAME_DEF_STMT (def)) != gimple_bb (stmt)
+  && !dominated_by_p (CDI_DOMINATORS, gimple_bb (stmt),
+  gimple_bb (SSA_NAME_DEF_STMT (def
+def = NULL;
+}
   if (def == NULL)
 {
   gimple_debug_bind_reset_value (stmt);

seems to fix the ICE, the question is if get_current_def can be trusted to be
the right SSA_NAME even after this check.
I guess if the definition bb is the same as stmt's bb, it can, similarly
if get_phi_state (var) == NEED_PHI_STATE_NO (plus the dominated_by_p check
above), or if bitmap_bit_p (get_def_blocks_for (var)->livein_blocks, gimple_bb
(stmt)->index).  Any other cases?

[Bug ada/49608] New: Ada option handling kludges

[jsm28 at gcc dot gnu.org]

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

   Summary: Ada option handling kludges
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: js...@gcc.gnu.org


The Ada front end has some option-handling kludges in ada/gcc-interface/misc.c
that should be implemented in a cleaner way:

* gnat_init_options reconstitutes a save_argv array for back_end.adb; it should
pass logical options in some form rather than back_end.adb reparsing textual
options.

* gnat_post_options initializes variables optimize, optimize_size,
flag_compare_debug and flag_stack_check, using #undef on the macro definitions
first, because the Ada code expects to access C variables under those names but
the generic compiler now puts them in global_options.  Ada should have its own
names for these settings, not conflicting with the C macros, so the #undef hack
isn't needed.

[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c

[dave.anglin at bell dot net]

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

--- Comment #7 from dave.anglin at bell dot net 2011-07-01 15:32:35 UTC ---
On 1-Jul-11, at 6:47 AM, hubicka at gcc dot gnu.org wrote:

> Hi,
> here is fixed version that does not warn.  Can someone try it out,  
> please?

While test on darwin9 and hpux.

Dave

[Bug c++/49609] New: No code emitted for address-taken instances of function templates

[srk31 at srcf dot ucam.org]

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

   Summary: No code emitted for address-taken instances of
function templates
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sr...@srcf.ucam.org


In the following code

template 
inline
void *
value_convert_function(From *from, To *to)
{
return 0;
}

void *(*my_table[])(void *, void *) = {
reinterpret_cast(&(value_convert_function)),
0
};

void *(*my_function_ptr)(void*, void *)
 = reinterpret_cast(&(value_convert_function));

void *(*my_uncast_function_ptr)(bool *, bool *)
 = &(value_convert_function);


... I expect to see code output for each of the three template instances that I
take the address of. But only the last one is actually generated. 

$ objdump -t test.o | c++filt

test.o: file format elf64-x86-64

SYMBOL TABLE:
 ldf *ABS*   test.cc
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .text._Z22value_convert_functionIbbEPvPT_PT0_ 
 .text._Z22value_convert_functionIbbEPvPT_PT0_
 ld  .note.GNU-stack
.note.GNU-stack
 ld  .eh_frame   .eh_frame
 ld  .comment    .comment
 ld  .group  .group
 g O .data  0010 my_table
 *UND*   void*
value_convert_function(double*, double*)
0010 g O .data  0008 my_function_ptr
 *UND*   void*
value_convert_function(float*, float*)
0018 g O .data  0008 my_uncast_function_ptr
  wF .text._Z22value_convert_functionIbbEPvPT_PT0_ 
0013 void* value_convert_function(bool*, bool*)


I notice that in g++ 4.4, the code for the first two is rejected with a clearly
bogus error ("address of overloaded function with no contextual type
information").  In 4.5.1 and later, it is accepted but yields an undefined
symbol (causing link errors in my actual use-case). This also happens in the
latest sources I've tried, which are a fairly recent subversion checkout:

$ g++ --version | head -n1
g++  (GCC) 4.7.0 20110417 (experimental)

One attempted workaround was to type my table entries as void *, insert no cast
and compile with -fpermissive (to get the implicit conversion to void*). But
that reverts to the 4.4-style bogus error, even in later versions:

void *my_voidptr_table[] = { &value_convert_function, 0 };

test.cc:20: error: cannot resolve overloaded function ‘value_convert_function’
based on conversion to type ‘void*’

My workaround for now is to separately instantiate everything I want to put in
the table, by defining a bunch of static function pointers. 

Thanks for reading!

[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|mips64: Unrecognizable insn |mips64: o64 Unrecognizable
   |when one noreturn function  |insn when one noreturn
   |calling another noreturn|function calling another
   |function|noreturn function
   Severity|major   |normal

--- Comment #2 from Andrew Pinski  2011-07-01 
15:49:41 UTC ---
O64 is the least supported ABI in GCC for MIPS.

[Bug middle-end/47406] gcc.dg/torture/builtin-modf-1.c FAILs on IRIX 6.5

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.01 16:06:51
 CC||jsm28 at gcc dot gnu.org
 Depends on||48341
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #3 from Rainer Orth  2011-07-01 16:06:51 UTC 
---
I've just found that if I remove the long double part of TESTIT_MODF, the test
passes.  So this may well be related to PR c/48341.

[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.01 16:08:24
 AssignedTo|unassigned at gcc dot   |iains at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #6 from Iain Sandoe  2011-07-01 16:08:24 
UTC ---
Created attachment 24655
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24655
make sure that the size of the dyld_stub_binding_helper is adjusted for arch.

please try this -
-  it resolves the problem for me on a cross to darwin8 from powerpc-darwin9.

If I have a chance over the w/e I'll boot the G5 into D8 and try a full test
cycle.

[Bug c++/49609] No code emitted for address-taken instances of function templates

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-07-01 
16:19:27 UTC ---
The C++ standard lists the contexts in which an overloaded function name can be
used without arguments, and reinterpret_cast is not one of them.

Based on that, I would think G++ 4.4 was correct to reject the code.  I note
that clang++ gives the same behaviour as G++ 4.7 (accepts the code but does not
instantiate the function template)

You can make it work by using an explicit type conversion to the correct type
before doing the reinterpret_cast:

void *(*my_function_ptr)(void*, void *)
 = reinterpret_cast(
(void*(*)(float*,float*))&(value_convert_function) );

[Bug c++/49495] -O3 causes error message "edge points to wrong declaration:"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.01 16:26:01
 Ever Confirmed|0   |1

--- Comment #1 from Martin Jambor  2011-07-01 
16:26:01 UTC ---
Happens also with -fno-inline -fno-devirtualize.

[Bug c++/49085] Crash with SIGSEGV during compilation.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #4 from Jason Merrill  2011-07-01 
16:32:59 UTC ---
Fixed for 4.7.0

[Bug c++/49609] No code emitted for address-taken instances of function templates

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-07-01 
16:34:32 UTC ---
(In reply to comment #1)
> The C++ standard lists the contexts in which an overloaded function name can 
> be
> used without arguments, and reinterpret_cast is not one of them.
> 
> Based on that, I would think G++ 4.4 was correct to reject the code.  I note
> that clang++ gives the same behaviour as G++ 4.7 (accepts the code but does 
> not
> instantiate the function template)

Ah, I think this behaviour is covered by the new text added to 13.4 p2 by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#115

That paragraph says that if template argument deduction succeeds then an
instantiation is generated. In your case deduction doesn't succeed because the
target type is not available.  The note added by DR 115 says that the
specialization can be identified if there's a template argument list, which is
what happens in your example, but it doesn't say that the function template is
instantiated in that case.

> You can make it work by using an explicit type conversion to the correct type
> before doing the reinterpret_cast:
> 
> void *(*my_function_ptr)(void*, void *)
>  = reinterpret_cast(
> (void*(*)(float*,float*))&(value_convert_function) );

You can also make it work by not specifying an explicit template argument list
and letting them be deduced:

void *(*my_function_ptr)(void*, void *)
  = reinterpret_cast(
(void*(*)(float*,float*))&value_convert_function);

As 13.4 p2 says, that causes the template to be instantiated.

[Bug debug/49522] Divide by zero in validate_subreg in emit-rtl.c:695

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.01 16:35:45
 CC||ramana at gcc dot gnu.org
  Component|middle-end  |debug
 Ever Confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  2011-07-01 
16:35:45 UTC ---

bt
#0  0x08270d79 in validate_subreg (omode=VOIDmode, imode=SImode,
reg=0xb7dae7e8, offset=0) at
/home/ramrad01/sources/fsf/trunk/gcc/emit-rtl.c:695
#1  0x08270fa0 in gen_rtx_SUBREG (mode=VOIDmode, reg=0xb7dae7e8, offset=0) at
/home/ramrad01/sources/fsf/trunk/gcc/emit-rtl.c:775
#2  0x08271027 in gen_lowpart_SUBREG (mode=VOIDmode, reg=0xb7dae7e8) at
/home/ramrad01/sources/fsf/trunk/gcc/emit-rtl.c:790
#3  0x0821c879 in dead_debug_insert_before (all_blocks=0x8dc1364) at
/home/ramrad01/sources/fsf/trunk/gcc/df-problems.c:3197
#4  df_note_bb_compute (all_blocks=0x8dc1364) at
/home/ramrad01/sources/fsf/trunk/gcc/df-problems.c:3399
#5  df_note_compute (all_blocks=0x8dc1364) at
/home/ramrad01/sources/fsf/trunk/gcc/df-problems.c:3452
#6  0x08215c16 in df_analyze_problem (dflow=0x8ddf078,
blocks_to_consider=0x8dc1364, postorder=0x8dc6ad0, n_blocks=3) at
/home/ramrad01/sources/fsf/trunk/gcc/df-core.c:1152
#7  0x08215e6b in df_analyze () at
/home/ramrad01/sources/fsf/trunk/gcc/df-core.c:1249
#8  0x08919a8b in sched_init () at
/home/ramrad01/sources/fsf/trunk/gcc/haifa-sched.c:3487
#9  0x08920472 in haifa_sched_init () at
/home/ramrad01/sources/fsf/trunk/gcc/haifa-sched.c:3526
#10 0x084b87aa in schedule_insns () at
/home/ramrad01/sources/fsf/trunk/gcc/sched-rgn.c:3302
#11 0x084b8e3d in rest_of_handle_sched2 () at
/home/ramrad01/sources/fsf/trunk/gcc/sched-rgn.c:3532
#12 0x0845bb99 in execute_one_pass (pass=0x8c2fd20) at
/home/ramrad01/sources/fsf/trunk/gcc/passes.c:2059
#13 0x0845becd in execute_pass_list (pass=0x8c2fd20) at
/home/ramrad01/sources/fsf/trunk/gcc/passes.c:2114
#14 0x0845bee0 in execute_pass_list (pass=0x8c2f6a0) at
/home/ramrad01/sources/fsf/trunk/gcc/passes.c:2115
#15 0x0845bee0 in execute_pass_list (pass=0x8c2f660) at
/home/ramrad01/sources/fsf/trunk/gcc/passes.c:2115
#16 0x08575621 in tree_rest_of_compilation (fndecl=0xb7d71c00) at
/home/ramrad01/sources/fsf/trunk/gcc/tree-optimize.c:416
#17 0x081f8482 in cgraph_expand_function (node=0xb7cfd668) at
/home/ramrad01/sources/fsf/trunk/gcc/cgraphunit.c:1792
#18 0x081fa41d in cgraph_expand_all_functions () at
/home/ramrad01/sources/fsf/trunk/gcc/cgraphunit.c:1851
#19 cgraph_optimize () at
/home/ramrad01/sources/fsf/trunk/gcc/cgraphunit.c:2121
#20 0x081fab55 in cgraph_finalize_compilation_unit () at
/home/ramrad01/sources/fsf/trunk/gcc/cgraphunit.c:1292
#21 0x080d4090 in c_write_global_declarations () at
/home/ramrad01/sources/fsf/trunk/gcc/c-decl.c:9844
#22 0x08508bc4 in compile_file (argc=5, argv=0xb394) at
/home/ramrad01/sources/fsf/trunk/gcc/toplev.c:571
#23 do_compile (argc=5, argv=0xb394) at
/home/ramrad01/sources/fsf/trunk/gcc/toplev.c:1908
#24 toplev_main (argc=5, argv=0xb394) at
/home/ramrad01/sources/fsf/trunk/gcc/toplev.c:1980
#25 0x081740cb in main (argc=5, argv=0xb394) at
/home/ramrad01/sources/fsf/trunk/gcc/main.c:36
(gdb) 


It appears as though we are attempting to create a subreg of a clobber
(const_int 0) . 


Ramana

[Bug c++/49495] -O3 causes error message "edge points to wrong declaration:"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Martin Jambor  2011-07-01 
16:36:58 UTC ---
The problem here is that cgraph_redirect_edge_call_stmt_to_callee(0 is
never called because inline_transform() is never called.  (I have
verified by putting gcc_unreachable to both, I did not believe my
gdb).

[Bug c++/48883] ?: ternary operator fails in certain contexts - link error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/48883] ?: ternary operator fails in certain contexts - link error

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-07-01 
16:50:36 UTC ---
Is this related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49609#c2 ?

The ternary operator is not one of the contexts listed in 13.4 [over.over] p1
either.  The explicit argument list uniquely identifies the specialization, so
myMax is an lvalue for the function template, but I don't see any 
requirement that it gets instantiated

[Bug debug/49408] member function template id not matching linkage name

[jkratoch at gcc dot gnu.org]

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

--- Comment #2 from jkratoch at gcc dot gnu.org 2011-07-01 17:16:51 UTC ---
Author: jkratoch
Date: Fri Jul  1 17:16:44 2011
New Revision: 175761

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175761
Log:
libiberty/
PR debug/49408
* cp-demangle.c (d_print_comp): Suppress argument list for function
references by the '&' unary operator.  Keep also already processed
variant without the argument list.  Suppress argument list types for
function call used in an expression.
* testsuite/demangle-expected: Fix excessive argument list types in
`test for typed function in decltype'.  New testcase for no argument
list types printed.  3 new testcases for function references by the
'&' unary operator..

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c
trunk/libiberty/testsuite/demangle-expected

[Bug debug/49408] member function template id not matching linkage name

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jan Kratochvil  
2011-07-01 17:19:06 UTC ---
Checked in.

[Bug tree-optimization/49610] New: Segfault with -ftree-vectorize (or -O3)

[arthur.j.odwyer at gmail dot com]

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

   Summary: Segfault with -ftree-vectorize (or -O3)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com


Created attachment 24656
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24656
Output of "ajo-gcc -std=c99 -O -ftree-vectorize test.c -v"

This failure reproduces for me with svn revision 175547
(2011-06-27). I'm on Ubuntu 10.10, x86-64.

cat >test.c < 1);
}
}
EOF
gcc -std=c99 -O -ftree-vectorize test.c 

test.c: In function ‘func_13’:
test.c:2:6: internal compiler error: Segmentation fault

Program received signal SIGSEGV, Segmentation fault.
flow_bb_inside_loop_p (loop=0x77ec1f68, bb=0x0) at ../../gcc/cfgloop.c:776
776  source_loop = bb->loop_father;
(gdb) backtrace
#0  flow_bb_inside_loop_p (loop=0x77ec1f68, bb=0x0)
at ../../gcc/cfgloop.c:776
#1  0x009cb3bb in vect_is_slp_reduction (loop_info=0x14c56e0, phi=XXX)
at ../../gcc/tree-vect-loop.c:1807
#2  vect_is_simple_reduction_1 (loop_info=0x14c56e0, phi=XXX)
at ../../gcc/tree-vect-loop.c:2269
[...]


This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04,
https://github.com/Quuxplusone/csmith/), using the following command line:
csmith --no-paranoid --longlong --pointers --arrays --no-jumps --consts
--no-volatiles --checksum --no-divs --muls --bitfields --packed-struct -s
1439171589

[Bug c++/48593] Wrong return type when applying address operator to inherited, template dependend member, using a typedef

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/49609] No code emitted for address-taken instances of function templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #3 from Jason Merrill  2011-07-01 
17:54:27 UTC ---
That's a pretty strained reading.  Even if that were pedantically what the
standard says, it would clearly be an oversight.

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

[Bug c++/48883] ?: ternary operator fails in certain contexts - link error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||srk31 at srcf dot ucam.org

--- Comment #4 from Jason Merrill  2011-07-01 
17:54:27 UTC ---
*** Bug 49609 has been marked as a duplicate of this bug. ***

[Bug c++/48261] internal compiler error: in lookup_template_function, at cp/pt.c:6227

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/49609] No code emitted for address-taken instances of function templates

[srk31 at srcf dot ucam.org]

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

--- Comment #4 from Stephen Kell  2011-07-01 
18:09:07 UTC ---
(In reply to comment #2)
> That paragraph says that if template argument deduction succeeds then an
> instantiation is generated. In your case deduction doesn't succeed because the
> target type is not available.  The note added by DR 115 says that the
> specialization can be identified if there's a template argument list, which is
> what happens in your example, but it doesn't say that the function template is
> instantiated in that case.

Ah, I see... I was thinking that the error was spurious because I hadn't
overloaded the function, but I guess the template argument-dependence defines a
family of overloads.

> > You can make it work by using an explicit type conversion to the correct 
> > type
> > before doing the reinterpret_cast:
> > 
> > void *(*my_function_ptr)(void*, void *)
> >  = reinterpret_cast(
> > (void*(*)(float*,float*))&(value_convert_function) );
> 
> You can also make it work by not specifying an explicit template argument list
> and letting them be deduced:
> 
> void *(*my_function_ptr)(void*, void *)
>   = reinterpret_cast(
> (void*(*)(float*,float*))&value_convert_function);

Cool -- thanks for this! That teaches me for thinking I can get away without
ever using C-style casts in C++

[Bug c++/49495] -O3 causes error message "edge points to wrong declaration:"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  2011-07-01 
18:11:48 UTC ---
Actually no, the problem is that the verifier is not alias-aware in this test. 
I have a fix, just need to polish and test it.

[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8

[fang at csl dot cornell.edu]

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

--- Comment #7 from David Fang  2011-07-01 
18:13:52 UTC ---
(In reply to comment #6)
> Created attachment 24655 [details]
> make sure that the size of the dyld_stub_binding_helper is adjusted for arch.
> 
> please try this -
> -  it resolves the problem for me on a cross to darwin8 from powerpc-darwin9.
> 
> If I have a chance over the w/e I'll boot the G5 into D8 and try a full test
> cycle.

Hi Iain, thanks for looking into this.
The above patch worked for me when I tried to re-run it in my previously failed
build dir.  I didn't try to resume the bootstrap from there.  

At the same time I also kicked off a --disable-multilib build. 
Also running on dual 533MHz G4, -j2 here, so results in half-a-day, though I
might be slow responding over the weekend.  :)

[Bug debug/49546] class DW_AT_name does not match method's linkage name prefix

[jan.kratochvil at redhat dot com]

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

--- Comment #2 from Jan Kratochvil  
2011-07-01 18:35:22 UTC ---
New GDB test:
http://sourceware.org/ml/gdb-cvs/2011-07/msg00020.html
gdb.cp/temargs.exp: test type of F in k3_m
gdb.cp/temargs.exp: test value of F in k3_m

[Bug c++/49609] No code emitted for address-taken instances of function templates

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-07-01 
18:56:19 UTC ---
(In reply to comment #3)
> That's a pretty strained reading.  Even if that were pedantically what the
> standard says, it would clearly be an oversight.

ok, good!  I would have assumed it was meant to work except that clang gives
exactly the same behaviour, so I started looking for reasons why.


(In reply to comment #4)
> > You can also make it work by not specifying an explicit template argument 
> > list
> > and letting them be deduced:
> > 
> > void *(*my_function_ptr)(void*, void *)
> >   = reinterpret_cast(
> > (void*(*)(float*,float*))&value_convert_function);
> 
> Cool -- thanks for this! That teaches me for thinking I can get away without
> ever using C-style casts in C++

You can do it without -style casts, using static_cast:

void *(*my_function_ptr)(void*, void *)
  = reinterpret_cast(
static_cast(&value_convert_function));

or with a functional-style cast:

typedef void*(*func_type)(float*,float*);

void *(*my_function_ptr)(void*, void *)
  = reinterpret_cast(
func_type(&value_convert_function));

[Bug tree-optimization/49610] Segfault with -ftree-vectorize (or -O3)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.07.01 19:17:53
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2011-07-01 
19:17:53 UTC ---
Revision 174379 is OK, r174433 is not.

[Bug target/43804] [4.5/4.6 regression] ICE in reload_cse_simplify_operands

[tg at mirbsd dot org]

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

--- Comment #25 from Thorsten Glaser  2011-07-01 19:36:06 
UTC ---
Applied the diff from svn r172920 to the Debian gcc-4.6 source package as well;
let’s see whether this works.

[Bug tree-optimization/49610] Segfault with -ftree-vectorize (or -O3)

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-07-01 
19:44:36 UTC ---
It could be due to revision 174425:

Author:irar
Date:Mon May 30 07:15:31 2011 UTC (4 weeks, 4 days ago)
Changed paths:5
Log Message:
PR tree-optimization/49199
* tree-vect-loop.c (vect_is_slp_reduction): Check that the 
non-reduction operands are either defined in the loop or
by induction.

[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Jonathan Wakely  2011-07-01 
19:56:48 UTC ---
patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00086.html

[Bug c++/48883] ?: ternary operator fails in certain contexts - link error

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-07-01 
20:24:16 UTC ---
Author: jason
Date: Fri Jul  1 20:24:08 2011
New Revision: 175764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175764
Log:
PR c++/48883
PR c++/49609
* pt.c (resolve_nondeduced_context): Call mark_used.

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

[Bug c++/48593] Wrong return type when applying address operator to inherited, template dependend member, using a typedef

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-07-01 
20:24:29 UTC ---
Author: jason
Date: Fri Jul  1 20:24:25 2011
New Revision: 175765

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175765
Log:
PR c++/48593
* pt.c (tsubst_qualified_id): Check PTRMEM_OK_P.
* tree.c (build_qualified_name): Set PTRMEM_OK_P.
* semantics.c (finish_parenthesized_expr): Clear PTRMEM_OK_P on
SCOPE_REF, too.
* cp-tree.h (PTRMEM_OK_P): Apply to SCOPE_REF, too.
(QUALIFIED_NAME_IS_TEMPLATE): Switch to lang flag 1.

Added:
trunk/gcc/testsuite/g++.dg/template/qualified-id4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49609] No code emitted for address-taken instances of function templates

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-07-01 
20:24:15 UTC ---
Author: jason
Date: Fri Jul  1 20:24:08 2011
New Revision: 175764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175764
Log:
PR c++/48883
PR c++/49609
* pt.c (resolve_nondeduced_context): Call mark_used.

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

[Bug c++/48261] internal compiler error: in lookup_template_function, at cp/pt.c:6227

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-07-01 
20:24:41 UTC ---
Author: jason
Date: Fri Jul  1 20:24:38 2011
New Revision: 175766

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175766
Log:
PR c++/48261
* pt.c (lookup_template_function): Handle non-function.

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

[Bug c++/48883] ?: ternary operator fails in certain contexts - link error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  2011-07-01 
20:51:38 UTC ---
Fixed for 4.7.

[Bug c++/48593] Wrong return type when applying address operator to inherited, template dependend member, using a typedef

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-07-01 
20:52:07 UTC ---
Fixed for 4.7.

[Bug c++/48261] internal compiler error: in lookup_template_function, at cp/pt.c:6227

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-07-01 
20:52:36 UTC ---
Fixed for 4.7.

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  2011-07-01 
21:10:46 UTC ---
(In reply to comment #6)
> +  DECL_COMDAT (node->decl) = DECL_COMDAT (decl_node->decl);
>   if (DECL_ONE_ONLY (decl_node->decl))
> {
> - DECL_COMDAT (node->decl) = DECL_COMDAT (decl_node->decl);

Looks good to me.

> Jason, the whole code copying visibilities to thunk decls is just a hack.  Do
> you think you can make C++ FE to put proper visibility flags on thunks and
> same body aliases?

I can certainly copy some flags across.  But it seems rather cumbersome to have
to manage same_comdat_group in the front end.  There's also the issue that in
order to set DECL_COMDAT_GROUP (and thus DECL_ONE_ONLY) we need to build the
mangled name for the main decl which otherwise might not be needed.

[Bug c++/49589] [C++0x] Internal compile error at decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.07.01 21:15:19
 CC||jason at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2011-07-01 
22:24:48 UTC ---
Author: redi
Date: Fri Jul  1 22:24:42 2011
New Revision: 175771

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175771
Log:
2011-07-01  Jonathan Wakely  

PR c++/49605
* init.c (build_delete): Only warn for sfk_deleting_destructor.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/delete-non-virtual-dtor.C

[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jonathan Wakely  2011-07-01 
23:43:29 UTC ---
done

[Bug inline-asm/49611] New: Inline asm should support input/output of flags

[scovich at gmail dot com]

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

   Summary: Inline asm should support input/output of flags
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: scov...@gmail.com


The main reason I find myself writing inline asm is to do "clever" things with
the flags register, especially in conjunction with unusual instructions. 

Some examples:

1. Using the sparc brz instruction if the compiler doesn't emit it (e.g. bug
#40067). 

2. Using the carry flag in x86 to determine whether the unsigned comparison a
!= b was greater or less than, using subtract-with-borrow (seen in gnu libc):
"sbb %eax, %eax; sbb $-1, %eax" leaves %eax containing -1 if a < b and +1 if a
> b. 

3. AMD's "Advanced Synchronization Facility" which proposes a jmp-like
instruction for starting hardware transactions. Its effect is similar to
fork(): on the first time past sets flags and eax to zero; a transaction
failure resumes from the same PC, but with eax and flags set to reflect an
error code. 

4. In my experience, the main reason people would want asm goto to allow
outputs is because they can't export flags (otherwise the goto can become
control flow in C/C++).

In all three cases the inline asm becomes needlessly long simply because uses
of the flags generated within the asm block will only work reliably within that
asm block (including branches, loops, etc.).

Consider the following concrete example:

#define EOL "\n"
#define EOLT EOL "\t"
long pstrcmp(unsigned char const* a, unsigned char const* b, long* pout, long
pin=0) {
long delta, tmp;
asm("#" EOL
"1:"EOLT
"movzb  (%[a], %[n]), %k[tmp]"  EOLT
"movzb  (%[b], %[n]), %k[delta]"EOLT
"cmpb   %b[delta], %b[tmp]" EOLT
"jnz2f" EOLT
"testb  %b[tmp], %b[tmp]"   EOLT
"jz 3f" EOLT
"sub%[m1], %[n]"EOLT
"jmp1b" EOL
"2:"EOLT
"sbb%[delta], %[delta]" EOLT
"sbb%[m1], %[delta]"EOL
"3:"
: [a] "+r"(a), [b] "+r"(b), [n] "+r"(pin),
  [delta] "=&q"(delta), [tmp] "=&q"(tmp)
: [m1] "i"(-1)
);
*pout = pin;
return delta;
}

With inline asm support for flags it would look more like this:

long pstrcmp(unsigned char const* a, unsigned char const* b, long* pout, long
pin=0) {
long delta, tmp;
  again:
if (a[pin] == b[pin]) {
if (a[pin] != 0) {
pin++;
goto again;
}
else {
delta = b[pin];
}
}
else {
asm("sbb%[delta], %[delta]" EOLT
"sbb%[m1], %[delta]"
: [delta] "=&r"
: [m1] "i"(-1), "flags"(a[pin] != b[pin])
);
}
*pout = pin;
return delta;
}

The intent is that the "flags" input specifier tells the compiler to arrange
for flags to be set at entry to the asm block as if the expression passed to it
had just completed (the compiler would warn/error if it were unclear the effect
evaluating the expression would have on flags). In theory the optimizer should
be able to eliminate common expressions and shuffle code to avoid materializing
the flags at all. 

Using flags as output (perhaps to pass as input to another inline asm block)
might look like this:

asm("cmp %0, %1" : "=flags"(flags) : "r"(a), "r"(b));
...
asm("jz 1f" : : "flags"(flags));

The flags should probably take type 'int' in C.

Ideally, the compiler could even recognize and optimize patterns like this:

asm("cmp %0, %1" : "=flags"(flags) : "r"(a), "r"(b));
enum { CF=1 };
if (flags & CF) {
...
}
else if (flags & ZF) {
...
}

[Bug c++/49598] [C++0x] Ice on lambda with implicit capture by value.

[3dw4rd at verizon dot net]

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

--- Comment #2 from Ed Smith-Rowland <3dw4rd at verizon dot net> 2011-07-02 
00:52:57 UTC ---
This compiled on gcc-4.5 but the answer is junk.

ed@bad-horse:~$ g++ -std=c++0x -o lamb2 lamb2.cpp
ed@bad-horse:~$ ./lamb2 
value capture
i: 10
ir: 617467132
&i: 0x7fff24cdcce0
&ir: 0x7fff24cdcce4


Compiler version of compile but junk answer:

ed@bad-horse:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)

[Bug libfortran/48906] Wrong rounding results with -m32

[jvdelisle at gcc dot gnu.org]

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

--- Comment #39 from Jerry DeLisle  2011-07-02 
01:32:42 UTC ---
Very Good, I will work toward this end.

[Bug lto/49612] New: LTO cannot link objects

[krisztian.kocsis at optimaster dot eu]

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

   Summary: LTO cannot link objects
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: krisztian.koc...@optimaster.eu


I made a toolchain for embedded Geode CPUs but if LTO is enabled (-flto) then
the compiler cannot link objects.

Piece of config.log from fuse:

configure:3352: checking whether the C compiler works
configure:3374:
/project/optinux/toolchains/geode-lx-r1/bin/i686-optinux-linux-gnu-gcc -pipe
--param l1-cache-line-size=32 --param l1-cache-size=64 --param
l2-cache-size=128 -march=i686 -mtune=geode -mmmx -m3dnow -g -O2 -fmodulo-sched
-fgcse-after-reload -ftree-loop-linear -fivopts -flto 
-D__optinux_target_geode_lx_r1__ -D__optinux_target__ -D__optinux__ -Wl,-O1
-Wl,-z,combreloc -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,noexecheap
-Wl,--enable-new-dtags -Wl,--gc-sections -Wl,--hash-style=both
../sysdeps/generic/initfini.c:86:1: error: '_init' has already been defined
../sysdeps/generic/initfini.c:86:1: note: previously defined here
../sysdeps/generic/initfini.c:63:1: error: 'dummy' has already been defined
../sysdeps/generic/initfini.c:63:1: note: previously defined here
../sysdeps/generic/initfini.c:112:1: error: '_fini' has already been defined
../sysdeps/generic/initfini.c:112:1: note: previously defined here
lto-wrapper:
/project/optinux/toolchains/geode-lx-r1/bin/i686-optinux-linux-gnu-gcc returned
1 exit status
lto-wrapper: deleting LTRANS file /tmp/ccoThRvh.lto.o: No such file or
directory
collect2: lto-wrapper returned 1 exit status
configure:3378: $? = 1
configure:3416: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "fuse"
| #define PACKAGE_TARNAME "fuse"
| #define PACKAGE_VERSION "2.8.5"
| #define PACKAGE_STRING "fuse 2.8.5"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define PACKAGE "fuse"
| #define VERSION "2.8.5"
| /* end confdefs.h.  */
|.
| int
| main ()
| {
|.
|   ;
|   return 0;
| }
configure:3421: error: in `/project/optinux/products/mpbr/.builds/fuse-2.8.5':
configure:3423: error: C compiler cannot create executables
See `config.log' for more details

If I remove '-flto' then everything works OK!

gmp-5.0.2
mpfr-3.0.1
ppl-0.10.2
cloog-ppl-0.15.11
mpc-0.9
libelf-0.8.13
linux-2.6.35 (headers)
binutils-2.21
gcc-4.5.3
eglibc-2.14