[Bug lto/47891] GCC 4.6/4.7 LTO not worked reliable on Windows target

[dongsheng.song at gmail dot com]

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

--- Comment #7 from Dongsheng Song  2011-03-15 
08:01:34 UTC ---
(In reply to comment #6)
> > Since gcc 4.6 branched, gcc trunk and 4.6 branch both have this issue now.
> 
> It is not a GCC bug, it's a Binutils bug. The patch
>  fixes this issue, 
> but
> it is not approved yet.

Yes, when I use hjl/lto-mixed branch of binutils:

[[[
commit fb6867660be917535a62b35e554dc222a74d92a5
Merge: e3654c4 a0a68e5
Author: H.J. Lu 
Date:   Sat Mar 12 09:29:46 2011 -0800

Merge remote-tracking branch 'hjl/intel/lto-mixed' into hjl/lto-mixed
]]]

gcc 4.6 on mingw-w64 (32 bit and 64 bit) target works fine.

[Bug c++/48132] New: Internal compiler error on array of std::complex with -std=cxx0x

[martin.kronbichler at it dot uu.se]

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

   Summary: Internal compiler error on array of std::complex with
-std=cxx0x
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: martin.kronbich...@it.uu.se


gcc 4.6.0 weekly snapshot 20110312

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran,objc,obj-c++,go
--prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --without-included-gettext
--enable-threads=posix --program-suffix=-4.6 --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror
--with-arch-32=i486 --with-tune=core2 --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-cpu=core2
Thread model: posix
gcc version 4.6.0 20110312 (experimental) (GCC)

With the following code:

#include 
void test () {
  std::complex array[] = { std::complex(0,1) };
}

I get:
$ g++ -std=c++0x  -c complex_test.cc -o complex_test.o
complex_test.cc: In function ‘void test()’:
complex_test.cc:4:62: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

The code compiles fine without -std=c++0x, and it is also fine with gcc 4.5.2.

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[mikpe at it dot uu.se]

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

--- Comment #16 from Mikael Pettersson  2011-03-15 
08:44:29 UTC ---
(In reply to comment #14)
> Created attachment 23614 [details]
> patch
> 
> testing appreciated

Applied to gcc 4.6/4.5/4.4 then bootstrapped and regression tested on
m68k-linux with --enable-languages=c,c++.  No bootstrap failures or test suite
regressions.  Fixed pr42956.c FAILs with 4.5/4.4.

[Bug fortran/42954] [4.5/4.6/4.7 regression] TARGET_*_CPP_BUILDINS issues with gfortran

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

[Bug c++/48132] [4.6/4.7 Regression] [C++0x] Internal compiler error on array of std::complex with -std=c++0x

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 08:59:36
Summary|Internal compiler error on  |[4.6/4.7 Regression]
   |array of std::complex with  |[C++0x] Internal compiler
   |-std=c++0x  |error on array of
   ||std::complex with
   ||-std=c++0x
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-03-15 
08:59:36 UTC ---
confirmed

[Bug tree-optimization/48129] [4.7 Regression]: gcc.c-torture/execute/builtins/snprintf-chk.c ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.15 09:09:37
  Component|regression  |tree-optimization
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

[Bug tree-optimization/45844] FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Target|powerpc-apple-darwin9   |powerpc-apple-darwin9,
   ||powerpc64-linux
 CC||amodra at gmail dot com

--- Comment #4 from Alan Modra  2011-03-15 09:18:31 
UTC ---
Seen also on powerpc64-linux.  The problem here is that the vsx_splat_V2DF/V2DI
load and store instructions only support mem[reg] or mem[reg+reg] addressing,
but the MEM mode is not a vsx vector mode.  So reg_offset_addressing_ok_p used
in rs6000_legitimate_address_p and other address predicates returns true,
wrongly allowing lo_sum addresses.

[Bug other/48111] libquadmath: strtoflt128 bug on MinGW

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-03-15 
09:20:20 UTC ---
That testcase has a small bug (noticed when seeing %Qa != %Qa in the output,
affects only non-glibc targets):

--- test.c.jj2011-03-15 10:14:33.0 +0100
+++ test.c2011-03-15 10:15:00.0 +0100
@@ -193,7 +193,7 @@ main (int argc, char ** argv)
 quadmath_snprintf (tb1, sizeof tb1, "%Qa",
strtoflt128 (ltests[n].str, NULL));
 quadmath_snprintf (tb2, sizeof tb2, "%Qa", ltests[n].l);
-printf ("ltests[%d]: %Qa != %Qa\n", n, tb1, tb2);
+printf ("ltests[%d]: %s != %s\n", n, tb1, tb2);
 #endif
 status = 1;
   }

Anyway, it is hard to guess what's wrong and I don't have access to any mingw
targets.  So, this needs to be debugged by someone with mingw access, ideally
side by side with a Linux debugging session to see where the differences start
appearing.  Kai, could you please look at it?

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  2011-03-15 
09:20:47 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Yeah.  Confirmed.
> > 
> > You need -Wframe-larger-than=500 -Werror=frame-larger-than which hopefully
> > doesn't reset the value to 1.
> 
> It doesn't, but not for the reason you would hope.  8-)

These are indeed several bugs related to not handling W options with parameters
properly. Check in options.c (enable_warning_as_error) for how -Werror=option
is handled and...

> /tmp/x.c:3:1: error: the frame size of 32 bytes is larger than 1 bytes
> [-Werror=frame-larger-than=]

diagnostics.c for how this is printed. This should print
-Werror=frame-larger-than=1 (without -Werror, does it print
[-Wframe-larger-than=1]) ?

I guess similar problems arise with Wlarger-than=, Woverflow= and
Wstrict-aliasing= (but perhaps the two latter are handled differently).

Fixing it should be fairly trivial.

[Bug libfortran/47883] libgfortran configuration should use AC_LINK_IFELSE instead of AC_TRY_LINK

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-03/msg00804.htm
   ||l

--- Comment #2 from Francois-Xavier Coudert  
2011-03-15 09:33:57 UTC ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00804.html

[Bug rtl-optimization/47166] [4.5 Regression] SpecCpu2000 Ammp segfaults for ARM with -O3 -mthumb

[rsandifo at gcc dot gnu.org]

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

--- Comment #33 from rsandifo at gcc dot gnu.org  
2011-03-15 09:38:10 UTC ---
Author: rsandifo
Date: Tue Mar 15 09:38:07 2011
New Revision: 170982

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170982
Log:
gcc/testsuite/
PR rtl-optimization/47166
* gcc.c-torture/execute/postmod-1.c: New test.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/postmod-1.c
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug target/45844] FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |amodra at gmail dot com
   |gnu.org |

--- Comment #5 from Alan Modra  2011-03-15 09:40:35 
UTC ---
Testing a fix

[Bug tree-optimization/48031] [4.4/4.5 Regression] gcc.c-torture/compile/pr42956.c ICEs gcc on m68k-linux, ivopts related?

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther  2011-03-15 
09:49:39 UTC ---
Author: rguenth
Date: Tue Mar 15 09:49:33 2011
New Revision: 170983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170983
Log:
2011-03-15  Richard Guenther  

PR middle-end/48031
* fold-const.c (fold_indirect_ref_1): Do not create new variable-sized
or variable-indexed array accesses when in gimple form.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug c++/48118] [4.3/4.4/4.5/4.6/4.7 regression] g++ sometimes allows copying a volatile class

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.3.6

[Bug fortran/48117] [4.5 Regression] ICE: OpenMP; in build_int_cst_wide, at tree.c:1178

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-03-15 
10:06:28 UTC ---
Oops - my bad ;)

[Bug rtl-optimization/47899] [4.5 Regression] ICE in get_loop_body, at cfgloop.c:831

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther  2011-03-15 
10:09:25 UTC ---
Confirmed, but can you track this in a new bug?

[Bug debug/45088] pointer type information lost in debuginfo

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Dodji Seketeli  2011-03-15 
10:12:06 UTC ---
Fixed in 4.6

[Bug middle-end/48124] [4.3/4.4/4.5/4.6/4.7 Regression] likely wrong code bug

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-15 
10:21:04 UTC ---
Hm, e has alignment of 8 bytes and f of 4 but the assembler doesn't pad
e's size to 8 byte multiples appearantly

.data
.align 8
.type   e, @object
.size   e, 12
e:
.byte   0
.byte   0
.byte   0
.byte   0
.value  0
.byte   0
.byte   0
.byte   1
.byte   0
.zero   2
.align 4
.type   f, @object
.size   f, 4
f:
.long   1

