[Bug debug/41353] VTA missed-debug issues

2009-10-05 Thread aoliva at gcc dot gnu dot org


--- Comment #15 from aoliva at gcc dot gnu dot org  2009-10-06 06:09 ---
Err, I messed up my testing.  #c9 is not fixed, I was looking at cprop dumps
(as in #c10), not regmove.  Sorry.  Looking into it now.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org


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



[Bug debug/41353] VTA missed-debug issues

2009-10-05 Thread aoliva at gcc dot gnu dot org


--- Comment #14 from aoliva at gcc dot gnu dot org  2009-10-06 06:05 ---
The patch that introduces debug temps fixes the problem in #c9.
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html

As for the testcase in #c10, the behavior is correct.  If the pseudo holding a
value becomes dead at a certain point, we shouldn't reference the dead value in
subsequent debug insns because, well, it is dead.  Trying to keep it alive
would do us no good: it would likely cause codegen differences.

Now...  Maybe we could make room for finding the value in alternate locations,
adding a debug temp insn right before the death of the pseudo, and referencing
the debug temp instead of the pseudo itself.  This wouldn't help if it's the
only location known to hold the value, and that location gets actually
clobbered afterwards, say if a register gets reused.  We might end up with lots
of useless debug stmts.  However, if the value survives, or is found at an
equivalent location, we might still represent it, but should we?  If we found
the value to be dead, wouldn't it be more accurate to say so?


-- 


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



[Bug middle-end/41264] [4.5 Regression] variable-tracking unbelievably slow

2009-10-05 Thread aoliva at gcc dot gnu dot org


--- Comment #6 from aoliva at gcc dot gnu dot org  2009-10-06 04:38 ---
The patch that introduces debug temps fixes this problem:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

2009-10-05 Thread aoliva at gcc dot gnu dot org


--- Comment #17 from aoliva at gcc dot gnu dot org  2009-10-06 04:38 ---
This patch fixes the problem:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html


-- 


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



[Bug debug/41447] Wrong debug with VTA on temporaries initialized from memory variable

2009-10-05 Thread aoliva at gcc dot gnu dot org


--- Comment #2 from aoliva at gcc dot gnu dot org  2009-10-06 04:25 ---
The patch that introduces debug temps fixes this bug.
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug libfortran/35862] [F2003] Implement new rounding modes for run time

2009-10-05 Thread jvdelisle at gcc dot gnu dot org


--- Comment #16 from jvdelisle at gcc dot gnu dot org  2009-10-06 03:12 
---
Subject: Bug 35862

Author: jvdelisle
Date: Tue Oct  6 03:12:21 2009
New Revision: 152484

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152484
Log:
2009-10-05  Jerry DeLisle  

PR libgfortran/35862
* gfortran.dg/round_2.f03: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/round_2.f03
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug libfortran/35862] [F2003] Implement new rounding modes for run time

2009-10-05 Thread jvdelisle at gcc dot gnu dot org


--- Comment #15 from jvdelisle at gcc dot gnu dot org  2009-10-06 03:08 
---
Subject: Bug 35862

Author: jvdelisle
Date: Tue Oct  6 03:08:20 2009
New Revision: 152483

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152483
Log:
2009-10-05  Jerry DeLisle  

PR libgfortran/35862
* write_float.def (outout_float): Fix handling of special case where no
digits after the decimal point and values less than 1.0. Adjust index
into digits string. (WRITE_FLOAT): Remove special case code from macro.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write_float.def


-- 


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread howarth at nitro dot med dot uc dot edu


--- Comment #39 from howarth at nitro dot med dot uc dot edu  2009-10-06 
02:19 ---
Mike,
Does darwin have named sections? If so, we can drop the check on
!targetm.have_named_sections.


-- 


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread howarth at nitro dot med dot uc dot edu


--- Comment #38 from howarth at nitro dot med dot uc dot edu  2009-10-06 
02:18 ---
Created an attachment (id=18718)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18718&action=view)
patch to handle unwind label and -freorder-blocks-and-partition control in
darwin.c


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

  Attachment #18703|0   |1
is obsolete||


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread davine at poczta dot onet dot pl


--- Comment #8 from davine at poczta dot onet dot pl  2009-10-06 02:13 
---
Thanks and sorry for the false alarm...


-- 


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread howarth at nitro dot med dot uc dot edu


--- Comment #37 from howarth at nitro dot med dot uc dot edu  2009-10-06 
02:05 ---
Opps. In both of the last patch...

+  if ((darwin_macosx_version_min && strverscmp(darwin_macosx_version_min,
"10.6") >= 0) || flag_reorder_blocks_and_partition)

should be

+  if (!(darwin_macosx_version_min && strverscmp(darwin_macosx_version_min,
"10.6") >= 0) && flag_reorder_blocks_and_partition)

of course.


-- 


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread howarth at nitro dot med dot uc dot edu


--- Comment #36 from howarth at nitro dot med dot uc dot edu  2009-10-06 
02:02 ---
This can be factored down to...

Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 152481)
+++ gcc/config/darwin.c (working copy)
@@ -1454,7 +1454,7 @@
 {
   char *lab;

-  if (! for_eh)
+  if ((! for_eh) || (darwin_macosx_version_min &&
strverscmp(darwin_macosx_version_min, "10.6") >= 0))
 return;

   lab = concat (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)), ".eh", NULL);
@@ -1697,6 +1697,19 @@
   if (dwarf_strict < 0) 
 dwarf_strict = 1;

