[Bug debug/43972] [4.5/4.6 Regression] ICE in loc_cmp

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-05-10 07:55 ---
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=43972

[Bug bootstrap/43994] [4.6 Regression] Revision 159063 failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 07:58:48
   date||


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

[Bug bootstrap/43994] [4.6 Regression] Revision 159063 failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-05-10 07:59 ---
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=43994

[Bug middle-end/43901] [4.6 Regression] FAIL: gcc.c-torture/compile/pr42196-2.c

[irar at il dot ibm dot com]

--- Comment #16 from irar at il dot ibm dot com  2010-05-10 08:17 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/39280] Optimizing integer power

[rguenther at suse dot de]

--- Comment #6 from rguenther at suse dot de  2010-05-10 08:41 ---
Subject: Re:  Optimizing integer power

On Sun, 9 May 2010, dfranke at gcc dot gnu dot org wrote:

> --- Comment #4 from dfranke at gcc dot gnu dot org  2010-05-09 21:08 
> ---
> Situation still the same with gcc version 4.6.0 20100509 (experimental) (GCC).
> 
> (In reply to comment #1)
> > ... this asks for a POW_EXPR middle-end tree I guess.  Or you can use
> > builtins.c:expand_powi* do generate an expanded power series.
> 
> Would that be enough of a gain to be worth the effort?

If the Fortran standard allows integer powers to be expanded as
power series by default then I would say yes (at least for
non-constant power, for constant power one needs to compare
generated code - the frontend does the power series expansion
manually in this case, no?).

Richard.


-- 


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

[Bug tree-optimization/44050] Wrong code is produced with -fipa-pta -fno-tree-pta

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-05-10 08:55 ---
Subject: Bug 44050

Author: rguenth
Date: Mon May 10 08:55:32 2010
New Revision: 159214

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

PR tree-optimization/44050
* tree-inline.c (tree_function_versioning): Clone the ipa-pta
flag.

* gcc.dg/torture/pr44050.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr44050.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c


-- 


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

[Bug tree-optimization/44050] Wrong code is produced with -fipa-pta -fno-tree-pta

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-05-10 08:56 ---
Fixed.


-- 

rguenth 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=44050

[Bug middle-end/44053] "benchmark" function attribute.

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-05-10 09:13 ---
4) is already fine with noclone,noinline

for 3) you can add artificial side-effects by an empty asm("");


-- 


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

[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2010-05-10 10:05 ---
(In reply to comment #2)
> ... should give a runtime error, since fun(0) evaluates to NULL.
> 
> F08 section 16.5.1.6 demands that, if the selector is a pointer, it should be
> associated.
> In the same way, having an allocatable selector which is not allocated, should
> also give a runtime error.

"If the selector has the POINTER attribute, it shall be associated"
"If the selector is allocatable, it shall be allocated"

Note: Those are not constraints, which the compiler has to diagnose but
constraints to the programmer. The compiler might diagnose those, but I think
it should not do so by default. Similarly to
  ptr = 5
where gfortran also does not do any checking. (Some checks are done for
-fcheck=pointer, though not for this one.) You can add a check using -fcheck=*
but doing a general check I do not like for performance / code-size reasons.


-- 


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

[Bug fortran/43665] Optimization of libgfortran calls: function annotations for noclobber/noescape arguments

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-05-10 10:10 ---
I/O: Currently both READ an WRITE map to the same function; this should be
changed such that for WRITE the arguments are marked as EAF_NOCLOBBER. This can
be done using aliases, cf. http://gcc.gnu.org/ml/fortran/2010-05/msg00048.html

For the committal of the middle-end / front end, see
- http://gcc.gnu.org/ml/fortran/2010-05/msg00092.html (committal)
- http://gcc.gnu.org/ml/fortran/2010-05/msg00032.html (patch)


-- 


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

[Bug debug/44023] [4.6 Regression] -fcompare-debug failure (length) for alphaev67 target (bootstrap failure)

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-05-10 10:13 ---
Created an attachment (id=20617)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20617&action=view)
gcc46-pr44023.patch

The bug is that if a debug insn references more than one dead pseudo, only the
first one is recorded using dead_debug_add.  That means the other pseudos
stay alive beyond REG_DEAD notes and affect e.g. RA decisions.

Attached patch fixes this by calling dead_debug_add on all the uses instead of
just one.  This alone crashes badly, because dead_debug_insert_before which
replaces one of the uses in a debug insn calls df_insn_rescan on it, which
invalidates all the other uses.  So we need to queue rescanning it until
dead_debug_finish (or, at least until all dead debug records referencing the
debug_insn are gone).

I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, Uros, can you
please do the same on alpha*-*?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/44054] New: Handle -Werror, -Werror=, -fdiagnostics-show-option

[burnus at gcc dot gnu dot org]

The middle end now supports besides -Werror also -Werror=list, where
-Werror= implies -W. Additionally, the middle end also annotates via
-fdiagnostics-show-option (enabled by default) the messages with the
warning-flag name in parentheses:

-Wuninitialized  (or, e.g.: -Wall)
  foo.c:4:2: warning: 'j' is used uninitialized in this function
[-Wuninitialized]
-Wuninitialized -fno-diagnostics-show-option:
  foo.c:4:2: warning: 'j' is used uninitialized in this function
-Werror=uninitialized (or, e.g.: -Werror -Wall)
  foo.c:4:2: error: 'j' is used uninitialized in this function
[-Werror=uninitialized]


Expected:

a) -Werror  caues gfortran to print "Error" rather than "Warning"; currently it
only changes the exit status code (and the total error count)

b) -f(no-)diagnostics-show-option is supported by printing the flag in
parenthesis after the warning

c) -Werror= is supported.


-- 
   Summary: Handle -Werror, -Werror=, -fdiagnostics-show-option
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-05-10 10:30 ---
-Werror= was added 2006 (
http://gcc.gnu.org/viewcvs?view=revision&revision=109907 ) and the
-fdiagnostics-show-option already exists since 2005
(http://gcc.gnu.org/viewcvs?view=revision&revision=99169 ) - though it has only
be enabled very recently, cf.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00910.html


-- 


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

[Bug fortran/44055] New: Warn (-Wconversion*) when converting single to double precision

[burnus at gcc dot gnu dot org]

With the patch http://gcc.gnu.org/ml/fortran/2010-05/msg00067.html (for PR
27866, PR 35003, PR 42809) the number of conversion warnings has drastically
been cut down by drastically cutting down the number of unintended warnings.
However, it no longer warns for

  real(8) :: sqrt2
  sqrt2 = sqrt(2.0)

where one has the precision loss due to forgetting to use "2.0_8" / "2.0d0"
instead of "2.0"; cf. PR 27866.

The idea is to add another -W* flag which finds those problems. Finding the
corresponding -W* flag will be made easier using PR 44054.

I think both the -Wconversion and the new -Wconversion-* warning should be
enabled with -Wall.


-- 
   Summary: Warn (-Wconversion*) when converting single to double
precision
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
 BugsThisDependsOn: 44054


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

[Bug fortran/40766] this fortran program is too slow

[maxim at codesourcery dot com]

--- Comment #20 from mkuvyrkov at gcc dot gnu dot org  2010-05-10 10:46 
---
Subject: Re:  this fortran program is too slow

On 5/7/10 1:38 AM, steven at gcc dot gnu dot org wrote:
> --- Comment #19 from steven at gcc dot gnu dot org  2010-05-06 21:38 
> ---
> One possibility is to see if the glibc patches for this issue can be merged
> into eglibc... Maxim what do you think?

I'll look into this when I have a minute.

I'm hesitant to merging patches to EGLIBC that were not submitted to 
either GLIBC or EGLIBC mailing lists.  There are copyright assignment 
issues with extracting patches from (open)SUSE's GLIBC and committing 
them in to EGLIBC.  Copyright assignment is not an absolutely blocking 
issue, but it is one of the concerns.

The plan of action is to find out who the author of the patch is and ask 
him or her to submit the patch to EGLIBC.


-- 


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

[Bug middle-end/44053] "benchmark" function attribute.

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2010-05-10 11:00 ---
In other words: not an issue.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug c/44056] New: plugin compile error: rtl.def uses "const" keyword because of "CONST" defined to "const" in include/ansidecl.h