this is probably a more general problem also with the vectorizer which
happily increases alignment of global variables independed on if their
size is a multiple of that alignment.

If the asm output machinery does not try to handle padding to multiples
of alignment size then that's the bug I guess.

[Bug target/48127] Program crashes reading a non-aligned variable

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Guenther  2011-03-15 
10:27:39 UTC ---
I think the testcase is invalid as you have two definitions of baz which
are not both common.

The vectorizer relies on being able to promote alignment of definitions
which I'm not sure it can do so for commons (it would rely on the linker
choosing the common with the largest alignment).

A testcase that works with -fno-common would be more convincing here ;)

[Bug rtl-optimization/48128] Excessive code generated for vectorized loop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|i686-*-*|i686-*-*, x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 10:32:18
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2011-03-15 
10:32:18 UTC ---
Confirmed.  The fun thing is that the tree level optimized code looks exactly
the same ...

On x86_64 we get

foo2:
.LFB1:
.cfi_startproc
movqbaz(%rip), %rdx
movq%rdx, -24(%rsp)
movl%edx, %eax
movqbaz+8(%rip), %rdx
movq%rdx, -16(%rsp)
movdqa  -24(%rsp), %xmm0
movdqa  %xmm0, bar(%rip)
movdqa  baz+16(%rip), %xmm0
movdqa  %xmm0, bar+16(%rip)
ret

so it spills everything to the stack here as well!?

[Bug libstdc++/48130] [4.7 Regression]: build fails on libsupc++/nested_exception.cc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug c++/48132] [4.6/4.7 Regression] [C++0x] Internal compiler error on array of std::complex with -std=c++0x

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug rtl-optimization/48133] New: [4.5/4.6/4.7 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[zsojka at seznam dot cz]

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

   Summary: [4.5/4.6/4.7 Regression] ICE: in get_loop_body, at
cfgloop.c:831 with -O -funroll-loops -fthread-jumps
-fno-tree-ch
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23662
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23662
reduced testcase (from gcc.dg/pr47899.c)

+++ This bug was initially created as a clone of Bug #47899 +++

Compiler output:
$ gcc -O -funroll-loops -fthread-jumps -fno-tree-ch testcase.c
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: in get_loop_body, at cfgloop.c:831
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x10f5258 "/mnt/svn/gcc-4_6/gcc/cfgloop.c", line=831,
function=0x10f5792 "get_loop_body")
at /mnt/svn/gcc-4_6/gcc/diagnostic.c:892
#1  0x005f1511 in get_loop_body (loop=0x77ed2d48) at
/mnt/svn/gcc-4_6/gcc/cfgloop.c:831
#2  0x005f2fe8 in verify_loop_structure () at
/mnt/svn/gcc-4_6/gcc/cfgloop.c:1343
#3  0x007bffbc in peel_loops_completely (flags=2) at
/mnt/svn/gcc-4_6/gcc/loop-unroll.c:259
#4  unroll_and_peel_loops (flags=2) at /mnt/svn/gcc-4_6/gcc/loop-unroll.c:165
#5  0x007afc48 in rtl_unroll_and_peel_loops () at
/mnt/svn/gcc-4_6/gcc/loop-init.c:332
#6  0x007f6b46 in execute_one_pass (pass=0x1639e20) at
/mnt/svn/gcc-4_6/gcc/passes.c:1556
#7  0x007f6e45 in execute_pass_list (pass=0x1639e20) at
/mnt/svn/gcc-4_6/gcc/passes.c:1611
#8  0x007f6e57 in execute_pass_list (pass=0x163a000) at
/mnt/svn/gcc-4_6/gcc/passes.c:1612
#9  0x007f6e57 in execute_pass_list (pass=0x163a220) at
/mnt/svn/gcc-4_6/gcc/passes.c:1612
#10 0x00939d76 in tree_rest_of_compilation (fndecl=0x75bcef00) at
/mnt/svn/gcc-4_6/gcc/tree-optimize.c:422
#11 0x00b01c12 in cgraph_expand_function (node=0x75bec000) at
/mnt/svn/gcc-4_6/gcc/cgraphunit.c:1576
#12 0x00b0435a in cgraph_expand_all_functions () at
/mnt/svn/gcc-4_6/gcc/cgraphunit.c:1635
#13 cgraph_optimize () at /mnt/svn/gcc-4_6/gcc/cgraphunit.c:1899
#14 0x00b048da in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-4_6/gcc/cgraphunit.c:1096
#15 0x005097fc in c_write_global_declarations () at
/mnt/svn/gcc-4_6/gcc/c-decl.c:9872
#16 0x008e2d08 in compile_file (argc=16, argv=0x7fffdc28) at
/mnt/svn/gcc-4_6/gcc/toplev.c:591
#17 do_compile (argc=16, argv=0x7fffdc28) at
/mnt/svn/gcc-4_6/gcc/toplev.c:1900
#18 toplev_main (argc=16, argv=0x7fffdc28) at
/mnt/svn/gcc-4_6/gcc/toplev.c:1963
#19 0x7648cb6d in __libc_start_main () from /lib/libc.so.6
#20 0x004f03b1 in _start ()

Tested revisions:
r170964 - crash
4.6 r170955 - crash
4.5 r170955 - crash
4.4 r170955 - OK

[Bug rtl-optimization/47899] [4.5 Regression] ICE in get_loop_body, at cfgloop.c:831

[zsojka at seznam dot cz]

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

--- Comment #12 from Zdenek Sojka  2011-03-15 10:50:35 
UTC ---
Thank you for reply. I opened PR48133 for the testcase from comment #10.

[Bug middle-end/48124] [4.3/4.4/4.5/4.6/4.7 Regression] likely wrong code bug

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-03-15 
10:52:44 UTC ---
I think that is not the problem, it is fine if some variables are aligned more
than they need to be for performance reasons.  TYPE_ALIGN is still 32 bits,
while just DECL_ALIGN is 64 bits.

The bug is in expand_assignment/store_bit_field{,_1} I think.
First expand_assignment calls set_mem_attributes_minus_bitpos (to_rtx, to, 0,
bitpos);
which changes
(mem/s/c:BLK (symbol_ref:DI ("e") [flags 0x2] ) [2
e+0 S12 A64])
into:
(mem/s/v/j/c:BLK (symbol_ref:DI ("e") [flags 0x2] )
[2 e+0 S2 A64])
so the information that e is 12 bytes long is harder to find (of course, one
can still look at MEM_EXPR's size).
Then store_bit_field_1 sees i386 has HAVE_insv and op_mode for -m64 insv is
DImode.  The first HAVE_insv if doesn't apply, as i386 (like also at least half
of other targets that HAVE_insv) doesn't allow memory on op0.
But then the if (HAVE_insv && MEM_P (op0)) triggers and it calls get_best_mode,
which for volatile (this case) and !targetm.narrow_bit_fields () decides to
enlarge the mode as much as possible and this "possible" takes into account
just
MEM_ALIGN (which comes from DECL_ALIGN and thus is large here) and the passed
in largest_mode (for insv it comes from insv insn mode).  It doesn't consider
the size of the decl (but see above, expand_assignment made it impossible to
use MEM_SIZE here).  Now, if this if (HAVE_insv && MEM_P (op0)) case is
disabled, it still generates wrong code, as store_fixed_bit_field does
essentially the same, just instead of insv's mode uses word_mode as
largest_mode passed to get_best_mode.

Now, the question is what we want to use as largest_mode in these cases.
Obviously it can't be too large to go beyond end of the object's size here (the
case in this testcase, the reason why sched2 reorders the two stores is because
it sees the first store using SYMBOL_REF ("e") as base and the second store
using SYMBOL_REF ("f") and assumes that those can't alias).  For OpenMP or
C++0x
memory model that isn't enough I guess, even if you have:
struct S
{
  signed a : 26;
  signed b : 16;
  signed c : 10;
  volatile signed d : 14;
  int e;
} s;
I think you can't just modify s.e when writing s.d (I think it is fine to
modify
adjacent bitfields though, Aldy?).  So for C++0x memory model we probably want
to find the next non-bitfield field and use that or something similar.

[Bug tree-optimization/41490] tree-ssa-sink does not really work

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-15 
11:09:14 UTC ---
Author: rguenth
Date: Tue Mar 15 11:09:09 2011
New Revision: 170984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170984
Log:
2011-03-15  Richard Guenther  