+  if ((darwin_macosx_version_min && strverscmp(darwin_macosx_version_min,
"10.6") >= 0) || flag_reorder_blocks_and_partition)
+{
+  if (flag_exceptions ||
+ flag_unwind_tables ||
+ !targetm.have_named_sections)
+   {
+ inform (input_location,
+  "-freorder-blocks-and-partition does not work with
exceptions on this architecture");
+ flag_reorder_blocks_and_partition = 0;
+ flag_reorder_blocks = 1;
+   }
+}
+
   if (flag_mkernel || flag_apple_kext)
 {
   /* -mkernel implies -fapple-kext for C++ */


-- 


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



[Bug debug/41272] FAIL: gcc.dg/debug/dwarf2/inline2.c scan-assembler-times \(DIE \(.*?\) DW_TAG_in lined_subroutine 6

2009-10-05 Thread danglin at gcc dot gnu dot org


--- Comment #6 from danglin at gcc dot gnu dot org  2009-10-06 01:54 ---
Neither -O3 or __attribute__((always_inline)) work.  There are four
instances of "\\(DIE \\(.*?\\) DW_TAG_lexical_block" and "\\(DIE \\(.*?\\)
DW_TAG_lexical_block" in the assembly output.  Reviewing the assembler,
all functions are inlined.

The test doesn't fail on trunk.

The test fails in the same way on hppa64-hp-hpux11.11.


-- 


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread howarth at nitro dot med dot uc dot edu


--- Comment #35 from howarth at nitro dot med dot uc dot edu  2009-10-06 
00:51 ---
Testing...

Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 152480)
+++ gcc/config/darwin.c (working copy)
@@ -1454,7 +1454,7 @@
 {
   char *lab;

-  if (! for_eh)
+  if ((! for_eh) || (darwin_macosx_version_min &&
strverscmp(darwin_macosx_version_min, "10.6") >= 0))
 return;

   lab = concat (IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)), ".eh", NULL);
@@ -1697,6 +1697,19 @@
   if (dwarf_strict < 0) 
 dwarf_strict = 1;

+  if (!(darwin_macosx_version_min && strverscmp(darwin_macosx_version_min,
"10.6") >= 0) && flag_reorder_blocks_and_partition)
+{
+  if (flag_exceptions ||
+ (flag_unwind_tables && !targetm.unwind_tables_default) ||
+ (!targetm.have_named_sections || (flag_unwind_tables &&
targetm.unwind_tables_default)))
+   {
+ inform (input_location,
+  "-freorder-blocks-and-partition does not work with
exceptions on this architecture");
+ flag_reorder_blocks_and_partition = 0;
+ flag_reorder_blocks = 1;
+   }
+}
+
   if (flag_mkernel || flag_apple_kext)
 {
   /* -mkernel implies -fapple-kext for C++ */


-- 


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



[Bug bootstrap/40968] [4.5 Regression] ICE when compiling O2g.gch; problem with --enable-gather-detailed-mem-stats

2009-10-05 Thread lucier at math dot purdue dot edu


--- Comment #3 from lucier at math dot purdue dot edu  2009-10-06 00:51 
---
Now I'm getting comparison errors with

[trunk revision 152459]

and the same configuration:

Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/libstdc++-v3/src/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/basic_file.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/future.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/debug.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/system_error.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/pool_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/debug.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/mt_allocator.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale_init.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/atomic.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/system_error.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/src/locale.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/vec.o differs
x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/basic_file.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/future.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/basic_file.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/future.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/pool_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/debug.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/mt_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale_init.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/atomic.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/system_error.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/locale.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/pool_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/debug.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/mt_allocator.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale_init.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/atomic.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/system_error.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/src/locale.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/guard.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_alloc.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/vec.o differs
x86_64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/eh_globals.o differs


-- 


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



[Bug lto/41597] Bad .comm directive

2009-10-05 Thread joseph at codesourcery dot com


--- Comment #1 from joseph at codesourcery dot com  2009-10-06 00:10 ---
Subject: Re:   New: Bad .comm directive

On Mon, 5 Oct 2009, danglin at gcc dot gnu dot org wrote:

> The directive is:
> 
> .comm   gnu_lto_v1,1,1
> 
> This apparently comes from here:
> 
>   /* Emit LTO marker if LTO info has been previously emitted.  This is
>  used by collect2 to determine whether an object file contains IL.
>  We used to emit an undefined reference here, but this produces
>  link errors if an object file with IL is stored into a shared
>  library without invoking lto1.  */
>   if (flag_generate_lto)
> fprintf (asm_out_file,"\t.comm\tgnu_lto_v1,1,1\n");

I pointed out in my review that this was inappropriate, both because of 
the hardcoding of .comm syntax and because the name is in the user 
namespace.  The LTO people need to reread my comments (on all the patches, 
not just this one) and look for any others that have not been addressed or 
had PRs filed.

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02139.html has these 
particular comments.


-- 


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



[Bug c++/41545] [4.5 Regression] ICE tree check: expected var_decl or function_decl, have error_mark in grokdeclarator, at cp/decl.c:9305

2009-10-05 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread howarth at nitro dot med dot uc dot edu


--- Comment #34 from howarth at nitro dot med dot uc dot edu  2009-10-05 
23:25 ---
Actually, I just noticed that with the latest patch we still fail...

gcc.dg/tree-prof/pr34999.c

Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/gcc/testsuite/gcc.dg/tree-prof/pr34999.c
  -O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20091003/darwin_objdir/gcc/testsuite/gcc/pr34999.x02
   (timeout = 300)
/var/tmp//ccTlWKzV.s:219:FATAL:Symbol _main.eh already defined.
compiler exited with status 1
output is:
/var/tmp//ccTlWKzV.s:219:FATAL:Symbol _main.eh already defined.

FAIL: gcc.dg/tree-prof/pr34999.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr34999.c execution,-fprofile-use
-D_PROFILE_USE

I'll take a look at perhaps just setting...

flag_reorder_blocks_and_partition = 0;
flag_reorder_blocks = 1;

 in darwin.c's overrides when targeting <10.6 and adjusting
darwin_emit_unwind() to not emit labels when targeting >=10.6.


-- 


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



[Bug lto/41598] bootstrap *using* lto fails

2009-10-05 Thread espindola at google dot com


--- Comment #2 from espindola at google dot com  2009-10-05 23:12 ---
Created an attachment (id=18717)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18717&action=view)
testcase


-- 


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



[Bug lto/41598] bootstrap *using* lto fails

2009-10-05 Thread espindola at google dot com


--- Comment #1 from espindola at google dot com  2009-10-05 23:12 ---
Created an attachment (id=18716)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18716&action=view)
testcase


-- 


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



[Bug lto/41598] New: bootstrap *using* lto fails

2009-10-05 Thread espindola at google dot com
To reproduce with the delta reduced test

cc1 dwarf2out.i -quiet -O2 -flto -o dwarf2out.s
as -V -Qy -o dwarf2out.o dwarf2out.s
cc1 c-decl.i -quiet -O2  -flto -o c-decl.s 
as -V -Qy -o c-decl.o c-decl.s
lto1 -quiet -O2 c-decl.o dwarf2out.o -o /dev/null

Produces:

In function 'gt_pch_p_20VEC_die_arg_entry_gc':
lto1: error: type mismatch in address expression
union tree_node * *

union tree_node *

D.2877_8 = &x_3->base.vec[i0_1].arg;

lto1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
--


-- 
   Summary: bootstrap *using* lto fails
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: espindola at google dot com
 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=41598



[Bug target/41175] -Os generates significantly larger code

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2009-10-05 22:22 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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



[Bug c++/39866] [c++0x] deleted functions not removed from "no match" error messages

2009-10-05 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-10-05 22:22 
---
Likewise... 


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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



[Bug c++/39863] variadic templates : wrong error "mismatched argument pack lengths"

2009-10-05 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2009-10-05 22:22 
---
Let's CC Jason...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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



[Bug lto/41597] New: Bad .comm directive

2009-10-05 Thread danglin at gcc dot gnu dot org
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/  
-
O2 -flto  -w -c  -o 2105-1.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/c
ompile/2105-1.c(timeout = 300)
/var/tmp//cc74uIsZ.s: Assembler messages:
/var/tmp//cc74uIsZ.s:105: Error: bad or irreducible absolute expression
/var/tmp//cc74uIsZ.s:105: Error: junk at end of line, first unrecognized
charact
er is `,'
compiler exited with status 1

The directive is:

.comm   gnu_lto_v1,1,1

This apparently comes from here:

  /* Emit LTO marker if LTO info has been previously emitted.  This is
 used by collect2 to determine whether an object file contains IL.
 We used to emit an undefined reference here, but this produces
 link errors if an object file with IL is stored into a shared
 library without invoking lto1.  */
  if (flag_generate_lto)
fprintf (asm_out_file,"\t.comm\tgnu_lto_v1,1,1\n");


-- 
   Summary: Bad .comm directive
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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



[Bug bootstrap/41205] [4.5 Regression] Bootstrap broken on i686-apple-darwin9 by revision 151249

2009-10-05 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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



[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-10-05 22:07 ---
I just was able to compile this using the lto branch as the starting GCC since
that was the newest powerpc-linux-gnu build I had.


-- 


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



[Bug c++/39866] [c++0x] deleted functions not removed from "no match" error messages

2009-10-05 Thread sylvain dot pion at sophia dot inria dot fr


--- Comment #1 from sylvain dot pion at sophia dot inria dot fr  2009-10-05 
21:52 ---
Problem still present as of today's trunk.


-- 


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



[Bug c++/39863] variadic templates : wrong error "mismatched argument pack lengths"

2009-10-05 Thread sylvain dot pion at sophia dot inria dot fr


--- Comment #1 from sylvain dot pion at sophia dot inria dot fr  2009-10-05 
21:51 ---
Same situation as of today's trunk.


-- 


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



[Bug libmudflap/41253] mudflap complains about c++ temporary passed in to global ctor

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-05 21:46 ---
***
mudflap violation 1 (check/write): time=1254779079.565574 ptr=0x7fffe830
size=8
pc=0x2abccec1 location=`t.cc:3:37 (desc::desc)'
  /home/pinskia/local-gcc/lib64/libmudflap.so.0(__mf_check+0x41)
[0x2abccec1]
  ./a.out(_ZN4descC1EPKc+0x7c) [0x400a74]
  ./a.out(__wrap_main+0x145) [0x40098d]
number of nearby objects: 0

Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|other   |libmudflap
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-05 21:46:51
   date||


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



[Bug rtl-optimization/41239] Scheduler reorders division by zero before a call that might not return

2009-10-05 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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



[Bug target/41240] [4.5 regression] ICE: in get_attr_got, at config/mips/mips.md:455 building stage1 N64 libgcc

2009-10-05 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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



[Bug tree-optimization/38156] gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2009-10-05 21:41 ---
Fixed in 4.5.0 so closing as fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug libmudflap/41559] fgetc_unlocked fails with -fmudflap -O1

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2009-10-05 21:39 ---
This works for me on the trunk.  At least on x86_64-linux-gnu.