[crquan at gmail dot com]

Tried native compile gcc-4.50 on both x86_64-linux and i686-linux, and install
into separate directory, it can compile small plugin demo, and demo plugin also
worked well;

but while writing a useful gcc plugin with FOR_EACH_LOOP from cfgloop.h, it
exited with error:

gcc -I.
-I/opt/gcc-4.5.0/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.5.0/plugin/include
-fPIC -c -o sensor_code_generators/univariate_polynomial.o
sensor_code_generators/univariate_polynomial.c
In file included from
/opt/gcc-4.5.0/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.5.0/plugin/include/rtl.h:48:0,
 from
/opt/gcc-4.5.0/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.5.0/plugin/include/cfgloop.h:26,
 from sensor_code_generators/univariate_polynomial.c:15:
/opt/gcc-4.5.0/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.5.0/plugin/include/rtl.def:336:1:
error: expected identifier before 'const'
In file included from
/opt/gcc-4.5.0/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.5.0/plugin/include/cfgloop.h:26:0,
 from sensor_code_generators/univariate_polynomial.c:15:
/opt/gcc-4.5.0/usr/bin/../lib/gcc/x86_64-pc-linux-gnu/4.5.0/plugin/include/rtl.h:98:39:
error: 'LAST_AND_UNUSED_RTX_CODE' undeclared here (not in a function)
sensor_code_generators/univariate_polynomial.c:92:1: warning: useless storage
class specifier in empty declaration
make: *** [sensor_code_generators/univariate_polynomial.o] Error 1

The very first error is "expected identifier before 'const'", due to "const"
keyword used as enumeration, in rtl.def,

Further speaking, CONST is defined to const in include/ansidecl.h, only when
without IN_GCC defined,

But if I use -DIN_GCC to compile my own plugin, it produced other more random
errors,

So I think the problem is because rtl.def ansidecl.h conflicts,

Searched one mail archive on this Feb 2010 is related, but the author didn't
tell how to "reorder",

http://www.mail-archive.com/g...@gcc.gnu.org/msg49585.html


BTW: There may be other gcc-4.5.0 new plugin system bugs, I personally suggest
a new bugzilla component "gcc-plugin" for this category of bugs;


-- 
   Summary: plugin compile error: rtl.def uses "const" keyword
because of "CONST" defined to "const" in
include/ansidecl.h
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: crquan at gmail dot com
  GCC host triplet: native x86_64-linux and i686-linux


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

[Bug c/44057] New: building gcc doesn't find Sun ar

[jay dot krell at cornell dot edu]

bin/bash: ar: command not found
gmake[2]: *** [libiberty.a] Error 127
gmake[2]: Leaving directory `/home/jkrell/obj/gcc.x86.sol9/libiberty'
gmake[1]: *** [all-libiberty] Error 2
gmake[1]: Leaving directory `/home/jkrell/obj/gcc.x86.sol9'
gmake: *** [all] Error 2


This is a common occurence for me.
It isn't specific to Solaris 2.9, it also occurs on 2.10.
I don't think it is x86 specific but I don't remember.

Might be nice to add /usr/ccs/bin to path or somesuch.
  Yeah yeah, I can do it myself.

This is with 4.5.0.
Doing a native build.

  $ /home/jkrell/src/gcc-4.5.0/configure -without-gnu-ld
-with-ld=/usr/ccs/bin/ld -without-gnu-as -with-as=/usr/ccs/bin/as -disable-nls
-verbose -disable-bootstrap -prefix=/home/jkrell/i386

Thanks,
 - Jay


-- 
   Summary: building gcc doesn't find Sun ar
   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 build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


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

[Bug fortran/19168] Mismatched KINDs in SELECT CASE constucts is not handled correctly

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2010-05-10 11:51 ---
James Van Buskirk post:
 
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7681f2c8f86c4687/


-- 


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

[Bug c/44056] plugin compile error: rtl.def uses "const" keyword because of "CONST" defined to "const" in include/ansidecl.h

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2010-05-10 12:51 ---
+1 for the idea of a new "plugin" category.


-- 


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

[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2010-05-10 12:54 ---
Subject: Bug 44044

Author: janus
Date: Mon May 10 12:54:25 2010
New Revision: 159217

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159217
Log:
2010-05-10  Janus Weil  

PR fortran/44044
* match.c (gfc_match_select_type): Move error message to
resolve_select_type.
* resolve.c (resolve_select_type): Error message moved here from
gfc_match_select_type. Correctly set type of temporary.


2010-05-10  Janus Weil  

PR fortran/44044
* gfortran.dg/class_7.f03: Modified.
* gfortran.dg/select_type_1.f03: Modified.
* gfortran.dg/select_type_12.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/select_type_12.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_7.f03
trunk/gcc/testsuite/gfortran.dg/select_type_1.f03


-- 


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

[Bug c/44048] dbxout.c:1870: error: NULLPTR_TYPE undeclared

[michael dot a dot richmond at nasa dot gov]

--- Comment #1 from michael dot a dot richmond at nasa dot gov  2010-05-10 
12:58 ---
In http://gfortran.org/download/ there is a binary built from this snapshot.
Was the source code patched?


-- 


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

[Bug c++/44017] [4.6 regression] ICE with template hierarchy

[baldrick at gcc dot gnu dot org]

--- Comment #1 from baldrick at gcc dot gnu dot org  2010-05-10 13:17 
---
This bug fires when trying to build LLVM using trunk.


-- 


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

[Bug ada/44058] New: The No_Tasking restriction does not imply No_Task_Hierarchy, but should

[baldrick at gcc dot gnu dot org]

Build_Class_Wide_Master in exp_ch3.adb starts with this check:

  --  Nothing to do if there is no task hierarchy
  if Restriction_Active (No_Task_Hierarchy) then
 return;
  end if;

This early return should obviously also occur if tasking is not allowed, for
example if the restriction No_Tasking is in force, but it doesn't.  This
can cause the tasking runtime to be pulled in for programs using tagged types
in funky ways even in the presence of
  pragma Restrictions (No_Tasking);


-- 
   Summary: The No_Tasking restriction does not imply
No_Task_Hierarchy, but should
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: baldrick at gcc dot gnu dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug debug/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-05-10 13:26 ---
Created an attachment (id=20618)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20618&action=view)
gcc46-pr44028.patch