PR tree-optimization/41490
* tree-ssa-dce.c (propagate_necessity): Handle returns without
value but with VUSE.
* tree-ssa-operands.c (parse_ssa_operands): Add a VUSE on all
return statements.
* tree-ssa-sink.c (statement_sink_location): Fix store sinking.
* tree-ssa-phiopt.c (tree_ssa_phiopt_worker): Handle virtual PHIs.
* tree-tailcall.c (find_tail_calls): Ignore returns.

* gcc.dg/tree-ssa/ssa-sink-6.c: New testcase.
* gcc.dg/tree-ssa/ssa-sink-7.c: Likewise.
* gcc.dg/tree-ssa/ssa-sink-8.c: Likewise.
* gcc.dg/tree-ssa/ssa-sink-9.c: Likewise.
* g++.dg/tree-ssa/pr33604.C: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr33604.C
trunk/gcc/tree-ssa-dce.c
trunk/gcc/tree-ssa-operands.c
trunk/gcc/tree-ssa-phiopt.c
trunk/gcc/tree-ssa-sink.c
trunk/gcc/tree-tailcall.c

[Bug tree-optimization/41490] tree-ssa-sink does not really work

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Guenther  2011-03-15 
11:10:40 UTC ---
Fixed in 4.7.

[Bug target/12395] Suboptimal code with global variables

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther  2011-03-15 
11:24:13 UTC ---
(In reply to comment #16)
> To optimize
> 
> void foo() {
> extern int a;
> if(++a) ++a;
> }
> 
> we need to have partial dead store elimination, basically sink the store
> to after the condition:
> 
> void bar() {
> extern int a;
> int tmp = a;
> if (++tmp)
>   ++tmp;
> a = tmp;
> }
> 
> bar:
> movla, %eax
> pushl   %ebp
> movl%esp, %ebp
> movl%eax, %edx
> addl$1, %edx
> je  .L5
> leal2(%eax), %edx
> .L5:
> movl%edx, a
> popl%ebp
> ret
> 
> we'd then assemble this to similar code as the testcase from comment #2.
> 
> See also PR41490, though a working tree-ssa-sink would at most generate
> 
> void foobar() {
> extern int a;
> int tmp = a;
> if (++tmp)
>   {
> ++tmp;
> a = tmp;
>   }
> else
>   a = tmp;
> }
> 
> Still an improvement as we'd propagate zero to the second store:
> 
> foobar:
> movla, %eax
> pushl   %ebp
> movl%esp, %ebp
> cmpl$-1, %eax
> jne .L9
> movl$0, a
> popl%ebp
> ret
> .p2align 4,,7
> .p2align 3
> .L9:
> addl$2, %eax
> movl%eax, a
> popl%ebp
> ret

It now does this (for 4.7).

[Bug tree-optimization/48129] [4.7 Regression]: gcc.c-torture/execute/builtins/snprintf-chk.c ICE

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2011-03-15 
11:28:38 UTC ---
Author: jakub
Date: Tue Mar 15 11:28:35 2011
New Revision: 170985

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170985
Log:
PR tree-optimization/48129
* builtins.c (fold_builtin_snprintf): Convert to type of
built_in_decls[BUILT_IN_SNPRINTF] retval instead of
implicit_built_in_decls[BUILT_IN_SNPRINTF] retval.

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

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org
  Known to fail||

--- Comment #7 from Iain Sandoe  2011-03-15 11:29:29 
UTC ---
can the language lawyers take a look at this so that we can decide on a way
forward?

[Bug tree-optimization/46763] gcc 4.5: missed optimization: copy global to local, prefetch

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #3 from Richard Guenther  2011-03-15 
11:32:49 UTC ---
store sinking now works and exposes an if-conversion possibility:

:
  g.1_6 = i_19 + 1;
  g = g.1_6;
  i_7 = bar (i_16);
  g = i_7;
  goto ;

:
  g = i_16;

:
  # i_5 = PHI 

the stores to g can be if-converted by re-using the existing PHI like so:

:
  g.1_6 = i_19 + 1;
  g = g.1_6;
  i_7 = bar (i_16);
  goto ;

:
  ;

:
  # i_5 = PHI 
  g = i_5;

that eventually fits into the cs_elim framework, but cs_elim runs
too early - Micha, do you remember why it runs where it runs?

[Bug rtl-optimization/48133] [4.5/4.6/4.7 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 11:44:24
   Target Milestone|--- |4.5.3
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-15 
11:44:24 UTC ---
Confirmed.

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-03-15 
11:49:12 UTC ---
The easiest way is to attach the may_alias attribute to all object types that
should not be subject to TBAA.  Bonus point if you transition that attribute
to use a flag instead.

[Bug c++/48132] [4.6/4.7 Regression] [C++0x] Internal compiler error on array of std::complex with -std=c++0x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-15 
12:15:13 UTC ---
Reduced testcase:

struct C
{
  constexpr C (int x) : c (x) {}
  int c;
};

void
foo ()
{
  C a[] = { C (0) };
}

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2011-03-15 
12:22:18 UTC ---
Author: rguenth
Date: Tue Mar 15 12:22:12 2011
New Revision: 170986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170986
Log:
2011-03-15  Richard Guenther  

PR tree-optimization/48037
* tree-ssa.c (maybe_rewrite_mem_ref_base): Rewrite vector
selects into BIT_FIELD_REFs.
(non_rewritable_mem_ref_base): Check if a MEM_REF is a
vector select.

* gcc.target/i386/pr48037-1.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr48037-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c

[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-03-15 
12:41:57 UTC ---
The patch fixed the pass-by-value cases to no longer go through stack memory.
The useless reg-reg moves prevail:

_Z6vsqrt2U8__vectord:
.LFB520:
.cfi_startproc
sqrtsd  %xmm0, %xmm1
unpckhpd%xmm0, %xmm0
movapd  %xmm1, %xmm2
sqrtsd  %xmm0, %xmm0
unpcklpd%xmm0, %xmm2
movapd  %xmm2, %xmm0
ret

both movapds can be avoided by better register allocation.

[Bug middle-end/48124] [4.3/4.4/4.5/4.6/4.7 Regression] likely wrong code bug

[aldyh at redhat dot com]

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

--- Comment #5 from Aldy Hernandez  2011-03-15 
12:42:36 UTC ---
> struct S
> {
>signed a : 26;
>signed b : 16;
>signed c : 10;
>volatile signed d : 14;
>int e;
> } s;
> I think you can't just modify s.e when writing s.d (I think it is fine to
> modify
> adjacent bitfields though, Aldy?).

No, you can't modify s.e when writing to s.d.  However, you can modify 
adjacent bitfields.  All contiguous bitfields can be considered a single 
memory location for the purpose of introducing data races.  The only 
exception is when bitfields are separated by a zero-length bitfield, or 
when they happen to be contiguous but occur in different 
structures/unions.  Those conditions force alignments on those fields.

[Bug target/48032] PowerPC64 -mcmodel=medium invalid ld offset

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  2011-03-15 12:57:42 
UTC ---
Author: amodra
Date: Tue Mar 15 12:57:37 2011
New Revision: 170990

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170990
Log:
PR target/48032
* config/rs6000/rs6000.c (offsettable_ok_by_alignment): Do not
presume symbol_refs without a symbol_ref_decl are suitably
aligned, nor other trees we may see here.  Handle anchor symbols.
(legitimate_constant_pool_address_p): Comment.  Add mode param.
Check cmodel=medium addresses.  Adjust all calls.
(rs6000_emit_move): Don't call offsettable_ok_by_alignment on
creating cmodel=medium optimized access to locals.
* config/rs6000/constraints.md (R): Pass QImode to
legitimate_constant_pool_address_p.
* config/rs6000/predicates.md (input_operand): Pass mode to
legitimate_constant_pool_address_p.
* config/rs6000/rs6000-protos.h (legitimate_constant_pool_address_p):
Update prototype.


Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/rs6000/constraints.md
branches/gcc-4_6-branch/gcc/config/rs6000/predicates.md
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c

[Bug target/48032] PowerPC64 -mcmodel=medium invalid ld offset

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #5 from Alan Modra  2011-03-15 12:59:25 
UTC ---
Fixed

[Bug target/45844] FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, patch
 Status|NEW |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-03/msg00829.htm
   ||l

[Bug c++/48132] [4.6/4.7 Regression] [C++0x] Internal compiler error on array of std::complex with -std=c++0x

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-15 
13:19:09 UTC ---
Regressed (expectedly) with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166167
The problem seems to be that the middle-end relies on indexes being filled in
in ctors for arrays, but the C++ FE in this case doesn't fill them in.
For POD arrays the indexes are added by process_init_constructor_array, but
that
isn't called in this case (both because check_initializer will do:
  /* Don't call digest_init; it's unnecessary and will complain
 about aggregate initialization of non-aggregate classes.  */
  flags |= LOOKUP_ALREADY_DIGESTED;
and also because it is called only for:
  if (BRACE_ENCLOSED_INITIALIZER_P (init)
  && !TYPE_NON_AGGREGATE_CLASS (type))
return process_init_constructor (type, init);

[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther  2011-03-15 
13:37:42 UTC ---
Author: rguenth
Date: Tue Mar 15 13:37:23 2011
New Revision: 170994

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170994
Log:
2011-03-15  Richard Guenther  

PR tree-optimization/13954
* tree-ssa-sccvn.c (vn_reference_lookup_3): Look through memcpy
and friends.

* g++.dg/tree-ssa/pr13954.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr13954.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/48134] New: [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[zsojka at seznam dot cz]

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

   Summary: [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at
tree-ssa-alias.c:1085 with custom flags
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23663
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23663
reduced testcase (from gcc.dg/pr19633-1.c)

Maybe similiar to PR47283.

Compiler output:
$ gcc -O2 -fstack-check=specific -fno-tree-dse -fno-tree-fre
-fno-tree-loop-optimize -g testcase.c
testcase.c: In function 'foo':
testcase.c:26:1: internal compiler error: in refs_may_alias_p_1, at
tree-ssa-alias.c:1085
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r170964 - crash
4.6 r170955 - crash
4.5 r170955 - OK

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther  2011-03-15 
13:39:50 UTC ---
Author: rguenth
Date: Tue Mar 15 13:39:28 2011
New Revision: 170995

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170995
Log:
2011-03-15  Richard Guenther  

PR middle-end/47650
* tree-pretty-print.c (dump_function_declaration): Properly
dump unprototyped and varargs function types.

* gfortran.dg/c_f_pointer_tests_3.f90: Adjust.
* gfortran.dg/ishft_4.f90: Likewise.
* gfortran.dg/leadz_trailz_3.f90: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90
trunk/gcc/testsuite/gfortran.dg/ishft_4.f90
trunk/gcc/testsuite/gfortran.dg/leadz_trailz_3.f90
trunk/gcc/tree-pretty-print.c

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #15 from Richard Guenther  2011-03-15 
13:41:02 UTC ---
Fixed.

[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #19 from Richard Guenther  2011-03-15 
13:41:43 UTC ---
Fixed.

[Bug tree-optimization/48134] [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 13:55:32
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-15 
13:55:32 UTC ---
Confirmed.

(gdb) call debug_rtx (mem)
(mem/s/j/c:SI (plus:DI (debug_expr:DI D#3)
(const_int -12 [0xfff4])) [0 MEM[(struct S *)&t.s].z+0 S4
A32])

invalid MEM_EXPR again.

[Bug tree-optimization/48134] [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-03-15 
13:59:05 UTC ---
That's the COMPONENT_REF case which runs into get_inner_reference which
doesn't deal with invalid MEM_REFs either.  It returns t.s as base.

[Bug rtl-optimization/48133] [4.5/4.6/4.7 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-15 
14:13:22 UTC ---
Started failing with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149206

[Bug tree-optimization/48134] [4.6/4.7 Regression] ICE: in refs_may_alias_p_1, at tree-ssa-alias.c:1085 with custom flags

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-15 
14:36:39 UTC ---
Created attachment 23664
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23664
gcc46-pr48134.patch

This fixes it, though perhaps as discussed earlier we want to fold everything
in expand_debug_expr except for memory addresses or something similar.

For 4.6 this is low priority, as with --enable-checking=release it will just
work, so doesn't need to be fixed before 4.6.0 release.

[Bug bootstrap/48135] New: build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[Denis.Excoffier at airbus dot com]

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

   Summary: build fails on Solaris2.8 due to Glob.pm not found
within /usr/perl5
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: denis.excoff...@airbus.com
  Host: sparc64-sun-solaris2.8
Target: sparc64-sun-solaris2.8
 Build: sparc64-sun-solaris2.8


Building gcc-4.6.0-RC-20110314 on solaris8 (with gcc-3.3.2 preinstalled) fails
with the following message:


Can't locate File/Glob.pm in @INC (@INC contains:
/usr/perl5/5.00503/sun4-solaris /usr/perl5/5.00503
/usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 .) at
/tmp/lcl/tmp/gcc/gcc-4.6.0-RC-20110314/libgomp/../contrib/make_sunver.pl
 line 19.
BEGIN failed--compilation aborted at
/tmp/lcl/tmp/gcc/gcc-4.6.0-RC-20110314/libgomp/../contrib/make_sunver.pl line
19.
make[5]: *** [libgomp.map-sun] Error 1


Indeed, there is no Glob.pm in the folders indicated. Under Solaris2.10 (where
we have /usr/perl5/5.8.4/lib/sun4-solaris-64int/File/Glob.pm) the build is ok
up to the end.

With GCC 4.5.2 no build problem with Solaris2.8 or Solaris2.10.

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Guenther  2011-03-15 
14:55:16 UTC ---
As documented in install.texi.

@item Perl version 5.6.1 (or later)

Necessary when regenerating @file{Makefile} dependencies in libiberty.
Necessary when regenerating @file{libiberty/functions.texi}.
Necessary when generating manpages from Texinfo manuals.
Necessary when targetting Darwin, building @samp{libstdc++},
and not using @option{--disable-symvers}.
Necessary when targetting Solaris 2 with Sun @command{ld}, building
@samp{libstdc++}, and not using @option{--disable-symvers}.  A helper
scripts needs @samp{Glob.pm}, which is missing from @command{perl} 5.005
included in Solaris@tie{}8.  The bundled @command{perl} in Solaris@tie{}9 and
up
works.
Used by various scripts to generate some files included in SVN (mainly
Unicode-related and rarely changing) from source tables.

[Bug c/48136] New: verify_gimple failed at -O0

[regehr at cs dot utah.edu]

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

   Summary: verify_gimple failed at -O0
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu


regehr@home:~/volatile/bugs/tmp003$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/mnt/z/z/compiler-install/gcc-r170969-install/libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/mnt/z/z/compiler-install/gcc-r170969-install
--program-prefix=r170969- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20110314 (experimental) (GCC) 

regehr@home:~/volatile/bugs/tmp003$ current-gcc -O0 small.c

small.c: In function ‘func_16’:
small.c:12:15: error: type mismatch in comparison expression
int
unsigned int
int
D.1965 = D.1963 == D.1964;

small.c:12:15: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

regehr@home:~/volatile/bugs/tmp003$ cat small.c


static short foo(short si1, short si2 ) {
  return si1 + si2;
}

static int bar(int si1, short si2 ) {
  return si1 + si2;
}

short g_2[1][9] = {
};

unsigned char func_16(unsigned p_17, const int p_18) 
{
 lbl_51:  
  {
  lbl_350:  
{
  ((5U ^ p_18) == (bar(0, 1) ^ 1)) > foo(1, 0)  ;
}
  }
  return 0;
}

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[Denis.Excoffier at airbus dot com]

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

--- Comment #2 from Denis Excoffier  
2011-03-15 15:09:37 UTC ---
Oh, thank you for pointing, but i should not be concerned since i
didn't modify the sources (i simply include gmp/mpfr/mpc within
the source directory tree).

Perhaps this is a side-effect because two files have the same mtime
(that will disappear with the final gcc-4.6.0)?

[Bug fortran/48112] [4.6/4.7 Regression] generic interface to external function in module

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 15:13:27
 CC||janus at gcc dot gnu.org
Summary|generic interface to|[4.6/4.7 Regression]
   |external function in module |generic interface to
   ||external function in module
 Ever Confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org 2011-03-15 15:13:27 UTC ---
Confirmed. Seems to be a regression in 4.6.

At first glance your code looks completely innocent. I think the bug may be
somehow related to the interface and the result variable having the same name.
Removing (or renaming) the result variable makes the error go away.

In any case the problem seems to occur during module writing. Backtrace:

#0  0x004c9fc8 in error_string (p=0xfbadac84 ) at /home/jweil/gcc47/trunk/gcc/fortran/error.c:132
#1  0x004cafd7 in error_print (type=0x11d5508 "", format0=0x11e3a88
"write_symbol(): bad module symbol '%s'", argp=0x7fffd980)
at /home/jweil/gcc47/trunk/gcc/fortran/error.c:671
#2  0x004cbc56 in gfc_internal_error (format=0x11e3a88 "write_symbol():
bad module symbol '%s'") at /home/jweil/gcc47/trunk/gcc/fortran/error.c:977
#3  0x00510351 in write_symbol (n=6, sym=0x1973dd0) at
/home/jweil/gcc47/trunk/gcc/fortran/module.c:4848
#4  0x00510572 in write_symbol1 (p=0x1974f60) at
/home/jweil/gcc47/trunk/gcc/fortran/module.c:4933
#5  0x005109b2 in write_module () at
/home/jweil/gcc47/trunk/gcc/fortran/module.c:5081
#6  0x00510e23 in gfc_dump_module (name=0x77f651f0 "module_m",
dump_flag=1) at /home/jweil/gcc47/trunk/gcc/fortran/module.c:5224
#7  0x0051eb09 in gfc_parse_file () at
/home/jweil/gcc47/trunk/gcc/fortran/parse.c:4377
#8  0x005641c4 in gfc_be_parse_file () at
/home/jweil/gcc47/trunk/gcc/fortran/f95-lang.c:250
#9  0x00a56410 in compile_file () at
/home/jweil/gcc47/trunk/gcc/toplev.c:579
#10 0x00a5862b in do_compile () at
/home/jweil/gcc47/trunk/gcc/toplev.c:1900
#11 0x00a58778 in toplev_main (argc=2, argv=0x7fffddd8) at
/home/jweil/gcc47/trunk/gcc/toplev.c:1963
#12 0x005fe2b4 in main (argc=2, argv=0x7fffddd8) at
/home/jweil/gcc47/trunk/gcc/main.c:36

[Bug c/48136] verify_gimple failed at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.15 15:13:11
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-03-15 
15:13:11 UTC ---
Simplified testcase:

extern int foo (void);

int
baz (int x)
{
  return ((5U ^ x) == (foo () ^ 1)) > foo ();
}

Looking at it.

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-03-15 
15:19:34 UTC ---
But are you using Sun ld, building libstdc++, and not using --disable-symvers?

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[jb at gcc dot gnu.org]

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

--- Comment #7 from Janne Blomqvist  2011-03-15 15:26:05 
UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > If not before, perhaps something to fix when/if we change to use size_t for
> > string lengths, see http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
> 
> Just as a remark: you're not going to use size_t, but the signed ssize_t,
> right?

I think the idea was to use the unsigned size_t. 

- size_t is the natural type for representing the size of a memory object in
bytes. There is no need for negative values, and SSIZE_MAX is smaller than the
largest possible object (=SIZE_MAX) (an obscure corner case, but still).

- size_t is what the C string.h functions use, which is used in the
implementation of various string handling functions in gfortran (in libgfortran
and code generated directly by the frontend). Using the same type might also
help mixed C/Fortran programs.

- size_t is what Intel Fortran uses

- Yes, Fortran itself does not have unsigned integers, but the string length
type is invisible to Fortran programs. The LEN intrinsic does return the string
length typecast to a signed integer kind depending on the optional KIND
argument, or to a default kind integer. Depending on whether the target
supports an integer kind > sizeof(size_t) it might be possible to represent all
possible string lengths, or then not. But IMHO this does not change the fact
that the correct type for the (Fortran invisible) string length is the unsigned
size_t. Also, consider that at the asm level, typecasting from an unsigned to a
signed value of the same size is a no-op, so there is no efficiency loss.

[Bug c/48136] verify_gimple failed at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #2 from Jakub Jelinek  2011-03-15 
15:26:55 UTC ---
Folder, what else, likely triggered by my PR38878 fix.

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[fxcoudert at gcc dot gnu.org]

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

--- Comment #8 from Francois-Xavier Coudert  
2011-03-15 15:36:16 UTC ---
(In reply to comment #7)
> - Yes, Fortran itself does not have unsigned integers, but the string length
> type is invisible to Fortran programs. The LEN intrinsic does return the 
> string
> length typecast to a signed integer kind depending on the optional KIND
> argument, or to a default kind integer.

My point is just that, if you're merely changing the size of the variable, you
are less likely to unearth new bugs than if you change both that and
signedness.

Plus, as you say, the difference between SIZE_MAX and SSIZE_MAX is a corner
case, and maybe a huge size_t value isn't usable in common code.

Finally, you'd loose some compatibility with what used to be done

> Also, consider that at the asm level, typecasting from an unsigned to a
> signed value of the same size is a no-op, so there is no efficiency loss.

And casts from signed to unsigned, with checks for positivity, when string
lengths are passed as function arguments.

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #16 from joe at mcknight dot de 2011-03-15 15:52:01 UTC ---
Created attachment 23665
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23665
dump_function_declaration with debug

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #17 from joe at mcknight dot de 2011-03-15 15:53:23 UTC ---
Created attachment 23666
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23666
debug output from a run of the modified function

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther  2011-03-15 
15:56:04 UTC ---
comment #13 would happen if the list of argument types is not terminated by
the shared tree node void_list_node but by a clone.  We expect the
shared void_list_node to be used elsewhere as well.

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther  2011-03-15 
15:59:44 UTC ---
All looks good to me with your C testcase:

gcc> gdb --args ./cc1 -quiet t.i
(gdb) b gimplify_function_tree
Breakpoint 5 at 0x855ac4: file /space/rguenther/src/svn/trunk/gcc/gimplify.c,
line 7820.
(gdb) run
Breakpoint 5, gimplify_function_tree (fndecl=0x75b49000)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7820
7820  gcc_assert (!gimple_body (fndecl));
(gdb) call debug_generic_expr (fndecl->common.type)
int  (struct 
{
  double dvar;
  int ivar;
} *)
(gdb) call debug_generic_expr (fndecl)
myfunc
(gdb) c
Continuing.

Breakpoint 5, gimplify_function_tree (fndecl=0x75b29f00)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7820
7820  gcc_assert (!gimple_body (fndecl));
(gdb) call debug_generic_expr (fndecl)
GetFunctionPointer
(gdb) call debug_generic_expr (fndecl->common.type)
void (*Handler) (int, void *)  (void)
(gdb) c
Continuing.

Breakpoint 3, 0x763ca250 in exit () from /lib64/libc.so.6

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #20 from joe at mcknight dot de 2011-03-15 16:03:23 UTC ---
Unfortunately I cannot confirm that this bug is fixed, so I need to reopen it.

For one thing this bug is not only about variadic functions, but
dump_function_declaration() returns wrong output also for other cases as
described, like functions involving function pointers and typedef'ed structs.

Second I am still seeing the issue described earlier, where a function now
returns a variadic function even though there is none.

I have modified the function to print debug output to a file and I am attaching
both the modified function and its debug output. For me it looks like the "arg
!= void_list_node" does not work, so the while loop is executed once more,
printing the "void" and then arg goes NULL, the loop is left and since arg is
NULL, the function prints ", ..." at the end.

Let me know if there is anything else I can do to help.

[Bug c++/47688] [C++0x] Segfault when assigning lambda to std::function variable

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  2011-03-15 
16:14:29 UTC ---
Author: ramana
Date: Tue Mar 15 16:14:21 2011
New Revision: 171000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171000
Log:
Fix PR 47688

2011-03-18  Ramana Radhakrishnan  

PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use 'L' instead of 'c'
in the output template.
gcc/testsuite/
* gcc.target/arm/pr47688.c: New.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/47668] missing 'typename' in debug-mode map

[ramana at gcc dot gnu.org]

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

--- Comment #8 from Ramana Radhakrishnan  2011-03-15 
16:14:29 UTC ---
Author: ramana
Date: Tue Mar 15 16:14:21 2011
New Revision: 171000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171000
Log:
Fix PR 47688

2011-03-18  Ramana Radhakrishnan  

PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use 'L' instead of 'c'
in the output template.
gcc/testsuite/
* gcc.target/arm/pr47688.c: New.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #21 from joe at mcknight dot de 2011-03-15 16:18:37 UTC ---
(In reply to comment #19)
> All looks good to me with your C testcase:
> 
> (gdb) call debug_generic_expr (fndecl->common.type)
> int  (struct 
> {
>   double dvar;
>   int ivar;
> } *)

Hm, the function was declared to take a new type "tpdefp", so I was expecting
the dump to return it like this and not resolve it to whatever it is typedef'ed
to.

Compare it to:

typedef int mytype;
int myfunc2(mytype var) {
return 1;
};

which outputs

  static int myfunc2 (mytype);

i.e. returns the newly created type as well.


> (gdb) call debug_generic_expr (fndecl->common.type)
> void (*Handler) (int, void *)  (void)

It outputs "static void (*Handler) (int, void *) GetFunctionPointer (void);"

And this is not C  :-)

The compiler throws a parse error when I compile a function with the prototype
that it outputs.

[Bug tree-optimization/48137] New: [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[zsojka at seznam dot cz]

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

   Summary: [4.6/4.7 Regression] "sorry, unimplemented: inlining
failed in call to 'cb'" with -fnon-call-exceptions
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O -fipa-cp -fnon-call-exceptions testcase.c   
testcase.c: In function 'f1':
testcase.c:3:52: sorry, unimplemented: inlining failed in call to 'cb': 
testcase.c:10:6: sorry, unimplemented: called from here

Compilation succeeds when either:
a) __attribute__ ((always_inline)) is removed from cb()
b) -fnon-call-exceptions is removed
c) -fipa-cp is removed
d) *p (dereferencing null pointer) is removed

(e) -O is removed)

In all a,b,c,d cases, the generated code is:
f1:
.LFB3:
.cfi_startproc
addl$1, x(%rip)
ret
.cfi_endproc

so the (possibly causing exception?) *p is removed. (even when it is declared
as "volatile int *")

This seems to be a recent regression, as r170436 seems to work fine (generated
code is the same as above). Also, r170436 (and 4.5.2) generates write to *p if
it is "volatile int *".

I don't know what's the expected behaviour, but removing write to null pointer
looks strange.

Tested revisions:
r170964 - fail
r170436 - OK
4.5.2 - OK

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-03-15 16:24:01 UTC ---
>> I'd really like to see this fixed before 4.6.0: it is a regression from
>> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively
>> minor gain on other platforms.
>
> Well, do we really have any actual gfortran users on Tru64? Whereas a
> high-resolution monotonic clock, while admittedly not a huge feature per se, 
> is
> something that is now available to gfortran users on some rather more popular
> platforms.

Why would they tell me: `Hey, I'm using gfortran on Tru64 UNIX and all
is fine.'?   You will only learn if things break.

>>  If all else fails, I'd go as far as
>> advocating to revert the patch that introduced clock_gettime
>
> There has been a number of patches in this area more or less related to
> clock_gettime, so IMHO fixing it properly is simpler and less prone to
> introduce new regressions. My previous message in this PR hopefully does
> exactly this and introduces a patch which should fix it along the lines
> previously discussed. As my normal gcc development machine is packed in a box,
> I haven't been able to test it. Also, note that it won't apply cleanly as the
> paths are messed up (but the contents should otherwise apply fine). 

There have been some subsequent suggestions/updates, so I'm uncertain if
I should test this patch or wait for an update.

> As I mentioned previously, I'd prefer to commit it after the 4.6 release, but
> if the reviewer(s) feel it's safe I'm fine with getting it in for 4.6.

Now that 4.6 has branched, it's safer to commit to mainline after some
testing and only backport to 4.6 after it has proven correct.  If all
else fails, one could apply a hack to 4.6 along the lines of

#if defined(__alpha__) && defined(__osf__)
#undef HAVE_CLOCK_GETTIME
#endif

or some configure.ac equivalent.  Ugly but still better than completely
breaking Fortran.

Rainer

[Bug debug/47510] DW_TAG_typedef can have children when designating a naming typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2011-03-15 
16:24:27 UTC ---
(In reply to comment #4)
> This is because G++ generates struct F::C.  The instantiated
> F::C a typedef.  No anonymous struct is generated inside F.
> What is generated is really the same as for:
> 
> template
> class F
> {
>   struct C {int i};
>   C a;
> };
> F f;
> 
> I guess we could try hard to trick the dwarf emitter into describing
> debug information for a typedef and an anonymous code that is actually
> not generated (instantiated), but would that be really worth it?

See also PR47939.  Yes, debug info consumers expect typedefs to be available
if they are used in source.

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-03-15 
16:29:33 UTC ---
indirect calls can't be always-inline, the testcase is invalid.

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  2011-03-15 16:32:37 
UTC ---
Oh, sorry. It was reduced from gcc.c-torture/compile/pr44043.c:

...
static inline __attribute__((always_inline)) int dst_output(struct sk_buff
*skb) {
return skb_dst(skb)->output(skb);
};
...
  NF_HOOK(2, NF_INET_LOCAL_OUT, skb, ((void *)0), rt->u.dst.dev,
   dst_output);
...

dst_output is always_inline there, but is used in this way.

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  
2011-03-15 16:33:09 UTC ---
On Tue, 15 Mar 2011, joe at mcknight dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650
> 
> --- Comment #21 from joe at mcknight dot de 2011-03-15 16:18:37 UTC ---
> (In reply to comment #19)
> > All looks good to me with your C testcase:
> > 
> > (gdb) call debug_generic_expr (fndecl->common.type)
> > int  (struct 
> > {
> >   double dvar;
> >   int ivar;
> > } *)
> 
> Hm, the function was declared to take a new type "tpdefp", so I was expecting
> the dump to return it like this and not resolve it to whatever it is 
> typedef'ed
> to.
> 
> Compare it to:
> 
> typedef int mytype;
> int myfunc2(mytype var) {
> return 1;
> };
> 
> which outputs
> 
>   static int myfunc2 (mytype);
> 
> i.e. returns the newly created type as well.

That's by design.

> > (gdb) call debug_generic_expr (fndecl->common.type)
> > void (*Handler) (int, void *)  (void)
> 
> It outputs "static void (*Handler) (int, void *) GetFunctionPointer (void);"
> 
> And this is not C  :-)
> 
> The compiler throws a parse error when I compile a function with the prototype
> that it outputs.

It's not designed to do that.  The functions are for debugging and
diagnostic output only, they are not supposed to generate valid C.

Richard.

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-15 
16:36:34 UTC ---
Yes, well ... if it "works" you are lucky.  "Works" in this case can even
mean we simply don't turn the indirect call into a direct one (in which
case we'll not notice the fn is always-inline and do not complain).

I suggested to emit a diagnostic whenever the address of an always-inline
function is taken, but kernel people will take that not lightly I guess ;)

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[Denis.Excoffier at airbus dot com]

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

Denis Excoffier  changed:

   What|Removed |Added

 CC||Denis.Excoffier at airbus
   ||dot com

--- Comment #4 from Denis Excoffier  
2011-03-15 16:40:13 UTC ---
Sun ld yes, libstdc++ i suppose (although i was caught in libgomp) and
--disable-symvers is the next thing i'm going to try.

Still not convinced that i am "modifying GCC".

[Bug middle-end/48136] verify_gimple failed at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-15 
16:46:02 UTC ---
Created attachment 23668
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23668
gcc47-pr48136.patch

Patch I'm going to bootstrap/regtest.

[Bug tree-optimization/48137] [4.6/4.7 Regression] "sorry, unimplemented: inlining failed in call to 'cb'" with -fnon-call-exceptions

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Zdenek Sojka  2011-03-15 16:49:13 
UTC ---
Thank you for quick replies.

Now it seems I was also wrong with that "write to volatile int * is removed"
statement - I can't reproduce it any more... Sorry for the noise.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

  Attachment #23648|0   |1
is obsolete||

--- Comment #38 from Janne Blomqvist  2011-03-15 
17:04:41 UTC ---
Created attachment 23669
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23669
Updated patch

This patch takes into account the comments by Jakub, and unconditionally sets
GF_CLOCK_MONOTONIC if clock_gettime is available; this should fix a bug if
CLOCK_* are not preprocessor macros.

Also, paths should be correct now, if the patch is applied in libgfortran/

[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin

[joe at mcknight dot de]

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

--- Comment #23 from joe at mcknight dot de 2011-03-15 17:05:24 UTC ---
(In reply to comment #22)
> > Compare it to:
> > 
> > typedef int mytype;
> > int myfunc2(mytype var) {
> > return 1;
> > };
> > 
> > which outputs
> > 
> >   static int myfunc2 (mytype);
> > 
> > i.e. returns the newly created type as well.
> 
> That's by design.

Then what is the design rule behind it, for me it looks inconsistent to once
inline the original type and another time use the newly created type.


> > It outputs "static void (*Handler) (int, void *) GetFunctionPointer (void);"
> 
> It's not designed to do that.  The functions are for debugging and
> diagnostic output only, they are not supposed to generate valid C.

I know, but instead of creating a new language, wouldn't it be good to just
stick to the C grammar to describe what is being seen?



Was the debug output helpful with respect to the wrong variadic output?

thanks!

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

--- Comment #5 from Ramana Radhakrishnan  2011-03-15 
17:05:56 UTC ---
Author: ramana
Date: Tue Mar 15 17:05:51 2011
New Revision: 171002

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

Fixup last commit.

Fixed PR target/46788 and not PR 47688


Added:
trunk/gcc/testsuite/gcc.target/arm/pr46788.c
  - copied unchanged from r171001,
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug c++/47688] [C++0x] Segfault when assigning lambda to std::function variable

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  2011-03-15 
17:05:56 UTC ---
Author: ramana
Date: Tue Mar 15 17:05:51 2011
New Revision: 171002

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

Fixup last commit.

Fixed PR target/46788 and not PR 47688


Added:
trunk/gcc/testsuite/gcc.target/arm/pr46788.c
  - copied unchanged from r171001,
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-03-15 
17:07:04 UTC ---
(In reply to comment #4)
> Sun ld yes, libstdc++ i suppose (although i was caught in libgomp) and
> --disable-symvers is the next thing i'm going to try.
> 
> Still not convinced that i am "modifying GCC".

You're not, but I think the prerequisites docs are misleading.  The Perl
requirement shouldn't be in the "modifying GCC" section. Perl is required when
doing any of:

* regenerating Makefile dependencies in libiberty.
* regenerating libiberty/functions.texi. 
* generating manpages from Texinfo manuals.
* targetting Darwin, building `libstdc++', and not using --disable-symvers
* targetting Solaris 2 with Sun ld, building `libstdc++', and not using
--disable-symvers.

Only the first two belong under the "modifying GCC" heading.

You are targetting Solaris2 with Sun ld, building libstdc++ and not using
--disable-symvers, so Perl (and Glob.pm) is required.

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan  2011-03-15 
17:07:56 UTC ---

(In reply to comment #5)
> Author: ramana
> Date: Tue Mar 15 17:05:51 2011
> New Revision: 171002
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171002
> Log:
> 
> Fixup last commit.
> 
> Fixed PR target/46788 and not PR 47688
> 
> 
> Added:
> trunk/gcc/testsuite/gcc.target/arm/pr46788.c
>   - copied unchanged from r171001,
> trunk/gcc/testsuite/gcc.target/arm/pr47688.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/testsuite/ChangeLog


This was fixed on trunk with this original commit followed by the commit in the
previous comment.


Author: ramana
Date: Tue Mar 15 16:14:21 2011
New Revision: 171000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171000
Log:
Fix PR 47688

2011-03-18  Ramana Radhakrishnan  

PR target/47668
gcc/
* config/arm/arm.md (arm_movtas_ze): Use 'L' instead of 'c'
in the output template.
gcc/testsuite/
* gcc.target/arm/pr47688.c: New.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr47688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jakub at gcc dot gnu.org]

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

--- Comment #39 from Jakub Jelinek  2011-03-15 
17:08:03 UTC ---
Looks fine to me.

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2011-03-15 
17:16:11 UTC ---
AFAICS, however, pr47688.c is still there.

[Bug fortran/47571] [4.6/4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011

[jb at gcc dot gnu.org]

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

--- Comment #40 from Janne Blomqvist  2011-03-15 
17:19:43 UTC ---
(In reply to comment #37)
> >> I'd really like to see this fixed before 4.6.0: it is a regression from
> >> 4.5 and makes fortran completely unusable on Tru64 UNIX for a relatively
> >> minor gain on other platforms.
> >
> > Well, do we really have any actual gfortran users on Tru64? Whereas a
> > high-resolution monotonic clock, while admittedly not a huge feature per 
> > se, is
> > something that is now available to gfortran users on some rather more 
> > popular
> > platforms.
> 
> Why would they tell me: `Hey, I'm using gfortran on Tru64 UNIX and all
> is fine.'?   You will only learn if things break.

While I have no proof, I find it difficult to imagine that we have a
significant amount of bleeding edge users that upgrade to the latest and
greatest gcc release on an expensive platform where new hw isn't sold since
many years, and the OS is scheduled to go EOL in a year or so. So while IMHO it
would be nice if we could get a fix into 4.6, I don't think it's the end of the
world if these users, if they exist at all, will have to wait until 4.6.1.

> >>  If all else fails, I'd go as far as
> >> advocating to revert the patch that introduced clock_gettime
> >
> > There has been a number of patches in this area more or less related to
> > clock_gettime, so IMHO fixing it properly is simpler and less prone to
> > introduce new regressions. My previous message in this PR hopefully does
> > exactly this and introduces a patch which should fix it along the lines
> > previously discussed. As my normal gcc development machine is packed in a 
> > box,
> > I haven't been able to test it. Also, note that it won't apply cleanly as 
> > the
> > paths are messed up (but the contents should otherwise apply fine). 
> 
> There have been some subsequent suggestions/updates, so I'm uncertain if
> I should test this patch or wait for an update.

The suggestion are only for the potential corner case where CLOCK_* are not
preprocessor macros but e.g. enums. In any case, this is fixed in the updated
patch I just posted, so feel free to try that one.

> Now that 4.6 has branched, it's safer to commit to mainline after some
> testing and only backport to 4.6 after it has proven correct.

I agree.

>  If all
> else fails, one could apply a hack to 4.6 along the lines of
> 
> #if defined(__alpha__) && defined(__osf__)
> #undef HAVE_CLOCK_GETTIME
> #endif
> 
> or some configure.ac equivalent.  Ugly but still better than completely
> breaking Fortran.

Yes, that's a possibility. OTOH I think my patch should be fairly simple and
safe, but ultimately that's up to the reviewer(s) to decide.

MIPS: va_arg is unable to correct extract an empty zero-length array

[Nick Clifton]

Hi Eric, Hi Richard,

  A customer has reported the following bug with the MIPS target.  Since
  it is for a GNU extension to the C language (zero-length arrays) that
  is being used in a non-intended fashion (the zero-length array is in a
  structure with no other fields) I doubt if you will want to
  investigate the problem too much, but I thought that it was worth
  reporting anyway:

% mips64vr-elf-gcc -mgp32 -O2 -Tddb.ld -march=vr5500 bug.c
% mips64vr-elf-run a.out
assertion "arg4 == va4" failed: file "bug.c", line 40, function: foo

  As an aside if the type3 structure in bug.c is given another,
  non-zero-length field, then the test passes.

Cheers
  Nick

#include 
#include 
#include 

typedef int * type1;

typedef struct 
{
  union u1 { double f1; long int f2; } f3[0];
} type3;

typedef int type4;

static type1 arg1 = 0;
static double arg2 = 1.0;
static type3 arg3 = {{}};
static type4 arg4 = 0x12345678;

void
foo (double parm,
 ...)
{
  va_list  ap;
  type1va1;
  double   va2;
  type3va3;
  type4va4;

  va_start (ap, parm);

  va1 = va_arg (ap, type1);
  assert (arg1 == va1);

  va2 = va_arg (ap, double);
  assert (arg2 == va2);

  va3 = va_arg (ap, type3);

  va4 = va_arg (ap, type4);
  assert (arg4 == va4);

  va_end (ap);
}

int
main (void)
{
  foo (1.0, arg1, arg2, arg3, arg4);
  return 0;
}

[Bug target/48127] Program crashes reading a non-aligned variable

[d.g.gorbachev at gmail dot com]

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

--- Comment #3 from Dmitry Gorbachev  
2011-03-15 18:00:23 UTC ---
I do not agree that the testcase is invalid. As the standart says:

  Common extensions

  Multiple external definitions

 There may be more than one external definition for the identifier of
  an object, with or without the explicit use of the keyword extern; if
  the definitions disagree, or more than one is initialized, the behavior
  is undefined.

According to the Binutils documentation,

  The linker turns a common symbol into a declaration, if there is a
  definition of the same variable.

Also, from Ian Lance Taylor's article [1]:

  5. If A is a strong definition in an object file:

* If B is a common symbol, then we treat B as an undefined reference.

I think it would be better to fix this problem in the linker. Gold does not
even warn about it!

However, I don't understand why GCC makes baz[8] to have 32 bytes alignment,
while baz[4] has only 4 bytes alignment. It seems to be a GCC bug.

When baz is declared extern in main.c, the generated code is correct, but less
optimal.


1. http://www.airs.com/blog/archives/49

[Bug c++/48138] New: __attribute__((aligned)) should give an error when applied to a typedef or template parameter, at least in C++0x mode.

[jyasskin at gcc dot gnu.org]

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

   Summary: __attribute__((aligned)) should give an error when
applied to a typedef or template parameter, at least
in C++0x mode.
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


In the C++0x draft, [dcl.align] says:

"An alignment-specifier may be applied to a variable or to a class
data member, but it shall not be applied to a bit-field, a function
parameter, the formal parameter of a catch clause (15.3), or a
variable declared with the register storage class specifier.  An
alignment-specifier may also be applied to the declaration of a class
or enumeration type."

This does not allow its use on a typedef or next to a typename template
parameter.  It might make sense for gcc to support that as an extension, but
gcc's current behavior is not what people expect that extension to do:

$ cat test.cc
#include 

#define ALIGNED(x) __attribute__((aligned(x)))

struct Char15 {
  char x[15];
}  ALIGNED(8);

template
void print_type_alignment(const T&) {
  struct { char c; T t; } s;
  std::cout << sizeof(T) << ' ' << ((char*)&s.t - (char*)&s.c) << '\n';
}

int main() {
  typedef char unaligned[15];
  typedef char aligned[15] ALIGNED(8);
  unaligned x[10];
  aligned y[10];
  Char15 c15[10];
  std::cout << sizeof(unaligned) << ' ' << sizeof(x) << '\n';
  std::cout << sizeof(aligned) << ' ' << sizeof(y) << '\n';
  std::cout << sizeof(Char15) << ' ' << sizeof(c15) << '\n';

  aligned z ALIGNED(8);
  print_type_alignment(z);
}

$ g++-mp-4.6 -std=gnu++0x test.cc && ./a.out
15 150
15 152
16 160
15 1


Note that the alignment on the typedef applies to the final variable, not the
defined type, which means that interior members of arrays of the defined type
have an unexpected alignment. This has been reported several times before
(PR43798, PR47557, PR12742, PR42098), but the core problem seems to be that
alignments on typedefs aren't supported.

__attribute__((aligned)) on template arguments seems to have no effect at all.





$ g++-mp-4.6 -v
Using built-in specs.
COLLECT_GCC=g++-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.6-20110305/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++
--libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.6
--with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking
--disable-multilib --enable-fully-dynamic-string
Thread model: posix
gcc version 4.6.0 20110305 (experimental) (GCC)

[Bug c/47557] Effect of aligned attribute on arrays

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin  changed:

   What|Removed |Added

 CC||jyasskin at gcc dot gnu.org

--- Comment #3 from Jeffrey Yasskin  2011-03-15 
18:18:06 UTC ---
Alignments on typedefs behave very strangely (PR48138). What you want is:

typedef struct __attribute__((aligned(2))) {
char a[3];
} T;

unsigned x1 = sizeof(T);// sizeof is 4
unsigned x2 = sizeof(T[1]); // sizeof is 4
unsigned x3 = sizeof(T[2]); // sizeof is 8
unsigned x4 = sizeof(T[2][1]);  // sizeof is 8
unsigned x5 = sizeof(T[1][2]);  // sizeof is 8

Moving the attribute makes it apply to the struct instead of the typedef, which
fixes everything. C1x and C++0x don't allow alignments on typedefs either.

[Bug c++/34758] [4.3/4.4/4.5/4.6/4.7 regression] Bad diagnostic for circular dependency in constructor default argument

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2011-03-15 
18:27:15 UTC ---
Author: jason
Date: Tue Mar 15 18:27:09 2011
New Revision: 171009

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171009
Log:
PR c++/34758
* call.c (convert_default_arg): Use DECL_ORIGIN of fn.  Check for
recursion first.
(push_defarg_context, pop_defarg_context): New.
* parser.c (cp_parser_late_parsing_default_args): Use them.
* cp-tree.h: Declare them.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr34758.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug objc/39753] [4.3/4.4/4.5/4.6/4.7 Regression] Objective-C(++) and C90 strict-aliasing interaction bug