-- 


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



[Bug lto/41554] -flto and -fwhopr should be moved to common.opt

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-10-05 21:16 ---
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02102.html


-- 


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



[Bug target/41595] object-c++ mangled local labels are not correctly recognized.

2009-10-05 Thread mrs at apple dot com


--- Comment #2 from mrs at apple dot com  2009-10-05 21:21 ---
Ok.


-- 


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread mrs at apple dot com


--- Comment #33 from mrs at apple dot com  2009-10-05 21:16 ---
I'm fine with the latest patch.


-- 


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



[Bug lto/41554] -flto and -fwhopr should be moved to common.opt

2009-10-05 Thread laurent at guerby dot net


--- Comment #2 from laurent at guerby dot net  2009-10-05 21:15 ---
Not set for gnat1 (Ada):

(gdb) b gate_lto_out
Breakpoint 1 at 0xedd700: file ../../trunk/gcc/lto-streamer.c, line 803.
(gdb) r  -quiet -dumpbase p.adb -auxbase p -O3 -flto -mtune=generic p.adb -o
/tmp/cclbAgyw.s
Starting program:
/home/guerby/install-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/gnat1
-quiet -dumpbase p.adb -auxbase p -O3 -flto -mtune=generic p.adb -o
/tmp/cclbAgyw.s

Breakpoint 1, gate_lto_out () at ../../trunk/gcc/lto-streamer.c:803
803   return ((flag_generate_lto || in_lto_p)
(gdb) p in_lto_p
$1 = 0 '\0'
(gdb) p flag_generate_lto
$2 = 0


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread mrs at apple dot com


--- Comment #32 from mrs at apple dot com  2009-10-05 20:55 ---
I suspect the other case is simply:

if (flag_exceptions)
  flag_reorder_blocks_and_partition = 0;

be added, just like the code for flag_unwind_tables.  I suspect this, as the
testcase is *.C.


-- 


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



[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.

2009-10-05 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #1 from developer at sandoe-acoustics dot co dot uk  2009-10-05 
20:25 ---
Created an attachment (id=18715)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18715&action=view)
allow specification of -static-libstdc++ on the CL while generating PCH

this patch alters the behavior of g++spec.c such that it 
(a) notes if libstdc++ is needed
(b) notes if the user has requested static-libstdc++

It only outputs "-lstdc++" if the lib is needed- and when it does it decides on
the mechanism depending on the availability of static options. 

Finally, for platforms that don't have Bstatic/Bdynamic - it places
"static-libstdc++" back into the command line so that link specs can use it to
trigger substitution.

log:
  *gcc/cp/g++spec.c(lang_specific_driver): Do not insert -lstdc++ unless we
really need it.  
   Insert 'static-libstdc++' for platforms without Bstatic/Bdynamic to
allow link spec substitution.


-- 


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



[Bug c++/41596] New: handling of library-related options by g++spec.c causes a failure when generating pch.

2009-10-05 Thread developer at sandoe-acoustics dot co dot uk
The recognition of any library-related option in g++-spec.c causes the
insertion of  "-lstdc++".  This causes link to be invoked when trying to
generate PCH, which then fails.  This bit me when trying to run the testsuite
with /-static-libstdc++

The behavior here appears to differ from gcc where one can put "-static-libgcc"
on the CL and the link phase is not invoked for PCH-generation.


-- 
   Summary: handling of library-related options by g++spec.c causes
a failure when generating pch.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: developer at sandoe-acoustics dot co dot uk
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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



[Bug tree-optimization/39390] [4.4 Regression] Bogus aliasing warning with std::set

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #6 from pinskia at gcc dot gnu dot org  2009-10-05 20:16 ---
This is fixed on the trunk


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4/4.5 Regression] Bogus  |[4.4 Regression] Bogus
   |aliasing warning with   |aliasing warning with
   |std::set|std::set


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



[Bug tree-optimization/39612] [4.3/4.4/4.5 Regression] LIM inserts loads from uninitialized local memory

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #9 from pinskia at gcc dot gnu dot org  2009-10-05 20:09 ---
The warning is gone but the issue still exist.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-04-03 17:41:20 |2009-10-05 20:09:44
   date||


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



[Bug libgcj/39747] [4.4/4.5 Regression] Installation documentation should suggest building libgmp as PIC for building with libjava

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2009-10-05 20:06 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-10-05 20:06:26
   date||