Untested fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/44059] New: Static initializers executed more than once when using unique global symbols

[ivan dot stankovic at avl dot com]

With g++ 4.5.0 static initializers can be executed more than once.
Here's how. Let a.cc contain the following code:

#include 

struct A {
  A() {
static int x = printf("x initialized at @%p\n", &x);
  }
};

extern "C" void inita();

void inita()
{
  A x;
  A y;
}

And let b.cc be the copy of a.cc where 'inita' has been renamed
to 'initb'. Then make a shared library a.so from a.cc and b.so from
b.cc. Finally, make a program that dynamically loads a.so and b.so
and calls inita and initb functions.

Since 'x' ends up as a unique global symbol, there will be only one
object in the process, but the initialization code will be run twice
(the address printed will be the same).


-- 
   Summary: Static initializers executed more than once when using
unique global symbols
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivan dot stankovic at avl dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[ivan dot stankovic at avl dot com]

--- Comment #1 from ivan dot stankovic at avl dot com  2010-05-10 13:40 
---
Created an attachment (id=20619)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20619&action=view)
The test case

Just unpack and run 'make; make run'. The output
should be something like:

x initialized at @0x40021a28
x initialized at @0x40021a28

(note that the addresses are identical).


-- 


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

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-05-10 13:54 ---
It works for me.  You need to build shared libraries with -fPIC.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-05-10 13:57 ---
Or rather as you use dlopen you need to use RTLD_GLOBAL.


-- 


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

[Bug debug/44023] [4.6 Regression] -fcompare-debug failure (length) for alphaev67 target (bootstrap failure)

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2010-05-10 13:58 ---
(In reply to comment #9)

> I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, Uros, can you
> please do the same on alpha*-*?

The patch bootstraps OK on alphaev68-pc-linux-gnu. Regression test just
started, but I don't expect any problems here.

I'd say that the patch is OK.


-- 


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

[Bug rtl-optimization/44012] [4.5/4.6 Regression] ICE: SIGSEGV in ira_merge_allocno_live_ranges

[hjl at gcc dot gnu dot org]

--- Comment #13 from hjl at gcc dot gnu dot org  2010-05-10 14:02 ---
Subject: Bug 44012

Author: hjl
Date: Mon May 10 14:02:43 2010
New Revision: 159223

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159223
Log:
Nullify regno_allocno_map of the removed allocno.

gcc/

2010-05-10  H.J. Lu
Vladimir Makarov

PR rtl-optimization/44012
* ira-build.c (remove_unnecessary_allocnos): Nullify
regno_allocno_map of the removed allocno.

gcc/testsuite/

2010-05-10  H.J. Lu  

PR rtl-optimization/44012
* gcc.dg/pr44012.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr44012.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-build.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'

[dougmencken at gmail dot com]

--- Comment #19 from dougmencken at gmail dot com  2010-05-10 14:03 ---
It works on powerpc-uclibc host, but if bootstrapped the following way:

Configured with: ./configure --prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc
--host=powerpc-gnu-linux-uclibc --target=powerpc-gnu-linux-uclibc
--with-system-zlib --enable-languages=c,c++,fortran --disable-nls
--disable-werror --disable-multilib --disable-libssp --disable-shared
--enable-threads=posix --disable-__cxa_atexit
Thread model: posix
gcc version 4.5.0 (GCC)

I just changed --enable-shared to --disable-shared and got working g++.


-- 


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

[Bug rtl-optimization/44012] [4.5/4.6 Regression] ICE: SIGSEGV in ira_merge_allocno_live_ranges

[hjl at gcc dot gnu dot org]

--- Comment #14 from hjl at gcc dot gnu dot org  2010-05-10 14:05 ---
Subject: Bug 44012

Author: hjl
Date: Mon May 10 14:05:16 2010
New Revision: 159224

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159224
Log:
Nullify regno_allocno_map of the removed allocno.

gcc/

2010-05-10  H.J. Lu  

Backport from mainline
2010-05-10  H.J. Lu
Vladimir Makarov

PR rtl-optimization/44012
* ira-build.c (remove_unnecessary_allocnos): Nullify
regno_allocno_map of the removed allocno.

gcc/testsuite/

2010-05-10  H.J. Lu  

Backport from mainline
2010-05-10  H.J. Lu  

PR rtl-optimization/44012
* gcc.dg/pr44012.c: New.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr44012.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/ira-build.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-10 14:09 ---
Re: #c2, that's just because you are using too old binutils I guess.

The bug seems to be in:
.type _ZGVZN1AC1EvE1x, @object
.type _ZZN1AC1EvE1x, @gnu_unique_object
I believe the guard needs to be @gnu_unique_object as well.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 14:09:22
   date||


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

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[ivan dot stankovic at avl dot com]

--- Comment #5 from ivan dot stankovic at avl dot com  2010-05-10 14:14 
---
Indeed, using RTLD_GLOBAL works around the problem. However, I don't think
one should just resort to using this flag with dlopen everywhere. The problem
was originally found with Python modules written in C, and while one can
change the dlopen flags used for Python imports, I'm not sure that that won't
break something else.

As Jakub has pointed out, the guard needs to be unique as well.


-- 


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

[Bug target/44060] New: miscompilation with -Os on x86

[bernhardloos at googlemail dot com]

Gcc 4.5 miscompiles the following code:

char buf[1024];
void add_input_file(int file) 
{
(*((int **)&buf))[0] = file;
}

it results in this asm:
Disassembly of section .text:

 :
   0:   c3  ret

The file argument is completly ignored.

gcc4.4 does the right thing:
Disassembly of section .text:

 :
   0:   a1 00 00 00 00  mov0x0,%eax
   5:   8b 54 24 04 mov0x4(%esp),%edx
   9:   89 10   mov%edx,(%eax)
   b:   c3  ret

The command used to produce this output was i486-openwrt-linux-gcc -c asdf.c
-fomit-frame-pointer -Os -o asdf2.o

Openwrt adds a number of patches to gcc, they can be seen here:
https://dev.openwrt.org/browser/trunk/toolchain/gcc/patches/4.5.0
None of them should interfer with the codegeneration for x86.
The problem doesn't seem to happen with the mips target.

This is the output of gcc -v:
Using built-in specs.
COLLECT_GCC=../staging_dir/toolchain-i386_gcc-4.5.0_uClibc-0.9.30.3/usr/bin/i486-openwrt-linux-gcc
COLLECT_LTO_WRAPPER=/home/asdf/openwrt/trunk/staging_dir/toolchain-i386_gcc-4.5.0_uClibc-0.9.30.3/usr/libexec/gcc/i486-openwrt-linux-uclibc/4.5.0/lto-wrapper
Target: i486-openwrt-linux-uclibc
Configured with:
/home/asdf/openwrt/trunk/build_dir/toolchain-i386_gcc-4.5.0_uClibc-0.9.30.3/gcc-4.5.0/configure
--prefix=/home/asdf/openwrt/trunk/staging_dir/toolchain-i386_gcc-4.5.0_uClibc-0.9.30.3/usr
--build=i586-redhat-linux --host=i586-redhat-linux
--target=i486-openwrt-linux-uclibc --with-gnu-ld --enable-target-optspace
--disable-libgomp --disable-libmudflap --disable-multilib --disable-nls
--with-ppl --with-cloog --with-host-libstdcxx=-lstdc++
--with-gmp=/home/asdf/openwrt/trunk/staging_dir/host
--with-mpfr=/home/asdf/openwrt/trunk/staging_dir/host --disable-decimal-float
--disable-libssp --disable-__cxa_atexit --enable-languages=c,c++
--enable-shared --enable-threads
--with-slibdir=/home/asdf/openwrt/trunk/staging_dir/toolchain-i386_gcc-4.5.0_uClibc-0.9.30.3/lib
--enable-lto --disable-tls
Thread model: posix
gcc version 4.5.0 (GCC)


-- 
   Summary: miscompilation with -Os on x86
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernhardloos at googlemail dot com
GCC target triplet: i486-openwrt-linux-uclibc


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

[Bug tree-optimization/44061] New: [4.5/4.6 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section

[rguenth at gcc dot gnu dot org]

int a[2];
int foo (int q)
{
  if (__builtin_constant_p (q))
{
  if (q == 4)
return a[4];
  else
return a[0];
}
  else
return a[q];
}


-- 
   Summary: [4.5/4.6 Regression] Warns about out-of-bounds array
access inside __builtin_constant_p guarded section
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug tree-optimization/44061] [4.5/4.6 Regression] Warns about out-of-bounds array access inside __builtin_constant_p guarded section

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-05-10 14:38 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to fail||4.5.0
  Known to work||4.3.4 4.4.3
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 14:38:05
   date||
   Target Milestone|--- |4.5.1


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

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-05-10 14:39 ---
I guess the problem is in the !DECL_ARTIFICIAL (DECL) test in
ASM_DECLARE_OBJECT_NAME macro - the guard is artificial.
Not sure why that has been added.
  /* For template static data member instantiations or  \
 inline fn local statics, use gnu_unique_object so that \
 they will be combined even under RTLD_LOCAL.  */   \
  if (USE_GNU_UNIQUE_OBJECT \
  && !DECL_ARTIFICIAL (DECL) && DECL_ONE_ONLY (DECL))   \
ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "gnu_unique_object");\
  else  \
