[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[davek at gcc dot gnu.org]

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

--- Comment #11 from Dave Korn  2010-12-04 06:28:48 
UTC ---
Created attachment 22626
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22626
preprocessed source

[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[davek at gcc dot gnu.org]

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

--- Comment #10 from Dave Korn  2010-12-04 06:28:04 
UTC ---
Created attachment 22625
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22625
generated assembler

This is the assembler output that has been generated up to the point when it
ICEs.

[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 CC||davek at gcc dot gnu.org

--- Comment #9 from Dave Korn  2010-12-04 06:26:55 
UTC ---
The testcase is failing for me on i686-pc-cygwin:

spawn /gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../g++
-B/gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../
/gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/pr46123.C -nostdinc++
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include
-I/gnu/gcc/gcc-patched/libstdc++-v3/libsupc++
-I/gnu/gcc/gcc-patched/libstdc++-v3/include/backward
-I/gnu/gcc/gcc-patched/libstdc++-v3/testsuite/util -fmessage-length=0 -gdwarf-2
-g -feliminate-dwarf2-dups -S -o pr46123.s 
/gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/pr46123.C:47:1: internal
compiler error: in output_aranges, at dwarf2out.c:11678

 It happens here, 

(gdb) bt
#0  0x007c7c70 in fancy_abort (
file=0xe22afc "/gnu/gcc/gcc-patched/gcc/dwarf2out.c", line=11678,
function=0xe284b4 "output_aranges")
at /gnu/gcc/gcc-patched/gcc/diagnostic.c:101
#1  0x0066b9c1 in dwarf2out_finish (
filename=0x59bccaa
"/gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/pr46123.
C") at /gnu/gcc/gcc-patched/gcc/dwarf2out.c:1109

... in dwarf2out.c, where output_aranges() has been inlined into
dwarf2out_finish:

  /* It is necessary not to output these entries if the sections were
 not used; if the sections were not used, the length will be 0 and
 the address may end up as 0 if the section is discarded by ld
 --gc-sections, leaving an invalid (0, 0) entry that can be
 confused with the terminator.  */
  if (text_section_used)
{
  dw2_asm_output_addr (DWARF2_ADDR_SIZE, text_section_label, "Address");
  dw2_asm_output_delta (DWARF2_ADDR_SIZE, text_end_label,
text_section_label, "Length");
}
  if (cold_text_section_used)
{
  dw2_asm_output_addr (DWARF2_ADDR_SIZE, cold_text_section_label,
   "Address");
  dw2_asm_output_delta (DWARF2_ADDR_SIZE, cold_end_label,
cold_text_section_label, "Length");
}

  for (i = 0; i < arange_table_in_use; i++)
{
  dw_die_ref die = arange_table[i];

  /* We shouldn't see aranges for DIEs outside of the main CU.  */
  gcc_assert (die->die_mark);

  This assertion triggers on the second address range in the table:

(gdb) p arange_table[0][0]
$2 = {die_id = {die_symbol = 0x0, die_type_node = 0x0},
  die_attr = 0x7ff01400, die_parent = 0x7feb1980, die_child = 0x7feb1b00,
  die_sib = 0x7feb19e0, die_definition = 0x0, die_offset = 98,
  die_abbrev = 4, die_mark = 0, die_perennial_p = 0, decl_id = 1705,
  die_tag = DW_TAG_subprogram}
(gdb) p arange_table[1][0]
$3 = {die_id = {die_symbol = 0x0, die_type_node = 0x0},
  die_attr = 0x7ff816c0, die_parent = 0x7feb0360, die_child = 0x7feb1e00,
  die_sib = 0x7feb2340, die_definition = 0x0, die_offset = 78,
  die_abbrev = 9, die_mark = 1, die_perennial_p = 0, decl_id = 1697,
  die_tag = DW_TAG_subprogram}
(gdb) p arange_table[2]
$4 = (dw_die_ref) 0x0
(gdb)

  Any ideas what this could mean?

[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

 CC||davek at gcc dot gnu.org

--- Comment #7 from Dave Korn  2010-12-04 05:36:36 
UTC ---
  I think this may also have caused

FAIL: g++.dg/debug/debug9.C (test for excess errors)

on i686-pc-cygwin.  I get all sorts of assembler complaints:

/gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../g++
-B/gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../ -nostdinc++
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include
-I/gnu/gcc/gcc-patched/libstdc++-v3/libsupc++
-I/gnu/gcc/gcc-patched/libstdc++-v3/include/backward
-I/gnu/gcc/gcc-patched/libstdc++-v3/testsuite/util -fmessage-length=0 -gcoff3
-O2 -c -o debug9.o /gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/debug9.C 
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s: Assembler messages:
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:61: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:62: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:63: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:65: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:67: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:69: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:71: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:75: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:135: Error: .cfi_endproc
without corresponding .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:178: Error: open CFI at the
end of file; missing .cfi_endproc directive
compiler exited with status 1

... and these are caused because we're hopping around between .text and
.text.startup, and we do so:

.file"debug9.C"
.text
.def_s;.scl10;.type010;.size1;.endef
.def.eos;.val1;.scl102;.tag_s;.size1;  
 .endef
.def_s;.scl13;.tag_s;.size1;.type010;  
 .endef
.def___main;.scl2;.type32;.endef
.section.text.startup,"x"
.p2align 4,,15
.text
.def_main;.val_main;.scl2;.type044;.endef
.globl_main
_main:
.def.bf;.val.;.scl101;.line23;.endef
.section.text.startup,"x"
LFB1:
.cfi_startproc
.cfi_personality 0,___gxx_personality_v0
.cfi_lsda 0,LLSDA1
leal4(%esp), %ecx
.cfi_def_cfa 1, 0
andl$-16, %esp
pushl-4(%ecx)
pushl%ebp
movl%esp, %ebp
.cfi_escape 0x10,0x5,0x2,0x75,0
pushl%esi
pushl%ebx
pushl%ecx
.cfi_escape 0xf,0x3,0x75,0x74,0x6
.cfi_escape 0x10,0x3,0x2,0x75,0x78
.cfi_escape 0x10,0x6,0x2,0x75,0x7c
subl$44, %esp
.ln1
call___main
.def.bb;.val.;.scl100;.line1;.endef
.def.bb;.val.;.scl100;.line1;.endef
.text

... here, right in the middle of an open CFI.  GAS can't handle this even if we
were to switch back to the original section anyway, but in this case it's even
worse:

.def_c;.val-26;.scl1;.tag_s;.size1;   
.type010;.endef
leal-26(%ebp), %ebx
leal-25(%ebp), %esi

... as we end up carrying on code generation in a different section.  Urk!

  This test is compiled with -gcoff in effect, and the problematic switch back
to the .text section is generated in sdbout.c#sdbout_one_type(), right here at
the start:

static void
sdbout_one_type (tree type)
{
  if (current_function_decl != NULL_TREE
  && DECL_SECTION_NAME (current_function_decl) != NULL_TREE)
; /* Don't change section amid function.  */
  else
switch_to_section (text_section);

  For some reason this doesn't realise that we may be in a section other than
the .text section any more.  current_function_decl points to main() at the time
of the problem, but DECL_SECTION_NAME is indeed null.

  Honza, any ideas how to teach it about the new sections?

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #33 from Jack Howarth  2010-12-04 
03:18:41 UTC ---
Using the patch...

Index: gcc/collect2.c
===
--- gcc/collect2.c(revision 167430)
+++ gcc/collect2.c(working copy)
@@ -1055,8 +1055,10 @@
  optimized by the LTO with the temporary file generated by the LTO. 
*/
   fork_execute ("ld", out_lto_ld_argv);
   free (lto_ld_argv);
-
+#if 0
   maybe_unlink_list (lto_o_files);
+#endif
+  printf("would have executed maybe_unlink_list\n");
 }
   else if (force)
 {

...the previous test compilation of "gcc -flto -g -v himenoBMTxpa.c", changes
to...

COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v' '-mtune=core2'
'-fltrans' '-o' '/var/tmp//cc52uGqn.ltrans0.ltrans.o'
would have executed maybe_unlink_list
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 dsymutil a.out

and is the only instance of that call.

[Bug target/45263] registers used in __do_global_ctors can get clobbered

[westfw at yahoo dot com]

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

--- Comment #9 from Bill Westfield  2010-12-04 
03:11:23 UTC ---
This is essentially identical to the patch I provided for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
so it looks good to me.
I had two worries:
Is R15 used anywhere else in startup code that might not obey the register save
conventions (ie does do_global_ctors need to preserve R15)
The AVR has a lot of opcodes that are not valid on registers less than 16.  It
doesn't look like any of these are used here, but I wasn't 100% positive that
using R15 wouldn't cause problems...

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #32 from Jack Howarth  2010-12-04 
02:10:50 UTC ---
While the hack in Comment 31 produces the missing .dSYM output for -g -flto, it
also leave behind the temporary *.ltrans0.ltrans.o files in /var/tmp at the
end. A simple compile shows...


[frodo:~] howarth% ./dist/bin/gcc -flto -g -v himenoBMTxpa.c
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/cc1 -quiet -v
-D__DYNAMIC__ himenoBMTxpa.c -fPIC -feliminate-unused-debug-symbols -quiet
-dumpbase himenoBMTxpa.c -mmacosx-version-min=10.6.5 -mtune=core2 -auxbase
himenoBMTxpa -g -version -flto -o /var/tmp//ccAAPCUI.s
GNU C (GCC) version 4.6.0 20101203 (experimental) (x86_64-apple-darwin10.5.0)
compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../../x86_64-apple-darwin10.5.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include
 /Users/howarth/dist/include
 /Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C (GCC) version 4.6.0 20101203 (experimental) (x86_64-apple-darwin10.5.0)
compiled by GNU C version 4.6.0 20101203 (experimental), GMP version 4.3.2,
MPFR version 2.4.2-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 27436f303ba35e8877de0a62c5c2d06f
himenoBMTxpa.c: In function 'main':
himenoBMTxpa.c:79:5: warning: incompatible implicit declaration of built-in
function 'strcpy' [enabled by default]
himenoBMTxpa.c: In function 'set_param':
himenoBMTxpa.c:226:5: warning: incompatible implicit declaration of built-in
function 'exit' [enabled by default]
himenoBMTxpa.c: In function 'newMat':
himenoBMTxpa.c:239:5: warning: incompatible implicit declaration of built-in
function 'malloc' [enabled by default]
himenoBMTxpa.c: In function 'clearMat':
himenoBMTxpa.c:248:5: warning: incompatible implicit declaration of built-in
function 'free' [enabled by default]
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o /var/tmp//cci8rGh2.o
/var/tmp//ccAAPCUI.s
COMPILER_PATH=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/
LIBRARY_PATH=/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/:/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.6.5' '-flto' '-g' '-v'
'-mtune=core2'
 /Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/collect2 -flto
-dynamic -arch x86_64 -macosx_version_min 10.6.5 -weak_reference_mismatches
non-weak -o a.out -lcrt1.10.5.o
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0
-L/Users/howarth/dist/lib/gcc/x86_64-apple-darwin10.5.0/4.6.0/../../..
/var/tmp//cci8rGh2.o -lgcc_ext.10.5 -lgcc -no_compact_unwind -lSystem
 ./dist/bin/gcc @/var/tmp//cctadu4J.args
Using built-in specs.
COLLECT_GCC=./dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.5.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.5.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20101203 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-mmacosx-version-min=10.6.5' '-g' '-v'

[Bug c++/45822] [4.6-regression] Qt 4.7.0 build fails

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.04 01:56:18
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #7 from Jason Merrill  2010-12-04 
01:56:18 UTC ---
Mine.  This is a problem with my overload resolution hack from the implicitly
deleted patch.

[Bug bootstrap/46776] gogo-tree.cc uses TRAMPOLINE_ALIGNMENT and TRAMPOLINE_SIZE

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #2 from Ian Lance Taylor  2010-12-04 01:48:50 
UTC ---
Should be fixed.  Thanks.

[Bug bootstrap/46776] gogo-tree.cc uses TRAMPOLINE_ALIGNMENT and TRAMPOLINE_SIZE

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  2010-12-04 
01:47:25 UTC ---
Author: ian
Date: Sat Dec  4 01:47:21 2010
New Revision: 167451

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167451
Log:
PR bootstrap/46776
* go-backend.c: New file.
* go-c.h (go_type_alignment): Declare.
(go_field_alignment, go_trampoline_info): Declare.
* Make-lang.in (GO_OBJS): Add go/go-backend.o.
(go/go-backend.o): New target.
(go/go-lang.o): Make dependencies match source file.
(go/expressions.o): Don't depend on $(TM_H) $(TM_P_H).
(go/gogo-tree.o): Don't depend on $(TM_H).
Remove #include "tm.h" from gofrontend/*.cc.

Added:
trunk/gcc/go/go-backend.c
Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/Make-lang.in
trunk/gcc/go/go-c.h
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/gogo-tree.cc

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

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

--- Comment #28 from Jorn Wolfgang Rennecke  
2010-12-04 01:03:18 UTC ---
(In reply to comment #27)
> No, the build still failed the same way. In fact, when issuing command 'file
> gcc/tm.texi' on the build directory, gcc/tm.texi: ASCII English text, with 
> very
> long lines is outputed.

Did your Makefile actually get regenerated?

The idea is that gcc/tm.texi is no longer compared against
$(srcdir))/doc/tm.texi,
but against gcc/tmp3-tm.texi, which should have the same line endings as
gcc/tm.texi .

This temporary file is not deleted in the miscompare case, so you should be
able to inspect it, too.

[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

  Attachment #22549|0   |1
is obsolete||
   Keywords||patch
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-12/msg00132.htm
   ||l

--- Comment #5 from Dave Korn  2010-11-28 05:40:58 
UTC ---
Created attachment 22552
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22552
revised patch

last one had a couple of quoting glitches in it.  fixed in this spin.

don't forget to regenerate everything.  aclocal requires the args "-I ../config
-I . -I .. " in every directory except libjava where it requires "-I . -I .. -I
../config -I libltdl".  autoconf required in each of the top-level subdirs
touched, automake in all but libobjc.

[Bug lto/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled

[davek at gcc dot gnu.org]

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

Dave Korn  changed:

   What|Removed |Added

  Component|other   |lto

--- Comment #6 from Dave Korn  2010-12-04 00:29:15 
UTC ---
Problems with the plugin are filed under the LTO category, so adjusting.  This
bug should be resolved by the patch I've posted for Bug 40125.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mikestump at comcast dot net]

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

--- Comment #31 from Mike Stump  2010-12-04 
00:18:07 UTC ---
On Dec 3, 2010, at 3:20 PM, rguenther at suse dot de wrote:
> yes, I would have expected that this happens already.  Now, I (or
> somebody else) needs to take the time and investigate why this
> doesn't happen.

Ah, I can explain it, collect2 does `stuff', and what it does is to remove the
lto temporary files, early.  The below are the files that are too early, and
will `fix' the issue.

Index: collect2.c
===
--- collect2.c(revision 167409)
+++ collect2.c(working copy)
@@ -1056,7 +1056,9 @@
   fork_execute ("ld", out_lto_ld_argv);
   free (lto_ld_argv);

+#if 0
   maybe_unlink_list (lto_o_files);
+#endif
 }
   else if (force)
 {

If collect2 was folded into gcc.c and all the lto stuff was flat, inside gcc.c
and then we let record_temp_file register _all_ the temporary files, and the
let gcc.c delete the temporary files at the end, all work work just fine.

[Bug debug/46796] debug info missing builtin type names with lto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2010-12-03 
23:52:55 UTC ---
but it conflicts with the way we pre-seed the cache with our common tree nodes,
so it doesn't actually work but ICEs.

[Bug debug/46796] debug info missing builtin type names with lto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 CC||rguenth at gcc dot gnu.org
  Component|lto |debug
Summary|debug info missing builtin  |debug info missing builtin
   |type names on darwin|type names with lto

--- Comment #3 from Richard Guenther  2010-12-03 
23:51:27 UTC ---
Sth like

Index: gimple.c
===
--- gimple.c(revision 167445)
+++ gimple.c(working copy)
@@ -3436,6 +3436,10 @@ gtc_visit (tree t1, tree t2, enum gtc_mo
   if (TREE_CODE (t1) == VOID_TYPE)
 return true;

+  if (mode == GTC_MERGE
+  && !compare_type_names_p (t1, t2, false))
+return false;
+
   /* Do some simple checks before doing three hashtable queries.  */
   if (INTEGRAL_TYPE_P (t1)
   || SCALAR_FLOAT_TYPE_P (t1)
@@ -3874,6 +3878,10 @@ gimple_types_compatible_p (tree t1, tree
   if (TREE_CODE (t1) == VOID_TYPE)
 return true;

+  if (mode == GTC_MERGE
+  && !compare_type_names_p (t1, t2, false))
+return false;
+
   /* Do some simple checks before doing three hashtable queries.  */
   if (INTEGRAL_TYPE_P (t1)
   || SCALAR_FLOAT_TYPE_P (t1)


could fix this at the cost of some memory.

[Bug lto/46796] debug info missing builtin type names on darwin

[mrs at gcc dot gnu.org]

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

--- Comment #2 from mrs at gcc dot gnu.org  2010-12-03 
23:45:15 UTC ---
>From dwarfdump of the good .o file:

0x00a1: TAG_formal_parameter [3]  
 AT_name( "i" )
 AT_decl_file( "/Users/mrs/net/gcc-darwinLTO/gcc/t.c" )
 AT_decl_line( 5 )
 AT_type( {0x00ae} ( int ) )
 AT_location( fbreg -20 )

0x00ae: TAG_base_type [4]  
 AT_byte_size( 0x04 )
 AT_encoding( DW_ATE_signed )
 AT_name( "int" )

and for the bad version:

0x0110: TAG_formal_parameter [5]  
 AT_name( "i" )
 AT_decl_file( "/Users/mrs/net/gcc-darwinLTO/gcc/t.c" )
 AT_decl_line( 5 )
 AT_type( {0x00ea} ( __unknown__ ) )
 AT_location( fbreg -20 )

0x00ea: TAG_base_type [3]  
 AT_byte_size( 0x04 )
 AT_encoding( DW_ATE_signed )
 AT_name( "__unknown__" )

[Bug lto/46796] debug info missing builtin type names on darwin

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.03 23:41:59
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-12-03 
23:41:59 UTC ---
Confirmed.  We merge simple types without caring for their name (and thus
end up using the LTO frontend provided common tree node types).

[Bug lto/46796] New: debug info missing builtin type names on darwin

[mrs at gcc dot gnu.org]

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

   Summary: debug info missing builtin type names on darwin
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org


int i;

doesn't preserve the name "int" on the type under lto.  Consider:

$ cat t.c
volatile float a1, a2;

void * volatile vp;

void f(int i) {
  a1 = i;
  a1 = a2;
}

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

$ ./xgcc -B./ -flto t.c -g -v -Wl,-debug -save-temps
$ grep int cc*.s 
$ ./xgcc -B./ -S t.c -g -o t-normal.s
$ grep int t-normal.s 
.ascii "int\0"

because of this, this code:


  /* This probably indicates a bug.  */
  else if (mod_type_die && mod_type_die->die_tag == DW_TAG_base_type)
add_name_attribute (mod_type_die, "__unknown__");

in dwarf2out.c adds a name __unknown__ to most things, and under gdb, we get:

(gdb) start
(gdb) step
(gdb) ptype i
type = __unknown__

instead of:

(gdb) start
(gdb) step
(gdb) ptype i
type = int

when we compile without -flto.  If the name was preserved, then the type would
have the right name, instead of __unknown__.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

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

--- Comment #27 from Anh Vo  2010-12-03 23:23:49 
UTC ---
No, the build still failed the same way. In fact, when issuing command 'file
gcc/tm.texi' on the build directory, gcc/tm.texi: ASCII English text, with very
long lines is outputed.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[rguenther at suse dot de]

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

--- Comment #30 from rguenther at suse dot de  
2010-12-03 23:20:54 UTC ---
On Fri, 3 Dec 2010, mikestump at comcast dot net wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
> 
> --- Comment #29 from Mike Stump  2010-12-03 
> 23:13:02 UTC ---
> > The darwin people have to design a more robust way to run dsymutil.
> 
> 
> Ok.  How's this, you must run LINK_COMMAND_SPEC to link.  When you run it, any
> temporary real .o files created by the compilation process cannot be removed
> until after it finishes running, including any sub-invocations of the compiler
> that contribute content.

yes, I would have expected that this happens already.  Now, I (or
somebody else) needs to take the time and investigate why this
doesn't happen.

[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

[mikestump at comcast dot net]

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

--- Comment #29 from Mike Stump  2010-12-03 
23:13:02 UTC ---
> The darwin people have to design a more robust way to run dsymutil.


Ok.  How's this, you must run LINK_COMMAND_SPEC to link.  When you run it, any
temporary real .o files created by the compilation process cannot be removed
until after it finishes running, including any sub-invocations of the compiler
that contribute content.

[Bug rtl-optimization/46793] -fschedule-insns causes ICE in compiling zlib/trees.c

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  2010-12-03 23:04:52 UTC ---
We should disable this option (with a warning) in 
ix86_option_override_internal if we don't think it can work reliably, 
rather than leaving it to ICE.

[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #11 from Jack Howarth  2010-12-03 
23:01:13 UTC ---
(In reply to comment #10)
> Jack says that some of the spurious warnings are fixed in Xcode 3.2.3.  I have
> 3.2.4 on my system.  Could you update Xcode and see if any we care about
> remain.  If so, please file a Apple bug report.  If fixed, we can simply
> require the newer Xcode.  If it won't work on darwin9, and we care, we could
> have the .f addition in darwin10.h alone.  I don't favor the stripping, but 
> I'g
> go along with a darwin9 stripper and a darwin10 and later no strip version.

FYI, this was radar 7851516.

[Bug bootstrap/46795] New: bootstrap with gccgo fails

[kargl at gcc dot gnu.org]

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

   Summary: bootstrap with gccgo fails
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ka...@gcc.gnu.org


gmake[3]: Entering directory
`/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/libgo'
gmake[4]: Entering directory
`/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/libgo'
/bin/sh ../../../gcc4x/libgo/mksysinfo.sh
gmake[4]: *** [sysinfo.go] Error 1
gmake[4]: Leaving directory
`/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/libgo'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/libgo'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/usr/home/kargl/gcc/obj4x/i386-unknown-freebsd9.0/libgo'
gmake[1]: *** [all-target-libgo] Error 2
gmake[1]: Leaving directory `/usr/home/kargl/gcc/obj4x'
gmake: *** [all] Error 2

[Bug lto/46769] LTO failed to build gold

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Richard Guenther  2010-12-03 
22:40:08 UTC ---
Confirmed.  Thanks for the testcase (reducing).

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

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

--- Comment #26 from Anh Vo  2010-12-03 22:35:13 
UTC ---
Rebuilding was just started.

[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.6.0   |---

[Bug c++/46791] [4.6 Regression] GCC fails on "for(struct { } f;;) ;", incorrectly treating it as a range-based for loop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |4.6.0
Summary|GCC fails on "for(struct {  |[4.6 Regression] GCC fails
   |} f;;) ;", incorrectly  |on "for(struct { } f;;) ;",
   |treating it as a|incorrectly treating it as
   |range-based for loop|a range-based for loop

[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

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

--- Comment #25 from Jorn Wolfgang Rennecke  
2010-12-03 21:35:52 UTC ---
Created attachment 22624
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22624
patch to use \r-stripped copy of $(srcdir)/doc/tm.texi for comparison

Could you verify if this patch helps for your setting?

[Bug rtl-optimization/46793] -fschedule-insns causes ICE in compiling zlib/trees.c

[changpeng.fang at amd dot com]

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

--- Comment #4 from Changpeng Fang  2010-12-03 
21:24:06 UTC ---
Thanks, I understand the issue now.
Yes, -fschedule-insns and -fsched-pressure should be a paired options for
x86. -fsched-pressure does not solve the -m32 issue.

[Bug middle-end/46790] [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18

[sje at cup dot hp.com]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at cup dot hp.com

--- Comment #1 from Steve Ellcey  2010-12-03 21:19:55 
UTC ---
It may be completely unrelated but I have a bunch of failures in C++ on IA64
HP-UX (and probably Linux) involving exceptions that I tracked back to the
latest GNU Assembler rather then any GCC change.  The change was made to the
ToT GAS sources on December 2 and the bug report I submitted is:

http://sourceware.org/bugzilla/show_bug.cgi?id=12287

This report mentions using ld 2.18 but it doesn't say what gas was used,
if it is not ToT then it is unrelated.

[Bug fortran/46794] ICE on valid code involving power of small integer kinds

[domob at gcc dot gnu.org]

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

Daniel Kraft  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.03 21:17:50
 AssignedTo|unassigned at gcc dot   |domob at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Daniel Kraft  2010-12-03 21:17:50 
UTC ---
Taking this on.

[Bug fortran/46794] New: ICE on valid code involving power of small integer kinds

[domob at gcc dot gnu.org]

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

   Summary: ICE on valid code involving power of small integer
kinds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: do...@gcc.gnu.org


The following reduced code ICEs:

PROGRAM main
  IMPLICIT NONE
  INTEGER(KIND=2) :: j

  j = 1_2 + 1_2**j
END PROGRAM main

I get something like:

[/tmp]# gfortran-dev test.f03 
test.f03: In function 'MAIN__':
test.f03:1:0: error: type mismatch in binary expression
integer(kind=2)

integer(kind=4)

integer(kind=2)

j = D.1476 + 1;

test.f03:1:0: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The problem is that for "small" integer kinds (1 and 2) we still call the
library power routine for kind 4 but the result is not converted back to the
smaller integer kinds properly.

This seems to be a regression, with 4.3 and 4.5 the code compiles cleanly for 
me.

[Bug rtl-optimization/46793] -fschedule-insns causes ICE in compiling zlib/trees.c

[steven at gcc dot gnu.org]

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

--- Comment #3 from Steven Bosscher  2010-12-03 
21:05:46 UTC ---
The bug is in the architecture, not in the scheduling pass. You cannot expect
scheduling before register allocation to always yield code that you can
register-allocate with just 3 general registers available.

Enabling it only for AMD64 is not a work-around, it's the only proper thing to
do if you want to enable the pre-RA scheduling pass by default.

And there is still -fsched-pressure that you could try.

But I doubt you will get a patch approved to enable scheduling for 32-bits
ix86. The failure you are seeing can be triggered quite easily even _without_
scheduling enabled. Just search bugzilla for all the "unable to find spill
register" bugs on i386, this one is far from unique.

[Bug rtl-optimization/46793] -fschedule-insns causes ICE in compiling zlib/trees.c

[changpeng.fang at amd dot com]

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

--- Comment #2 from Changpeng Fang  2010-12-03 
20:52:11 UTC ---
This bug should be fixed.

We are trying to make -fschedule-insns default for x86, and this enablement
causes
bootstrapping failure at this point.

Of course we can work around this by just enabling it for 64 bit.

[Bug libffi/46792] libffi fails building for cris-elf

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

[Bug libffi/46792] libffi fails building for cris-elf

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  2010-12-03 
20:38:54 UTC ---
Author: hp
Date: Fri Dec  3 20:38:47 2010
New Revision: 167442

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167442
Log:
PR libffi/46792
* configure.ac (cris-*-elf, crisv32-*-elf): Disable target-libffi.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac

[Bug rtl-optimization/46793] -fschedule-insns causes ICE in compiling zlib/trees.c

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||steven at gcc dot gnu.org
 Resolution||WONTFIX

--- Comment #1 from Steven Bosscher  2010-12-03 
20:36:52 UTC ---
Try with -fsched-pressure?

But -fschedule-insns on 32-bits ix86 is a Really Bad Idea. There are plenty bug
reports for similar failures. There are just not enough registers and too many
special constraints. This is not a fixable issue, beyond keeping
-fschedule-insns disabled.

=> WONTFIX

[Bug rtl-optimization/46793] New: -fschedule-insns causes ICE in compiling zlib/trees.c

[changpeng.fang at amd dot com]

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

   Summary: -fschedule-insns causes ICE in compiling zlib/trees.c
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: changpeng.f...@amd.com


-fschedule-insns causes ICE in compiling zlib/trees.c: 
trees.c:701:1: error: unable to find a register to spill in class ‘Q_REGS’
This failure only occurs for -m32 compilation.

To reproduce:
cd trunk/zlib
gcc trees.c -c -o ~/tree.o -O2 -fschedule-insns -m32

[~/gcc-4.6-20101120/zlib]$ gcc trees.c -c -o ~/tree.o -O2 -fschedule-insns -m32
trees.c: In function ‘build_tree’:
trees.c:701:1: error: unable to find a register to spill in class ‘Q_REGS’
trees.c:701:1: error: this is the insn:
(insn 473 429 164 18 (set (subreg:SI (reg:QI 83 [ iftmp.7 ]) 0)
(if_then_else:SI (ltu (reg:CC 17 flags)
(const_int 0 [0]))
(subreg:SI (reg:QI 388) 0)
(subreg:SI (reg:QI 83 [ iftmp.7 ]) 0))) trees.c:677 854
{*movsicc_noc}
 (expr_list:REG_DEAD (reg:QI 388)
(expr_list:REG_DEAD (reg:CC 17 flags)
(nil
trees.c:701:1: internal compiler error: in spill_failure, at reload1.c:2105
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This should be a regression (I only know 4.3 is working)

[Bug libffi/46792] libffi fails building for cris-elf

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.12.03 20:21:50
 AssignedTo|unassigned at gcc dot   |hp at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug libffi/46792] New: libffi fails building for cris-elf

[hp at gcc dot gnu.org]

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

   Summary: libffi fails building for cris-elf
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
Target: cris-axis-elf


When support for CRIS v32 was added to the CRIS port, a "v32" multilib was
added to cris-elf.  Unfortunately, libffi wasn't updated, resulting in build
failure for the whole of gcc without special configure options:

libtool: compile:  /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostd\
inc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v32/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/\
v32/newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cr\
is-elf/v32/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/v32/libgloss/libnosys
-L/tmp/hpautotest-gcc1/g\
cc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -i\
system /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-inclu\
de -march=v32 -mbest-lib-options -DHAVE_CONFIG_H -I.
-I/tmp/hpautotest-gcc1/gcc/libffi -I. -I/tmp/hpautotest-gcc1/gcc/l\
ibffi/include -Iinclude -I/tmp/hpautotest-gcc1/gcc/libffi/src -I.
-I/tmp/hpautotest-gcc1/gcc/libffi/include -Iinclude -\
I/tmp/hpautotest-gcc1/gcc/libffi/src -g -O2 -MT src/cris/sysv.lo -MD -MP -MF
src/cris/.deps/sysv.Tpo -c /tmp/hpautotest\
-gcc1/gcc/libffi/src/cris/sysv.S -o src/cris/sysv.o
/tmp/hpautotest-gcc1/gcc/libffi/src/cris/sysv.S: Assembler messages:
/tmp/hpautotest-gcc1/gcc/libffi/src/cris/sysv.S:51: Error: Unknown opcode:
`push'

A temporary fix is to disable libffi for cris-elf. (No other action should be
necessary: cris-linux doesn't have a v32 multilib and the crisv32-* tuples
aren't matched by libffi configure.)
The correct fix is not that hard; there's a common assembly-language subset
used in other assembly codes, for example newlib+libgloss.
E.g. push R -> subq 4,$sp / move.d R,[$sp]
(equivalent in function, size and cycles except when condition codes need to be
preserved.)
I'll fix this the temporary way, then suspend the PR.

[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.

[mikestump at comcast dot net]

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

--- Comment #10 from Mike Stump  2010-12-03 
20:17:03 UTC ---
Jack says that some of the spurious warnings are fixed in Xcode 3.2.3.  I have
3.2.4 on my system.  Could you update Xcode and see if any we care about
remain.  If so, please file a Apple bug report.  If fixed, we can simply
require the newer Xcode.  If it won't work on darwin9, and we care, we could
have the .f addition in darwin10.h alone.  I don't favor the stripping, but I'g
go along with a darwin9 stripper and a darwin10 and later no strip version.

[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED

--- Comment #8 from Jason Merrill  2010-12-03 
20:09:50 UTC ---
Fixed.

[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  2010-12-03 
20:08:32 UTC ---
Author: jason
Date: Fri Dec  3 20:08:28 2010
New Revision: 167441

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167441
Log:
PR debug/46123
* dwarf2out.c (gen_type_die_with_usage): Don't put local types in
a declaration DIE.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr46123.C
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/debug/pr46123.C
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dwarf2out.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/46791] New: GCC fails on "for(struct { } f;;) ;", incorrectly treating it as a range-based for loop

[schaub-johannes at web dot de]

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

   Summary: GCC fails on "for(struct { } f;;) ;", incorrectly
treating it as a range-based for loop
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub-johan...@web.de


The following has worked correctly before, but doesn't work anymore with GCC's
range-based for-loop support enabled

void f() {
for(struct { } f;;) ;
}

error: types may not be defined in range-based for loops

Structs in the initial part of the for loop can be useful and they are broken
by that diagnostic.

[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #20817|0   |1
is obsolete||

--- Comment #15 from Jonathan Wakely  2010-12-03 
19:07:03 UTC ---
Created attachment 22623
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22623
updated -Wmeminit patch for trunk (4.6.0)

[Bug c++/46645] [4.6 Regression] FAIL: 20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jason Merrill  2010-12-03 
18:45:15 UTC ---
Fixed.

[Bug c++/46058] [4.5/4.6 Regression] gcc crashes with lvalue error on the following Code

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jason Merrill  2010-12-03 
18:44:31 UTC ---
Fixed.

[Bug c++/46058] [4.5/4.6 Regression] gcc crashes with lvalue error on the following Code

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2010-12-03 
18:44:07 UTC ---
Author: jason
Date: Fri Dec  3 18:44:04 2010
New Revision: 167438

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167438
Log:
PR c++/46058
* tree.c (lvalue_kind) [SCOPE_REF]: Handle non-dependent case.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/scope4.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/tree.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug c++/45822] [4.6-regression] Qt 4.7.0 build fails

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #6 from Kai Tietz  2010-12-03 18:41:47 
UTC ---
Hmm, it seems that type "Enum' isn't automatical converted to 'int' anymore.
Does it help to add to template class QFlags the following constructor 'inline
QFlags(int f) : i((Enum)f) {}' ?

[Bug middle-end/46790] New: [4.6 regression] EH failures in libstdc++ testsuite with --gc-sections and GNU ld 2.18

[jason at gcc dot gnu.org]

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

   Summary: [4.6 regression] EH failures in libstdc++ testsuite
with --gc-sections and GNU ld 2.18
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
Target: x86_64-unknown-linux-gnu


Starting with r167085, test runs on gcc10.fsffrance.org have had a bunch of
failures in the libstdc++ testsuite; the testcases fail with calls to
terminate() because exceptions are not handled properly.  This seems to be due
to .gcc_except_table being thrown away by --gc-sections, which in turn seems to
be due to the change in the name of text subsections; .text.startup.main no
longer matches .gcc_except_table.main, so the heuristic that ld 2.18 uses to
keep .gcc_except_table hunks breaks.

One test that fails is 18_support/uncaught_exception/14026.cc.

[Bug lto/46769] LTO failed to build gold

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2010-12-03 18:28:58 
UTC ---
Created attachment 22622
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22622
A testcase

/usr/gcc-4.6/bin/g++ -r -W -Wall -flto-partition=none   -Werror
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=ld-new -g -O2
-flto=jobserver -fuse-linker-plugin -frandom-seed=1   -o ld-new i386.ii
-nostdlib
In file included from :867:0:
/export/gnu/import/git/binutils/gold/icf.h: In member function ‘__base_dtor ’:
/export/gnu/import/git/binutils/gold/icf.h:62:5: internal compiler error: in
force_type_die, at dwarf2out.c:20704
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/gcc-4.6/bin/g++ returned 1 exit status

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|WAITING |REOPENED

--- Comment #24 from Jorn Wolfgang Rennecke  
2010-12-03 18:15:18 UTC ---
(In reply to comment #23)
> Yes, it is. In fact, I downloaded it from
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101113/. The exact name of the
> snapshot is gcc-4.6-20101113.tar.bz2.

So the problem is that when building from an untarred snapshot / release,
CRLF translation might have been applied - unlike with svn, where you see
wxactly what is in the repository.

I suppose we should make a copy of $(srcdir)/doc/tm.texi with \r removed as
well, so that the comparison can succeed no matter if \r has been inserted or
not.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

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

--- Comment #23 from Anh Vo  2010-12-03 18:08:27 
UTC ---
Yes, it is. In fact, I downloaded it from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20101113/. The exact name of the
snapshot is gcc-4.6-20101113.tar.bz2.

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[amylaar at gcc dot gnu.org]

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

--- Comment #22 from Jorn Wolfgang Rennecke  
2010-12-03 17:57:22 UTC ---
(In reply to comment #21)
> Executing command 'file gcc/doc/tm.texi' yields
> ../gcc-4.6-20101113/gcc/doc/tm.texi: ASCII English text, with CRLF line
> terminators. 

So, does your source come from untarring a snapshot?

[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken

[anhvofrcaus at gmail dot com]

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

--- Comment #21 from Anh Vo  2010-12-03 17:45:58 
UTC ---
Executing command 'file gcc/doc/tm.texi' yields
../gcc-4.6-20101113/gcc/doc/tm.texi: ASCII English text, with CRLF line
terminators. 

However, executing command 'file gcc/tm.texi' in the build directory outputs
gcc/tm.texi: ASCII English text, with very long lines.

Obviously, the results are not the same.

[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #6 from dave at hiauly1 dot hia.nrc.ca 2010-12-03 17:22:07 UTC ---
On Fri, 03 Dec 2010, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671
> 
> --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> 2010-12-03 15:21:51 UTC ---
> Jan, your patch has broken bootstrap on two platforms for a week now,
> and there's not even an indication that you're looking at the problem.
> Please fix or revert ASAP.

The implementation of default_function_section in the change is elf
specific.  As a result, all targets that don't use elf sections are broken
by the change.  Even if I define TARGET_ASM_FUNCTION_SECTION, this
will still leave the other targets that don't use elf sections broken.
Elf sections were never the default before.

The change was applied during stage3 and it wasn't a bug fix.  So, the
commit was questionable.

Dave

[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2010-12-03 
16:56:59 UTC ---
Author: jason
Date: Fri Dec  3 16:56:53 2010
New Revision: 167436

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167436
Log:
PR debug/46123
* dwarf2out.c (gen_tagged_type_die): Don't put local types in
a declaration DIE.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr46123.C
trunk/gcc/testsuite/g++.dg/debug/pr46123.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/46058] [4.5/4.6 Regression] gcc crashes with lvalue error on the following Code

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2010-12-03 
16:56:42 UTC ---
Author: jason
Date: Fri Dec  3 16:56:37 2010
New Revision: 167435

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167435
Log:
PR c++/46058
* tree.c (lvalue_kind) [SCOPE_REF]: Handle non-dependent case.

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

[Bug lto/45638] No rule to make target `check-lto', needed by `check'. Stop.

[rwild at gcc dot gnu.org]

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

Ralf Wildenhues  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Ralf Wildenhues  2010-12-03 
16:54:24 UTC ---
Fixed, as far as I can see.

[Bug middle-end/46761] [4.6 Regression] -fgraphite-identity produces wrong code for array initialization arr[i] = i

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  2010-12-03 
16:54:26 UTC ---
Sometimes graphite generates wrong guards for regions.  The following patch
fixes the attached testcase for me, but I have not tested it any further.

diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 9a90ef7..8a80033 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -986,7 +986,7 @@ graphite_create_new_loop_guard (sese region, edge
entry_edge,
  : PLUS_EXPR, type, ub, one);

   /* When ub + 1 wraps around, use lb <= ub.  */
-  if (integer_zerop (ub_one))
+  if (TREE_OVERFLOW_P (ub_one))
 cond_expr = fold_build2 (LE_EXPR, boolean_type_node, lb, ub);
   else
 cond_expr = fold_build2 (LT_EXPR, boolean_type_node, lb, ub_one);

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu  2010-12-03 16:40:25 
UTC ---
(In reply to comment #15)
> I understand the issue now. Stock r167430 is fine but the addition of the
> approved patch to fix the md files and default i386 darwin to -mtune=core2
> causes the failure in...
> 
> FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq
> 
> Apparently the darwin core2 patch will also need to correct the
> sse2-init-v2di-2.c testcase with...
> 
> Index: gcc.target/i386/sse2-init-v2di-2.c
> ===
> --- gcc.target/i386/sse2-init-v2di-2.c(revision 167430)
> +++ gcc.target/i386/sse2-init-v2di-2.c(working copy)
> @@ -10,4 +10,4 @@
>return _mm_cvtsi64_si128 (b); 
>  }
> 
> -/* { dg-final { scan-assembler "movq" } } */
> +/* { dg-final { scan-assembler "movd" } } */

That is incorrect. I will fix it properly after Dwarn patch is checked in.

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #16 from Jack Howarth  2010-12-03 
16:29:31 UTC ---
Note the original i386 darwin patch with the rational for the movq to movd
assembly changes can be found at
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01024.html.

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #15 from Jack Howarth  2010-12-03 
16:27:52 UTC ---
I understand the issue now. Stock r167430 is fine but the addition of the
approved patch to fix the md files and default i386 darwin to -mtune=core2
causes the failure in...

FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq

Apparently the darwin core2 patch will also need to correct the
sse2-init-v2di-2.c testcase with...

Index: gcc.target/i386/sse2-init-v2di-2.c
===
--- gcc.target/i386/sse2-init-v2di-2.c(revision 167430)
+++ gcc.target/i386/sse2-init-v2di-2.c(working copy)
@@ -10,4 +10,4 @@
   return _mm_cvtsi64_si128 (b); 
 }

-/* { dg-final { scan-assembler "movq" } } */
+/* { dg-final { scan-assembler "movd" } } */

[Bug preprocessor/46784] Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.12.03 16:27:51
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2010-12-03 
16:27:51 UTC ---
Also you need to provide preprocessed source for cairo-bentley-ottmann.c and
the output of appending -v to the gcc command-line that causes the internal
compiler error.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-12-03 
16:25:40 UTC ---
Please report to CodeSourcery or use a FSF version.

[Bug lto/46769] LTO failed to build gold

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Richard Guenther  2010-12-03 
16:24:25 UTC ---
Can you use partial linking and reduce the set of object files (best when
reproducing with -flto-partition=none) and then attach preprocessed sources
of them?

LTO object code testcases are not very useful.

Thanks,
Richard.

[Bug middle-end/46745] [4.6 Regression] '#'mem_ref' not supported by dump_expr#'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2010-12-03 
16:23:00 UTC ---
Fixed.

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #14 from Jack Howarth  2010-12-03 
16:22:05 UTC ---
Created attachment 22621
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22621
darwin core2 patch

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #13 from Jack Howarth  2010-12-03 
16:20:59 UTC ---
Created attachment 22620
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22620
assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10
at r167430 with darwin core2 patch

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #12 from Jack Howarth  2010-12-03 
16:20:12 UTC ---
Created attachment 22619
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22619
assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10
at r167430

[Bug middle-end/46745] [4.6 Regression] '#'mem_ref' not supported by dump_expr#'

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-12-03 
16:10:43 UTC ---
Author: rguenth
Date: Fri Dec  3 16:10:36 2010
New Revision: 167433

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167433
Log:
2010-12-03  Richard Guenther  

PR c/46745
* c-pretty-print.c (pp_c_postfix_expression): Handle MEM_REF.
(pp_c_unary_expression): Likewise.
(pp_c_expression): Likewise.

cp/
* error.c (dump_expr): Handle MEM_REF.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pretty-print.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c

[Bug fortran/44352] ICE in string_to_single_character

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  2010-12-03 
15:55:42 UTC ---
This works:

  character*2 ddname,dname
  dname(x)=   'x '
  ddname=dname(0.0)
  END

We fail to pad the string for this case.

[Bug other/46789] New: go configuration with --prefix=/usr pollutes the /usr/lib namespace

[doko at ubuntu dot com]

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

   Summary: go configuration with --prefix=/usr pollutes the
/usr/lib namespace
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@ubuntu.com


[go/libgo components missing in the bug tracker]

with --prefix=/usr libgo "pollutes" /usr/lib ? is there a recommended way to
install the runtime into something like /usr/lib/go? or /usr/lib/go-

 - the .gox files maybe should go to /usr/lib/go or
   /usr/lib/go-, so that you can have parallel
   installations of different GCC versions with the
   same prefix. libjava is doing this too.

 - libgobegin.a maybe should installed into gcc_lib_dir?

[Bug lto/46769] LTO failed to build gold

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from H.J. Lu  2010-12-03 15:42:47 
UTC ---
From

http://www.kernel.org/pub/linux/devel/gcc/lto/ld-new.ltrans1.o.bz2

[...@gnu-6 gold]$ /usr/gcc-4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto1
-quiet -dumpdir ./ -dumpbase ld-new.ltrans1 -mtune=generic -march=x86-64
-auxbase-strip ld-new.ltrans1.ltrans.o -g -O2 -Wextra -Wall -Werror -version
-frandom-seed=ld-new -fuse-linker-plugin -frandom-seed=1 -fltrans
ld-new.ltrans1.o -o ld-new.ltrans1.s
GNU GIMPLE (GCC) version 4.6.0 20101202 (experimental) [trunk revision 167368]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101202 (experimental) [trunk revision
167368], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU GIMPLE (GCC) version 4.6.0 20101202 (experimental) [trunk revision 167368]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20101202 (experimental) [trunk revision
167368], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
In file included from /export/gnu/import/git/binutils/gold/options.h:7421:0,
 from :6349:
/export/gnu/import/git/binutils/gold/icf.h: In member function
\u2018__base_dtor \u2019:
/export/gnu/import/git/binutils/gold/icf.h:62:0: internal compiler error: in
force_type_die, at dwarf2out.c:20704
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-6 gold]$

[Bug tree-optimization/46785] Doesn't vectorize reduction x += y*y

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-12-03 
15:39:49 UTC ---
Btw, I wonder why we bother to check the defs at all and not just do

 def1 && flow_bb_inside_loop_p (loop, gimple_bb (def1))

we should be able to handle all vectorizable reduction operands, and
their vectorizability will be determined anyway.

[Bug tree-optimization/46781] [4.6 Regression] Missing optimization

[d.g.gorbachev at gmail dot com]

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

Dmitry Gorbachev  changed:

   What|Removed |Added

  Attachment #22612|application/octet-stream|text/plain
  mime type||

--- Comment #3 from Dmitry Gorbachev  
2010-12-03 15:39:16 UTC ---
Comment on attachment 22612
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22612
Code produced by GCC 4.6.0

(In reply to comment #2)
> Where did you get this testcase from?

May I know why do you ask?

IIRC, it was distilled from some large program. There was a difference when
compiling it with and without LTO, and I reported it as a bug 43201.

[Bug libstdc++/45133] [c++0x] std::future will crash with NULL deref if get() is called twice

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED

--- Comment #5 from Jonathan Wakely  2010-12-03 
15:38:53 UTC ---
The latest draft still says this is undefined behaviour, but has a note
encouraging implementations to detect this case and throw.  I am suitably
encouraged.

I'll start by doing that conditionally when _GLIBCXX_DEBUG is defined...

[Bug c/46788] New: unsigned int possible treated as signed in a union/struct

[tinokrauss at web dot de]

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

   Summary: unsigned int possible treated as signed in a
union/struct
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tinokra...@web.de


Created attachment 22618
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22618
a module

When compiling the attached file the compiler does not warn, but the assambler
gives the following error:
C:\DOKUME~1\tkr\LOKALE~1\Temp\ccqr1SmQ.s: Assembler messages:
C:\DOKUME~1\tkr\LOKALE~1\Temp\ccqr1SmQ.s:522: Error: immediate value out of
range -- `movt r3,-32768'
The line "dwCalcVal.u_16_values.u_16_value_1=0x8000u;" causes the error.
It looks to me like a singned-unsigned fault and in fact it is so. reducing the
constant to a value 0x till 0x7FFF will compile without error.
The problem appears also only when:
- the value is at the stack (local)
- the second value in struct is used (u_16_value_0 works fine).
GCC v 4.3.3 also works fine on the same code.

Configuarion:
-
PC Windows XP with Codesourcery, Target STM32F103 ARM-Controller
>arm-none-eabi-gcc.exe -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc.exe
COLLECT_LTO_WRAPPER=c:/temp/codesourcery/bin/../libexec/gcc/arm-none-eabi/4.5.1/lto-wrapper.exe
Target: arm-none-eabi
Configured with:
/scratch/julian/2010q3-release-eabi-lite/src/gcc-4.5-2010.09/configure
--build=i686-pc-linux-gnu --host=i686-mingw32 --target=arm-none-eabi
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--enable-extra-sgxxlite-multilibs --with-gnu-as --with-gnu-ld
--with-specs='%{save-temps: -fverbose-asm} -D__CS_SOURCERYGXX_MAJ__=2010
-D__CS_SOURCERYGXX_MIN__=9 -D__CS_SOURCERYGXX_REV__=51
%{O2:%{!fno-remove-local-statics: -fremove-local-statics}}
%{O*:%{O|O0|O1|O2|Os:;:%{!fno-remove-local-statics: -fremove-local-statics}}}'
--enable-languages=c,c++ --disable-s
hared --enable-lto --with-newlib --with-pkgversion='Sourcery G++ Lite
2010.09-51' --with-bugurl=https://support.codesourcery.com/GNUToolchain/
--disable-nls --prefix=/opt/codesourcery --with-headers=yes
--with-sysroot=/opt/codesourcery/arm-none-eabi
--with-build-sysroot=/scratch/julian/2010q3-release-eabi-lite/install/host-i686-mingw32/arm-none-eabi
--with-libiconv-prefix=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-gmp=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-mpfr=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-mpc=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-ppl=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lst dc++,-Bdynamic -lm'
--with-cloog=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--with-libelf=/scratch/julian/2010q3-release-eabi-lite/obj/host-libs-2010.09-51-arm-none-eabi-i686-mingw32/usr
--disable-libgomp --enable-poison-system-directories
--with-build-time-tools=/scratch/julian/2010q3-release-eabi-lite/obj/tools-i686-pc-linux-gnu-2010.09-51-arm-none-eabi-i686-mingw32/arm-none-eabi/bin
--with-build-time-tools=/scratch/julian/2010q3-release-eabi-lite/obj/tools-i686-pc-linux-gnu-2010.09-51-arm-none-eabi-i686-mingw32/arm-none-eabi/bin
Thread model: single
gcc version 4.5.1 (Sourcery G++ Lite 2010.09-51)


Call-Parameters:

COLLECT_GCC_OPTIONS='-c' '-mcpu=cortex-m3' '-mthumb' '-mtune=cortex-m3'
'-mfix-cortex-m3-ldrd' '-mlong-calls' '-pedantic' '-mfpu=vfp'
'-mfloat-abi=soft' '-nostdinc' '-Os' '-DLITTLE_ENDIAN' '-v' '-gdwarf-2'
'-fmessage-length=0' '-mlittle-endian' '-fshort-enums' '-mno-thumb-interwork'
'-mstructure-size-boundary=8' '-fno-builtin' '-funsigned-bitfields'
'-Wcast-align' '-Wreturn-type' '-Wimplicit' '-Wunused' '-Wswitch'
'-Wuninitialized' '-o' 'E:\workspace_tkr\FSD-ELMA\trunk\out/SA1/ALGAac1.o'
'-D__CS_SOURCERYGXX_MAJ__=2010' '-D__CS_SOURCERYGXX_MIN__=9'
'-D__CS_SOURCERYGXX_REV__=51'
e:/toolhome/arm/codesourcery/v_4_5_1/bin/../lib/gcc/arm-none-eabi/4.5.1/../../../../arm-none-eabi/bin/as.exe
-v -EL -mcpu=cortex-m3 -mfloat-abi=soft -mfpu=vfp -meabi=5 -alhcdn -o
E:\workspace_tkr\FSD-ELMA\trunk\out/SA1/ALGAac1.o
C:\DOKUME~1\tkr\LOKALE~1\Temp\ccqr1SmQ.s
GNU assembler version 2.20.51 (arm-none-eabi) using BFD version (Sourcery G++
Lite 2010.09-51) 2.20.51.20100809

[Bug tree-optimization/46787] Does not vectorize loop with load from scalar variable

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2010-12-03 
15:37:16 UTC ---
To fix:

  /* FIXME -- data dependence analysis does not work correctly for objects
 with invariant addresses in loop nests.  Let us fail here until the
 problem is fixed.  */
  if (dr_address_invariant_p (dr) && nest)
{
  free_data_ref (dr);
  if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "\tFAILED as dr address is invariant\n");
  ret = false;
  break;
}

for this to work and be a real improvement we need to pass down the
minimum iterations of the loop (thus, the minimum vectorization factor
in case of the vectorizer).

We can also fix it up locally in the vectorizer when
compute_data_dependences_for_loop would not re-scan the loop
for data references (but we'd do it in the vectorizer and remove
the scalar loads).

We can also avoid computing data dependences until
vect_analyze_data_ref_dependences then and save some compile-time for
non-vectorized loops.

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  2010-12-03 15:34:10 
UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > Created attachment 22616 [details] [details] [details]
> > > assembly file from gcc.target/i386/sse2-init-v2di-2.c on 
> > > x86_64-apple-darwin10
> > > at r167375
> > 
> > It was fixed by revision 167398.  Why do you use r167375?
> 
> Since it still occurs in r167400 on darwin, the difference between r167372  
> and
> r167375 should capture the assembly changes with the absent movq in
> sse2-init-v2di-2.s on x86_64-apple-darwin10.

I don't need to see the assembly code to know revision 167375 is bad.  
Please show the output from revision 167398 or above.

[Bug tree-optimization/46787] New: Does not vectorize loop with load from scalar variable

[rguenth at gcc dot gnu.org]

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

   Summary: Does not vectorize loop with load from scalar variable
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: i...@gcc.gnu.org


When looking at why GCC is so slow with the himeno benchmark in the usual
Phoronix testing I noticed that we do not vectorize

float *x;
float parm;
float
test (int start, int end)
{
  int i;
  for (i = start; i < end; ++i)
{
  float tem = x[i];
  x[i] = parm * tem;
}
}

because there is a scalar non-varying load of parm that, when the loop
rolls just a single time is aliased by the store to x[i].

We are though vectorizing with at least a vectorization factor of two,
which means that x cannot validly point to parm (and a vector store
would exceed the scalar variables size, something that after vectorization
alias-analysis would use to disambiguate the vector store and the load).

Thus we can treat loads of scalar decls as if they were done outside of
the loop and vectorize it as

 D.1234_3 = tem;
 vec_tmp_4 = { D.1234_3, D.1234_3 };

thus, as if D.1234_3 were a vect_external_def and mark the statement
itself as not relevant.

[Bug middle-end/46758] [4.5/4.6 Regression] -fgraphite-identity produces wrong code when using 64bit constants

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.03 15:27:13
 CC||amonakov at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Alexander Monakov  2010-12-03 
15:27:13 UTC ---
In this particular example, the problem is in scan_tree_for_params_int:

  int v = int_cst_value (cst);

  mpz_init (val);
  mpz_set_si (val, 0);

  /* Necessary to not get "-1 = 2^n - 1". */
  if (v < 0)
mpz_sub_ui (val, val, -v);
  else
mpz_add_ui (val, val, v);

(gdb) p cst
$8 = (tree) 0x75a4e848
(gdb) pt
 
constant -8589934593>
(gdb) p v
$9 = -1
(gdb) 

There are multiple places where graphite uses int_cst_value.  Note that the
problem may be more severe on 32-bit hosts as there the tree may hold a 64-bit
constant but mpz_*_{u,s}i accepts 'long's.

[Bug preprocessor/46784] Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges'

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  2010-12-03 
15:26:32 UTC ---
gcc-3.4.6 is no longer supported upstream.  Please upgrade to gcc-4.4 or
gcc-4.5.

[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-12-03 15:21:51 UTC ---
Jan, your patch has broken bootstrap on two platforms for a week now,
and there's not even an indication that you're looking at the problem.
Please fix or revert ASAP.

Rainer

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #10 from Jack Howarth  2010-12-03 
15:21:12 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Created attachment 22616 [details] [details]
> > assembly file from gcc.target/i386/sse2-init-v2di-2.c on 
> > x86_64-apple-darwin10
> > at r167375
> 
> It was fixed by revision 167398.  Why do you use r167375?

Since it still occurs in r167400 on darwin, the difference between r167372  and
r167375 should capture the assembly changes with the absent movq in
sse2-init-v2di-2.s on x86_64-apple-darwin10.

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  2010-12-03 15:06:31 
UTC ---
(In reply to comment #8)
> Created attachment 22616 [details]
> assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10
> at r167375

It was fixed by revision 167398.  Why do you use r167375?

[Bug rtl-optimization/46777] [4.5/4.6 Regression] ICE: in rtl_verify_flow_info, at cfgrtl.c:2164 with -O -fgcse -fno-tree-dominator-opts -funroll-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.12.03 15:03:28
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2010-12-03 15:03:28 
UTC ---
It was introduced by revision 146848:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01491.html

[Bug middle-end/46786] New: ICE: verify_stmts failed: statement marked for throw, but doesn't with -fopenmp -fnon-call-exceptions

[zsojka at seznam dot cz]

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

   Summary: ICE: verify_stmts failed: statement marked for throw,
but doesn't with -fopenmp -fnon-call-exceptions
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O -fopenmp -fexceptions -fnon-call-exceptions pr46786.c 
pr46786.c: In function 'foo._omp_fn.0':
pr46786.c:5:9: error: statement marked for throw, but doesn't
.omp_data_i__a_lsm.7_9 = D.2714_8;

pr46786.c:5:9: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r167383 - crash
4.5 r166509 - crash
4.4 r166509 - crash

[Bug tree-optimization/46785] New: Doesn't vectorize reduction x += y*y

[rguenth at gcc dot gnu.org]

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

   Summary: Doesn't vectorize reduction x += y*y
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: i...@gcc.gnu.org


When looking at why GCC is so slow with the himeno benchmark in the usual
Phoronix testing I noticed that we do not vectorize the reduction in

float x[1024];
float
test (void)
{
  int i;
  float gosa = 0.0;
  for (i = 0; i < 1024; ++i)
{
  float tem = x[i];
  gosa += tem * tem;
}
  return gosa;
}

because at analysis time we have

D.3171_6 = __builtin_powf (tem_5, 2.0e+0);

as the def for the addition which doesn't satisfy is_gimple_assign
nor any of the vinfo tests:

$3 = {type = undef_vec_info_type, live = 0 '\000', in_pattern_p = 0 '\000', 
  read_write_dep = 0 '\000', stmt = 0x77edc908, loop_vinfo = 0x18f77e0, 
  vectype = 0x0, vectorized_stmt = 0x0, data_ref_info = 0x0, 
  dr_base_address = 0x0, dr_init = 0x0, dr_offset = 0x0, dr_step = 0x0, 
  dr_aligned_to = 0x0, related_stmt = 0x0, same_align_refs = 0x18cf7f0, 
  def_type = vect_internal_def, slp_type = loop_vect, first_dr = 0x0, 
  next_dr = 0x0, same_dr_stmt = 0x0, size = 0, store_count = 0, gap = 0, 
  relevant = vect_unused_in_scope, cost = {outside_of_loop = 0, 
inside_of_loop = 0}, bb_vinfo = 0x0, vectorizable = 1 '\001'}

As we want to allow internal defs we can also just let calls slip through
here (so we vectorize reductions with veclib vectorized calls as well).

Ira?

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth  2010-12-03 
14:50:21 UTC ---
Created attachment 22616
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22616
assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10
at r167375

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth  2010-12-03 
14:49:40 UTC ---
Created attachment 22615
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22615
assembly file from gcc.target/i386/sse2-init-v2di-2.c on x86_64-apple-darwin10
at r167372

Generated with...

/Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/
/Users/howarth/gcc/gcc/testsuite/gcc.target/i386/sse2-init-v2di-2.c -O2 -msse4
-march=core2 -S -m64 -o sse2-init-v2di-2.s

[Bug target/39501] -O -ffinite-math-only gets min(x,y) optimization wrong for soft-float on arm-*-gnueabi

[martinwguy at gmail dot com]

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

--- Comment #17 from Martin Guy  2010-12-03 
14:46:28 UTC ---
Sort of. The cause of the bug was never found, and the workaround is to disable
an instruction.  It might be worth trying enabling movsfcc in current GCC and
re-running the tests, since the conditional execution stuff in the middle end
was rewritten between 4.3 and 4.4 if I remember correctly, so the actual bug in
the middle end may have gone away with that rewrite.

[Bug target/46768] [4.6 Regression] FAIL: gcc.target/i386/pr37434-[24].c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #6 from H.J. Lu  2010-12-03 14:34:35 
UTC ---
(In reply to comment #4)
> On x86_64-apple-darwin10 at r167400, we are still failing...
> 
> FAIL: gcc.target/i386/sse2-init-v2di-2.c scan-assembler movq
> 
> at -m64.

Works for me with a x86_64-apple-darwin10 cross compiler with revision 167416:

.globl _test
_test:
LFB516:
movq%rdi, %xmm0
ret
LFE516:
.section __TEXT,__eh_frame,coale

[Bug preprocessor/46784] New: Internal compiler error with cairo In function `_cairo_bo_sweep_line_compare_edges'

[r_no at hotmail dot com]

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

   Summary: Internal compiler error with cairo In function
`_cairo_bo_sweep_line_compare_edges'
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@hotmail.com


During a compilation of Cairo 1.10 I got the following error:
make[3]: Entering directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0/src'
  CC cairo-analysis-surface.lo
  CC cairo-arc.lo
  CC cairo-array.lo
  CC cairo-atomic.lo
  CC cairo-base64-stream.lo
  CC cairo-base85-stream.lo
  CC cairo-bentley-ottmann.lo
cairo-bentley-ottmann.c: In function `_cairo_bo_sweep_line_compare_edges':
cairo-bentley-ottmann.c:424: internal compiler error: in expand_mult, at
expmed.c:2653
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [cairo-bentley-ottmann.lo] Error 1
make[3]: Leaving directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/install/src/rrdtool-1.4.4/build/cairo-1.10.0'
make: *** [all] Error 2


so as good boy I open a bug report !!
SunOS mrtg 5.10 Generic_142909-17 on Sparc T-5120 with LDOM 1.3
pkg-config 0.25
fontconfig-2.4.2
pixman 0.21.2
cairo 1.10
gcc:
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6

Cairo config.sh option:
./configure --prefix=$INSTALL_DIR --enable-xlib=no --enable-xlib-render=no
--enable-win32=no CFLAGS="-O3 -fPIC -D_POSIX_PTHREAD_SEMANTICS"


I have no more clue what I suppose to give you in this case !

[Bug target/46779] wrong code generation for array access

[mschulze at ivs dot cs.ovgu.de]

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

--- Comment #4 from Michael Schulze  2010-12-03 
14:16:30 UTC ---
> I don't know anything about AVR, so I can't say that (I just noticed the r1
> issue).
Ok due to the compiler abi for the avr, r0,r1 are fixed registers that are
never allocated by gcc for local data, but often used for fixed purposes. r0 is
a temporary register that may be globbered by any C-code. r1 is assumed to be
always zero in any C-code. This is the reason, why it is cleared at the end of
the inline assembler.

[Bug fortran/46783] New: [OOP] TRANSFER with polymorphic MOLD=

[burnus at gcc dot gnu.org]

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

   Summary: [OOP] TRANSFER with polymorphic MOLD=
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Cf. http://j3-fortran.org/pipermail/j3/2010-December/004026.html

Currently, the declared type is used for MOLD= in TRANSFER. It seems as if the
effective type should be used instead.


This is a tracker bug as the standard is a bit ambiguous about it; I assume
that there will be an IR (interpretation request) about it.


Currently, F2008 just has:

MOLD shall be a scalar or array of any type. If it is a variable, it need not
be defined.

Result Characteristics. The result is of the same type and type parameters as
MOLD.

[Bug debug/46782] New: -fcompare-debug failure (length) with -fvar-tracking

[zsojka at seznam dot cz]

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

   Summary: -fcompare-debug failure (length) with -fvar-tracking
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: aol...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -fvar-tracking -fcompare-debug pr46782.c 
pr46782.c:1:0: warning: variable tracking requested, but useless unless
producing debug info [enabled by default]
gcc: error: pr46782.c: -fcompare-debug failure (length)

Fail with -g as well.

Tested revisions:
r167356 - fail
r153685 - fail
4.5 r166509 - fail