[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[ttsiodras at gmail dot com]

--- Comment #7 from ttsiodras at gmail dot com  2010-05-24 07:24 ---

>From my two tests in FreeBSD and Arch Linux, it appears that the "-flto" bug
that is triggered on my renderer, has occured with the "20100520 (prerelease)"
commits.

I hope this helps

Is there anything else I can provide?
Again, the GPL code triggering the bug is at:

http://users.softlab.ntua.gr/~ttsiod/renderer-2.x.latest.tar.bz2


-- 


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

[Bug tree-optimization/43416] [4.4 regression] internal compiler error in C++ template instantiations at -O3

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-05-24 07:45 ---
Can't reproduce with either branches/gcc-4_4-branch or
branches/redhat/gcc-4_4-branch any more.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/36553] Missing interface not detected in call to same file function

[paul dot richard dot thomas at gmail dot com]

--- Comment #12 from paul dot richard dot thomas at gmail dot com  
2010-05-24 08:31 ---
Subject: Re:  Missing interface not detected in call to 
same file function

With -fwhole-file, we get for the short testcase:

../pr36553/pr36553.f90:2.9:

 print *, f( (/ 0.0, 1.0/) )
 1
Error: The reference to function 'f' at (1) either needs an explicit
INTERFACE or the rank is incorrect

Paul

On Mon, May 24, 2010 at 12:34 AM, dfranke at gcc dot gnu dot org
 wrote:
>
>
> --- Comment #11 from dfranke at gcc dot gnu dot org  2010-05-23 22:34 
> ---
>
>
> *** This bug has been marked as a duplicate of 31346 ***
>
>
> --
>
> dfranke at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> 
>             Status|NEW                         |RESOLVED
>         Resolution|                            |DUPLICATE
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug debug/42801] C VLAs should use DW_AT_allocated

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-24 08:52 ---
I think DW_AT_allocated would be wrong for C VLAs, they don't have allocated
property like Fortran arrays.
The problems I see are:
1) for -O0 we don't do any var-tracking, while we should be tracking
   i) variables that don't live in memory (vars with register keyword mostly)
   ii) everything during prologues until the stack slots of those variables
   are actually set
   iii) for VLAs even outside of prologues we need to track the lengths before
they are actually set
   Of course this is going to slow down the compiler at -O0 somewhat, so needs
   to be done with extreme care
2) for -O2 there seems to be some issues with VLAs in inlines and cloned
   functions - the type is used from the abstract origin and thus can't have
   correct bounds.  I wonder whether it is ok to have DW_AT_abstract_origin
   and in addition to that DW_AT_type which overrides the original abstract
   origin's type (and, whether gdb will handle it right)


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu dot
   ||org


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

[Bug debug/42638] stack trace shows wrong value for a formal parameter in call-chain

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-24 08:58 ---
Current trunk prints fp=, which is correct (given that the
argument is passed in %eax using regparm calling conventions and the register
has been/could be clobbered by the call).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/41439] choose DW_OP_stack_value over DW_OP_implicit_value more often, please

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-24 09:01 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2010-05-24 09:31 ---
Bisection identified r159600 as the source of the failure on sparc64:

Author: rsandifo
Date: Wed May 19 21:08:53 2010
New Revision: 159600

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159600
Log:
gcc/
* combine.c (propagate_for_debug): Call make_compound_operation
on the source value.
(try_combine): When implementing a split chosen by find_split_point,
either copy i2src or set it to null.  Assert that i2src is not null
before substituting into CALL_INSN_FUNCTION_USAGE.

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

The corresponding gcc-patches thread started here:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01296.html

My ARM box is currently busy running another test, but as soon as that finishes
I'll check if r159600 is also responsible for the ARM bootstrap failure.


-- 


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

[Bug lto/41376] collect2 does not handle static libraries

[bmei at broadcom dot com]

--- Comment #8 from bmei at broadcom dot com  2010-05-24 09:31 ---
I integrated Dave's patch into LD with some modification (only emit those with
LTO sections) and hacked collect2 to support that. The size gain of LTO, our
main concern, is quite limited for our application. Large amount of functions
called only once cannot be inlined across files because compiler doesn't know
whether they are referred in non-LTO compiled code (mostly hand-code assembly
in our cases). We really need full resolution file, especially
LDPR_PREVAILING_DEF_IRONLY type. I will try next to make LD emit full
resolution file. 

Since GNU LD doesn't have plugin support like GOLD. Won't any changes here be
too invasive/specific for LTO purpose to be accepted by LD? We are fine to live
with that in our private port. 


-- 


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

[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues

[jamborm at gcc dot gnu dot org]

--- Comment #11 from jamborm at gcc dot gnu dot org  2010-05-24 09:43 
---
(In reply to comment #9)
> (In reply to comment #7)
> > This is now fixed on both the trunk and the 4.5 branch.
> > 
> 
> this commit produces broken libkhtml.so.5.4.0 from kdelibs-4.4.3.
> in details, it produces different/broken binaries for khtml/css/parser.cpp
> and khtml/svg/SVGGradientElement.cpp.
> 

Please file this as a separate bug and CC me.  I can't promise I'll be
able to look at it this week though.


-- 


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

[Bug fortran/36553] Missing interface not detected in call to same file function

[dfranke at gcc dot gnu dot org]

--- Comment #13 from dfranke at gcc dot gnu dot org  2010-05-24 10:44 
---
(In reply to comment #12)
> With -fwhole-file, we get for the short testcase:
> 
> ../pr36553/pr36553.f90:2.9:
> 
>  print *, f( (/ 0.0, 1.0/) )
>  1
> Error: The reference to function 'f' at (1) either needs an explicit
> INTERFACE or the rank is incorrect

Argh! How did I miss that?

Ok, if the array valued result is removed, it goes again unnoticed:

  real :: f
  print *, f( (/ 0.0, 1.0/) )
end

function f(x)
  real, intent(in) ::  x(:) ! assumed shape requires explicit interface in
caller
  real :: f
  f = sum(x)
end function


-- 


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

[Bug tree-optimization/44258] New: possible SRA wrong-code generation.

[pluto at agmk dot net]

the recent gcc-4.5-branch produces broken libkhtml.so.5.4.0 from kdelibs-4.4.3.
afaics it produces different/broken binaries for khtml/css/parser.cpp
and khtml/svg/SVGGradientElement.cpp.

finally we get a nice GPF during knode/kmail/konqueror startup:

[KCrash Handler]
#5  memcpy () at ../sysdeps/x86_64/memcpy.S:78
#6  0x7f546e63fc5e in QString::QString(QChar const*, int) () from 
/usr/lib64/libQtCore.so.4
#7  0x7f5469f70e2e in qString (ps=) at 
/usr/src/debug/kdelibs-4.4.3/khtml/css/cssparser.h:84
#8  DOM::CSSParser::parseValue (ps=) at 
/usr/src/debug/kdelibs-4.4.3/khtml/css/cssparser.cpp:518
#9  0x7f5469f95075 in cssyyparse (parser=0x7fff08c22820) at 
/usr/src/debug/kdelibs-4.4.3/khtml/css/parser.cpp:2969
#10 0x7f5469f67d00 in DOM::CSSParser::runParser (this=0x7fff08c22820) at 
/usr/src/debug/kdelibs-4.4.3/khtml/css/cssparser.cpp:151
(...)

with svn-bisect i've identified the first affected revision:

Author: jamborm
Date: Wed Apr 28 13:09:56 2010
New Revision: 158826

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158826
Log:
2010-04-28  Martin Jambor  

PR tree-optimization/43846
* tree-sra.c (struct access): New flag grp_assignment_read.
(build_accesses_from_assign): Set grp_assignment_read.
(sort_and_splice_var_accesses): Propagate grp_assignment_read.
(enum mark_read_status): New type.
(analyze_access_subtree): Propagate grp_assignment_read, create
accesses also if both direct_read and root->grp_assignment_read.

* testsuite/gcc.dg/tree-ssa/sra-10.c: New test.


-- 
   Summary: possible SRA wrong-code generation.
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
 GCC build triplet: x86_64-gnu-linux
  GCC host triplet: x86_64-gnu-linux
GCC target triplet: x86_64-gnu-linux


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

[Bug tree-optimization/44258] possible SRA wrong-code generation.

[pluto at agmk dot net]

--- Comment #1 from pluto at agmk dot net  2010-05-24 11:02 ---
Created an attachment (id=20732)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20732&action=view)
preprocessed parser from kdelibs sources.


-- 


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

[Bug tree-optimization/43846] [4.5 Regression] array vs members, total scalarization issues

[pluto at agmk dot net]

--- Comment #12 from pluto at agmk dot net  2010-05-24 11:04 ---
(From update of attachment 20731)
moved to separated PR44258.


-- 

pluto at agmk dot net changed:

   What|Removed |Added

  Attachment #20731|0   |1
is obsolete||


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

[Bug debug/41048] bad DW_AT_data_member_location from g++

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-24 11:13 ---
Created an attachment (id=20733)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20733&action=view)
gcc46-pr41048.patch

Untested fix.


-- 


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

[Bug debug/40713] Overlapping .debug_ranges (C++)

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-24 11:13 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[iains at gcc dot gnu dot org]

--- Comment #3 from iains at gcc dot gnu dot org  2010-05-24 11:46 ---
most likely this is a duplicate of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229

and potentially an LE/BE issue given that it's not reported on *x86*


-- 


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

[Bug bootstrap/44229] [4.6 Regression] 1 new GCC h...@159608 regression

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.5.1
  Known to work||4.5.0
Summary|possible SRA wrong-code |[4.5/4.6 Regression]
   |generation. |possible SRA wrong-code
   ||generation.
   Target Milestone|--- |4.5.1


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

[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.

[arekm at pld-linux dot org]

--- Comment #2 from arekm at pld-linux dot org  2010-05-24 12:14 ---
In meantime - is reversing the problematic gcc commit a sane thing to do for a
gcc user? (from what I understand it was simply a better optimization and no
real bugfix, right?)


-- 


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

[Bug lto/41376] collect2 does not handle static libraries

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-05-24 12:15 ---
(In reply to comment #8)
> I integrated Dave's patch into LD with some modification (only emit those with
> LTO sections) and hacked collect2 to support that. The size gain of LTO, our
> main concern, is quite limited for our application. Large amount of functions
> called only once cannot be inlined across files because compiler doesn't know
> whether they are referred in non-LTO compiled code (mostly hand-code assembly
> in our cases). We really need full resolution file, especially
> LDPR_PREVAILING_DEF_IRONLY type. I will try next to make LD emit full
> resolution file.

Note that for a notable size-gain you likely need to build with
-fwhole-program (which means GCC needs to see all references to functions
or you need to mark functions which are accessed from assembly code
with the externally_visible attribute).

> Since GNU LD doesn't have plugin support like GOLD. Won't any changes here be
> too invasive/specific for LTO purpose to be accepted by LD? We are fine to 
> live
> with that in our private port. 

I guess that outputting a full resolution file might be ok with the LD
folks as it can be a useful thing for debugging as well.  But of course
it would be their call, including details of the format.

I would also expect that a very simple approach for a collect2-only patch
would work most of the times (but when it wouldn't work it could result
in wrong-code or final linker failures).  Simply decompose lib*.a linker
arguments to their respective lib...@offset members for the lto1
invocation (and make lto1 ignore, not barf on non-LTO objects).

I will also try to see what incrementally doing the symbol resolution
would take.


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2010-05-24 12:18 ---
(In reply to comment #6)
> Well, I added "nostdlib" and removed all libraries from the cmd line, but
> still:
> 
> bash$ g++  -r -nostdlib -O3 -g -Wall -Wextra -fomit-frame-pointer -ffast-math
> -funsafe-math-optimizations -mtune=native -flto -msse -mrecip -mfpmath=sse
> -msse2 -mssse3 -DNDEBUG   -o renderer renderer-renderer.o renderer-Algebra.o
> renderer-Camera.o renderer-Keyboard.o renderer-Light.o renderer-Object3D.o
> renderer-Scene.o renderer-Screen.o renderer-Base3d.o -fwhole-program  
> lto1: internal compiler error: in gimple_register_type, at gimple.c:3820
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper: /usr/bin/g++ returned 1 exit status
> collect2: lto-wrapper returned 1 exit status
> 
> In fact, it crashes even when I remove -fwhole-program.
> It only works if I remove the -flto.

Yes, now with the above command-line remove .o files one-by one and figure
out the minimal set of *.o files that make it crash.  For those files
please attach pre-processed source.  (I expect it will be a single file)


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2010-05-24 12:24 ---
Btw, it reccurs to me that the issue will be fixed by

http://gcc.gnu.org/viewcvs/trunk/gcc/lto/lto.c?r1=158729&r2=158728&pathrev=158729


-- 


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

[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2010-05-24 12:31 ---
Created an attachment (id=20734)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20734&action=view)
Fix for this PR and PR40011 #42

This patch regtests OK apart from some peculiarities in proc_ptr_comp_9.f90 and
proc_ptr_23.f90, which fail to link with -g.  The problems do not appear to be
associated with this patch, however.

My belief is that with this patch and corrections of the "legacy style"
testsuite cases, -fwhole-file could be finally made the default.

Paul  


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2010-05-24 12:34 
---
Subject: Bug 44256

Author: rguenth
Date: Mon May 24 12:34:34 2010
New Revision: 159779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159779
Log:
2010-05-24  Richard Guenther  

PR lto/44256
* lto.c (lto_fixup_type): Deal with non-type TYPE_CONTEXT.

* gcc.dg/lto/20100426_0.c: New testcase.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/lto/20100426_0.c
Modified:
branches/gcc-4_5-branch/gcc/lto/ChangeLog
branches/gcc-4_5-branch/gcc/lto/lto.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-05-24 12:35 
---
The next snapshot will pick up this fix.


-- 


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

[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176

[rguenth at gcc dot gnu dot org]

--- Comment #24 from rguenth at gcc dot gnu dot org  2010-05-24 12:56 
---
(In reply to comment #23)
> Just wondering after so many adjustments - is the bug going to be fixed ?

Very unlikely.  If there is a small patch that fixed it for 4.4.0 then
that can possibly be back-ported (but nobody tried to bisect the svn for that
sofar).  But I guess that the thing that fixed it was the merge of the
new register allocator.


-- 


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

[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.

[jamborm at gcc dot gnu dot org]

--- Comment #3 from jamborm at gcc dot gnu dot org  2010-05-24 12:57 ---
(In reply to comment #2)
> In meantime - is reversing the problematic gcc commit a sane thing to do for a
> gcc user? (from what I understand it was simply a better optimization and no
> real bugfix, right?)
> 

If you're asking about reverting it in your local copy and by sane you
mean safe then yes, you certainly can do it.  I'll have a look at this
as soon as I can but unfortunately that probably means next week.


-- 


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

[Bug c/44259] New: pex-unix.c: error: conflicting types for '__char_ptr32'

[jay dot krell at cornell dot edu]

libiberty/pex-unix.c has some alpha64(ia64?)-dec-vms specific
code, that fails to compile for me due to mismatched typedefs:

+ make
if [ x"" != x ]; then \
  alpha64-dec-vms-gcc -c -DHAVE_CONFIG_H   -I.
-I/src/binutils/src/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic   /src/binutils/src/libiberty/pex-unix.c -o
pic/pex-unix.obj; \
else true; fi
alpha64-dec-vms-gcc -c -DHAVE_CONFIG_H   -I.
-I/src/binutils/src/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic  /src/binutils/src/libiberty/pex-unix.c -o
pex-unix.obj
/src/binutils/src/libiberty/pex-unix.c:70:16: error: conflicting types for
'__char_ptr32'
/usr/local/lib/gcc/alpha64-dec-vms/4_5_0/../../../../alpha64-dec-vms/include/decc$types.h:344:20:
note: previous declaration of '__char_ptr32' was here
/src/binutils/src/libiberty/pex-unix.c: In function 'to_ptr32':


Rather than "fix" it, there is a better reliable portable simpler way.
("portable" to alpha[64]-dec-vms at least, gcc and decc, without
dependence either on gcc __attribute__ or decc #pragma pointer_size)


Instead of using __attribute__, use int* when you want an
array of 32bit pointers, and cast, like:


e.g.:


#if defined(VMS) && defined (__LONG_POINTERS)

/* Return a 32 bit pointer to an array of 32 bit pointers 
   given a 64 bit pointer to an array of 64 bit pointers.  */

static char**
to_ptr32 (char **ptr64)
{
  int argc;
  int* short_argv;

  for (argc=0; ptr64[argc]; argc++);

  /* Reallocate argv with 32 bit pointers.  */
  short_argv = (int*) decc$_malloc32(sizeof (int) * (argc + 1));

  for (argc=0; ptr64[argc]; argc++)
short_argv[argc] = (int) decc$_strdup32 (ptr64[argc]);

  short_argv[argc] = 0;
  return (char**) short_argv;
}


-- 
   Summary: pex-unix.c: error: conflicting types for '__char_ptr32'
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jay dot krell at cornell dot edu
GCC target triplet: alpha64-dec-vms


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

[Bug tree-optimization/39874] [4.4 regression] missing VRP (submission)

[sandra at codesourcery dot com]

--- Comment #3 from sandra at codesourcery dot com  2010-05-24 13:08 ---
I'm testing a fix for this (better comparison combination logic in the
ifconvert pass).


-- 

sandra at codesourcery dot com changed:

   What|Removed |Added

 CC||sandra at codesourcery dot
   ||com


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

[Bug middle-end/28685] Multiple comparisons are not simplified

[sandra at codesourcery dot com]

--- Comment #13 from sandra at codesourcery dot com  2010-05-24 13:21 
---
I'm working on a patch that fixes the test case in comment #5 (originally filed
as PR 39874) and some other test cases by improving the comparison combination
logic in both tree-ssa-ifcombine and tree-ssa-reassoc.

The test case in comment #4 is a somewhat different problem -- maybe it is a
VRP failure?  The problem is figuring out the right place to attempt to combine
the comparisons


-- 


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

[Bug c++/44260] New: Strange behavior on bit fields sructures.

[dennis at conus dot info]

If compiled without -O3 option, this code snippet works fine (running
executable will print "i=11223344, bswap=44332211")
If compiled with -O3 option, executable will print "i=11223344,
bswap=".
Checked on 4.4.1 x86 and 4.4.3 x64.

#include 

struct int32_bytes
{
int byte1:8;
int byte2:8;
int byte3:8;
int byte4:8;
};

unsigned int bswap (unsigned int in)
{
struct int32_bytes *tmp_in;
struct int32_bytes *tmp_out;
unsigned int rt;

tmp_in=(struct int32_bytes *)∈
tmp_out=(struct int32_bytes *)&rt;

tmp_out->byte1 = tmp_in->byte4;
tmp_out->byte2 = tmp_in->byte3;
tmp_out->byte3 = tmp_in->byte2;
tmp_out->byte4 = tmp_in->byte1;

return rt;
};

int main()
{
for (int i=0x11223344; i<=0x112233FF; i++)
{
if (i==0x11223344)
printf ("i=%08X, bswap=%08X\n", i, bswap (i));
};
};


-- 
   Summary: Strange behavior on bit fields sructures.
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dennis at conus dot info
 GCC build triplet: 4.4.3
  GCC host triplet: 4.4.3
GCC target triplet: 4.4.3


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

[Bug lto/41376] collect2 does not handle static libraries

[bmei at broadcom dot com]

--- Comment #10 from bmei at broadcom dot com  2010-05-24 13:29 ---
annotating functions with externally_visible sounds a bit difficult to
maintain. Programmer needs to know whether a function is used outside of LTO
objects. This can change over time and extra efforts are needed to keep it
correct.  It would be better if GCC can derive that info with -fwhole-program,
whether it is deal with LTO-object file only or LTO/Regular object files, since
it should have all the symbol reference information by then. 


-- 


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

[Bug c++/44260] Strange behavior on bit fields sructures.

[dennis at conus dot info]

--- Comment #1 from dennis at conus dot info  2010-05-24 13:30 ---
The code 4.4.1 x86 generating (with -O3 option) for bswap() function I
mentioned earlier is strange too:


; bswap(unsigned int)
public _Z5bswapj
_Z5bswapj   proc near

var_4   = dword ptr -4
arg_0   = dword ptr  8

pushebp
mov ebp, esp
sub esp, 10h
mov eax, [ebp+arg_0]
mov edx, eax
sar edx, 18h
mov byte ptr [ebp+var_4], dl
mov edx, eax
shr edx, 10h
mov byte ptr [ebp+var_4+1], dl
movsx   edx, ah
mov byte ptr [ebp+var_4+3], al
mov eax, [ebp+var_4]   ; returning var_4
mov byte ptr [ebp+var_4+2], dl ; set last byte to var_4
leave
retn
_Z5bswapj   endp


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[ttsiodras at gmail dot com]

--- Comment #12 from ttsiodras at gmail dot com  2010-05-24 13:41 ---

I am at work, so I did a fresh compilation of GCC4.5 from the 20050520 
snapshot under my Debian stable using: 

../configure --prefix=/opt/gcc45 --enable-languages=c,c++ --enable-lto

The bug still happens, even if I trim the link line to include ONLY ONE
object file:

bash$ /opt/gcc-4.5-20100520/bin/g++ -r -nostdlib -O3 -g -Wall -Wextra
-fomit-frame-pointer -ffast-math -funsafe-math-optimizations -mtune=native
-flto -msse -mrecip -mfpmath=sse -msse2 -DNDEBUG   -o renderer
renderer-renderer.o
lto1: internal compiler error: in gimple_register_type, at gimple.c:3820
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /opt/gcc-4.5-20100520/bin/g++ returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[ttsiodras at gmail dot com]

--- Comment #13 from ttsiodras at gmail dot com  2010-05-24 13:44 ---

I meant 20100520, obviously, not 20050520 (no flto back then! :-)

Anyway, if I understood correctly, I should wait for the next snapshot... ETA?


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[ttsiodras at gmail dot com]

--- Comment #14 from ttsiodras at gmail dot com  2010-05-24 13:47 ---

And now that we see that it happens even with one object file,
here is the preprocessed (.ii) for the code behind this object file:

http://users.softlab.ntua.gr/~ttsiod/renderer.ii.gz


-- 


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

[Bug c++/44260] Strange behavior on bit fields structures

[xinping dot huang at gmail dot com]

--- Comment #2 from xinping dot huang at gmail dot com  2010-05-24 13:51 
---
Subject: Re:  Strange behavior on bit fields sructures.

My gcc 4.4.4 generate the correct binary and get the correct result
even with -O3 option.

Wesley

2010/5/24 dennis at conus dot info :
>
>
> --- Comment #1 from dennis at conus dot info  2010-05-24 13:30 ---
> The code 4.4.1 x86 generating (with -O3 option) for bswap() function I
> mentioned earlier is strange too:
>
>
> ; bswap(unsigned int)
>                public _Z5bswapj
> _Z5bswapj       proc near
>
> var_4           = dword ptr -4
> arg_0           = dword ptr  8
>
>                push    ebp
>                mov     ebp, esp
>                sub     esp, 10h
>                mov     eax, [ebp+arg_0]
>                mov     edx, eax
>                sar     edx, 18h
>                mov     byte ptr [ebp+var_4], dl
>                mov     edx, eax
>                shr     edx, 10h
>                mov     byte ptr [ebp+var_4+1], dl
>                movsx   edx, ah
>                mov     byte ptr [ebp+var_4+3], al
>                mov     eax, [ebp+var_4]           ; returning var_4
>                mov     byte ptr [ebp+var_4+2], dl ; set last byte to var_4
>                leave
>                retn
> _Z5bswapj       endp
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44260
>
>


-- 


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

[Bug c++/44260] Strange behavior on bit fields structures

[xinping dot huang at gmail dot com]

--- Comment #3 from xinping dot huang at gmail dot com  2010-05-24 13:53 
---
Subject: Re:  Strange behavior on bit fields structures

Sorry I made a mistake here, it works on 32bit mode, but failed on the
64bit mode.

Wesley

2010/5/24 xinping dot huang at gmail dot com :
>
>
> --- Comment #2 from xinping dot huang at gmail dot com  2010-05-24 13:51 
> ---
> Subject: Re:  Strange behavior on bit fields sructures.
>
> My gcc 4.4.4 generate the correct binary and get the correct result
> even with -O3 option.
>
> Wesley
>
> 2010/5/24 dennis at conus dot info :
>>
>>
>> --- Comment #1 from dennis at conus dot info  2010-05-24 13:30 ---
>> The code 4.4.1 x86 generating (with -O3 option) for bswap() function I
>> mentioned earlier is strange too:
>>
>>
>> ; bswap(unsigned int)
>>                public _Z5bswapj
>> _Z5bswapj       proc near
>>
>> var_4           = dword ptr -4
>> arg_0           = dword ptr  8
>>
>>                push    ebp
>>                mov     ebp, esp
>>                sub     esp, 10h
>>                mov     eax, [ebp+arg_0]
>>                mov     edx, eax
>>                sar     edx, 18h
>>                mov     byte ptr [ebp+var_4], dl
>>                mov     edx, eax
>>                shr     edx, 10h
>>                mov     byte ptr [ebp+var_4+1], dl
>>                movsx   edx, ah
>>                mov     byte ptr [ebp+var_4+3], al
>>                mov     eax, [ebp+var_4]           ; returning var_4
>>                mov     byte ptr [ebp+var_4+2], dl ; set last byte to var_4
>>                leave
>>                retn
>> _Z5bswapj       endp
>>
>>
>> --
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44260
>>
>>
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44260
>
>


-- 


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

[Bug fortran/26227] accepts invalid fortran, different dummy types/number

[dfranke at gcc dot gnu dot org]

--- Comment #14 from dfranke at gcc dot gnu dot org  2010-05-24 14:03 
---
(In reply to comment #13)
> Should we close this?

Yes, this is testcase gfortran.dg/whole_file_2.f90.
Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[iains at gcc dot gnu dot org]

--- Comment #23 from iains at gcc dot gnu dot org  2010-05-24 14:36 ---
Subject: Bug 43602

Author: iains
Date: Mon May 24 14:36:32 2010
New Revision: 159781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159781
Log:
2010-05-24  Iain Sandoe  

PR target/44132
PR middle-end/43602
* varasm.c (get_emutls_init_templ_addr): Copy DECL_PRESERVE_P,
DECL_VISIBILITY_SPECIFIED.
(emutls_decl): Set DECL_PRESERVE_P and copy
DECL_VISIBILITY_SPECIFIED, DECL_RESTRICTED_P.
(emutls_finalize_control_var): New callback.
(emutls_finish): Finalize emutls control variables.
* toplev.c (compile_file): Move the call to emutls_finish () 
before varpool_assemble_pending_decls ().


Modified:
trunk/gcc/ChangeLog
trunk/gcc/toplev.c
trunk/gcc/varasm.c


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #22 from iains at gcc dot gnu dot org  2010-05-24 14:36 ---
Subject: Bug 44132

Author: iains
Date: Mon May 24 14:36:32 2010
New Revision: 159781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159781
Log:
2010-05-24  Iain Sandoe  

PR target/44132
PR middle-end/43602
* varasm.c (get_emutls_init_templ_addr): Copy DECL_PRESERVE_P,
DECL_VISIBILITY_SPECIFIED.
(emutls_decl): Set DECL_PRESERVE_P and copy
DECL_VISIBILITY_SPECIFIED, DECL_RESTRICTED_P.
(emutls_finalize_control_var): New callback.
(emutls_finish): Finalize emutls control variables.
* toplev.c (compile_file): Move the call to emutls_finish () 
before varpool_assemble_pending_decls ().


Modified:
trunk/gcc/ChangeLog
trunk/gcc/toplev.c
trunk/gcc/varasm.c


-- 


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

[Bug debug/42801] C VLAs should use DW_AT_allocated

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-24 14:38 ---
Created an attachment (id=20735)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20735&action=view)
gcc46-pr42801.patch

Patch for the -O2 issue.
The standard says:
"Concrete inlined instance entries may omit attributes that are not specific to
the concrete instance (but present in the abstract instance) and need include
only attributes that are specific to the concrete instance (but omitted in the
abstract instance).", which I read as not forbidding duplication of the
DW_AT_type attribute (dropping DW_AT_type in the abstract instance doesn't seem
to be a good idea, even when bounds aren't known the type otherwise gives
useful info).  Perhaps we should handle DW_TAG_formal_parameters the same way
in dwarf2out.c.
Unfortunately, gdb prints 0 instead of 24 in the second case.


-- 


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

[Bug bootstrap/44019] xgcc: error trying to exec '/test/gnu/gcc/objdir/./prev-gcc/gnat1': execv: Not e

[danglin at gcc dot gnu dot org]

--- Comment #6 from danglin at gcc dot gnu dot org  2010-05-24 15:28 ---
this was caused by the maxtsiz limit.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/44165] 5/15/2010 snapshot build failure on hppa Linux

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2010-05-24 15:36 ---
I have also seen this error.

It's a bit of a puzzle.  A segfault occurs in the startup of
the a.out file run by configure.  A null constructor address
is loaded from the constructor table causing the fault. 


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-24 15:36:21
   date||


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

[Bug c++/44260] Strange behavior on bit fields structures

[schwab at linux-m68k dot org]

--- Comment #4 from schwab at linux-m68k dot org  2010-05-24 15:48 ---


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


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/21920] aliasing violations

[schwab at linux-m68k dot org]

--- Comment #152 from schwab at linux-m68k dot org  2010-05-24 15:48 ---
*** Bug 44260 has been marked as a duplicate of this bug. ***


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 CC||dennis at conus dot info


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2010-05-24 16:16 ---
(In reply to comment #3)
> most likely this is a duplicate of:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
> 
> and potentially an LE/BE issue given that it's not reported on *x86*

However:
1. I see the failure on both BE (sparc64) and LE (armv5tel).
2. Both BE (powerpc64-linux) and LE (x86) don't see the failure.

So I doubt it's an endianess issue.


-- 


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2010-05-24 16:21 ---
Comparing stage2-libiberty/cp-demangle.o with stage3-libiberty/cp-demangle.o
shows that one instruction has had it's source operands swapped:

> objdump -d stage2-libiberty/cp-demangle.o > a
> objdump -d stage3-libiberty/cp-demangle.o > b
> diff -u a b
--- a   2010-05-24 17:59:49.0 +0200
+++ b   2010-05-24 17:59:54.0 +0200
@@ -1,5 +1,5 @@

-stage2-libiberty/cp-demangle.o: file format elf32-sparc
+stage3-libiberty/cp-demangle.o: file format elf32-sparc


 Disassembly of section .text:
@@ -4702,7 +4702,7 @@
 5078:  89 29 20 04 sll  %g4, 4, %g4
 507c:  84 00 80 04 add  %g2, %g4, %g2
 5080:  84 00 b8 6c add  %g2, -1940, %g2
-5084:  84 80 80 03 addcc  %g2, %g3, %g2
+5084:  84 80 c0 02 addcc  %g3, %g2, %g2
 5088:  22 80 02 11 be,a   58cc 
 508c:  c4 00 a0 04 ld  [ %g2 + 4 ], %g2
 5090:  c6 06 20 14 ld  [ %i0 + 0x14 ], %g3

Now, the code is still correct, but gcc shouldn't arbitrarily change it's mind
like this in stage3. Hence I suspect r159600 introduces some non-determinism,
or exposes latent non-determinism.


-- 


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

[Bug target/44261] New: Multiplying -1 by NaN is not valid.

[carlos at codesourcery dot com]

The following testcase is an example of code used in a glibc testcase. I'm
trying hard to shake out the bugs in the glibc testsuite for debian, and one
testsuite failure looks like a compiler issue.

The expected behaviour is for the testcase to print the raw IEEE754 value of
-NAN.

The observed behaviour, when -DALT is on the command line, is that the testcase
prints the incorrect raw value e.g. NAN.

GCC 4.4.3 in debian doesn't compile this code correctly.

cat >> tst-mul-nan.c <
#include 

#ifdef ALT
volatile double nanval;
#else
#define nanval NAN
#endif

int
main ()
{
#ifdef ALT
 nanval = NAN;
#endif
 printf ("0x%llx\n", -nanval);
 return 0;
}
EOF

gcc -g3 -O0 -save-temps -o test-mul-nan-OK test-mul-nan.c; ./test-mul-nan-OK
0xfff7

This is the correct result e.g. -NAN. In the correct case the compiler has
already computer -NAN and it's loaded directly from the local symbol e.g.

.LC1:
   .word   -524289
   .word   -1

This is the case that is not working correctly:

gcc -g3 -O0 -save-temps -DALT -o test-mul-nan-NG test-mul-nan.c;
./test-mul-nan-NG
0x7ff7

That result is not -NAN, it is NAN. This is incorrect.

In the incorrect compilation the compiler loads NAN from a local constant:

.LC0:
   .word   2146959359
   .word   -1

This is 0x7ff7 e.g. NAN.

Then it loads a 64-bit double -1.0.

.LC2:
   .word   -1074790400
   .word   0

In the incorrect case the compiler tries to multiply -1.0 by NAN to get a
result of -NAN.

   addil LR'nanval-$global$,%r27
   copy %r1,%r19
   ldo RR'nanval-$global$(%r19),%r19
   fldds 0(%r19),%fr23
   ldil LR'.LC2,%r19
   ldo RR'.LC2(%r19),%r19
   fldds 0(%r19),%fr22
   fmpy,dbl %fr23,%fr22,%fr22

This is not going to work because -1.0 times NAN is NAN, and the sign of the
input will be ignored.

See: PA-RISC 2.0 Architecture, Floating Coprocessor 8-23 "Operations With
NaNs", and 8-24 "Sign Bit" can be referenced for information on NANs.

After the multiplication fr22 still contains NAN, and that is what is printed
instead of the expected result of -NAN.

John David Anglin indicates:

This is a bug.

The code should xor the sign bit when doing negation.  The existing code
doesn't work for NANs.  I'll try to fix negdf2 and negsf2.

The problem is PA1.1 doesn't have a fneg instruction, so the above takes a bit
of work to implement.  You will get the correct result if you specify
-march=2.0.

Unfortunately I can't use -march=2.0 in this case, the C library has to work on
PA1.1 class systems.


-- 
   Summary: Multiplying -1 by NaN is not valid.
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at codesourcery dot com
 GCC build triplet: hppa-linux-gnu
  GCC host triplet: hppa-linux-gnu
GCC target triplet: hppa-linux-gnu


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

[Bug target/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[uros at gcc dot gnu dot org]

--- Comment #28 from uros at gcc dot gnu dot org  2010-05-24 16:23 ---
Subject: Bug 43733

Author: uros
Date: Mon May 24 16:22:30 2010
New Revision: 159785

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159785
Log:
Backport from mainline:
2010-05-20  Uros Bizjak  

PR target/43733
* configure.ac (gcc_cv_as_ix86_sahf): Switch to 64bit mode.
* configure: Regenerate.
* config.in: Regenerate.
* config/i386/i386.md (x86_sahf_1): Conditionally output 0x9e
instead of sahf only for 64bit targets.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config.in
branches/gcc-4_5-branch/gcc/config/i386/i386.md
branches/gcc-4_5-branch/gcc/configure
branches/gcc-4_5-branch/gcc/configure.ac


-- 


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

[Bug target/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[uros at gcc dot gnu dot org]

--- Comment #29 from uros at gcc dot gnu dot org  2010-05-24 16:26 ---
Subject: Bug 43733

Author: uros
Date: Mon May 24 16:26:17 2010
New Revision: 159786

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159786
Log:
Backport from mainline:
2010-05-20  Uros Bizjak  

PR target/43733
* configure.ac (gcc_cv_as_ix86_sahf): Switch to 64bit mode.
* configure: Regenerate.
* config.in: Regenerate.
* config/i386/i386.md (x86_sahf_1): Conditionally output 0x9e
instead of sahf only for 64bit targets.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config.in
branches/gcc-4_4-branch/gcc/config/i386/i386.md
branches/gcc-4_4-branch/gcc/configure
branches/gcc-4_4-branch/gcc/configure.ac


-- 


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

[Bug target/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[uros at gcc dot gnu dot org]

--- Comment #30 from uros at gcc dot gnu dot org  2010-05-24 16:29 ---
Subject: Bug 43733

Author: uros
Date: Mon May 24 16:28:53 2010
New Revision: 159787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159787
Log:
Backport from mainline:
2010-05-20  Uros Bizjak  

PR target/43733
* configure.ac (gcc_cv_as_ix86_sahf): Switch to 64bit mode.
* configure: Regenerate.
* config.in: Regenerate.
* config/i386/i386.md (x86_sahf_1): Conditionally output 0x9e
instead of sahf only for 64bit targets.


Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config.in
branches/gcc-4_3-branch/gcc/config/i386/i386.md
branches/gcc-4_3-branch/gcc/configure
branches/gcc-4_3-branch/gcc/configure.ac


-- 


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

[Bug target/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[ubizjak at gmail dot com]

--- Comment #31 from ubizjak at gmail dot com  2010-05-24 16:31 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Keywords||build
 Resolution||FIXED
   Target Milestone|--- |4.3.6


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

[Bug lto/41376] collect2 does not handle static libraries

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2010-05-24 17:27 ---
Subject: Re:  collect2 does not handle static libraries

On Mon, 24 May 2010, bmei at broadcom dot com wrote:

> --- Comment #10 from bmei at broadcom dot com  2010-05-24 13:29 ---
> annotating functions with externally_visible sounds a bit difficult to
> maintain. Programmer needs to know whether a function is used outside of LTO
> objects. This can change over time and extra efforts are needed to keep it
> correct.  It would be better if GCC can derive that info with -fwhole-program,
> whether it is deal with LTO-object file only or LTO/Regular object files, 
> since
> it should have all the symbol reference information by then. 

Indeed - at least if you are not dealing with building a shared
library or a program which needs to expose symbols to plugins
that are loaded at runtime.  Of course at the moment - if at all - the
symbol reference information is only available when using something
like the linker-plugin.

Richard.


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #23 from iains at gcc dot gnu dot org  2010-05-24 17:27 ---
Created an attachment (id=20736)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20736&action=view)
candidate solution 

OK, so comment #22 is the work-around ... 

.. here is the current version of the "proper" solution - that makes the emutls
vars recognized by OMP and LTO.

This works for me for c, c++,Objc, ObjC++ and Fortran (i686 and x86_64 darwin,
[ powerpc as well but not recently bootstrapped]) with one regression:

gcc.dg/tls/asm-1.c  -- would be good if someone more gimplifier experience
could look at gimplify_asm () and see where there is a wrong assumption about
arguments...

There is a "latent" regression in c++ (if we enable all the tls_native tests
applicable) - this is a case where there are two conflicting error messages -
and I think the FE has got confused about whether the var is __thread or not
and tries to create a static constructor for a failed case .. but not 100% sure
about that.



TODO:  The expansion of gimplification in tree-profile.c (not a regression
currently, but one waiting to happen).



This is ready to kick around a bit -- could other affected targets test/give
opinions etc?

I guess we should get comments on whether this is too invasive...
...  although, if that's felt to be the case I'd like suggestions as to where
else to hook in.. :-)


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20701|0   |1
is obsolete||


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2010-05-24 17:42 
---
Subject: Bug 44196

Author: rguenth
Date: Mon May 24 17:41:47 2010
New Revision: 159789

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159789
Log:
2010-05-24  Richard Guenther  

PR lto/44196
* tree.c (find_decls_types_r): Walk BLOCKs and its vars.

* g++.dg/lto/20100519-1_0.C: New testcase.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/lto/20100519-1_0.C
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree.c


-- 


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

[Bug lto/44196] lto1: ICE: tree check: expected field_decl, have type_decl in gimple_types_compatible_p, at gimple.c:3597

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2010-05-24 17:52 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.6.0   |4.5.1 4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.5.1


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

[Bug target/44261] Multiplying -1 by NaN is not valid.

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-05-24 17:55 ---
Well - GCC has fallback expansions for some sign-related instructions by doing
bit-fiddling instead.  I think that's whats required if the arch cannot do
a IEEE negate.


-- 


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

[Bug c++/44256] When using -flto and -fwhole-program the compiler/linker crash

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2010-05-24 18:02 
---
Thanks.  With the preprocessed source I can confirm the crash and also confirm
that the fix I just committed fixes the crash.

Snapshots are generated every week, so the next is due on May 29th.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.1


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

[Bug target/44261] Multiplying -1 by NaN is not valid.

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2010-05-24 
18:11 ---
Subject: Re:  Multiplying -1 by NaN is not valid.

On Mon, 24 May 2010, rguenth at gcc dot gnu dot org wrote:

> Well - GCC has fallback expansions for some sign-related instructions by doing
> bit-fiddling instead.  I think that's whats required if the arch cannot do
> a IEEE negate.

I am testing the attached change to fiddle the sign bit.  It is probably
more efficient than a generic fallback.

Dave


--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2010-05-24 
18:11 ---
Created an attachment (id=20737)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20737&action=view)


-- 


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

[Bug c++/44254] Template pointer and reference arguments not always recognized as referencing to the same variable

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-24 18:24 ---
Most likely the same issue as 20357.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||20357


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

[Bug c++/41510] [C++0x] std::complex vs. initialization lists

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2010-05-24 18:38 ---
Subject: Bug 41510

Author: jason
Date: Mon May 24 18:38:16 2010
New Revision: 159792

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159792
Log:
PR c++/41510
* decl.c (check_initializer): Don't wrap an init-list in a
TREE_LIST.
* init.c (build_aggr_init): Don't assume copy-initialization if
init has CONSTRUCTOR_IS_DIRECT_INIT.
* call.c (build_new_method_call): Sanity check.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist35.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/init/brace6.C


-- 


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

[Bug objc/44140] objc.dg/torture/tls/thr-init-3.m failure

[iains at gcc dot gnu dot org]

--- Comment #5 from iains at gcc dot gnu dot org  2010-05-24 19:22 ---
this has nothing to do with tls it is a general issue with ObjC/lto..  : 
the following code (OK w.out,   error with -flto)
===

cat trivial.m:

extern int printf (char *,...) ;

typedef struct objc_class *Class;

struct objc_class {
Class isa;
/* other stuff... */
}  ;

@interface Object {
@public
 Class isa;
}
+initialize;
+(Class)class;

@end

@implementation Object
+initialize {
 return self;
}

+(Class)class {
 return (Class)self;
}

@end

int main(void)
{
  [Object class];
  printf("trivial OK\n");
  return 0;
}

===

will take a look at it as soon as poss.


-- 


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

[Bug debug/44113] bad debugging information for unrolled loops

[jan dot kratochvil at redhat dot com]

--- Comment #10 from jan dot kratochvil at redhat dot com  2010-05-24 19:49 
---
GDB counterpart (no patch now):
http://sourceware.org/bugzilla/show_bug.cgi?id=11631


-- 


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

[Bug debug/42801] C VLAs should use DW_AT_allocated

[jan dot kratochvil at redhat dot com]

--- Comment #4 from jan dot kratochvil at redhat dot com  2010-05-24 19:53 
---
Archer counterpart (no patch now):
http://sourceware.org/bugzilla/show_bug.cgi?id=11632


-- 


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

[Bug lto/44090] lto ice in verify_stmts

[astrange at ithinksw dot com]

--- Comment #3 from astrange at ithinksw dot com  2010-05-24 20:01 ---
Fixed itself. Though lto still doesn't build ffmpeg, it's just a different bug
now.


-- 

astrange at ithinksw dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #24 from iains at gcc dot gnu dot org  2010-05-24 20:11 ---
Created an attachment (id=20738)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20738&action=view)
candidate solution (with all the files)

and now with all the changed files ...


-- 

iains at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20736|0   |1
is obsolete||


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

[Bug c++/41510] [C++0x] std::complex vs. initialization lists

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2010-05-24 20:33 ---
Fixed for 4.5.1.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/41510] [C++0x] std::complex vs. initialization lists

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2010-05-24 20:33 ---
Subject: Bug 41510

Author: jason
Date: Mon May 24 20:33:06 2010
New Revision: 159796

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159796
Log:
PR c++/41510
* decl.c (check_initializer): Don't wrap an init-list in a
TREE_LIST.
* init.c (build_aggr_init): Don't assume copy-initialization if
init has CONSTRUCTOR_IS_DIRECT_INIT.
* call.c (build_new_method_call): Sanity check.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/cpp0x/initlist35.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/call.c
branches/gcc-4_5-branch/gcc/cp/decl.c
branches/gcc-4_5-branch/gcc/cp/init.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/init/brace6.C


-- 


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

[Bug c/44262] New: va_list usage missed optimization.

[svfuerst at gmail dot com]

This function generates the following asm under -O3 in version 4.5

#include 
void va_overload2(int p1, int p2);
void va_overload3(int p1, int p2, int p3);

void va_overload(int p1, int p2, ...)
{
if (p2 == 7)
{
va_list v;
va_start(v, p2);

int p3 = va_arg(v, int);
va_end(v);
va_overload3(p1, p2, p3);

return;
}

va_overload2(p1, p2);
}

Dump of assembler code for function va_overload:
   0x00400520 <+0>: sub$0x58,%rsp
   0x00400524 <+4>: cmp$0x7,%esi
   0x00400527 <+7>: mov%rdx,0x30(%rsp)
   0x0040052c <+12>:je 0x400540 
   0x0040052e <+14>:callq  0x4004f0 
   0x00400533 <+19>:add$0x58,%rsp
   0x00400537 <+23>:retq   
   0x00400538 <+24>:nopl   0x0(%rax,%rax,1)
   0x00400540 <+32>:lea0x60(%rsp),%rax
   0x00400545 <+37>:mov0x30(%rsp),%edx
   0x00400549 <+41>:movl   $0x18,(%rsp)
   0x00400550 <+48>:mov%rax,0x8(%rsp)
   0x00400555 <+53>:lea0x20(%rsp),%rax
   0x0040055a <+58>:mov%rax,0x10(%rsp)
   0x0040055f <+63>:callq  0x400500 
   0x00400564 <+68>:add$0x58,%rsp
   0x00400568 <+72>:retq

This could be replaced with the much more compact:
cmp $0x7, %esi
je  1f
jmp va_overload2
1:  jmp va_overload3
since the third parameter is passed in a register, and will still be there
after the comparison.  (Actually, if it were passed on the stack it still
wouldn't matter, because we can tail-call here.)


-- 
   Summary: va_list usage missed optimization.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug ada/38394] [4.3/4.4 regression] clashing assembler symbols

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2010-05-24 21:43 
---
Subject: Bug 38394

Author: ebotcazou
Date: Mon May 24 21:43:31 2010
New Revision: 159798

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159798
Log:
PR ada/38394
* gnat.dg/array13.ad[sb]: New test.

Added:
trunk/gcc/testsuite/gnat.dg/array13.adb
trunk/gcc/testsuite/gnat.dg/array13.ads
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug ada/38394] [4.3/4.4 regression] clashing assembler symbols

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2010-05-24 21:46 
---
Subject: Bug 38394

Author: ebotcazou
Date: Mon May 24 21:46:05 2010
New Revision: 159799

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159799
Log:
PR ada/38394
* gnat.dg/array13.ad[sb]: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gnat.dg/array13.adb
  - copied unchanged from r159798, trunk/gcc/testsuite/gnat.dg/array13.adb
branches/gcc-4_5-branch/gcc/testsuite/gnat.dg/array13.ads
  - copied unchanged from r159798, trunk/gcc/testsuite/gnat.dg/array13.ads
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/43838] Incorrect output from abi::__cxa_demangle

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-05-24 21:47 
---
Can you please provide a shorter, self-contained (no includes), testcase?
Thanks in advance. CC-ing Ian...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||iant at google dot com
 Status|UNCONFIRMED |WAITING


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

[Bug ada/38394] [4.3/4.4 regression] clashing assembler symbols

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2010-05-24 21:49 
---
Too delicate to fix on the older branches.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|NEW |RESOLVED
   Keywords|link-failure|wrong-code
  Known to fail|4.3.2 4.4.0 |4.3.2 4.4.0 4.4.4
  Known to work|4.2.4   |4.2.4 4.5.0
 Resolution||FIXED
   Target Milestone|4.3.6   |4.5.0


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

[Bug middle-end/44100] [4.6 regression] ICE compiling g++.dg/init/struct2.C on Tru64 UNIX V5.1B

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2010-05-24 22:03 
---
Subject: Bug 44100

Author: ebotcazou
Date: Mon May 24 22:03:09 2010
New Revision: 159800

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159800
Log:
PR middle-end/44100
* typeck.c (cp_build_unary_op): Fold offsetof-like computations.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/array-size2.C


-- 


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

[Bug middle-end/44100] [4.6 regression] ICE compiling g++.dg/init/struct2.C on Tru64 UNIX V5.1B

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2010-05-24 22:05 
---
Should work again.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/44263] New: missing diagnostic on questionable array sizes with -pedantic

[ebotcazou at gcc dot gnu dot org]

The C++ compiler now accepts the following constructs (parse/array-size2.C):

struct S
{
  char a[4];
  int b;
};

extern void bar (char *, char *);

void
foo (void)
{
  char g[(char *) &((struct S *) 0)->b - (char *) 0];
  char h[(__SIZE_TYPE__) &((struct S *) 8)->b];
  bar (g, h);
}

like the C compiler.  But it should warn on them in pedantic mode.


-- 
   Summary: missing diagnostic on questionable array sizes with -
pedantic
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org


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

[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2010-05-24 22:24 ---
The stage 3 comparison failure on ARM is as follows:
...
Bootstrap comparison failure!
libiberty/pic/cp-demangle.o differs

Comparing the disassembly listings of prev-libiberty/pic/cp-demangle.o and
libiberty/pic/cp-demangle.o yields:

@@ -1,5 +1,5 @@

-prev-libiberty/pic/cp-demangle.o: file format elf32-littlearm
+libiberty/pic/cp-demangle.o: file format elf32-littlearm


 Disassembly of section .text:
@@ -4751,12 +4751,12 @@
 4954:  e58d0004str r0, [sp, #4]
 4958:  eae7b   48fc 
 495c:  e3a01014mov r1, #20 ; 0x14
-4960:  e0010193mul r1, r3, r1
-4964:  e59f38e8ldr r3, [pc, #2280] ; 5254

-4968:  e2411e79sub r1, r1, #1936   ; 0x790
-496c:  e2411004sub r1, r1, #4  ; 0x4
-4970:  e7923003ldr r3, [r2, r3]
-4974:  e0913003addsr3, r1, r3
+4960:  e0030391mul r3, r1, r3
+4964:  e59f18e8ldr r1, [pc, #2280] ; 5254

+4968:  e2433e79sub r3, r3, #1936   ; 0x790
+496c:  e2433004sub r3, r3, #4  ; 0x4
+4970:  e7922001ldr r2, [r2, r1]
+4974:  e0923003addsr3, r2, r3
 4978:  0a000215beq 51d4 
 497c:  e5942014ldr r2, [r4, #20]
 4980:  e5941018ldr r1, [r4, #24]

So it's not just two swapped source operands in an arithmetic instruction as on
sparc, but also different (still valid) register assignment.


-- 


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

[Bug lto/44264] New: [4.5 regression] ICE with virtual functions

[reichelt at gcc dot gnu dot org]

The following valid code snippet triggers an ICE on the 4.5 branch
when compiled and linked with "-flto -g":

=
namespace N
{
  struct A {};
}

struct B
{
  virtual void foo(N::A) {}
};

int main()
{
  B b;
  return 0;
}
=

lto1: internal compiler error: in gimple_register_type, at gimple.c:3820
Please submit a full bug report, [etc.]

GCC 4.5.0 and trunk are not affected.


-- 
   Summary: [4.5 regression] ICE with virtual functions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored, lto
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug lto/44264] [4.5 regression] ICE with virtual functions

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.1
Version|4.6.0   |4.5.1


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

[Bug lto/44264] [4.5 regression] ICE with virtual functions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-24 22:41 ---
This sounds like the same as PR 44256 which was just fixed today.


-- 


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

[Bug tree-optimization/43423] gcc should vectorize this loop through if-conversion

[spop at gcc dot gnu dot org]

--- Comment #8 from spop at gcc dot gnu dot org  2010-05-24 22:44 ---
-fgraphite-identity does iteration splitting for this case.


-- 


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

[Bug tree-optimization/43423] gcc should vectorize this loop through if-conversion

[changpeng dot fang at amd dot com]

--- Comment #9 from changpeng dot fang at amd dot com  2010-05-24 22:47 
---
(In reply to comment #8)
> -fgraphite-identity does iteration splitting for this case.

Do you know why it could not be vectorized after iteration 
range splitting?


-- 


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

[Bug tree-optimization/43423] gcc should vectorize this loop through if-conversion

[spop at gcc dot gnu dot org]

--- Comment #10 from spop at gcc dot gnu dot org  2010-05-24 23:02 ---
note: not vectorized: number of iterations cannot be computed.

Graphite has a problem with the generation of induction variables types
that makes the code harder to analyze after Graphite.  I will try to get this
fixed to make this loop vectorized with the iteration range splitting that
Graphite does by default. 

Sebastian


-- 


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

[Bug middle-end/44230] Support multiple EH personalities without .cfi_personality

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-24 23:37 ---
To fix PR 23616 fully this bug needs to be fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||23616
  nThis||


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

[Bug target/43729] Mach-O LTO support needed for darwin

[mrs at gcc dot gnu dot org]

--- Comment #49 from mrs at gcc dot gnu dot org  2010-05-25 00:29 ---
r159527 has yet more lto work in it.


-- 


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

[Bug objc++/43689] [4.6 Regression] const-str-5/6 fails

[mrs at gcc dot gnu dot org]

--- Comment #2 from mrs at gcc dot gnu dot org  2010-05-25 01:00 ---
Subject: Bug 43689

Author: mrs
Date: Tue May 25 01:00:16 2010
New Revision: 159805

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159805
Log:
2010-05-24  Iain Sandoe  

PR ObjC++/43689
* obj-c++.dg/const-str-5.mm: Name pointer equivalence union.
* obj-c++.dg/const-str-6.mm: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/const-str-5.mm
trunk/gcc/testsuite/obj-c++.dg/const-str-6.mm


-- 


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

[Bug objc++/43689] [4.6 Regression] const-str-5/6 fails

[mrs at gcc dot gnu dot org]

--- Comment #3 from mrs at gcc dot gnu dot org  2010-05-25 01:02 ---
Fixed now.


-- 

mrs at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/44265] New: Link error with reference to parameter array in specification expression

[ian_harvey at bigpond dot com]

The following program compiles successfully, but results in an undefined
reference to `___MOD_names' during linking.  It compiles and links successfully
with g95 0.92! (May 31, 2009)and ifort 11.1.065.

Using gfortran built from svn trunk revision 159797.  Command line was simply
"gfortran filename.f90".  Some experimentation shows that the problem is
related to the use of an module procedure scoped array parameter in the
specification expression for the function result.  The type of the parameter
array doesn't seem to matter.

MODULE Fruits
  IMPLICIT NONE
  PRIVATE
  PUBLIC :: Get
CONTAINS
  FUNCTION Get(i) RESULT(s)
CHARACTER(*), PARAMETER :: names(3) = [  &
'Apple  ',  &
'Orange ',  &
'Mango  ' ];  
INTEGER, INTENT(IN) :: i
CHARACTER(LEN_TRIM(names(i))) :: s
!
s = names(i)
  END FUNCTION Get
END MODULE Fruits

PROGRAM WheresThatbLinkingConstantGone
  USE Fruits  
  IMPLICIT NONE
  !
  WRITE (*, "('Eat the tasty ',A)") Get(1)
END PROGRAM WheresThatbLinkingConstantGone


-- 
   Summary: Link error with reference to parameter array in
specification expression
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian_harvey at bigpond dot com
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


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

[Bug target/44227] Invalid instruction generation in Thumb2 for tst instruction.

[carrot at google dot com]

--- Comment #2 from carrot at google dot com  2010-05-25 02:28 ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00860.html.

Ramana, could you help to verify and close it?

thanks
Carrot


-- 


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

[Bug target/44266] New: stack frame lacks parameter save area

[amodra at gmail dot com]

A function that makes no other calls besides calls to __tls_get_addr does not
allocate a stack frame with a parameter save area.  According to the PowerPC64
ABI, any function that makes calls must allocate at least a 112 byte stack
frame.  This testcase, extracted from libstdc++

/* -m64 -fPIC -O2 */
int *
get_global (void)
{
  static __thread int global;
  return &global;
}

results in

mflr 0
std 0,16(1)
stdu 1,-48(1)
addi 3,2,.lanch...@got@tlsld
bl __tls_get_addr
nop
addi 1,1,48
addis 3,3,.lanch...@dtprel@ha
addi 3,3,.lanch...@dtprel@l
ld 0,16(1)
mtlr 0
blr

Note the 48 byte stack frame.


-- 
   Summary: stack frame lacks parameter save area
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: amodra at gmail dot com
ReportedBy: amodra at gmail dot com
GCC target triplet: powerpc64-linux


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

[Bug target/44266] stack frame lacks parameter save area

[amodra at gmail dot com]

-- 

amodra at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-25 04:19:20
   date||


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

[Bug c++/44267] New: SFINAE does not handle down static_cast over virtual inheritance

[cjoldfield at gmail dot com]

g++ fails to overlook template instantiation errors involving down static_casts
over virtual inheritance boundaries. Example:

struct B {};
struct D : B {};
struct VD : virtual B {};

template  T create();

typedef char one[1];
typedef char two[2];

template 
one& f(char (*)[sizeof(static_cast(create()))]);

template 
two& f(...);

int main()
{
   f(0);
   f(0);
   f(0);
   return 0;
}

gives error: cannot convert from base ‘B’ to derived type ‘VD’ via virtual base
‘B’

Expected behavior is for template instantiation to fail for the first template
f function and selection of the second template f function.  

Same issue for gcc 4.3.4.  

May be related to report 41468.


-- 
   Summary: SFINAE does not handle down static_cast over virtual
inheritance
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cjoldfield at gmail dot com


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

[Bug c++/18249] C++ parser i18n problems

[pzhao at gcc dot gnu dot org]

--- Comment #1 from pzhao at gcc dot gnu dot org  2010-05-25 06:26 ---
Subject: Bug 18249

Author: pzhao
Date: Tue May 25 06:26:07 2010
New Revision: 159808

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159808
Log:
2010-05-25  Shujing Zhao  

PR c++/18249
* parser.c: Remove inclusion of dyn-string.h.
(non_integral_constant): New enum.
(name_lookup_error): New enum.
(required_token): New enum.
(cp_parser_required_error): New function.
(cp_parser_require): Change the type of variable token_desc to
required_token and use cp_parser_required_error.
(cp_parser_require_keyword): Likewise.
(cp_parser_error): Use gmsgid as parameter.
(cp_parser_name_lookup_error): Change the type of variable desired to
name_lookup_error and put the diagnostic in the full sentences. Change
caller.
(cp_parser_non_integral_constant_expression): Change the type of the
variable thing to non_integral_constant and put the diagnostics in
full sentences. Change caller.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c


-- 


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

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[wilson at gcc dot gnu dot org]

--- Comment #5 from wilson at gcc dot gnu dot org  2010-05-25 06:30 ---
Richard Guenther suggested using DOT_PROD_EXPR.  I ran into several problems
with that.

DOT_PROD_EXPR expands to the sdot_prodM pattern.  The mips port is using
maddMN.  We essentially have two named patterns that are doing the exact same
thing, except that one is only used with vector types and one is only used with
integer types.  The name DOT_PROD_EXPR makes sense for the vector type case,
but not so much for the integer type case.

sdot_prodM gets installed into the optabs table with mode M.  maddMN gets
installed into the optabs table with mode N, where N is twice the size of mode
M.  This complicates lookup, since we need to use different modes for the
different operators.  All widening integer operations use mode N here, so it
seems wrong to change one.

sdot_prodM is available in two flavors, signed/unsigned.  maddMN is available
in 8 flavors, signed/unsigned saturating/non-saturating multiply add/subtract. 
The subtract part is the hard one, since I can't see any way to get a subtract
from a dot product operator.  Dot product very strongly implies that you are
doing addition, and I know of no equivalent that uses subtraction.

dot_prodM patterns are used in 3 md files (i386, ia64, rs6000).  maddMN
patterns are used in 1 md file (mips).

Rather than mess with this, I ended up just adding some new tree operators,
WIDEN_MULT_PLUS_EXPR and WIDEN_MULT_MINUS_EXPR.


-- 


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

[Bug target/43902] suboptimal MIPS widening multiply accumulate

[wilson at gcc dot gnu dot org]

--- Comment #6 from wilson at gcc dot gnu dot org  2010-05-25 06:35 ---
Created an attachment (id=20739)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20739&action=view)
second patch attempt, modifying widen_mult tree pass

This removes about 100 lines from expr.c, and adds about 90 lines to
tree-ssa-math, plus unfortunately infrastructure for the new tree codes
WIDEN_MULT_{PLUS,MINUS}_EXPR which is about 70 lines.  It works for simple
testcases.  Needs a more thorough test.


-- 


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

[Bug c++/18249] C++ parser i18n problems

[pzhao at gcc dot gnu dot org]

--- Comment #2 from pzhao at gcc dot gnu dot org  2010-05-25 06:57 ---
Fixed for 4.6.0.


-- 


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

[Bug c++/18249] C++ parser i18n problems

[pzhao at gcc dot gnu dot org]

--- Comment #3 from pzhao at gcc dot gnu dot org  2010-05-25 06:57 ---
Fixed.


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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