ASM_OUTPUT_TYPE_DIRECTIVE (FILE, NAME, "object");   \


-- 


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

[Bug c++/44059] Static initializers executed more than once when using unique global symbols

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-05-10 14:39 ---
Reopening.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/44060] miscompilation with -Os on x86

[schwab at linux-m68k dot org]

--- Comment #1 from schwab at linux-m68k dot org  2010-05-10 14:43 ---
Try -Wstrict-aliasing.


-- 

schwab at linux-m68k dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/44053] "benchmark" function attribute.

[svfuerst at gmail dot com]

--- Comment #5 from svfuerst at gmail dot com  2010-05-10 14:53 ---
The problem is that the list of these workarounds tends to increase with each
release of gcc.  (i.e. noclone was added in gcc 4.5) It would be nice if there
was a single attribute to use that would work with all future versions of the
compiler, no matter how smart it gets.  For example, putting the function to
benchmark into a separate compilation unit isn't guaranteed to work
indefinitely.  If ever lto is enabled by default in the future, it will then
cause problems.

Think of it as the difference between "-O2", and the long list of command line
optimization flags that -O2 represents.  Eventually the complexity of adding
that new flag is less than the complexity of the list of things it represents.


-- 


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

[Bug target/44060] miscompilation with -Os on x86

[bernhardloos at googlemail dot com]

--- Comment #2 from bernhardloos at googlemail dot com  2010-05-10 14:57 
---
(In reply to comment #1)
> Try -Wstrict-aliasing.
> 

It does produce a warning about dreferencing a type-punned pointer.
I tried to compile the snipped with both -fstrict-aliasing and
-fno-strict-aliasing and it doesn't produce a difference in the code. Not on
the i486 gcc4.5 nor on the gcc4.4 in fedora.

Busybox uses this in some places and it did work in the past, so it would be
really nice, if this could get fixed.


-- 


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

[Bug c++/44062] New: (void)var; doesn't prevent 'set but not used' warning

[jeffrey dot donner at gmail dot com]

Doing

  (void)var;

does not 'use' the var, eg: 

  void f()
  {
 int i = 6; // or a fn call whose return value you don't care about
 (void)i;
  }

j...@shade:~$ g++ -Wall -Wextra unused.cpp
unused.cpp: In function ‘void f()’:
unused.cpp:3:8: warning: variable ‘i’ set but not used
[-Wunused-but-set-variable]

Doing this (void)var; trick is a long-standing way to quiet 'unused' warnings -
eg in g++ 4.4.3 there is no warning. 

Version used:

j...@shade:~$ g++ --version
g++ (GCC) 4.6.0 20100508 (experimental)


-- 
   Summary: (void)var; doesn't prevent 'set but not used' warning
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeffrey dot donner at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/44031] [4.4/4.5/4.6 Regression] ice in subst_reloads, at reload.c:6327

[vmakarov at redhat dot com]

--- Comment #3 from vmakarov at redhat dot com  2010-05-10 15:22 ---

> It is caused by revision 152533:
> 
> http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00182.html
> 

If it is so, the patch triggered some reload bug IMO.  The patch itself was
very safe because it resulted in creation of additional conflicts.

I hope that Jeff Law's work on new reload will fix it when it is in 4.6
finally.  Otherwise, we should work on this PR.


-- 


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

[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2010-05-10 15:30 ---
The testcase is invalid; 5.17 doesn't allow assignment to an array from an
initializer list (although I'm not sure why not).  But certainly we should give
an error rather than crash.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |4.6.0


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

[Bug c++/44017] [4.6 regression] ICE with template hierarchy

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-05-10 15:32 ---
It is caused by revision 158806:

http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00913.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug c++/44062] (void)var; doesn't prevent 'set but not used' warning

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-05-10 15:48 ---
Oops, seems something I should have covered in the testsuite.  For C it works
correctly.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot
   ||org, dodji at gcc dot gnu
   ||dot org


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

[Bug c++/44062] (void)var; doesn't prevent 'set but not used' warning

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-10 15:51 ---
Created an attachment (id=20620)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20620&action=view)
testcases

2 new testcases


-- 


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

[Bug target/43961] [ARM thumb] "branch out of range" with thumb1_output_casesi

[ramana at gcc dot gnu dot org]

--- Comment #4 from ramana at gcc dot gnu dot org  2010-05-10 16:03 ---
Confirmed - marking as a target bug .


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |target
 Ever Confirmed|0   |1
 GCC target triplet|arm-elf |arm-elf,arm-eabi
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 16:03:26
   date||


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