[mrs at gcc dot gnu.org]

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

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

   What|Removed |Added

   Keywords|alias, wrong-code   |
 Status|NEW |WAITING

--- Comment #9 from mrs at gcc dot gnu.org  2011-03-15 
18:36:33 UTC ---
So, I'm sort of skeptical of this problem.  Please engineer a test case that
shows bad code.  I think you'll find it is a rather bit harder than you expect.
 I think most dynamic things happen at the end of a function call, that you
can't see into (the Object-C run-time), and those things that happen before
that point, must happen before that point, and those things that happen after
that point, can't come before it.  Objective-C adds a ton of these type of
calls all over the place, which controls just how far the optimizer can move
anything.  Escape analysis should quickly realize that it doesn't own much of
anything, which further prevents almost anything from happening.  As for an
individual pointer, statically, the type should always be reasonable, though,
we do expect to up-cast and downcast pointers.  Some on the C side of things
might disagree, but, once the C people realize that up-casting and down-casting
are both valid, then even this is fine.  Once you combine all these factors,
there is no wiggle room left for the optimizer to do anything.  If you can find
any, test case please.  We can then address the specific concern.

Until then, we'll wait for a testcase.

As far as missing language definition bits, please describe a missing bit, be
specific.  I can't think of any off the top of my head.