Summary|[4.4/4.5 Regression]|[4.4/4.5 Regression]
   |Installation documentation  |Installation documentation
   |should suggest building |should suggest building
   |libgmp as PIC   |libgmp as PIC for building
   ||with libjava


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



[Bug objc++/41595] object-c++ mangled local labels are not correctly recognized.

2009-10-05 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #1 from developer at sandoe-acoustics dot co dot uk  2009-10-05 
20:04 ---
Created an attachment (id=18714)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18714&action=view)
recognize name-mangled obj-c++ internal symbols.

this is modeled on the mechanism of the fix for the radar applied to apple
local 4.2.

However; this implementation it is different in that I have re-written it such
that its effect is local to darwin.


-- 


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



[Bug objc++/41595] New: object-c++ mangled local labels are not correctly recognized.

2009-10-05 Thread developer at sandoe-acoustics dot co dot uk
Originally (radar: 5202926)

we need to make objective c internal labels local.  At present the name-mangled
ones are not recognized.


-- 
   Summary: object-c++ mangled local labels are not correctly
recognized.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: developer at sandoe-acoustics dot co dot uk
 GCC build triplet: *-apple-darwin*
  GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*


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



[Bug debug/41558] gfortran -O code excessive DW_OP_deref's

2009-10-05 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2009-10-05 19:51 ---
Subject: Bug 41558

Author: jakub
Date: Mon Oct  5 19:50:57 2009
New Revision: 152467

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152467
Log:
PR debug/41558
* dwarf2out.c (loc_by_reference): Removed.
(dw_loc_list_1): New function.
(dw_loc_list): Remove toplev argument, add want_address argument.
Don't look at decl_by_reference_p at all.  Use dw_loc_list_1.
(loc_list_from_tree) : Pass want_address rather than
want_address == 2 to dw_loc_list.  For successful dw_loc_list
set have_address to 1 only if want_address is not 0.

* gcc.dg/guality/guality.exp: Move gdb-test proc into...
* lib/gcc-gdb-test.exp: ... here.  New file.
* gfortran.dg/guality/guality.exp: New file.
* gfortran.dg/guality/pr41558.f90: New test.
* gfortran.dg/guality/arg1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/guality/
trunk/gcc/testsuite/gfortran.dg/guality/arg1.f90
trunk/gcc/testsuite/gfortran.dg/guality/guality.exp
trunk/gcc/testsuite/gfortran.dg/guality/pr41558.f90
trunk/gcc/testsuite/lib/gcc-gdb-test.exp
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/guality/guality.exp


-- 


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread joseph at codesourcery dot com


--- Comment #7 from joseph at codesourcery dot com  2009-10-05 19:46 ---
Subject: Re:  Misnamed hpp files in gcc-4.4.1.tar.bz2 
 from ftp://gd.tuwien.ac.at

On Mon, 5 Oct 2009, davine at poczta dot onet dot pl wrote:

> of 2 files and no real corruption? (the build was successful) If anything it
> must be something with my tar, perhaps it's too old? (version 1.13) 

At http://gcc.gnu.org/install/prerequisites.html we explicitly document 
that you need GNU tar version 1.14 or later.


-- 


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



[Bug driver/41594] -static-libstdc++ is not recognized as valid by the gcc driver.

2009-10-05 Thread developer at sandoe-acoustics dot co dot uk


--- Comment #1 from developer at sandoe-acoustics dot co dot uk  2009-10-05 
19:39 ---
Created an attachment (id=18713)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18713&action=view)
recognize "-static-libstdc++" as a valid option

log: 
   *gcc/gcc.c: Add -static-libstdc++ to list of recognized options.


-- 


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



[Bug driver/41594] New: -static-libstdc++ is not recognized as valid by the gcc driver.

2009-10-05 Thread developer at sandoe-acoustics dot co dot uk
although the option is parsed by g++spec.c it is not accepted by gcc.


-- 
   Summary: -static-libstdc++ is not recognized as valid by the gcc
driver.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: developer at sandoe-acoustics dot co dot uk
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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



[Bug c++/41533] ASM_PREFERRED_EH_DATA_FORMAT macros is not implemented for ARM

2009-10-05 Thread kirill at shutemov dot name


--- Comment #12 from kirill at shutemov dot name  2009-10-05 19:34 ---
Yes, it works.

Thanks.


-- 

kirill at shutemov dot name changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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



[Bug bootstrap/41451] [4.5 Regression] Bootstrap failure with fold checking

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #4 from pinskia at gcc dot gnu dot org  2009-10-05 18:55 ---
This was caused by:
http://gcc.gnu.org/viewcvs?view=revision&revision=149722


  tem = fold_build2_loc (loc, code, type,
 fold_convert_loc (loc, TREE_TYPE (op0),
   TREE_OPERAND (arg0, 1)), op1);
  protected_set_expr_location (tem, loc);


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu dot org
  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=41451



[Bug bootstrap/41451] [4.5 Regression] Bootstrap failure with fold checking

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-10-05 18:45 ---
Before:
t.c:4:35>>

After:
t.c:4:7>>

This is on the compound_expr's operand 1 which is eq_expr.


-- 


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



[Bug lto/41593] New: slightly confusing configure message about lto

2009-10-05 Thread laurent at guerby dot net
../trunk/configure --enable-languages=c,lto --enable-__cxa_atexit --disable-nls
--enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.4.1/
--with-gmp=/opt/cfarm/gmp-4.2.4/  --prefix=/n/16/guerby/install-trunk
--with-libelf=/opt/cfarm/libelf-0.8.12
...
checking for the correct version of libelf... yes
The following languages will be built: c,lto,lto

=> Note the duplicate lto.


-- 
   Summary: slightly confusing configure message about lto
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread davine at poczta dot onet dot pl


--- Comment #6 from davine at poczta dot onet dot pl  2009-10-05 18:08 
---
Wouldn't you consider it strange that a wrong md5 would only cause a renaming
of 2 files and no real corruption? (the build was successful) If anything it
must be something with my tar, perhaps it's too old? (version 1.13) 


-- 


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



[Bug libstdc++/41530] [c++0x] Cannot move-construct std::tuple from a different type of std::tuple

2009-10-05 Thread paolo dot carlini at oracle dot com


--- Comment #6 from paolo dot carlini at oracle dot com  2009-10-05 17:59 
---
Fixed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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



[Bug c++/41313] r150553 causes g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

2009-10-05 Thread howarth at nitro dot med dot uc dot edu