[Bug target/44060] miscompilation with -Os on x86

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-05-10 16:16 ---
Gcc 4.6 generates expected code.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'

[dougmencken at gmail dot com]

--- Comment #20 from dougmencken at gmail dot com  2010-05-10 16:23 ---
But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?

$ ./print-sharedlib-deps.sh /usr/bin/ld
/usr/bin/ld:
libz.so.1
libc.so.0
libgcc_s.so.1

Now I'm using libgcc_s.so.1 copied from 4.4.2 (the last working one), and tried
to build binutils with --disable-shared too, but the above list (it is from
this build) does show that this lib is still required for ld to work (i.e. for
any non-static program to work). I can't imagine how long 4.4.2's libgcc_s.so.1
will remain binary compatible with any new GCC release.


-- 


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

[Bug target/44060] miscompilation with -Os on x86

[pluto at agmk dot net]

--- Comment #4 from pluto at agmk dot net  2010-05-10 16:26 ---
(In reply to comment #3)
> Gcc 4.6 generates expected code.
> 

PR43987 dupllication?


-- 


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

[Bug tree-optimization/44063] New: [4.6 Regression]: build broken for libgcc cris-elf, ICE in cgraph_estimate_size_after_inlining, at ipa-inline

[hp at gcc dot gnu dot org]

With revision 159199 the trunk built for cris-elf.
With revision 159204 and on, including at least 159229, build was broken as
follows:

/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include-g -O2 -march=v10
-mbest-lib-options -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/tmp/hpautotest-gcc1/gcc/libgcc -I/tmp/hpautotest-gcc1/gcc/libgcc/.
-I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc
-I/tmp/hpautotest-gcc1/gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
_mul_sf.o -MT _mul_sf.o -MD -MP -MF _mul_sf.dep -DFINE_GRAINED_LIBRARIES
-DL_mul_sf -c ../../.././gcc/tmplibgcc_fp_bit.c 
../../.././gcc/tmplibgcc_fp_bit.c: In function '__mulsf3':
../../.././gcc/tmplibgcc_fp_bit.c:959:1: internal compiler error: in
cgraph_estimate_size_after_inlining, at ipa-inline.c:208

Author of suspect patch in revision range CC:ed.
Preprocessed code attached momentarily.


-- 
   Summary: [4.6 Regression]: build broken for libgcc cris-elf, ICE
in cgraph_estimate_size_after_inlining, at ipa-inline
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'

[pluto at agmk dot net]

--- Comment #21 from pluto at agmk dot net  2010-05-10 16:31 ---
(In reply to comment #20)
> But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?

configure binutils with --disable-shared --enable-static and build
with make AM_LDFLAGS="-all-static". you also need to have installed
static version of glibc.


-- 


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

[Bug tree-optimization/44063] [4.6 Regression]: build broken for libgcc cris-elf, ICE in cgraph_estimate_size_after_inlining, at ipa-inline

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2010-05-10 16:35 ---
Created an attachment (id=20621)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20621&action=view)
Preprocessed code, slightly reduced.

Compile with "./cc1 -O2 t.i", observe ICE as in the description.


-- 


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

[Bug target/44060] miscompilation with -Os on x86

[bernhardloos at googlemail dot com]

--- Comment #5 from bernhardloos at googlemail dot com  2010-05-10 16:48 
---
It is a duplicate, my problem happens in exactly the same place.
Sorry I missed the other bug.

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


-- 

bernhardloos at googlemail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/43987] [4.5 Regression] type-punning causes broken binaries unless -O0 is used

[bernhardloos at googlemail dot com]

--- Comment #21 from bernhardloos at googlemail dot com  2010-05-10 16:48 
---
*** Bug 44060 has been marked as a duplicate of this bug. ***


-- 

bernhardloos at googlemail dot com changed:

   What|Removed |Added

 CC||bernhardloos at googlemail
   ||dot com


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

[Bug c++/44062] (void)var; doesn't prevent 'set but not used' warning

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-10 16:50 ---
Created an attachment (id=20622)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20622&action=view)
gcc46-pr44062.patch

Actually, I've found 2 issues even in the C FE related to comma expressions
with
LHS or RHS without side-effects.
The C++ FE changes needed for these new testcases are missing though.


-- 


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

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2010-05-10 16:58 ---
This probably superseeds (accompanies?) PR31601.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[ubizjak at gmail dot com]

--- Comment #16 from ubizjak at gmail dot com  2010-05-10 17:01 ---
On alphaev68-pc-linux-gnu, I'm getting:

make[4]: Entering directory
`/space/uros/gcc-build/alphaev68-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Allocated 5687484 collectable objects
Allocated 306 uncollectable objects
Allocated 3749022 atomic objects
Allocated 34440 stubborn objects
Finalized 6617/6617 objects - finalization is probably ok
Total number of bytes allocated is 228541040
Final heap size is 11345920 bytes
Collector appears to work
Completed 322 collections
PASS: gctest
Leaked composite object at 0x22cdee0
(../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL)

FAIL: leaktest
Final heap size is 131072
PASS: middletest
PASS: staticrootstest
===
1 of 4 tests failed
===
make[4]: *** [check-TESTS] Error 1

Is this failure something to worry about?


-- 


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

[Bug fortran/44055] Warn (-Wconversion*) when converting single to double precision

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-05-10 17:02 ---
I think -Wconversion-extra would be a good choice.
We could enable -Wconversion with -Wall and -Wconversion-extra with -Wextra?!


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 17:02:05
   date||


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

[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real

[dfranke at gcc dot gnu dot org]

--- Comment #9 from dfranke at gcc dot gnu dot org  2010-05-10 17:11 ---
Subject: Bug 27866

Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159238
Log:
gcc/fortran/:
2010-05-10  Daniel Franke  

PR fortran/27866
PR fortran/35003
PR fortran/42809
* intrinsic.c (gfc_convert_type_warn): Be more discriminative
about conversion warnings.

gcc/testsuite/:
2010-05-08  Daniel Franke  

PR fortran/27866
PR fortran/35003
PR fortran/42809
* gfortran.dg/array_constructor_type_17.f03: Updated match string.
* gfortran.dg/warn_conversion.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_conversion.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/array_constructor_type_17.f03


-- 


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

[Bug fortran/35003] spurious warning using -Wconversion, a do loop, and 8 byte integers

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2010-05-10 17:11 ---
Subject: Bug 35003

Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159238
Log:
gcc/fortran/:
2010-05-10  Daniel Franke  

PR fortran/27866
PR fortran/35003
PR fortran/42809
* intrinsic.c (gfc_convert_type_warn): Be more discriminative
about conversion warnings.

gcc/testsuite/:
2010-05-08  Daniel Franke  

PR fortran/27866
PR fortran/35003
PR fortran/42809
* gfortran.dg/array_constructor_type_17.f03: Updated match string.
* gfortran.dg/warn_conversion.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_conversion.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/array_constructor_type_17.f03


-- 


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

[Bug fortran/42809] Too much noise with -Wconversion

[dfranke at gcc dot gnu dot org]

--- Comment #7 from dfranke at gcc dot gnu dot org  2010-05-10 17:11 ---
Subject: Bug 42809

Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159238
Log:
gcc/fortran/:
2010-05-10  Daniel Franke  

PR fortran/27866
PR fortran/35003
PR fortran/42809
* intrinsic.c (gfc_convert_type_warn): Be more discriminative
about conversion warnings.

gcc/testsuite/:
2010-05-08  Daniel Franke  

PR fortran/27866
PR fortran/35003
PR fortran/42809
* gfortran.dg/array_constructor_type_17.f03: Updated match string.
* gfortran.dg/warn_conversion.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_conversion.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/array_constructor_type_17.f03


-- 


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

[Bug libfortran/44064] New: ICE with file containing two modules and one program

[pchwood at yahoo dot com]

The following testcase segfaults in 4.6:

module module_myclass

implicit none

type :: inner
contains
procedure :: set
end type inner

type :: myclass
type(inner) :: slice
end type myclass

contains

subroutine set(this)
class(inner), intent(inout) :: this
end subroutine set

end module module_myclass

module module_mysubclass

use module_myclass, only : myclass
implicit none

type, extends(myclass) :: mysubclass
contains
procedure :: init
end type mysubclass

contains

subroutine init(this)
class(mysubclass), intent(inout) :: this
call this%slice%set() ! XXX PROBLEM HERE this%slice not resolved
end subroutine init

end module module_mysubclass

program test

use module_mysubclass, only : mysubclass
implicit none

class(mysubclass), allocatable :: obs

end program test


-- 
   Summary: ICE with file containing two modules and one program
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pchwood at yahoo dot com


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

[Bug debug/44023] [4.6 Regression] -fcompare-debug failure (length) for alphaev67 target (bootstrap failure)

[ubizjak at gmail dot com]

--- Comment #11 from ubizjak at gmail dot com  2010-05-10 17:15 ---
(In reply to comment #10)

> I'd say that the patch is OK.

Regression test results at [1], everything looks OK.

[1] http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00960.html


-- 


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

[Bug fortran/32817] MODULE functions are not inlined

[mikael at gcc dot gnu dot org]

--- Comment #8 from mikael at gcc dot gnu dot org  2010-05-10 17:16 ---
(In reply to comment #7)
> With -fwhole-file I now get the same timings either way. I call that fixed.
> 
Unless there is one other bug tracking inlining of use-associated functions,
one cannot close this yet. 
The comment #5 case is still not inlined


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2010-05-10 17:16 ---
(In reply to comment #2)
> This probably superseeds (accompanies?) PR31601.

Not really. This is about warnings - the other is about errors due to -std=.
For warnings, the purpose is to help fine-tuning the warnings - while for
errors (-std=, -f(no-)range-check) the idea is to point the user to an option,
which allows him/her to still compile the program. 

(Sometimes one is simply not aware that a certain option exists - and
especially non-Fortran programmers tend to compile legacy Fortran programs. But
even I tend to forget about. e.g., -std=legacy or -fdollar-ok.)


-- 


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

[Bug libfortran/44065] New: Undefined reference to TBP

[pchwood at yahoo dot com]

In the following testcase (tested against 4.6), a procedure bound to an
attribute of a super class is not resolved in the subclass.
The test case below doesn't go through the linker.

The error message is:

> gfortran -c -ffree-form module.f test.f
> gfortran -o test test.o module.o

module.o: In function `__module_mysubclass_MOD_init':
module.f:(.text+0x19): undefined reference to `vtab$inner.1586'
module.f:(.text+0x25): undefined reference to `vtab$inner.1586'
module.f:(.text+0x2e): undefined reference to `vtab$inner.1586'
collect2: ld a retourné 1 code d'état d'exécution

(note that combining the two following files into a single one creates a
segfault #44064)

file module.f:
module module_myclass

implicit none

type :: inner
contains
procedure :: set
end type inner

type :: myclass
type(inner) :: slice
end type myclass

contains

subroutine set(this)
class(inner), intent(inout) :: this
end subroutine set

end module module_myclass

module module_mysubclass

use module_myclass, only : myclass
implicit none

type, extends(myclass) :: mysubclass
contains
procedure :: init
end type mysubclass

contains

subroutine init(this)
class(mysubclass), intent(inout) :: this
call this%slice%set() ! XXX PROBLEM HERE this%slice not resolved
end subroutine init

end module module_mysubclass

and file test.f:

program test

use module_mysubclass, only : mysubclass
implicit none

class(mysubclass), allocatable :: obs

end program test


-- 
   Summary: Undefined reference to TBP
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pchwood at yahoo dot com


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

[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault

[dougsemler at gmail dot com]

--- Comment #10 from dougsemler at gmail dot com  2010-05-10 17:18 ---
Well, is it really invalid code with -std=c++0x?

The virutal destructor seems to be causing the issue.

With gcc 4.4.3 (after changing virtual ~base() to virtual void func()):

$ g++ gcc_bug.cc 
gcc_bug.cc: In function ‘int main()’:
gcc_bug.cc:9: warning: extended initializer lists only available with
-std=c++0x or -std=gnu++0x

$ g++ gcc_bug.cc  -std=c++0x
$


So you can see that g++ sees this as valid code.


-- 


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

[Bug libfortran/44064] ICE with file containing two modules and one program

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-05-10 17:19 ---
On x86_64-apple-darwin10 at revision 159234 (+ a few patches) I get:

[macbook] f90/bug% gfc pr44064.f90
Undefined symbols:
  "_vtab$inner.1583", referenced from:
  ___module_mysubclass_MOD_init in cc4CUNex.o
  ___module_mysubclass_MOD_init in cc4CUNex.o
  ___module_mysubclass_MOD_init in cc4CUNex.o
ld: symbol(s) not found
collect2: ld returned 1 exit status


-- 


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

[Bug libfortran/44064] ICE with file containing two modules and one program

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2010-05-10 17:21 ---
On powerpc-apple-darwin9 at revision 159191 (without gfortran patch) I get:

[karma] f90/bug% gfc pr44064.f90
/var/tmp//ccpUV3i0.s:65:non-relocatable subtraction expression,
"_vtab$inner.1183" minus "L001$pb"
/var/tmp//ccpUV3i0.s:65:symbol: "_vtab$inner.1183" can't be undefined in a
subtraction expression
/var/tmp//ccpUV3i0.s:63:non-relocatable subtraction expression,
"_vtab$inner.1183" minus "L001$pb"
/var/tmp//ccpUV3i0.s:63:symbol: "_vtab$inner.1183" can't be undefined in a
subtraction expression
/var/tmp//ccpUV3i0.s:57:non-relocatable subtraction expression,
"_vtab$inner.1183" minus "L001$pb"
/var/tmp//ccpUV3i0.s:57:symbol: "_vtab$inner.1183" can't be undefined in a
subtraction expression
/var/tmp//ccpUV3i0.s:55:non-relocatable subtraction expression,
"_vtab$inner.1183" minus "L001$pb"
/var/tmp//ccpUV3i0.s:55:symbol: "_vtab$inner.1183" can't be undefined in a
subtraction expression
/var/tmp//ccpUV3i0.s:50:non-relocatable subtraction expression,
"_vtab$inner.1183" minus "L001$pb"
/var/tmp//ccpUV3i0.s:50:symbol: "_vtab$inner.1183" can't be undefined in a
subtraction expression
/var/tmp//ccpUV3i0.s:48:non-relocatable subtraction expression,
"_vtab$inner.1183" minus "L001$pb"
/var/tmp//ccpUV3i0.s:48:symbol: "_vtab$inner.1183" can't be undefined in a
subtraction expression


-- 


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

[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'

[redi at gcc dot gnu dot org]

--- Comment #22 from redi at gcc dot gnu dot org  2010-05-10 17:28 ---
(In reply to comment #17)
> So can you please tell me how to "install libgcc" then?

"make install" should do it.  if it's not, look to see if libgcc_s.so is built,
is it in the build tree? does the one in the build tree have the right symbols
with the right versions?

does "make install" even try to install it? the output should show.

there should be lots more things you can check to see why a working libgcc_s
isn't being installed


-- 


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

[Bug libfortran/44065] Undefined reference to TBP

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-05-10 17:32 ---
On x86_64-apple-darwin10, I do not see any difference between this PR and
pr44064. On powerpc-apple-darwin9, I get the errors reported in pr44064#c2 when
compiling the module file.


-- 


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

[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault

[redi at gcc dot gnu dot org]

--- Comment #11 from redi at gcc dot gnu dot org  2010-05-10 17:32 ---
(In reply to comment #10) 
> So you can see that g++ sees this as valid code.

I think that's a bug too


-- 


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

[Bug fortran/32515] F2003: Reject COMMON block names if local symbol already exists

[mikael at gcc dot gnu dot org]

--- Comment #3 from mikael at gcc dot gnu dot org  2010-05-10 17:35 ---
If I understand correctly, an external symbol can be used for a common block
name in f2003. 
Thus, there should be no error with -std=f2003. 


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/44066] New: excessive memory usage when compiling array initializers.

[john at puckerupgames dot com]

Description:

Compiling an array with an initializer list takes memory roughly 140 times the
size of the array. For example, and array of unsigned char with 1M entries
(i.e., sizeof is 1MB), takes 140 MB to compile. An array of 5MB requires over
600MB of memory to compile. Below are some rough measurements based on the
code,

 const unsigned char arr[] = {0,0,0, /*...NUM zeros here*/ };

Array_Size  /  GCC_Memory
1M  /  149M
2M  /  289M
3M  /  510M
4M  /  566M
5M  /  623M

At the above rate, GCC could require over 4GB of memory to compile a 20MB
array. In general, GCC will exhaust system memory when compiling an array of
size (Total_System_Memory/140).

How-To-Repeat:

/* This code takes roughly (140*NUM) bytes of memory to compile.  */
const unsigned char arr[] = {0,0, /*... NUM more values here*/};

The code above compiled a "C" suffers the same problem, but GCC's memory usage
is slightly lower compared to C++, at 100 times the size of the array.

Fix:

There is a workaround, but it is undesirable. Instead of an array, use a string
literal. A string literal does not appear to have this memory usage or
scalability defect. Example:

/* BAD: */
const unsigned char arr[]={0xAB,0xCD,0xEF,...};

/* WORKAROUND: */
const unsigned char *arr=(unsigned char*)"\xAB\xCD\xEF...";


Keywords: memory-hog


-- 
   Summary: excessive memory usage when compiling array
initializers.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john at puckerupgames dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/36842] Fortran: Minimize heap allocation of temporary arrays.

[mikael at gcc dot gnu dot org]

--- Comment #2 from mikael at gcc dot gnu dot org  2010-05-10 18:25 ---
(In reply to comment #1)
> Confirmed.  Dependency analysis should see that no temporary is required here.
> 
As both Rx and Ry have the pointer attribute, I'm not so sure about it. 
Note that if one removes the pointer attribute, there is no temporary any more. 


-- 


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

[Bug debug/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-05-10 18:28 ---
Subject: Bug 44028

Author: jakub
Date: Mon May 10 18:28:03 2010
New Revision: 159240

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159240
Log:
PR debug/44028
* haifa-sched.c (schedule_insn): When clearing INSN_VAR_LOCATION_LOC,
clear also INSN_REG_USE_LIST.

* gcc.dg/pr44028.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr44028.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/43719] uninitialized const member incorrectly accepted, using an array

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2010-05-10 18:37 ---
Subject: Bug 43719

Author: jason
Date: Mon May 10 18:37:45 2010
New Revision: 159242

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159242
Log:
PR c++/43719
* decl.c (check_initializer): strip array type before checking for
uninitialized const or ref members.

Added:
trunk/gcc/testsuite/g++.dg/init/pr43719.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/anon-struct4.C


-- 


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

[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2010-05-10 18:38 ---
Subject: Bug 44045

Author: jason
Date: Mon May 10 18:37:56 2010
New Revision: 159243

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159243
Log:
PR c++/44045
* typeck.c (cp_build_modify_expr): Complain about assignment to
array from init list.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/initlist26.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist28.C


-- 


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

[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2010-05-10 18:40 ---
Fixed for 4.6.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/44017] [4.6 regression] ICE with template hierarchy

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 18:41:08
   date||


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

[Bug fortran/32817] MODULE functions are not inlined

[mikael at gcc dot gnu dot org]

--- Comment #9 from mikael at gcc dot gnu dot org  2010-05-10 18:42 ---
This depends on the double decl problem, which is : 
if a module is both defined and used in the same file, we create new symbols
when we load the module, instead of reusing/sharing them.  

(In reply to comment #8)
> one cannot close this yet. 
> 
I'll mark as waiting for pr25708


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||25708
 Status|REOPENED|SUSPENDED


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

[Bug fortran/35003] spurious warning using -Wconversion, a do loop, and 8 byte integers

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2010-05-10 19:24 ---
Fixed. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/42809] Too much noise with -Wconversion

[dfranke at gcc dot gnu dot org]

--- Comment #8 from dfranke at gcc dot gnu dot org  2010-05-10 19:26 ---
(In reply to comment #6)
> The bad pointer position is another instance of the many PRs complaining about
> this. I think this PR should be closed after a patch for -Wconversion was
> applied and a new one for the error locus should be opened.

Fixed the conversion warnings. See PR44055 for a follow up to get some of the
warnings now omitted back. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real

[dfranke at gcc dot gnu dot org]

--- Comment #10 from dfranke at gcc dot gnu dot org  2010-05-10 19:29 
---
We should now have about the same behaviour as with C.

The additional requests in comment #4 (integer division) are not handled by the
patch in #9. These are special cases and not necessarily related to
-Wconversion. Please open another PR if this should be pursued.

Closing as fixed.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

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

[rsandifo at gcc dot gnu dot org]

--- Comment #16 from rsandifo at gcc dot gnu dot org  2010-05-10 19:49 
---
Thanks Andreas.  I don't have access to m68k-elfy targets these days, so could
someone test it just to be sure?  I'll commit if everything goes OK.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 19:49:34
   date||


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

[Bug debug/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-05-10 20:05 ---
Subject: Bug 44028

Author: jakub
Date: Mon May 10 20:05:09 2010
New Revision: 159244

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159244
Log:
PR debug/44028
* haifa-sched.c (schedule_insn): When clearing INSN_VAR_LOCATION_LOC,
clear also INSN_REG_USE_LIST.

* gcc.dg/pr44028.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr44028.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/haifa-sched.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/44028] -fcompare-debug failure (length) with -O3 -fsched-pressure -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-05-10 20:15 ---
Fixed.


-- 

jakub 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=44028

[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1

[davek at gcc dot gnu dot org]

--- Comment #17 from davek at gcc dot gnu dot org  2010-05-10 20:54 ---
(In reply to comment #16)
> On alphaev68-pc-linux-gnu, I'm getting:
> FAIL: leaktest

> 1 of 4 tests failed

> Is this failure something to worry about?

The honest answer is: I can't tell you.  These are test cases that come with
the boehm-gc itself, that have previously been disabled in the gcc import, now
I re-enabled them.  You won't be suffering from any problem that you didn't
already suffer from, in particular w.r.t the use of boehm-gc in libjava, but
while it's possible this is a false positive dependent on the precise details
of the platform, it's also possible this points to a real unfixed bug.  I don't
know of any way to tell without really getting down into debugging the
internals of the GC to see why it's complaining.

But, it's only a new failure because the test didn't used to be run before at
all.  You're definitely no worse off than you used to be; just now, you know
it.


-- 


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

[Bug c++/43803] uninitialized const member wrongly accepted using a temporary

[fabien dot chene at gmail dot com]

--- Comment #3 from fabien dot chene at gmail dot com  2010-05-10 21:12 
---
This is valid code, the use of the temporary value-initializes the const
member.


-- 

fabien dot chene at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/44067] New: internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713

[raj dot khem at gmail dot com]

gcc 4.5.0 fails to build libgcc when configured as follows

/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/configure
--build=x86_64-linux --host=x86_64-linux --target=powerpc-oe-linux-gnuspe
--prefix=/scratch/oe/calamari/cross/ppce500v2
--exec_prefix=/scratch/oe/calamari/cross/ppce500v2
--bindir=/scratch/oe/calamari/cross/ppce500v2/bin
--sbindir=/scratch/oe/calamari/cross/ppce500v2/bin
--libexecdir=/scratch/oe/calamari/cross/ppce500v2/libexec
--datadir=/scratch/oe/calamari/cross/ppce500v2/share
--sysconfdir=/scratch/oe/calamari/cross/ppce500v2/etc
--sharedstatedir=/scratch/oe/calamari/cross/ppce500v2/com
--localstatedir=/scratch/oe/calamari/cross/ppce500v2/var
--libdir=/scratch/oe/calamari/cross/ppce500v2/lib
--includedir=/scratch/oe/calamari/cross/ppce500v2/include
--oldincludedir=/scratch/oe/calamari/cross/ppce500v2/include
--infodir=/scratch/oe/calamari/cross/ppce500v2/share/info
--mandir=/scratch/oe/calamari/cross/ppce500v2/share/man
--with-local-prefix=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe/usr
--with-newlib --without-headers --disable-shared --disable-threads
--disable-multilib --disable-__cxa_atexit --enable-languages=c
--program-prefix=powerpc-oe-linux-gnuspe-
--with-sysroot=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe
--with-build-sysroot=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe
--disable-libmudflap --disable-libgomp --disable-libssp
--enable-decimal-float=no --program-prefix=powerpc-oe-linux-gnuspe-


It fails in libgcc 

/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/build.x86_64-linux.powerpc-oe-linux-gnuspe/./gcc/xgcc
-B/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/build.x86_64-linux.powerpc-oe-linux-gnuspe/./gcc/
-mcpu=8548 -mspe=yes -mabi=spe -mfloat-gprs=double
-isystem/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe/usr/include
-B/scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/bin/
-B/scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/lib/ -isystem
/scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/include -isystem
/scratch/oe/calamari/cross/ppce500v2/powerpc-oe-linux-gnuspe/sys-include
--sysroot=/scratch/oe/calamari/sysroots/ppce500v2-oe-linux-gnuspe  
-isystem/scratch/oe/calamari/sysroots/x86_64-linux/usr/include -O2 -g -O2 
-isystem/scratch/oe/calamari/sysroots/x86_64-linux/usr/include -O2 -g -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I. -I../.././gcc
-I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc
-I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/.
-I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc
-I/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../include
 -DHAVE_CC_TLS  -o _powidf2.o -MT _powidf2.o -MD -MP -MF _powidf2.dep
-DL_powidf2 -c
/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc/libgcc2.c
/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc/libgcc2.c:
In function ‘__powidf2’:
/scratch/oe/calamari/work/ppce500v2-oe-linux-gnuspe/gcc-cross-initial-4.5.0-r0/gcc-4.5.0/libgcc/../gcc/libgcc2.c:1739:1:
internal compiler error: in rs6000_split_multireg_move, at
config/rs6000/rs6000.c:16713
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


If I remove -mfloat-gprs=double from the commandline then the ICE does not
happen.


-- 
   Summary: internal compiler error: in rs6000_split_multireg_move,
at config/rs6000/rs6000.c:16713
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: raj dot khem at gmail dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: powerpc-oe-linux-gnuspe


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

[Bug c++/44017] [4.6 regression] ICE with template hierarchy

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2010-05-10 21:21 ---
Subject: Bug 44017

Author: jason
Date: Mon May 10 21:20:47 2010
New Revision: 159246

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159246
Log:
PR c++/44017
* semantics.c (baselink_for_fns): Revert earlier change.

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


-- 


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

[Bug c/19513] [IMA] High memory usage when compiling multiple files at a time

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2010-05-10 21:29 ---
IMA will not be fixed. Actually, it never worked properly to begin with...

GCC 4.5 has -flto, but I don't expect it will do much better than IMA, from a
memory usage point of view. GCC 4.5 also has -fwhopr, but that is experimental.

To the reporter: sorry this took so long, with, I suppose, not a very
satisfying end. Keep an eye on GCC 4.6, it may bring you something better than
IMA.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/44064] [OOP] ICE with file containing two modules and one program

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-05-10 21:59 ---
For me, compiling the code in comment #0 in a single file seems to get stuck in
an endless loop (trunk rev. 159217 on x86_64-unknown-linux-gnu).


-- 


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

[Bug target/44057] building gcc doesn't find Sun ar

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-10 22:03 ---
If ar is not in your path, there is no GCC bug here really.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target


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

[Bug middle-end/44053] "benchmark" function attribute.

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2010-05-10 22:04 ---
Also I think it is a bad idea for having this kind of attribute.  If your
benchmark can be optimized away, that is better for newer versions of the
compiler.


-- 


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

[Bug fortran/44065] [OOP] Undefined reference to TBP

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-05-10 22:06 ---
Confirmed.

Compiling via ...

gfortran-4.6 -c module.f90
gfortran-4.6 test.f90 

... works, though.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|libfortran  |fortran
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-10 22:06:33
   date||
Summary|Undefined reference to TBP  |[OOP] Undefined reference to
   ||TBP


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