[Bug libstdc++/46922] Missing exported symbols from libstdc++

[bkoz at gcc dot gnu.org]

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

--- Comment #5 from Benjamin Kosnik  2011-03-15 
18:43:21 UTC ---

Hey P, why was bad_function_call added in CXXABI instead of GLIBCXX? That
doesn't make sense to me.

-benjamin

[Bug boehm-gc/47309] gcc-4.4.5 fails to build on darwin/ppc due to issues in boehm-gc GC_test_and_set

[elelay at macports dot org]

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

Eric Le Lay  changed:

   What|Removed |Added

 CC||elelay at macports dot org

--- Comment #2 from Eric Le Lay  2011-03-15 
18:58:00 UTC ---
(In reply to comment #1)
> How did you configure GCC?  It seems you are building without bootstrap
> and/or with custom CFLAGS (you lack any optimization).

Hi,
jumping in because I experience the same issue on Gentoo with a PPC32 ibook g4.

Here is my current gcc : 
Target: powerpc-unknown-linux-gnu
Configuré avec: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.3.4/include/g++-v4
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-werror --enable-secureplt --disable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp --enable-checking=release
--disable-libgcj --enable-objc-gc
--enable-languages=c,c++,objc,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.1,
pie-10.1.5'
Modèle de thread: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.1, pie-10.1.5) 