--- Comment #31 from howarth at nitro dot med dot uc dot edu  2009-10-05 
18:05 ---
(In reply to comment #12)
> It is unclear what those labels are good for, but if darwin is to support
> hot/cold partitioning and FDEs covering it, the emit unwind_label hook (which
> is apparently darwin specific only) should be passed also the SECOND variable
> and create different label name for the second FDE for the same function (if
> function starts in hot section, then the second one is covering the cold
> section, and vice versa).
> The patch in #c11 would just mean you'd keep older versions broken.
> 

Jakub,
   Do you mean that we need to pass 'second' from gcc/ira-int.h?

  /* Allocnos connected by the copy.  The first allocno should have
 smaller order number than the second one.  */
  ira_allocno_t first, second;

to darwin_emit_unwind_label()? Also, what would we use to detect whether the
first and second FDE's came from hot or cold sections?


-- 


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread redi at gcc dot gnu dot org


--- Comment #5 from redi at gcc dot gnu dot org  2009-10-05 17:59 ---
(In reply to comment #4)
> Could you elaborate? Did you mean a wrong tar for creating a tarball?

No, he said untar.

I just downloaded the file from that mirror and it matches its md5 sum,
extracts without errors, and has no misnamed files. I suggest you check the md5
sum of the file you have and download it again if necessary.


-- 


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



[Bug libstdc++/41530] [c++0x] Cannot move-construct std::tuple from a different type of std::tuple

2009-10-05 Thread paolo at gcc dot gnu dot org


--- Comment #5 from paolo at gcc dot gnu dot org  2009-10-05 17:56 ---
Subject: Bug 41530

Author: paolo
Date: Mon Oct  5 17:56:02 2009
New Revision: 152461

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152461
Log:
2009-10-05  John Bytheway  

PR libstdc++/41530
* include/std/tuple (_Tuple_impl<>::_Tuple_impl(_Tuple_impl<>&&)):
Fix to just move.
* testsuite/20_util/tuple/cons/41530.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/tuple/cons/41530.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/tuple


-- 


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



[Bug rtl-optimization/41511] [4.5 Regression] combine behaves differently with/without -g

2009-10-05 Thread ebotcazou at gcc dot gnu dot org


--- Comment #6 from ebotcazou at gcc dot gnu dot org  2009-10-05 17:53 
---
After the longest freeze ever :-)


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug lto/41591] documentation should document interaction of -flto and -fwhole-program

2009-10-05 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2009-10-05 17:50 ---
Draft patch at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00300.html,
has room for improvements.


-- 


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



[Bug target/41095] 4x bigger object when compiled with -O3 option

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #8 from pinskia at gcc dot gnu dot org  2009-10-05 17:48 ---
Doubt it is the same as 40992 as this does not use inline-asm that much.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn|40992   |


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



[Bug rtl-optimization/41511] [4.5 Regression] combine behaves differently with/without -g

2009-10-05 Thread ebotcazou at gcc dot gnu dot org


--- Comment #5 from ebotcazou at gcc dot gnu dot org  2009-10-05 17:48 
---
Subject: Bug 41511

Author: ebotcazou
Date: Mon Oct  5 17:48:09 2009
New Revision: 152459

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152459
Log:
PR rtl-optimization/41511
* combine.c (record_value_for_reg): Pass explicit values as argument
to get_last_value_validate.
(get_last_value_validate): Document INSN parameter.
For non-readonly MEMs, assume they might have been modified if INSN
was in another basic block.
(get_last_value): Minor reformatting.

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


-- 


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



[Bug libstdc++/41530] [c++0x] Cannot move-construct std::tuple from a different type of std::tuple

2009-10-05 Thread jbytheway at gmail dot com


--- Comment #4 from jbytheway at gmail dot com  2009-10-05 17:48 ---
I've added my name to my account details.  You should see it up there somewhere
^^.


-- 


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



[Bug tree-optimization/40992] [4.3/4.4 Regression] cunroll ignoring asm size

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #7 from pinskia at gcc dot gnu dot org  2009-10-05 17:46 ---
Fixed on the trunk.


--- Comment #8 from pinskia at gcc dot gnu dot org  2009-10-05 17:46 ---
Subject: Bug 40992

Author: pinskia
Date: Mon Oct  5 17:46:35 2009
New Revision: 152458

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152458
Log:
2009-10-05  Andrew Pinski  

PR tree-opt/40992
* final.c (asm_str_count): Split out from asm_insn_count.
* rtl.h (asm_str_count): New prototype.
* tree-inline (estimate_num_insns) : Call
asm_str_count.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/final.c
trunk/gcc/rtl.h
trunk/gcc/tree-inline.c


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] cunroll
   |cunroll ignoring asm size   |ignoring asm size


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



[Bug tree-optimization/40992] [4.3/4.4 Regression] cunroll ignoring asm size

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #7 from pinskia at gcc dot gnu dot org  2009-10-05 17:46 ---
Fixed on the trunk.


--- Comment #8 from pinskia at gcc dot gnu dot org  2009-10-05 17:46 ---
Subject: Bug 40992

Author: pinskia
Date: Mon Oct  5 17:46:35 2009
New Revision: 152458

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152458
Log:
2009-10-05  Andrew Pinski  

PR tree-opt/40992
* final.c (asm_str_count): Split out from asm_insn_count.
* rtl.h (asm_str_count): New prototype.
* tree-inline (estimate_num_insns) : Call
asm_str_count.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/final.c
trunk/gcc/rtl.h
trunk/gcc/tree-inline.c


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] cunroll
   |cunroll ignoring asm size   |ignoring asm size


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread davine at poczta dot onet dot pl


--- Comment #4 from davine at poczta dot onet dot pl  2009-10-05 17:31 
---
Could you elaborate? Did you mean a wrong tar for creating a tarball? I'm
ceratinly using gnu tar here and have never had any such problems.


-- 


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2009-10-05 17:23 ---
The problem usually stems from using the wrong tar to untar it.
GNU tar is usually the best tar to use for the gcc sources.


-- 


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread davine at poczta dot onet dot pl


--- Comment #2 from davine at poczta dot onet dot pl  2009-10-05 17:20 
---
Still I hope the mirrored file gets fixed. Thanks


-- 


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



[Bug tree-optimization/41589] lto does not eliminate unused variables

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #7 from pinskia at gcc dot gnu dot org  2009-10-05 17:07 ---
(In reply to comment #6)
> I use binutils 2.19 (from opensuse 11.1).

What I meant was that -ffunction-sections -fdata-sections and then
-Wl,--gc-sections to remove the unused variables/functions.


-- 


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



[Bug ada/41416] Conversion Float to fixed-point behaves differently for static expressions

2009-10-05 Thread dirk dot herrmann-privat at gmx dot de


--- Comment #2 from dirk dot herrmann-privat at gmx dot de  2009-10-05 
16:48 ---
Hi,

thanks for considering my report.

The relevant sections seem to be (these were pointed out to me on comp.lang.ada
by Adam Beneschan):

4.9(38) : "For a real static expression that is not part of a larger static
expression ... the implementation shall round or truncate the value (according
to the Machine_Rounds attribute of the expected type) to the nearest machine
number of the expected type...".

4.9(38.1/2): "The rounding of static floating point expressions is
implementation-defined. It is recommended that the rounding be the same as the
default rounding on the target system."

A.5.4(3): S'Machine_Rounds: Yields the value True if rounding is performed on
inexact results of every predefined operation that yields a result of the type
T; yields the value False otherwise. The value of this attribute is of the
predefined type Boolean.

Here's the interpretation (for which I also used some input from comp.lang.ada
by Adam Beneschan):

4.9(38) demands rounding or truncation for real static expressions, depending
on the value of Machine_Rounds.  A.5.4(3) is not limited to static expressions,
but relates "Machine_Rounds = True" to rounding.  The behaviour in case of
"Machine_Rounds = False" is left open by A.5.4(3), though.  The implementation
advice in 4.9(38.1/2) recommends that static rounding should be the same as the
default rounding.

There is no explicit statement with respect to how non-static expressions
should be handled in case of "Machine_Rounds = False".  But, 4.9(38.1/2) can be
interpreted such that it is generally desired that static and non-static
behaviour should match.  Therefore: 4.9(38) demands truncation for static
expressions in case of "Machine_Rounds = False", and it seems plausible to me
that this should then also apply for non-static expressions.

Thanks again,
Dirk


-- 


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



[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code.

2009-10-05 Thread dougkwan at google dot com


--- Comment #6 from dougkwan at google dot com  2009-10-05 15:48 ---
Subject: Re:  Distribute floating point 
expressions causes bad code.

Just saw Diego's e-mail about the me breaking the freeze.  Sorry I
should have checked that before checking thing in.  It was just my
bad.

2009/10/5 Doug Kwan (Ãö®¶¼w) :
> I am aware of the fact the stage one has ended but this is a bug fix,
> not an experimental new feature.  Did I break a code freeze?  If so, I
> am sorry and can back out the fix until the tree is reopen.
>
> 2009/10/5 ebotcazou at gcc dot gnu dot org :
>>
>>
>> --- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-10-05 10:00 
>> ---
>>> The ChangeLog entry is wrong.
>>
>> And folks from Google shouldn't feel entitled to break a freeze imposed by
>> other folks from Google even if, yes, it is annoyingly long. :-)
>>
>>
>> --
>>
>> ebotcazou at gcc dot gnu dot org changed:
>>
>>   What|Removed |Added
>> 
>> CC||ebotcazou at gcc dot gnu dot
>>   ||org
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
>>
>> --- You are receiving this mail because: ---
>> You reported the bug, or are watching the reporter.
>>
>


-- 


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



[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code.

2009-10-05 Thread dougkwan at google dot com


--- Comment #5 from dougkwan at google dot com  2009-10-05 15:44 ---
Subject: Re:  Distribute floating point 
expressions causes bad code.

I am aware of the fact the stage one has ended but this is a bug fix,
not an experimental new feature.  Did I break a code freeze?  If so, I
am sorry and can back out the fix until the tree is reopen.

2009/10/5 ebotcazou at gcc dot gnu dot org :
>
>
> --- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-10-05 10:00 
> ---
>> The ChangeLog entry is wrong.
>
> And folks from Google shouldn't feel entitled to break a freeze imposed by
> other folks from Google even if, yes, it is annoyingly long. :-)
>
>
> --
>
> ebotcazou at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> 
>                 CC|                            |ebotcazou at gcc dot gnu dot
>                   |                            |org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>


-- 


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



[Bug tree-optimization/41589] lto does not eliminate unused variables

2009-10-05 Thread andi-gcc at firstfloor dot org


--- Comment #6 from andi-gcc at firstfloor dot org  2009-10-05 15:42 ---
I use binutils 2.19 (from opensuse 11.1).


-- 


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



[Bug libstdc++/41592] Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread paolo dot carlini at oracle dot com


--- Comment #1 from paolo dot carlini at oracle dot com  2009-10-05 15:42 
---
The files are definitely named correctly in SVN.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug libstdc++/41592] New: Misnamed hpp files in gcc-4.4.1.tar.bz2 from ftp://gd.tuwien.ac.at

2009-10-05 Thread davine at poczta dot onet dot pl
Hi,

It looks like the following file from one of the gcc mirrors:
ftp://gd.tuwien.ac.at/gnu/gcc/releases/gcc-4.4.1/gcc-4.4.1.tar.bz2

has two .hpp files misnamed as .hp which causes the build to fail, namely:

hash_load_check_resize_trigger_imp.hp
constructors_destructor_fn_imps.hp


-- 
   Summary: Misnamed hpp files in gcc-4.4.1.tar.bz2  from
ftp://gd.tuwien.ac.at
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davine at poczta dot onet dot pl


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



[Bug fortran/41586] Allocatable _scalars_ are never auto-deallocated

2009-10-05 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2009-10-05 15:17 ---
Does not need to be a component or derived type, any scalar leaks:

integer , allocatable :: a
allocate(a)
a = 42
end


MAIN__ ()
{
  integer(kind=4) * a;
  {
void * restrict D.1366;
D.1366 = (void * restrict) __builtin_malloc (4);
if (D.1366 == 0B)
  {
_gfortran_os_error (&"Out of memory"[1]{lb: 1 sz: 1});
  }
a = (integer(kind=4) *) D.1366;
  }
  *a = 42;
}


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[OOP] Allocatable _scalar_  |Allocatable _scalars_ are
   |TYPE/CLASS leak memory  |never auto-deallocated


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



[Bug tree-optimization/41589] lto does not eliminate unused variables

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #5 from pinskia at gcc dot gnu dot org  2009-10-05 15:16 ---
I think this optimization is up to the linker as the variables are marked as
hidden and not marked as local to the Translational unit.


-- 


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



[Bug c++/41575] GCC lists private methods as candidates in "no matching function for call"

2009-10-05 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2009-10-05 15:14 ---
Namelookup is done before access control IIRC.


-- 


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



[Bug c++/31951] local structure problem

2009-10-05 Thread dmitry at lsi dot upc dot edu


--- Comment #3 from dmitry at lsi dot upc dot edu  2009-10-05 14:42 ---
(In reply to comment #1)
> This is not a bug, local classes cannot be template arguments.
> 
What does prevent them to be?


-- 


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



[Bug c++/31951] local structure problem

2009-10-05 Thread redi at gcc dot gnu dot org


--- Comment #4 from redi at gcc dot gnu dot org  2009-10-05 14:58 ---
14.3.1 [temp.arg.type] paragraph 2 in the current C++ standard says:

A type without linkage (3.5) shall not be used as a template argument for a
template type parameter. 

This is changing for C++0x, based on the proposal
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm


-- 


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



[Bug lto/41591] documentation should document interaction of -flto and -fwhole-program

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2009-10-05 14:37 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||documentation
   Last reconfirmed|-00-00 00:00:00 |2009-10-05 14:37:56
   date||


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



[Bug lto/41591] New: documentation should document interaction of -flto and -fwhole-program

2009-10-05 Thread andi-gcc at firstfloor dot org
e.g. when -fwhole-program should be specified, at compile or at line time
and that it applies to the object files

I figured it out using the source and #gcc, but it would be better in
the texinfo file.


-- 
   Summary: documentation should document interaction of -flto and -
fwhole-program
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux


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



[Bug lto/41281] toplevel asms do not work

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-05 14:31 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug lto/41281] toplevel asms do not work

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-05 14:30 ---
Subject: Bug 41281

Author: rguenth
Date: Mon Oct  5 14:30:10 2009
New Revision: 152453

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

PR lto/41281
* lto-cgraph.c (output_cgraph): Output toplevel asms.
(input_cgraph_1): Input toplevel asms.

* gcc.dg/lto/20090914-2_0.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/lto/20090914-2_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-cgraph.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug lto/40902] LTO doesn't merge CV differences properly

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-05 14:28 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug lto/40902] LTO doesn't merge CV differences properly

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-05 14:28 ---
Subject: Bug 40902

Author: rguenth
Date: Mon Oct  5 14:27:39 2009
New Revision: 152452

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

PR lto/40902
* lto-symtab.c (lto_compatible_attributes_p): Remove.
(external_aggregate_decl_p): Likewise.
(lto_symtab_compatible): Re-structure.  Remove dead code.
For variables ignore toplevel qualifiers when comparing types.
Issue warnings, not errors for mismatched user-alignment.

* gcc.dg/lto/20091005-1_0.c: New testcase.
* gcc.dg/lto/20091005-1_1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/lto/20091005-1_0.c
trunk/gcc/testsuite/gcc.dg/lto/20091005-1_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-symtab.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug tree-optimization/41589] lto does not eliminate unused variables

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2009-10-05 14:20 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|lto |tree-optimization
 Ever Confirmed|0   |1
   Keywords||lto, missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2009-10-05 14:20:35
   date||


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



[Bug lto/41487] ICE in duplicate_node_data, at ipa-pure-const.c:633

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #14 from rguenth at gcc dot gnu dot org  2009-10-05 14:17 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug lto/41552] Undefined references with -flto, dependent on object file ordering

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #7 from rguenth at gcc dot gnu dot org  2009-10-05 14:16 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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



[Bug preprocessor/41590] New: No __STDC__ definition in -g3 -E output on STDC_0_IN_SYSTEM_HEADERS systems

2009-10-05 Thread ro at gcc dot gnu dot org
When investigating PR lto/40702, I noticed that no definition of __STDC__ is
emitted at all in the output of gcc -g3 -save-temps, making it very hard to
understand why conditional pieces of code are used.

$ cat head.h
#define HEAD 1
$ cat stdc0.c
#include 
#define STDC0
$ gcc -I. -g3 -save-temps -c stdc0.c
$ grep __STDC__ stdc0.i
$


-- 
   Summary: No __STDC__ definition in -g3 -E output on
STDC_0_IN_SYSTEM_HEADERS systems
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
GCC target triplet: *-*-solaris2*


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



[Bug lto/41552] Undefined references with -flto, dependent on object file ordering

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2009-10-05 14:06 ---
Subject: Bug 41552

Author: rguenth
Date: Mon Oct  5 14:05:54 2009
New Revision: 152450

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

PR lto/41552
PR lto/41487
* lto-symtab.c (struct lto_symtab_base_def): Remove.
(struct lto_symtab_identifier_def): Likewise.
(struct lto_symtab_decl_def): Likewise.
(struct lto_symtab_entry_def): New.
(lto_symtab_identifier_t): Rename to ...
(lto_symtab_entry_t): ... this.
(lto_symtab_decls): Remove.
(lto_symtab_base_hash): Rename to ...
(lto_symtab_entry_hash): ... this.
(lto_symtab_base_eq): Rename to ...
(lto_symtab_entry_eq): ... this.
(lto_symtab_base_marked_p): Rename to ...
(lto_symtab_entry_marked_p): ... this.
(lto_symtab_identifier_marked_p): Remove.
(lto_symtab_decl_marked_p): Likewise.
(lto_symtab_maybe_init_hash_tables): Rename to ...
(lto_symtab_maybe_init_hash_table): ... this.
(lto_symtab_set_resolution_and_file_data): Remove.
(lto_symtab_register_decl): New function.
(lto_symtab_get_identifier): Remove.
(lto_symtab_get): New function.
(lto_symtab_get_resolution): Adjust.
(lto_symtab_get_identifier_decl): Remove.
(lto_symtab_set_identifier_decl): Likewise.
(lto_symtab_merge_decl): Rename to ...
(lto_symtab_merge): ... this.  Rewrite.
(lto_symtab_merge_var): Remove.
(lto_symtab_merge_fn): Likewise.
(lto_symtab_prevailing_decl): Adjust.
(lto_cgraph_replace_node): New function.
(lto_symtab_merge_decls_2): Likewise.
(lto_symtab_merge_decls_1): Likewise.
(lto_symtab_fixup_var_decls): Likewise.
(lto_symtab_resolve_symbols): Likewise.
(lto_symtab_merge_decls): Likewise.
(lto_symtab_prevailing_decl): Adjust.
(lto_symtab_get_symtab_def): Remove.
(lto_symtab_get_file_data): Likewise.
(lto_symtab_clear_resolution): Adjust.
(lto_symtab_clear_resolution): Likewise.
* lto-cgraph.c (input_edge): Do not merge cgraph nodes here.
(input_cgraph_1): Likewise.
* lto-streamer-in.c (get_resolution): Do not provide fake
symbol resolutions here.
(deferred_global_decls): Remove.
(lto_register_deferred_decls_in_symtab): Likewise.
(lto_register_var_decl_in_symtab): Change signature, register
variable via lto_symtab_register_decl.
(lto_register_function_decl_in_symtab): Likewise.
(lto_read_tree): Adjust.
* lto-streamer.h (lto_register_deferred_decls_in_symtab): Remove.
(lto_symtab_merge_var): Likewise.
(lto_symtab_merge_fn): Likewise.
(lto_symtab_register_decl): Declare.
(lto_symtab_merge_decls): Likewise.

lto/
* lto.c (lto_read_decls): Do not register deferred decls.
(read_cgraph_and_symbols): Delay symbol and cgraph merging
until after reading the IPA summaries.

* g++.dg/lto/20091002-1_0.C: Adjust flags.
* g++.dg/lto/20091004-1_0.C: New testcase.
* g++.dg/lto/20091004-1_1.C: Likewise.
* g++.dg/lto/20091004-2_0.C: Likewise.
* g++.dg/lto/20091004-2_1.C: Likewise.
* g++.dg/lto/20091004-3_0.C: Likewise.
* g++.dg/lto/20091004-3_1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/lto/20091004-1_0.C
trunk/gcc/testsuite/g++.dg/lto/20091004-1_1.C
trunk/gcc/testsuite/g++.dg/lto/20091004-2_0.C
trunk/gcc/testsuite/g++.dg/lto/20091004-2_1.C
trunk/gcc/testsuite/g++.dg/lto/20091004-3_0.C
trunk/gcc/testsuite/g++.dg/lto/20091004-3_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-cgraph.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer.h
trunk/gcc/lto-symtab.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/20091002-1_0.C


-- 


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



[Bug lto/41487] ICE in duplicate_node_data, at ipa-pure-const.c:633

2009-10-05 Thread rguenth at gcc dot gnu dot org


--- Comment #13 from rguenth at gcc dot gnu dot org  2009-10-05 14:06 
---
Subject: Bug 41487

Author: rguenth
Date: Mon Oct  5 14:05:54 2009
New Revision: 152450

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

PR lto/41552
PR lto/41487
* lto-symtab.c (struct lto_symtab_base_def): Remove.
(struct lto_symtab_identifier_def): Likewise.
(struct lto_symtab_decl_def): Likewise.
(struct lto_symtab_entry_def): New.
(lto_symtab_identifier_t): Rename to ...
(lto_symtab_entry_t): ... this.
(lto_symtab_decls): Remove.
(lto_symtab_base_hash): Rename to ...
(lto_symtab_entry_hash): ... this.
(lto_symtab_base_eq): Rename to ...
(lto_symtab_entry_eq): ... this.
(lto_symtab_base_marked_p): Rename to ...
(lto_symtab_entry_marked_p): ... this.
(lto_symtab_identifier_marked_p): Remove.
(lto_symtab_decl_marked_p): Likewise.
(lto_symtab_maybe_init_hash_tables): Rename to ...
(lto_symtab_maybe_init_hash_table): ... this.
(lto_symtab_set_resolution_and_file_data): Remove.
(lto_symtab_register_decl): New function.
(lto_symtab_get_identifier): Remove.
(lto_symtab_get): New function.
(lto_symtab_get_resolution): Adjust.
(lto_symtab_get_identifier_decl): Remove.
(lto_symtab_set_identifier_decl): Likewise.
(lto_symtab_merge_decl): Rename to ...
(lto_symtab_merge): ... this.  Rewrite.
(lto_symtab_merge_var): Remove.
(lto_symtab_merge_fn): Likewise.
(lto_symtab_prevailing_decl): Adjust.
(lto_cgraph_replace_node): New function.
(lto_symtab_merge_decls_2): Likewise.
(lto_symtab_merge_decls_1): Likewise.
(lto_symtab_fixup_var_decls): Likewise.
(lto_symtab_resolve_symbols): Likewise.
(lto_symtab_merge_decls): Likewise.
(lto_symtab_prevailing_decl): Adjust.
(lto_symtab_get_symtab_def): Remove.
(lto_symtab_get_file_data): Likewise.
(lto_symtab_clear_resolution): Adjust.
(lto_symtab_clear_resolution): Likewise.
* lto-cgraph.c (input_edge): Do not merge cgraph nodes here.
(input_cgraph_1): Likewise.
* lto-streamer-in.c (get_resolution): Do not provide fake
symbol resolutions here.
(deferred_global_decls): Remove.
(lto_register_deferred_decls_in_symtab): Likewise.
(lto_register_var_decl_in_symtab): Change signature, register
variable via lto_symtab_register_decl.
(lto_register_function_decl_in_symtab): Likewise.
(lto_read_tree): Adjust.
* lto-streamer.h (lto_register_deferred_decls_in_symtab): Remove.
(lto_symtab_merge_var): Likewise.
(lto_symtab_merge_fn): Likewise.
(lto_symtab_register_decl): Declare.
(lto_symtab_merge_decls): Likewise.

lto/
* lto.c (lto_read_decls): Do not register deferred decls.
(read_cgraph_and_symbols): Delay symbol and cgraph merging
until after reading the IPA summaries.

* g++.dg/lto/20091002-1_0.C: Adjust flags.
* g++.dg/lto/20091004-1_0.C: New testcase.
* g++.dg/lto/20091004-1_1.C: Likewise.
* g++.dg/lto/20091004-2_0.C: Likewise.
* g++.dg/lto/20091004-2_1.C: Likewise.
* g++.dg/lto/20091004-3_0.C: Likewise.
* g++.dg/lto/20091004-3_1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/lto/20091004-1_0.C
trunk/gcc/testsuite/g++.dg/lto/20091004-1_1.C
trunk/gcc/testsuite/g++.dg/lto/20091004-2_0.C
trunk/gcc/testsuite/g++.dg/lto/20091004-2_1.C
trunk/gcc/testsuite/g++.dg/lto/20091004-3_0.C
trunk/gcc/testsuite/g++.dg/lto/20091004-3_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-cgraph.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer.h
trunk/gcc/lto-symtab.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/20091002-1_0.C


-- 


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



[Bug lto/40702] lto-elf.c fails to compile on Solaris

2009-10-05 Thread ro at techfak dot uni-bielefeld dot de


--- Comment #4 from ro at techfak dot uni-bielefeld dot de  2009-10-05 
14:05 ---
Subject: Re:  lto-elf.c fails to compile on Solaris

> --- Comment #3 from rguenth at gcc dot gnu dot org  2009-10-05 13:13 
> ---
> That's weird.  So is this a libelf bug after all or can we somehow workaround
> it
> in gcc?

I think it's a libelf bug.  I'll report it upstream.  In addition, I'll
check if STDC_0_IN_SYSTEM_HEADERS is still necessary on Solaris 2.

Rainer


-- 


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



[Bug lto/41589] lto does not eliminate unused variables

2009-10-05 Thread andi-gcc at firstfloor dot org


--- Comment #3 from andi-gcc at firstfloor dot org  2009-10-05 14:04 ---
Created an attachment (id=18712)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18712&action=view)
Makefile.lto


-- 


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



[Bug lto/41589] lto does not eliminate unused variables

2009-10-05 Thread andi-gcc at firstfloor dot org


--- Comment #2 from andi-gcc at firstfloor dot org  2009-10-05 14:04 ---
Created an attachment (id=18711)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18711&action=view)
tlto2.c


-- 


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



[Bug lto/41589] New: lto does not eliminate unused variables

2009-10-05 Thread andi-gcc at firstfloor dot org
Using built-in specs.
COLLECT_GCC=gcc45
COLLECT_LTO_WRAPPER=/pkg/gcc-4.5-091004/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/pkg/gcc-4.5-091004
--enable-checking=release --enable-languages=c,c++ --disable-nls --enable-lto
Thread model: posix
gcc version 4.5.0 20091004 (experimental) (GCC) 


With the attached simple lto test case I would have expected f1 and f2 and y to
be optimized away when built with -fwhole-program. But that was not the case.
nm ./tlto
...

00601020 b completed.5856
00601010 W data_start
00601028 b dtor_idx.5858
00400560 T f1
00400550 T f2
004004f0 t frame_dummy
00400520 T main
 U printf@@GLIBC_2.2.5
00601030 B y


-- 
   Summary: lto does not eliminate unused variables
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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



[Bug lto/41589] lto does not eliminate unused variables

2009-10-05 Thread andi-gcc at firstfloor dot org


--- Comment #1 from andi-gcc at firstfloor dot org  2009-10-05 14:04 ---
Created an attachment (id=18710)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18710&action=view)
tlto1.c


-- 


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



[Bug lto/41588] LTO bugs to be addressed before the merge

2009-10-05 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker


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



[Bug lto/41588] LTO bugs to be addressed before the merge

2009-10-05 Thread rguenth at gcc dot gnu dot org


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||41526, 41528, 41529, 41550,
   ||41554
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2009-10-05 13:35:03
   date||


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



  1   2   >