Here is the configure command line
:/var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure --prefix=/usr
--bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.4.5
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.5/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.5/include/g++-v4
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --disable-fixed-point --without-ppl --without-cloog
--enable-nls --without-included-gettext --with-system-zlib --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/powerpc-unknown-linux-gnu/4.4.5/python
--enable-checking=release --disable-libgcj --enable-objc-gc
--enable-languages=c,c++,objc,fortran --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.4.5 p1.2,
pie-0.4.5

I can attach the full log if it helps...

[Bug libstdc++/48130] [4.7 Regression]: build fails on libsupc++/nested_exception.cc

[bkoz at gcc dot gnu.org]

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

--- Comment #5 from Benjamin Kosnik  2011-03-15 
19:01:57 UTC ---

HP if you can confirm this is now working, can you close this? thanks.

[Bug libstdc++/46922] Missing exported symbols from libstdc++

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-03-15 
19:03:01 UTC ---
Uhhhm, you are right, doesn't make much sense, I don't know what i was
thinking. Luckily we are still in time to move those lines in gnu.ver. Let me
know if you want me to do it or you have the tweak part of other work.

[Bug libstdc++/46922] Missing exported symbols from libstdc++

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #7 from Paolo Carlini  2011-03-15 
19:07:44 UTC ---
By the way, it's not at all clear to me why those misplaced patterns actually
do the exporting work (of course at least I verified that, at the time).

[Bug rtl-optimization/47862] Incorrect code for spilling a vector register

[pthaugen at gcc dot gnu.org]

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

--- Comment #8 from Pat Haugen  2011-03-15 
19:43:44 UTC ---
Author: pthaugen
Date: Tue Mar 15 19:43:38 2011
New Revision: 171016

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171016
Log:
PR target/47862
* caller-save.c (insert_restore, insert_save): Use non-validate
form of adjust_address.


Modified:
branches/ibm/gcc-4_5-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_5-branch/gcc/caller-save.c

[Bug target/46788] unsigned int possible treated as signed in a union/struct

[ramana at gcc dot gnu.org]

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

--- Comment #8 from Ramana Radhakrishnan  2011-03-15 
19:59:29 UTC ---
Author: ramana
Date: Tue Mar 15 19:59:25 2011
New Revision: 171017

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

Fix PR target/46788


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/pr46788.c
  - copied unchanged from r171005,
trunk/gcc/testsuite/gcc.target/arm/pr46788.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.md
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog