[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #22 from Kai Tietz ktietz at gcc dot gnu.org 2011-02-07 08:20:59 UTC --- Author: ktietz Date: Mon Feb 7 08:20:56 2011 New Revision: 169877 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169877 Log: 2011-02-07 Kai Tietz kai.ti...@onevision.com PR lto/47225 * Makefile.am (Wl): New helper for encoding -Wl,. (liblto_plugin_la_LIBADD): Use -Wl for libiberty library. * Makefile.in: Regenerated. Modified: trunk/lto-plugin/ChangeLog trunk/lto-plugin/Makefile.am trunk/lto-plugin/Makefile.in
Re: [Bug ada/36939] Build Failure Ada SH2e
With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds Ada. Is this OK to commit? Note that the proper place to submit a patch officially is gcc-patches. In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to have target specific implementations, or stubbed implementation, that's a kludge which is not really acceptable for mainstream. Arno
[Bug ada/36939] Build Failure Ada SH2e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939 --- Comment #17 from charlet at adacore dot com charlet at adacore dot com 2011-02-07 09:04:18 UTC --- With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds Ada. Is this OK to commit? Note that the proper place to submit a patch officially is gcc-patches. In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to have target specific implementations, or stubbed implementation, that's a kludge which is not really acceptable for mainstream. Arno
[Bug rtl-optimization/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47620 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07 09:04:52 UTC --- Reverting the r169513 change fixes the ICE. To reproduce, just a --target=powerpc64-linux --enable-languages=c cross is enough, no need to bother with cross-binutils etc. Alex, could you please have a look at this?
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-07 09:17:08 UTC --- known issue, the fix changes the ABI and so can't be done yet N.B. N3225 is the current draft
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-07 09:30:42 UTC --- Oops, I think I'm confusing this with another related issue - despite what I said we do seem to have changed the signature, and we currently implement the C++0x draft spec. Tables 99 and 100 say erase takes a const_iterator, so does the synopsis of each container
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |ktietz at gcc dot gnu.org |gnu.org | --- Comment #23 from Thomas Schwinge tschwinge at gcc dot gnu.org 2011-02-07 09:43:59 UTC --- Kai? make[1]: Entering directory `/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc.obj/lto-plugin' /bin/sh ./libtool --tag=CC --tag=disable-static --mode=compile gcc -DHAVE_CONFIG_H -I. -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 -c -o lto-plugin.lo /home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/lto-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 -c /home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o make[1]: *** No rule to make target `-Wl,../libiberty/pic/libiberty.a', needed by `liblto_plugin.la'. Stop. make[1]: Leaving directory `/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc.obj/lto-plugin'
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #24 from Paolo Bonzini bonzini at gnu dot org 2011-02-07 09:48:42 UTC --- Please use LDFLAGS, not LIBADD.
[Bug tree-optimization/47615] [4.6 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 10:10:04 UTC --- Huh. Mine.
[Bug tree-optimization/47255] Missed CSE optimization with inline functions, and __attribute__((const))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47255 Paolo Bonzini bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #4 from Paolo Bonzini bonzini at gnu dot org 2011-02-07 10:57:54 UTC --- I think this is invalid. const attributes are a hint to GCC regarding parts of the program that it cannot see, but IMHO the const/pure/nothrow on a function that is static and a leaf should have no effect on code generation (since GCC can infer just as much). So, in the first example GCC is fixing a wrong usage of const on part of the program. In the second example attached, there is no use of syscalls and GCC properly optimizes out square2 and square3. If syscalls were added, the bug would be about missed attributes on the syscalls. BTW, getgid, getuid etc. are pure but not const.
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-07 10:58:20 UTC --- Indeed, in mainline, would be 4.6.0, we are already doing the right thing vs N3225, there is nothing to fix here.
[Bug target/47629] New: gcc.target/i386/pr47312.c fails to link on Solaris 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47629 Summary: gcc.target/i386/pr47312.c fails to link on Solaris 9 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ja...@redhat.com Host: i386-pc-solaris2.9 Target: i386-pc-solaris2.9 Build: i386-pc-solaris2.9 The new gcc.target/i386/pr47312.c testcase FAILs on Solaris 9/x86: +FAIL: gcc.target/i386/pr47312.c (test for excess errors) Excess errors: Undefined first referenced symbol in file fma /var/tmp//cckpBC57.o fmaf/var/tmp//cckpBC57.o fmal/var/tmp//cckpBC57.o ld: fatal: Symbol referencing errors. No output written to pr47312.exe Unlike Solaris 10+, Solaris 9 lacks fma* in libm. Perhaps this is a case for dg-require-effective-target c99_runtime?
[Bug lto/47625] FAIL: gcc.dg/guality/pr43077-1.c -O2 -flto -flto-partition=none line 42 a == 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47625 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 11:35:11 UTC --- Huh, there isn't even such a union in the testcase ;) On x86_64-linux for this testcase I get FAIL: gcc.dg/guality/pr43077-1.c -O2 -flto -flto-partition=none line 42 varb == 2 FAIL: gcc.dg/guality/pr43077-1.c -O2 -flto line 11 varb == 2 FAIL: gcc.dg/guality/pr43077-1.c -O2 -flto line 19 varb == 3 FAIL: gcc.dg/guality/pr43077-1.c -O2 -flto line 42 varb == 2 instead. That said, there are numerous known issues with debug support and LTO, but most of the guality fails would be nice to have analyzed as C debug support should be basically complete.
[Bug rtl-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-02/msg00301.htm ||l --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org 2011-02-07 11:35:52 UTC --- Link to proposed new patch. Looks like 4.7 material.
[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47624 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 11:42:28 UTC --- In the .optimized dump I see the exact same IL with/without -flto (yes, including debug stmts and locations).
[Bug debug/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web Web oldreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug target/47617] SSE rounding mode works -g, not -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47617 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-linux Status|UNCONFIRMED |WAITING Last reconfirmed||2011.02.07 11:52:28 Component|c |target Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 11:52:28 UTC --- Can you provide non-preprocessed source? I have difficulties in compiling with newer releases.
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Target Milestone|--- |4.6.0 Summary|cpu2000 benchmark 301.apsi |[4.6 Regression] cpu2000 |fails with revision 169782 |benchmark 301.apsi fails ||with revision 169782 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 11:54:13 UTC --- Btw, not really a patch that was appropriate for this stage ...
[Bug tree-optimization/47621] [4.6 Regression] Missed dependencies in address-taken optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47621 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 12:09:36 UTC --- Author: rguenth Date: Mon Feb 7 12:09:31 2011 New Revision: 169881 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169881 Log: 2011-02-07 Richard Guenther rguent...@suse.de PR tree-optimization/47621 * tree-ssa.c (non_rewritable_lvalue_p): New function, split out from two duplicates ... (execute_update_addresses_taken): ... here. Make it more conservative in what we accept. * gcc.dg/torture/pr47621.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47621.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa.c
[Bug bootstrap/47630] New: [4.6 regression] ICE in queue_insn, at haifa-sched.c:1322 compiling 64-bit libjava/java/lang/natString.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47630 Summary: [4.6 regression] ICE in queue_insn, at haifa-sched.c:1322 compiling 64-bit libjava/java/lang/natString.cc Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: aol...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 Created attachment 23263 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23263 preporcessed natString.cc For more than a week, mainline fails to bootstrap on IRIX 6.5: /vol/gcc/src/hg/trunk/local/libjava/java/lang/natString.cc: In member function 'jint java::lang::String::indexOf(jstring, jint)': /vol/gcc/src/hg/trunk/local/libjava/java/lang/natString.cc:832:1: internal compiler error: in queue_insn, at haifa-sched.c:1322 This happens both with the old and the current version of the Alexandre's patch to haifa-sched.c. I find the following cc1plus stacktrace: #0 fancy_abort (file=0x10bba438 error reading variable, line=1322, function=0x10bbadf0 error reading variable) at /vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:893 #1 0x105bc700 in queue_insn (next=0x4acdf40, delay=1) at /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:1322 #2 change_queue_index (next=0x4acdf40, delay=1) at /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:3968 #3 0x105bffb0 in fix_tick_ready (next=0x4acdf40) at /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:3936 #4 try_ready (next=0x4acdf40) at /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:3891 #5 0x108c4bd0 in init_ready_list () at /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:2119 #6 0x105c37a4 in schedule_block (target_bb=0x7ffb7a64) at /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:2877 #7 0x108c8f44 in schedule_region () at /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3000 #8 schedule_insns () at /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3321 #9 schedule_insns () at /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3300 #10 0x108c929c in rest_of_handle_sched () at /vol/gcc/src/hg/trunk/local/gcc/sched-rgn.c:3511 #11 0x106bf144 in execute_one_pass (pass=0x10cba0e0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1561 #12 0x106bf500 in execute_pass_list (pass=0x10cba0e0) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1616 #13 0x106bf51c in execute_pass_list (pass=0x10cb90d8) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:1617 #14 0x108e57a8 in tree_rest_of_compilation (fndecl=0x41a6b80) at /vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422 #15 0x1080fb7c in cgraph_expand_function (node=0x4a30740) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1563 #16 0x10812b60 in cgraph_expand_all_functions () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1622 #17 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1882 #18 0x10813250 in cgraph_finalize_compilation_unit () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1083 #19 0x1015ad50 in cp_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/cp/decl2.c:3977 #20 0x105acd34 in compile_file (argc=10, argv=0x7ffb7f04) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:591 #21 do_compile (argc=10, argv=0x7ffb7f04) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1874 #22 toplev_main (argc=10, argv=0x7ffb7f04) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1937 #23 0x10082620 in __start () (gdb) up #1 0x105bc700 in queue_insn (next=0x4acdf40, delay=1) at /vol/gcc/src/hg/trunk/local/gcc/haifa-sched.c:1322 (gdb) p insn $1 = (rtx) 0x4acdf40 (gdb) pr (debug_insn 72 71 73 7 (var_location:SI j (subreg:SI (reg/v:DI 213 [ j+-4 ]) 4)) -1 (nil)) The problem can be reproduced with included natString.ii and $ cc1plus -fpreprocessed natString.ii -mabi=64 -mno-synci -g -O2 -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers
[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.07 12:25:25
Ever Confirmed|0 |1
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07
12:25:25 UTC ---
(In reply to comment #8)
(In reply to comment #7)
looks wrong since it assumes D.2750_34 can be negative. But
sizetype values are sign-extended.
ivopts uses unsigned on purpose and create_mem_ref isn't prepared
to deal with. This isn't the right fix. It just shows we need to
properly sign-extended index when Pmode != ptr_mode:
diff --git a/gcc/tree-ssa-address.c b/gcc/tree-ssa-address.c
index a9ca835..4926a6d 100644
--- a/gcc/tree-ssa-address.c
+++ b/gcc/tree-ssa-address.c
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3. If not see
#include expr.h
#include ggc.h
#include target.h
+#include langhooks.h
/* TODO -- handling of symbols (according to Richard Hendersons
comments, http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00949.html):
@@ -658,6 +659,13 @@ addr_to_parts (tree type, aff_tree *addr, tree iv_cand,
}
if (addr-rest)
add_to_parts (parts, fold_convert (sizetype, addr-rest));
+
+ if (Pmode != ptr_mode parts-index)
+{
+ parts-index = fold_convert (ssizetype, parts-index);
+ parts-index = fold_convert (lang_hooks.types.type_for_mode (Pmode, 0),
+ parts-index);
+}
}
/* Force the PARTS to register. */
I think the issue is more involved. First we loose any information
of the signedness of the offset that was present in the C source because
of our stupid idea to convert all pointer offsets to sizetype (which,
in its other stupid way is a TYPE_UNSIGNED type that is supposed to be
sign-extended). Second, there is no way for the target to specify
whether offsets to ptr_mode should be sign- or zero-extended to
an integer type of the with of Pmode. We'd need a OFFSETS_EXTEND_UNSIGNED
macro for this (if it should be a consistent extension).
OTOH on my TODO list there is preserve signedness of pointer offsets,
thus, drop the sizetype conversion requirement and just extend offsets
based on their actual sign.
The above said, a IVOPTs-local solution isn't a solution. We have
the same issue with all POINTER_PLUS_EXPRs (how does it happen that
they work for you (in all werid cases)?).
You can maybe work around the issue by computing the resulting address
in ptr_mode (including all offsets) and only then extending to
Pmode according to POINTERS_EXTEND_UNSIGNED. That works unless
sizetype != ptr_mode size.
[Bug middle-end/47048] misc vect.exp failures with -fgraphite-identity enabled at -O2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47048 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-07 12:29:10 UTC --- (In reply to comment #4) More specifically, the code that is now confused by the (int) cast is: dr_analyze_innermost (dr); dr_analyze_indices (dr, nest, loop); in create_data_ref. Is this fixable for the 4.6.0 release or would that be to invasive for stage 4?
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-02-07 12:35:06 UTC --- Btw, not really a patch that was appropriate for this stage ... Are you the same Richard Guenther who wrote comment #29 under PR 43494? :-) That being said, feel free to overrule and declare this 4.7 material.
[Bug bootstrap/47630] [4.6 regression] ICE in queue_insn, at haifa-sched.c:1322 compiling 64-bit libjava/java/lang/natString.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47630 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 12:49:56 UTC --- (In reply to comment #3) Btw, not really a patch that was appropriate for this stage ... Are you the same Richard Guenther who wrote comment #29 under PR 43494? :-) That being said, feel free to overrule and declare this 4.7 material. I suppose pinging it on the ML is better than pinging it here. is a general comment. I didn't even look at the patch when saying that ;) A brief look suggests the patch may only change var-tracking behavior, but it seems that is not the case.
[Bug target/47631] New: Support native TLS on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47631
Summary: Support native TLS on Tru64 UNIX
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: r...@gcc.gnu.org
Host: alpha-dec-osf5.1b
Target: alpha-dec-osf5.1b
Build: alpha-dec-osf5.1b
I've just noticed that Tru64 UNIX does have native support for TLS, obviously
already in V4.0. The details are described in the Object File and Symbol Table
Format Specification:
http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/SUPPDOCS/OBJSPEC/TITLE.HTM
especially
3.3.9Thread Local Storage (TLS) Data
4.3.3.7 TLS Relocations
4.3.4.26 R_TLS_LITERAL
4.3.4.27 R_TLS_HIGH
4.3.4.28 R_TLS_LOW
8.3.5Finding Thread Local Storage (TLS) Symbols
13.3.5 TLS Symbols
Compiling th example in 4.3.4.26
__declspec(thread) long foo;
main(){
foo = 2;
}
with cc -S, I get
.set noat
.set noreorder
.tlscomm foo 8
.rdata
$$1:
.extern __tlsoffset 8
.text
.arch generic
.align 4
.file 1 osf-tls.c
.loc 1 2
# 2 main(){
.globl main
.entmain
.loc 1 2
main:
.context full
ldah$gp, ($27)!gpdisp!1
lda $gp, ($gp)!gpdisp!1
.frame $sp, 0, $26
.prologue 1
L$2:
.loc 1 3
# 3 foo = 2;
call_pal 0x9E # rdunique
# 03
ldq $0, 96($0)
ldq $28, __tlsoffset($gp)!tlsliteral!2
addq$0, $28, $0
ldq $0, ($0)
mov 2, $3
ldah$0, foo($0)!tlshigh!3
stq $3, foo($0)!tlslow!3
.loc 1 4
# 4 }
mov $31, $0
# 04
unop
ret ($26)
.endmain
.loc 1 2
A port will probably be somewhat different from an ELF port since there aren't
the 4 different access models.
[Bug tree-optimization/47632] New: [4.6 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -fnon-call-exceptions -ftrapv and operator new[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47632 Summary: [4.6 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -fnon-call-exceptions -ftrapv and operator new[] Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 23264 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23264 reduced testcase Compiler output: $ gcc -O -fnon-call-exceptions -ftrapv testcase.C testcase.C: In function 'void foo(Schar*)': testcase.C:11:1: error: BB 4 can not throw but has an EH edge testcase.C:11:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r169824 - crash r16 - OK
[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47624
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.07 13:08:13
CC||aoliva at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07
13:08:13 UTC ---
Yeah, this looks like a var-tracking bug.
We have:
(insn 32 7 9 2 (set (reg/f:DI 4 4 [127])
(reg/f:DI 1 1)) pr43077-1.c:34 358 {*movdi_internal64}
(expr_list:REG_EQUAL (reg/f:DI 1 1)
(nil)))
which adjust_insn transforms into:
(insn 32 7 9 2 (set (reg/f:DI 4 4 [127])
(plus:DI (reg/f:DI 67 ap)
(const_int -128 [0xff80]))) pr43077-1.c:34 358
{*movdi_internal64}
(expr_list:REG_EQUAL (reg/f:DI 1 1)
(nil)))
and:
(insn 9 32 31 2 (set (mem/c/i:DI (pre_modify:DI (reg/f:DI 4 4 [127])
(plus:DI (reg/f:DI 4 4 [127])
(const_int 120 [0x78]))) [0 c+0 S8 A64])
(reg:DI 0 0 [125])) pr43077-1.c:34 358 {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 0 0 [125])
(expr_list:REG_INC (reg/f:DI 4 4 [127])
(nil
which is adjusted into:
(insn 9 32 31 2 (parallel [
(set (mem/c/i:DI (plus:DI (reg/f:DI 4 4 [127])
(const_int 120 [0x78])) [0 c+0 S8 A64])
(reg:DI 0 0 [125]))
(set (reg/f:DI 4 4 [127])
(plus:DI (reg/f:DI 4 4 [127])
(const_int 120 [0x78])))
]) pr43077-1.c:34 358 {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 0 0 [125])
(expr_list:REG_INC (reg/f:DI 4 4 [127])
(nil
I believe that is correct. Now, for the latter insn, we get following uops:
bb 2 op 12 insn 9 MO_USE_NO_VAR (reg/f:DI 4 4 [127])
bb 2 op 13 insn 9 MO_USE_NO_VAR (reg:DI 0 0 [125])
bb 2 op 14 insn 9 MO_USE_NO_VAR (reg/f:DI 4 4 [127])
bb 2 op 15 insn 9 MO_VAL_SET (concat/u/i:DI (concat:DI (value/u:DI 7:7851
@0x2fb62b0/0x2fb6150)
(reg/f:DI 4 4 [127]))
(concat:DI (value/u:DI 4:3802 @0x2fb6268/0x2fb60c0)
(plus:DI (value/u:DI 7:7851 @0x2fb62b0/0x2fb6150)
(const_int -120 [0xff88]
bb 2 op 16 insn 9 MO_VAL_SET (concat (concat:DI (value/u:DI 5:3870
@0x2fb6280/0x2fb60f0)
(mem/c/i:DI (value/u:DI 7:7851 @0x2fb62b0/0x2fb6150) [0 cD.1258+0
S8 A64]))
(set (mem/c/i:DI (plus:DI (reg/f:DI 4 4 [127])
(const_int 120 [0x78])) [0 cD.1258+0 S8 A64])
(reg:DI 0 0 [125])))
In the last uop, we have VAL_HOLDS_TRACK_EXPR set and no other flags. As c is
only ever mentioned in MEM_ATTRS, the raw r4 + 120 address is used as its
location instead of tracking its value, and furthermore it doesn't even take
into account that r4 has been incremented in the very same insn and thus right
after the insn it is (mem (reg 4)) anyway.
Not sure why we don't value track the mem's address even for decls mentioned in
MEM_ATTRS (i.e. why the MEM doesn't use a VALUE as the address), that IMHO
would magically fix this. We would even figure out c is stored into a fbreg
based loc. Adding manually (in the debugger) a
@@ -5383,6 +5383,7 @@ add_stores (rtx loc, const_rtx expr, voi
if (GET_CODE (expr) == SET SET_DEST (expr) == loc)
src = var_lowpart (mode2, SET_SRC (expr));
loc = var_lowpart (mode2, loc);
+if (type == MO_VAL_SET) loc = replace_expr_with_values (loc);
if (src == NULL)
{
call partly fixes the testcase, c is not claimed to be at r4 + 120 anymore, but
at r4, which is correct at that spot; the following call to foo makes r4
register dead though, and so during and after the call the location info for c
is not valid anymore.
We could try harder and say canonicalize in cselib locs of the form
(plus (value X) (const_int N)) (or minus) where (value X) has locs
(plus cfa_base_preserved_val-v_val_rtx (const_int M)) into
a (plus cfa_base_preserved_val-v_val_rtx (const_int M+N)) and then we'd figure
out that r4 + 120 here is actually ap + offset and could even use a hardcoded,
non-value related, ap + offset location in this case. But we also need to
figure out what to do in a more general case. Alex, ideas?
Not a 4.6 material though.
[Bug bootstrap/47630] [4.6 regression] ICE in queue_insn, at haifa-sched.c:1322 compiling 64-bit libjava/java/lang/natString.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47630 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07 13:13:10 UTC --- Might be a dup of PR47620.
[Bug fortran/47633] New: Result of COMPILER_VERSION() has NULL byte appended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633 Summary: Result of COMPILER_VERSION() has NULL byte appended Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net The string returned by the COMPILER_VERSION function of the ISO_FORTRAN_ENV module has a NULL byte at the last character position. Expected result: Just the string, without the extra null byte. PROGRAM TESTENV USE ISO_FORTRAN_ENV CHARACTER(LEN=256) V INTEGER L V = COMPILER_VERSION() L = LEN(COMPILER_VERSION()) PRINT (A), V(1:L-1) PRINT *, ICHAR(V(L:L)) END PROGRAM TESTENV GCC version 4.6.0 20110205 (experimental) [trunk revision 169855] 0
[Bug tree-optimization/47621] [4.6 Regression] Missed dependencies in address-taken optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47621 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07 13:42:15 UTC --- Fixed.
[Bug rtl-optimization/47620] [4.6 Regression] Profiledbootstrap failure on powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47620 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07 13:45:18 UTC --- Also seen on s390x: https://bugzilla.redhat.com/show_bug.cgi?id=675711
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
Ian Bolton ibolton at gcc dot gnu.org changed:
What|Removed |Added
CC||ibolton at gcc dot gnu.org
--- Comment #15 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-07
13:47:35 UTC ---
(In reply to comment #10)
Subject: Bug 36158
Author: burnus
Date: Sat Aug 21 10:12:53 2010
New Revision: 163440
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163440
Log:
2010-08-21 Tobias Burnus bur...@net-b.de
PR fortran/36158
PR fortran/33197
* intrinsic.c (add_sym): Init value attribute.
(set_attr_value): New function.
(add_functions) Use it and add JN/YN resolvers.
* symbol.c (gfc_copy_formal_args_intr): Copy value attr.
* intrinsic.h (gfc_resolve_bessel_n2): New prototype.
* gfortran.h (gfc_intrinsic_arg): Add value attribute.
* iresolve.c (gfc_resolve_bessel_n2): New function.
* trans-intrinsic.c (gfc_get_symbol_for_expr): Create
formal arg list.
(gfc_conv_intrinsic_function,gfc_is_intrinsic_libcall):
Add GFC_ISYM_JN2/GFC_ISYM_YN2 as case value.
* simplify.c (): For YN set to -INF if previous values
was -INF.
* trans-expr.c (gfc_conv_procedure_call): Don't crash
if sym-as is NULL.
* iresolve.c (gfc_resolve_extends_type_of): Set the
type of the dummy argument to the one of the actual.
2010-08-21 Tobias Burnus bur...@net-b.de
PR fortran/36158
PR fortran/33197
* m4/bessel.m4: Implement bessel_jn and bessel_yn.
* gfortran.map: Add the generated bessel_jn_r{4,8,10,16}
and bessel_yn_r{4,8,10,16}.
* Makefile.am: Add bessel.m4.
* Makefile.in: Regenerated.
* generated/bessel_r4.c: Generated.
* generated/bessel_r16.c: Generated.
* generated/bessel_r8.c: Generated.
* generated/bessel_r10.c: Generated.
2010-08-21 Tobias Burnus bur...@net-b.de
PR fortran/36158
PR fortran/33197
* gfortran.dg/bessel_6.f90: New.
* gfortran.dg/bessel_7.f90: New.
Is this going to be backported to 4.5? It is required to make CSHIFT function
correctly.
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #5 from Bryce Lelbach (wash) blelbach at cct dot lsu.edu 2011-02-07 14:20:09 UTC --- Sorry! Wasn't aware this was correct.
[Bug ada/36939] Build Failure Ada SH2e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939 --- Comment #18 from Joel Sherrill joel at gcc dot gnu.org 2011-02-07 14:22:20 UTC --- (In reply to comment #17) With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds Ada. Is this OK to commit? Note that the proper place to submit a patch officially is gcc-patches. In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to have target specific implementations, or stubbed implementation, that's a kludge which is not really acceptable for mainstream. I didn't like this solution but it does let the target compile. But the underlying problem is more general. How should targets with only single precision floating point be supported by s-scaval.adb? I am pretty sure there is currently a PowerPC e500 core with only single precision. Arno
[Bug c++/47634] New: Incorrect checking of attribute format printf on constructor of derived class with virtual base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634
Summary: Incorrect checking of attribute format printf on
constructor of derived class with virtual base
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@randomdan.homeip.net
Given the below code, gcc produces the following warnings:
exception.cpp: In function 'int main(int, char**)':
exception.cpp:28: warning: format not a string literal and no format arguments
Changing the __attribute__ on VDerived's constructor to be the same as Derived
produces the following error:
exception.cpp:9: error: format string argument not a string type
Compiled simply with:
g++ exception.cpp
class Base {
public:
Base() {
}
};
class VDerived : public virtual Base {
public:
VDerived(int x, const char * f, ...) __attribute__((format(printf, 5,
6)));
};
class Derived : public Base {
public:
Derived(int x, const char * f, ...) __attribute__((format(printf, 3,
4)));
};
VDerived::VDerived(int x, const char * f, ...)
{
}
Derived::Derived(int x, const char * f, ...)
{
}
int
main(int, char **)
{
throw VDerived(1, %s %d, foo, 1);
throw Derived(1, %s %d, bar, 1);
}
[Bug tree-optimization/47615] [4.6 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07
14:50:43 UTC ---
;; basic block 2, loop depth 0, count 0
;; prev block 0, next block 11
;; pred: ENTRY [100.0%] (fallthru,exec)
;; succ: 11 [50.0%] (true,exec) 3 [50.0%] (false,exec)
bb 2:
p_y_5 = p_nd_2(D)-m_p_parent;
p_y_5-m_p_right = p_nd_2(D);
D.3165.m_p_nd = p_nd_2(D);
node_it = D.3165;
if (D.3177_7(D) != 0)
goto bb 11;
else
goto bb 3;
...
;; basic block 5, loop depth 0, count 0
;; prev block 12, next block 6
;; pred: 4 [61.0%] (false,exec)
;; succ: 6 [100.0%] (fallthru,exec)
bb 5:
D.3176_15 = r_child_it.m_p_nd;
r_rank_16 = MEM[(const long unsigned int )D.3176_15 + 16];
;; basic block 6, loop depth 0, count 0
;; prev block 5, next block 13
;; pred: 12 [100.0%] (fallthru) 5 [100.0%] (fallthru,exec)
;; succ: 13 [50.0%] (true,exec) 7 [50.0%] (false,exec)
bb 6:
# r_rank_19 = PHI 1(12), r_rank_16(5)
D.3178_17 = node_it.m_p_nd;
D.3184_20 = r_rank_19 + l_rank_18;
MEM[(long unsigned int )D.3178_17 + 16] = D.3184_20;
D.3160_6 = p_nd_2(D)-m_p_parent;
D.3189.m_p_nd = D.3160_6;
node_it = D.3189;
if (D.3201_21(D) != 0)
goto bb 13;
else
goto bb 7;
bb 13:
goto bb 8;
bb 7:
# VUSE .MEM_47
D.3199_23 = l_child_it.m_p_nd;
# VUSE .MEM_47
l_rank_24 = MEM[(const long unsigned int )D.3199_23 + 16];
bb 8:
# l_rank_32 = PHI 1(13), l_rank_24(7)
# VUSE .MEM_47
D.3206_25 = node_it.m_p_nd;
# VUSE .MEM_47
D.3207_26 = D.3206_25-m_p_right;
translating
{component_refm_p_right,mem_ref0B,p_y_5}@.MEM_35
to BB 5 results in translating
{component_refm_p_parent,mem_ref0B,p_nd_2(D)}@.MEM_3(D)
which is the leader for p_y_5 which results in translating
{component_refm_p_right,mem_ref0B,p_y_5}@.MEM_35
which is the leader for p_nd_2(D)
and we end up with a cycle. D.3206_25 is value-numbered to p_y_5
by SCCVN which looks ok.
The problem seems to be that we have a cycle for leaders. Simply caused by
p_y_5 = p_nd_2(D)-m_p_parent;
p_y_5-m_p_right = p_nd_2(D);
what seems bogus is that p_nd_2(D) isn't the leader for itself but
p_y_5-m_p_right is.
The issue is that we look at the intersection of the current ANTIC set
{ {component_refm_p_parent,mem_ref0B,p_nd_2(D)}@.MEM_3(D) (0005), l_rank_18
(0012), r_rank_19 (0013), {plus_expr,l_rank_18,r_rank_19} (0014),
{component_refm_p_right,mem_ref0B,p_y_5}@.MEM_35 (0002) }
with the expression set of the value
{ p_nd_2(D) (0002), {component_refm_p_nd,D.3165}@.MEM_37 (0002), D.3182_11
(0002), D.3178_17 (0002), D.3207_26 (0002),
{component_refm_p_right,mem_ref0B,p_y_5}@.MEM_35 (0002),
{component_refm_p_nd,D.3205}@.MEM_49 (0002), D.3200_29 (0002) }
and the only common one is {component_refm_p_right,mem_ref0B,p_y_5}@.MEM_35
(0002), p_nd_2(D) isn't ANTIC itself (which is what the referenced patch
changed - previously we'd recognized that the original reference we
now try to translate is equal to p_nd_2(D)).
It looks like fixing this disparity is the easiest thing we can do ...
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #16 from kargl at gcc dot gnu.org 2011-02-07 15:21:11 UTC --- (In reply to comment #15) Is this going to be backported to 4.5? It is required to make CSHIFT function correctly. It may be prudent to actually describe the problem with cshift and give a short example. The above is of little value.
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158 --- Comment #17 from Ian Bolton ibolton at gcc dot gnu.org 2011-02-07 15:41:14 UTC --- (In reply to comment #16) (In reply to comment #15) Is this going to be backported to 4.5? It is required to make CSHIFT function correctly. It may be prudent to actually describe the problem with cshift and give a short example. The above is of little value. Sorry about that. You are right - I should have given more information. Here goes: Currently, the code for the gfc_get_symbol_for_expr() function on the 4.5 branch has a comment that says: /* TODO: proper argument lists for external intrinsics. */ CSHIFT is one such fortran intrinsic, which will have an incorrect formal argument list due to this TODO not being done. Specifically, we can end up with a _gfortran_cshift0_4 call with no formal arguments. Here is a reduced testcase (adapted from an existing testcase) that shows such an issue with _gfortran_cshift0_4: ! Program to test the cshift intrinsic program intrinsic_cshift integer, dimension(3, 2) :: a ! Scalar shift a = reshape ((/1, 2, 3, 4, 5, 6/), (/3, 2/)) a = cshift (a, 1, 1) if (any (a .ne. reshape ((/2, 3, 1, 5, 6, 4/), (/3, 2/ call abort end program There is no information within the existing tree dumps to show things have gone wrong, but debugging with gdb and inserting a breakpoint within the gfc_get_symbol_for_expr function will show that expr-value.function.isym.formal has three items in it, whereas the new sym that we create is empty. The patch that fixed PR36158 correctly copies the formal arguments from isym to sym and we then get the correct behaviour. I hope that information is sufficient.
[Bug tree-optimization/47632] [4.6 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -fnon-call-exceptions -ftrapv and operator new[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47632 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.07 16:01:01 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 16:01:01 UTC --- Mine. It's forwprop not cleaning up EH.
[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.02.07 16:02:20
CC||kargl at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from kargl at gcc dot gnu.org 2011-02-07 16:02:20 UTC ---
Confirmed. Here's a tentative patch and testcase.
! { dg-do run }
! PR fortran/47633
program testenv
use iso_fortran_env
character(len=60) v
integer n
v = compiler_version()
n = len(compiler_version())
if (ichar(v(n:n)) /= 32) call abort()
end program testenv
troutmask:sgk[291] svn diff simplify.c
Index: simplify.c
===
--- simplify.c (revision 169830)
+++ simplify.c (working copy)
@@ -6837,7 +6837,6 @@ gfc_simplify_compiler_options (void)
return result;
}
-
gfc_expr *
gfc_simplify_compiler_version (void)
{
@@ -6845,8 +6844,10 @@ gfc_simplify_compiler_version (void)
size_t len;
len = strlen (GCC version ) + strlen (version_string) + 1;
- buffer = (char*) alloca (len);
+ buffer = (char *) alloca (len);
snprintf (buffer, len, GCC version %s, version_string);
+ /* Remove the terminating NULL character. */
+ buffer[strlen(buffer)] = ' ';
return gfc_get_character_expr (gfc_default_character_kind,
gfc_current_locus, buffer, len);
}
[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07 16:11:58 UTC --- Why should there be the extra space at the end? Doesn't make sense. IMHO either pass len - 1 to gfc_get_character_expr or don't count '\0' in len (i.e. remove the + 1) and use len + 1 in alloca. You shouldn't use alloca btw, but XALLOCAVEC (char, len).
[Bug tree-optimization/47632] [4.6 Regression] ICE: verify_flow_info failed: BB 4 can not throw but has an EH edge with -fnon-call-exceptions -ftrapv and operator new[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47632 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 16:20:17 UTC --- We propagate D.2112_13 into the if, changing that to D.2112_22 != 0 and remove the D.2112_13 def w/o cleaning up EH. [LP 1] D.2112_13 = D.2112_22 + -1; goto bb 6; # SUCC: 6 [100.0%] (fallthru,exec) 5 (eh,exec) ... # BLOCK 6 freq:9700 # PRED: 4 [100.0%] (fallthru,exec) ivtmp.8_12 = ivtmp.8_14 - 1; if (D.2112_13 != -1)
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #34 from Jeffrey A. Law law at redhat dot com 2011-02-07 16:27:24 UTC --- Typically the right thing to do is to block all memory motions across a change in the stack pointer.It's somewhat overly pessimistic, but in reality the few motions lost aren't going to be performance critical. In the past each backend has emitted the blockage/barrier and it typically happened soon after the port was converted to use RTL prologues/epilogues... That's probably the main reason why this was never fixed in the scheduler itself -- the first couple ports emitted a blockage and after that it became normal practice. I would support both emitting the suitable blockage insn in the ARM backend or adding a dependency between the stack pointer adjustment insn and all memory insns in the scheduler. Either is IMHO acceptable given history. The first would be slightly preferred during this late stage of development with the latter being more appropriate in early stage development.
[Bug target/37440] [4.4/4.5/4.6 Regression] GNAT Bug Box a-ngcefu.adb:397
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 Chung-Lin Tang cltang at gcc dot gnu.org changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #12 from Chung-Lin Tang cltang at gcc dot gnu.org 2011-02-07 16:38:50 UTC --- This looks suspiciously like PR47540, which has a submitted (by still uncommitted?) upstream patch.
[Bug tree-optimization/47255] Missed CSE optimization with inline functions, and __attribute__((const))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47255 Seth Robertson in-gnu at baka dot org changed: What|Removed |Added Attachment #22946|0 |1 is obsolete|| --- Comment #5 from Seth Robertson in-gnu at baka dot org 2011-02-07 16:50:45 UTC --- Created attachment 23265 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23265 Correct version of revised test program exhibiting missed optimization Hmm. I somehow managed to not attach the correct second example, I must have changed the program between the attach and submit steps or something.obsoleting the incorrect test progam But I as a developer have additional information not known to the compiler. I know that getgid and getuid are const FOR ME because I'm not going to be running setuid and friends and those are not changible through external force through standard APIs (unlike, say, current priority). We have a way to provide this sort of information to the compiler. Why shouldn't the compiler take advantage of the information I provide?
[Bug c++/47635] New: ICE on invalid code in constructor_name_p, at cp/name-lookup.c:1809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47635
Summary: ICE on invalid code in constructor_name_p, at
cp/name-lookup.c:1809
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
in the preprocessed source there's a syntax error:
'LibraryVersion::version() const {'
instead of:
'LibraryVersion Library::version() const {'
and the 'g++ heshvpUtils.ii -c -std=gnu++0x' ices on this line.
[Bug c++/47635] ICE on invalid code in constructor_name_p, at cp/name-lookup.c:1809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47635 --- Comment #1 from Pawel Sikora pluto at agmk dot net 2011-02-07 16:53:27 UTC --- Created attachment 23266 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23266 testcase.
[Bug tree-optimization/47615] [4.6 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 16:58:20 UTC --- Author: rguenth Date: Mon Feb 7 16:58:17 2011 New Revision: 169888 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169888 Log: 2011-02-07 Richard Guenther rguent...@suse.de PR tree-optimization/47615 * tree-ssa-sccvn.h (run_scc_vn): Take a vn-walk mode argument. * tree-ssa-sccvn.c (default_vn_walk_kind): New global. (run_scc_vn): Initialize it. (visit_reference_op_load): Use it. * tree-ssa-pre.c (execute_pre): Use VN_WALK if in PRE. * g++.dg/opt/pr47615.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr47615.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-sccvn.h
[Bug tree-optimization/47615] [4.5 Regression] ICE: too deep recursion in phi_translate/phi_translate_1 with -ftree-pre -fno-tree-fre -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47615 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Target Milestone|4.6.0 |4.5.3 Summary|[4.6 Regression] ICE: too |[4.5 Regression] ICE: too |deep recursion in |deep recursion in |phi_translate/phi_translate |phi_translate/phi_translate |_1 with -ftree-pre |_1 with -ftree-pre |-fno-tree-fre -fno-tree-sra |-fno-tree-fre -fno-tree-sra Known to fail|4.6.0 |4.5.3 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-07 16:59:44 UTC --- Fixed on trunk, latent on the branch still.
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-07
17:03:01 UTC ---
btw, your analysis at
http://article.gmane.org/gmane.comp.lib.boost.devel/214412 is bogus
There is no C++99, presumably you mean C++98
C++0x mode is absolutely not the default mode of either g++ or libstdc++, I
don't know what gave you that idea.
The Boost.Signals code is ambiguous with or without C++0x mode enabled,
although there is an extra ambiguity with C++0x mode
I believe the underlying problem is that stored_group has a catch all
constructor, which means that the conversion from non-const iterator to
const_iterator is not better than the conversion from non-const iterator to
key_type (i.e. stored_group)
You should try this (untested) alternative fix, which should work for C++03 and
C++0x, and looks like an improvement anyway:
--- boost/signals/detail/named_slot_map.hpp.orig2011-02-07
17:01:46.297942798 +
+++ boost/signals/detail/named_slot_map.hpp 2011-02-07 17:01:47.665572465
+
@@ -35,7 +35,7 @@
stored_group(storage_kind kind = sk_empty) : kind(kind), group() { }
templatetypename T
- stored_group(const T group) : kind(sk_group), group(new T(group)) { }
+ explicit stored_group(const T group) : kind(sk_group), group(new T(group))
{ }
bool is_front() const { return kind == sk_front; }
bool is_back() const { return kind == sk_back; }
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-07
17:17:54 UTC ---
Here's a reduced form of the code, which works with GCC 4.5 and earlier, but is
ambiguous with 4.6
#include map
struct Key
{
Key() { }
Key(const Key) { }
templatetypename T
Key(const T)
{ }
bool operator(const Key) const;
};
typedef std::mapKey, int Map;
void f()
{
Map m;
(void) m[Key()];
Map::iterator i = m.begin();
m.erase(i);
}
I'm not sure if the code is valid or not (Paolo?)
In C++0x mode the ambiguity is in the user code, because non-const iterator can
be converted to const_iterator or key_type (I believe this behaviour is
required by the standard)
In C++98 mode it's in the library code when calling _M_t.erase - this is a
regression. Paolo, should _Rb_tree::erase take a non-const iterator in c++98
mode? That's what map::erase passes it.
[Bug ada/36939] Build Failure Ada SH2e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939 --- Comment #19 from Joel Sherrill joel at gcc dot gnu.org 2011-02-07 17:22:59 UTC --- Following up on my own comment. Dealing with targets without double precision FPUs is a broader issue: $ grep -r DOUBLE_TYPE_SIZE . | grep SIZE.*32 | grep -v .svn ./rx/rx.h:#define DOUBLE_TYPE_SIZE (TARGET_64BIT_DOUBLES ? 64 : 32) ./rx/rx.h:#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 32 ./sh/sh.h:#define DOUBLE_TYPE_SIZE ((TARGET_SH2E ! TARGET_SH4 ! TARGET_SH2A_DOUBLE) ? 32 : 64) ./picochip/picochip.h:#define DOUBLE_TYPE_SIZE 32 ./picochip/picochip.h:#define LONG_DOUBLE_TYPE_SIZE 32 ./h8300/h8300.h:#define DOUBLE_TYPE_SIZE32 ./avr/avr.h:#define DOUBLE_TYPE_SIZE 32 ./avr/avr.h:#define LONG_DOUBLE_TYPE_SIZE 32
[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633
--- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-02-07 17:43:25 UTC ---
On Mon, Feb 07, 2011 at 04:12:00PM +, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07
16:11:58 UTC ---
Why should there be the extra space at the end? Doesn't make sense.
IMHO either pass len - 1 to gfc_get_character_expr or don't count '\0' in len
(i.e. remove the + 1) and use len + 1 in alloca. You shouldn't use alloca
btw,
but XALLOCAVEC (char, len).
You're right. I could do the len - 1, but when I tried that
I misinterpreted the results of the test program. Here's an
update diff and testcase. I'll start a regression test shortly,
and submit a patch for approval.
troutmask:sgk[218] svn diff simplify.c
Index: simplify.c
===
--- simplify.c (revision 169830)
+++ simplify.c (working copy)
@@ -6845,8 +6845,8 @@ gfc_simplify_compiler_version (void)
size_t len;
len = strlen (GCC version ) + strlen (version_string) + 1;
- buffer = (char*) alloca (len);
+ buffer = XALLOCAVEC (char, len);
snprintf (buffer, len, GCC version %s, version_string);
return gfc_get_character_expr (gfc_default_character_kind,
-gfc_current_locus, buffer, len);
+gfc_current_locus, buffer, len - 1);
}
troutmask:sgk[407] cat h.f90
! { dg-do run }
! PR fortran/47633
program testenv
use iso_fortran_env
character(len=60) v
integer n
v = compiler_version()
n = len(compiler_version())
if (ichar(v(n:n)) /= 41 .or. ichar(v(n+1:n+1)) /= 32) call abort()
end program testenv
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jwakely.gcc at gmail dot ||com --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-07 17:49:33 UTC --- Boring. Time ago I removed the other erase overloads for C++98, because it seemed redundant. Now, I'm thinking, instead of readding it, with all the stupid reduncancy, can't we just have a single overload taking a const_iterator and avoid differently the ambiguity with _Rb_tree::erase(const key_type)? Like renaming it, whatever?
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2011.02.07 17:56:37 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-07 17:56:37 UTC --- Well, thanks to the new _M_erase_aux helper I added at that time, it's actually just two lines of code, let's play safe and do that, for 4.6.0. Thanks Jon for the testcase.
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.0
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-02-07 18:00:50 UTC --- Great. For the record, Bryce, the change to the standard was done by DR 180 http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#180 see also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2350.pdf The code is invalid in C++0x, so I recommend adding the 'explicit' keyword to the template constructor, if the Boost testsuite passes with that change. That will allow the same code to work with C++03 and C++0x compilers.
[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07 18:05:36 UTC --- The testcase is bad, because for vanilla gcc releases there is no (prerelease) etc. string at all (DEV-PHASE is empty), and because it hardcodes ASCII values, so I'm afraid it could fail on EBCDIC or other targets.
[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931 --- Comment #5 from simonb at gcc dot gnu.org 2011-02-07 18:10:21 UTC --- Author: simonb Date: Mon Feb 7 18:10:15 2011 New Revision: 169891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169891 Log: Auto-detect suitable default behaviour for prefix canonicalization. Current gcc offers -no-canonical-prefixes to turn off realpath() for prefixes generated from the path used to address the gcc driver. This allows gcc to work in symlink farm installations, where every file in gcc is actually a symlink to its real contents. However, the flag has to be given explicitly. If not, the default is to use realpath() to create prefixes and the result is usually failure to find cc1[plus], f951, etc. This patch adds a check for a file as a way to auto-detect whether prefix canonicalization is appropriate or not. Detection can be overridden by using the -[no-]canonical-prefixes flags. The patch also completes the fix for PR/29931, adding code that covers the unadopted portion of this PR's attached patch. gcc/ChangeLog.google: 2011-02-07 Simon Baldwin sim...@google.com PR driver/29931 * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation. * gcc.c (display_help): Help text for -[no-]canonical-prefixes. (driver_handle_option): Ignore OPT_canonical_prefixes. (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect suitable default prefix canonicalization mode. * common.opt (canonical-prefixes): New flag. Google ref: 40029, 38719 Modified: branches/google/integration/gcc/ChangeLog.google-integration branches/google/integration/gcc/common.opt branches/google/integration/gcc/doc/invoke.texi branches/google/integration/gcc/gcc.c
[Bug rtl-optimization/38403] unable to find a register to spill in class ‘CREG’ with -fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38403 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-02-07 18:15:26 UTC --- seems to work with 4.5 and 4.6 now.
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-02-07 18:21:23 UTC --- A brief look suggests the patch may only change var-tracking behavior, but it seems that is not the case. Quite very brief then. :-) PR 43494 was a wrong code regression and Alexandre's patch fixed it, that's why I looked at it in the first place after seeing the double ping.
[Bug fortran/47571] [4.6 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from Janne Blomqvist jb at gcc dot gnu.org 2011-02-07 18:36:33 UTC --- Fixed, closing.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #39 from Mike Hommey mh+gcc at glandium dot org 2011-02-07 18:40:22 UTC --- (In reply to comment #38) Created attachment 23253 [details] failing testcase With current mainline and top of tree mozilla, things seems to go well, sqlite issues are gone. I now however get elfhack fault: jh@evans:/abuild/jh/build-mozilla-new9/build/unix/elfhack /abuild/jh/build-mozilla-new9/build/unix/elfhack/elfhack -b test.so test.so: terminate called after throwing an instance of 'std::runtime_error' what(): Section index out of bounds Aborted (core dumped) I am attaching test.so I get to see if it is elfhack miscomplation or the binary. That could well be https://bugzilla.mozilla.org/show_bug.cgi?id=629638 Can you check with a changeset newer than http://hg.mozilla.org/mozilla-central/rev/2772a0cf36d1 ?
[Bug fortran/43829] Scalarization of reductions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829 --- Comment #31 from Mikael Morin mikael at gcc dot gnu.org 2011-02-07 18:49:10 UTC --- Created attachment 23267 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23267 testcase
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #25 from Iain Sandoe iains at gcc dot gnu.org 2011-02-07 18:52:17 UTC --- a bit late to this I had this yesterday on a cross from darwin9 to cris-elf. the liblto_plugin.dylib is built (correct shlib suffix) and copied to (builddir)/gcc - but the code is looking for liblto_plugin.so I sim-linked gcc/liblto_plugin.so - liblto_plugin.dylib as work-around... and the rest proceeded OK.
[Bug fortran/43829] Scalarization of reductions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Attachment #21016|0 |1 is obsolete|| --- Comment #32 from Mikael Morin mikael at gcc dot gnu.org 2011-02-07 18:54:55 UTC --- Created attachment 23268 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23268 More up-to-date patch This deserves a safe place to stay.
[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2011-02-07 18:58:24 UTC --- if (ichar(v(n:n)) /= 41 .or. ichar(v(n+1:n+1)) /= 32) call abort() (In reply to comment #4) The testcase is bad, because for vanilla gcc releases there is no (prerelease) etc. string at all (DEV-PHASE is empty), and because it hardcodes ASCII values, so I'm afraid it could fail on EBCDIC or other targets. Regarding the char: using iachar instead of ichar should work. * * * len = strlen (GCC version ) + strlen (version_string) + 1; + buffer = XALLOCAVEC (char, len); snprintf (buffer, len, GCC version %s, version_string); return gfc_get_character_expr (gfc_default_character_kind, +gfc_current_locus, buffer, len - 1); I wonder whether one should strip the +1 in the first line and use len+1 for alloca/snprintf; it seems to be easier to follow than the len - 1 in the last line.
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-02-07 19:13:28 UTC --- It doesn't affect var-tracking at all BTW, because var-tracking deals with pre/post_inc/dec/modify manually by changing the insns passed to cselib temporarily. It was originally written with the intent to be used in var-tracking though.
[Bug fortran/47633] Result of COMPILER_VERSION() has NULL byte appended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633 --- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-02-07 19:19:37 UTC --- On Mon, Feb 07, 2011 at 06:58:39PM +, burnus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47633 if (ichar(v(n:n)) /= 41 .or. ichar(v(n+1:n+1)) /= 32) call abort() (In reply to comment #4) The testcase is bad, because for vanilla gcc releases there is no (prerelease) etc. string at all (DEV-PHASE is empty), and because it hardcodes ASCII values, so I'm afraid it could fail on EBCDIC or other targets. Regarding the char: using iachar instead of ichar should work. That still doesn't help. The testcase is looking for the last valid character in the string and a following space. Jakub's point is that '(experimental)' in the string 'GCC version 4.6.0 20110204 (experimental)' is sometimes not present, so checking for ')' won't work in all situations. I'll suggest that we simply omit a testcase for this PR. len = strlen (GCC version ) + strlen (version_string) + 1; + buffer = XALLOCAVEC (char, len); snprintf (buffer, len, GCC version %s, version_string); return gfc_get_character_expr (gfc_default_character_kind, +gfc_current_locus, buffer, len - 1); I wonder whether one should strip the +1 in the first line and use len+1 for alloca/snprintf; it seems to be easier to follow than the len - 1 in the last line. Sure, no problem. Here's a tested patch. Index: simplify.c === --- simplify.c (revision 169830) +++ simplify.c (working copy) @@ -6844,9 +6844,9 @@ gfc_simplify_compiler_version (void) char *buffer; size_t len; - len = strlen (GCC version ) + strlen (version_string) + 1; - buffer = (char*) alloca (len); - snprintf (buffer, len, GCC version %s, version_string); + len = strlen (GCC version ) + strlen (version_string); + buffer = XALLOCAVEC (char, len + 1); + snprintf (buffer, len + 1, GCC version %s, version_string); return gfc_get_character_expr (gfc_default_character_kind, gfc_current_locus, buffer, len); }
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #26 from Kai Tietz ktietz at gcc dot gnu.org 2011-02-07 19:37:16 UTC --- (In reply to comment #23) Kai? make[1]: Entering directory `/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc.obj/lto-plugin' /bin/sh ./libtool --tag=CC --tag=disable-static --mode=compile gcc -DHAVE_CONFIG_H -I. -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 -c -o lto-plugin.lo /home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/lto-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin -I/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 -c /home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc/lto-plugin/lto-plugin.c -fPIC -DPIC -o .libs/lto-plugin.o make[1]: *** No rule to make target `-Wl,../libiberty/pic/libiberty.a', needed by `liblto_plugin.la'. Stop. make[1]: Leaving directory `/home/tschwinge/tmp/gnu-Elephant_Bird/src/gcc.obj/lto-plugin' Could you please test attached patch at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00469.html that it works for you? Thanks, Kai
[Bug target/47636] New: Powerpc rs6000.md uses RS6000_RECIP_HAVE_RSQRT_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47636 Summary: Powerpc rs6000.md uses RS6000_RECIP_HAVE_RSQRT_P Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: meiss...@gcc.gnu.org ReportedBy: meiss...@gcc.gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux There is a typo in rs6000.md in the rsqrttype generator functions. It refers to the RS6000_RECIP_HAVE_RSQRT_P macro, but the actual macro is RS6000_RECIP_HAVE_RSQRTE_P. You get a warning that the function is unknown in the build, but it doesn't stop the build since it just puts out a relocation for the RS6000_RECIP_HAVE_RSQRT_P function to be loaded later. However the rsqrttype generators are never called, you never get an error.
[Bug target/47636] Powerpc rs6000.md uses RS6000_RECIP_HAVE_RSQRT_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47636 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.07 19:43:31 Ever Confirmed|0 |1
[Bug bootstrap/47534] [regression] avr libgcc.S fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47534 --- Comment #1 from denisc at gcc dot gnu.org 2011-02-07 20:00:14 UTC --- Author: denisc Date: Mon Feb 7 20:00:08 2011 New Revision: 169896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169896 Log: PR target/47534 * config/avr/libgcc.S (exit): Move .endfunc Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/libgcc.S
[Bug libstdc++/47560] [4.6 Regression] FAIL: abi/header_cxxabi.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47560 --- Comment #6 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-02-07 20:06:08 UTC --- Author: bkoz Date: Mon Feb 7 20:06:03 2011 New Revision: 169897 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169897 Log: 2011-02-07 Benjamin Kosnik b...@redhat.com PR libstdc++/47560 try two * config/os/hpux/os_defines.h: Guard for C++. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/hpux/os_defines.h
[Bug c++/47172] [4.6 Regression] [C++0x] cannot call member function without object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47172 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||dodji at gcc dot gnu.org AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 --- Comment #11 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-02-07 20:15:59 UTC --- Author: paolo Date: Mon Feb 7 20:15:48 2011 New Revision: 169899 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169899 Log: 2011-02-07 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/47628 * include/bits/stl_tree.h (_Rb_tree::erase(iterator), erase(iterator, iterator)): Add back in C++03 mode. * testsuite/23_containers/map/modifiers/erase/47628.cc: New. * testsuite/23_containers/multimap/modifiers/erase/47628.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/erase/ trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/erase/47628.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/erase/ trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/erase/47628.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_tree.h
[Bug libstdc++/47628] non-compliant C++0x erase methods on STL containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47628 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-02-07 20:18:46 UTC --- Done.
[Bug target/47619] ICE in printf() with -fsplit-stack enabled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47619 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-02-07 20:25:37 UTC --- With GNU gold (GNU Binutils 2.21.51.20110207) 1.11, I got ... i = 1970, rsp = 0x7fffe615a8b0 make: *** [all] Segmentation fault [hjl@gnu-6 pr47619]$
[Bug target/47636] Powerpc rs6000.md uses RS6000_RECIP_HAVE_RSQRT_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47636 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org 2011-02-07 20:32:51 UTC --- Author: meissner Date: Mon Feb 7 20:32:45 2011 New Revision: 169901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169901 Log: Fix PR target/47636 Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #27 from Kai Tietz ktietz at gcc dot gnu.org 2011-02-07 20:32:24 UTC --- Author: ktietz Date: Mon Feb 7 20:32:17 2011 New Revision: 169900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169900 Log: 2011-02-07 Kai Tietz kai.ti...@onevision.com PR lto/47225 * Makefile.am (Wc): New helper for encoding -Wc,. (liblto_plugin_la_LIBADD): Use Wc for libiberty library. (liblto_plugin_la_DEPENDENCIES): Special case pic libiberty. * Makefile.in: Regenerated. Modified: trunk/lto-plugin/ChangeLog trunk/lto-plugin/Makefile.am trunk/lto-plugin/Makefile.in
[Bug target/47636] Powerpc rs6000.md uses RS6000_RECIP_HAVE_RSQRT_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47636 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org 2011-02-07 20:35:02 UTC --- Created attachment 23269 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23269 Patch that fixes the problem Spell RS6000_RECIP_HAVE_RSQRTE_P correctly.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #63 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-02-07 20:41:54 UTC --- Author: mrs Date: Mon Feb 7 20:41:50 2011 New Revision: 169902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169902 Log: PR target/47558 Add __ieee_divdc3 entry point. * config/i386/darwin.h (DECLARE_LIBRARY_RENAMES): Retain ___divdc3 entry point. (SUBTARGET_INIT_BUILTINS): Call darwin_rename_builtins. * config/i386/i386.c (TARGET_INIT_LIBFUNCS): Likewise. * config/darwin.c (darwin_rename_builtins): Add. * config/darwin-protos.h (darwin_rename_builtins): Add. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-protos.h trunk/gcc/config/darwin.c trunk/gcc/config/i386/darwin.h trunk/gcc/config/i386/i386.c
[Bug target/47481] [4.6 Regression] spill failure with -O2 -msoft-float on Ada RTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47481 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.07 20:41:22 AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-02-07 20:41:22 UTC --- Investigating.
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #28 from Iain Sandoe iains at gcc dot gnu.org 2011-02-07 20:48:48 UTC --- (In reply to comment #26) (In reply to comment #23) Could you please test attached patch at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00469.html that it works for you? I guess the bug I'm seeing must be different; ... applied the patch and still get: checking for suffix of object files... configure: error: in `/GCC/cross-trees/cris-elf/cris-elf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make: *** [all] Error 2 apollo:cris-elf $ ls gcc/liblto_plugin.* gcc/liblto_plugin.0.dylib gcc/liblto_plugin.dylib gcc/liblto_plugin.la apollo:cris-elf $ ./gcc/xgcc -Bgcc ../../tests/trivial-0.c -S xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found compilation terminated. after sym-linking gcc/liblto_plugin.dylib to gcc/liblto_plugin.so the compile runs fine and the build completes.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #64 from Iain Sandoe iains at gcc dot gnu.org 2011-02-07 20:52:40 UTC --- (In reply to comment #63) Author: mrs Date: Mon Feb 7 20:41:50 2011 New Revision: 169902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169902 Log: PR target/47558 Add __ieee_divdc3 entry point. * config/i386/darwin.h (DECLARE_LIBRARY_RENAMES): Retain ___divdc3 entry point. (SUBTARGET_INIT_BUILTINS): Call darwin_rename_builtins. * config/i386/i386.c (TARGET_INIT_LIBFUNCS): Likewise. * config/darwin.c (darwin_rename_builtins): Add. * config/darwin-protos.h (darwin_rename_builtins): Add. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-protos.h trunk/gcc/config/darwin.c trunk/gcc/config/i386/darwin.h trunk/gcc/config/i386/i386.c that would mean we could apply comment #58 without regression, if Mike approves ? (with/without amendment of FIXME text as you wish)
[Bug other/42333] complex division failure on darwin10 with -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 --- Comment #55 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-02-07 20:52:39 UTC --- Author: mrs Date: Mon Feb 7 20:52:33 2011 New Revision: 169903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169903 Log: PR target/42333 Add __ieee_divdc3 entry point. * config/i386/darwin.h (DECLARE_LIBRARY_RENAMES): Retain ___divdc3 entry point. (SUBTARGET_INIT_BUILTINS): Call darwin_rename_builtins. * config/i386/i386.c (TARGET_INIT_LIBFUNCS): Likewise. * config/darwin.c (darwin_rename_builtins): Add. * config/darwin-protos.h (darwin_rename_builtins): Add. Modified: trunk/gcc/ChangeLog
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #29 from Kai Tietz ktietz at gcc dot gnu.org 2011-02-07 20:53:32 UTC --- (In reply to comment #28) (In reply to comment #26) (In reply to comment #23) Could you please test attached patch at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00469.html that it works for you? I guess the bug I'm seeing must be different; ... applied the patch and still get: checking for suffix of object files... configure: error: in `/GCC/cross-trees/cris-elf/cris-elf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make: *** [all] Error 2 apollo:cris-elf $ ls gcc/liblto_plugin.* gcc/liblto_plugin.0.dylib gcc/liblto_plugin.dylib gcc/liblto_plugin.la apollo:cris-elf $ ./gcc/xgcc -Bgcc ../../tests/trivial-0.c -S xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found compilation terminated. after sym-linking gcc/liblto_plugin.dylib to gcc/liblto_plugin.so the compile runs fine and the build completes. Well, maybe check if target defines LTOPLUGINSONAME correct.
[Bug other/42333] complex division failure on darwin10 with -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED --- Comment #56 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-02-07 20:54:48 UTC --- This has been fixed. See PR47558 for the full patch.
[Bug target/47558] 163267 breaks exception traceback in xplor-nih
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558 --- Comment #65 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-02-07 20:55:31 UTC --- /* The system ___divdc3 routine in libSystem on darwin10 is not accurate to 1ulp, ours is, so we avoid ever using the system name for this routine and instead install a non-conflicting name that is accurate. I think this comment in gcc/config/darwin.c and gcc/config/i386/darwin.h is at best misleading. The problem is not about accuracy, but the range of validity of the chosen algorithm. In darwin10, it is tinyarg(complex_denominator)**2huge, while in the FSF lib it is tinyarg(complex_denominator)huge. Note that codes relying on this extended range are likely to generate infinities elsewhere.
[Bug other/42333] complex division failure on darwin10 with -lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333 --- Comment #57 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-02-07 20:56:32 UTC --- I'll pre-approve a backport to 4.5.x if someone really wants it, should be very safe.
[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248 --- Comment #11 from David Fang fang at csl dot cornell.edu 2011-02-07 21:02:13 UTC --- Any updates on this? re-confirmation? I would like to continue testing gcc-4.5.x on powerpc-darwin8, but can't b/c of this.
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225 --- Comment #30 from Iain Sandoe iains at gcc dot gnu.org 2011-02-07 21:03:02 UTC --- (In reply to comment #29) (In reply to comment #28) (In reply to comment #26) (In reply to comment #23) Could you please test attached patch at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00469.html that it works for you? I guess the bug I'm seeing must be different; ... applied the patch and still get: checking for suffix of object files... configure: error: in `/GCC/cross-trees/cris-elf/cris-elf/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make: *** [all] Error 2 apollo:cris-elf $ ls gcc/liblto_plugin.* gcc/liblto_plugin.0.dylib gcc/liblto_plugin.dylib gcc/liblto_plugin.la apollo:cris-elf $ ./gcc/xgcc -Bgcc ../../tests/trivial-0.c -S xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found compilation terminated. after sym-linking gcc/liblto_plugin.dylib to gcc/liblto_plugin.so the compile runs fine and the build completes. Well, maybe check if target defines LTOPLUGINSONAME correct. hm. it's running on the host tho. OK - I'll have an investigate at some point.
[Bug fortran/47349] missing warning: Actual argument contains too few elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47349
--- Comment #2 from janus at gcc dot gnu.org 2011-02-07 21:05:04 UTC ---
The patch in comment #1 produces a couple of regressions. The following should
take care of most of them:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 169891)
+++ gcc/fortran/interface.c(working copy)
@@ -1887,7 +1887,7 @@ get_expr_storage_size (gfc_expr *e)
else if (ref-type == REF_ARRAY ref-u.ar.type == AR_ELEMENT
e-expr_type == EXPR_VARIABLE)
{
- if (e-symtree-n.sym-as-type == AS_ASSUMED_SHAPE
+ if (ref-u.ar.as-type == AS_ASSUMED_SHAPE
|| e-symtree-n.sym-attr.pointer)
{
elements = 1;
@@ -1916,8 +1916,6 @@ get_expr_storage_size (gfc_expr *e)
- mpz_get_si (ref-u.ar.as-lower[i]-value.integer));
}
}
- else
-return 0;
}
if (substrlen)
@@ -2107,9 +2105,9 @@ compare_actual_formal (gfc_actual_arglist **ap, gf
actual_size = get_expr_storage_size (a-expr);
formal_size = get_sym_storage_size (f-sym);
- if (actual_size != 0
- actual_size formal_size
- a-expr-ts.type != BT_PROCEDURE)
+ if (actual_size != 0 actual_size formal_size
+ a-expr-ts.type != BT_PROCEDURE
+ f-sym-attr.flavor != FL_PROCEDURE)
{
if (a-expr-ts.type == BT_CHARACTER !f-sym-as where)
gfc_warning (Character length of actual argument shorter
[Bug target/46997] new ia64 vector instructions are broken on HP-UX (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46997 --- Comment #5 from Steve Ellcey sje at gcc dot gnu.org 2011-02-07 21:06:45 UTC --- Author: sje Date: Mon Feb 7 21:06:42 2011 New Revision: 169904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169904 Log: 2011-02-07 Steve Ellcey s...@cup.hp.com PR target/46997 * vect.md (vec_interleave_highv2sf): Change fmix for TARGET_BIG_ENDIAN. (vec_interleave_lowv2sf): Ditto. (vec_extract_evenv2sf): Add TARGET_BIG_ENDIAN check. (vec_extract_oddv2sf): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/vect.md
[Bug target/47324] g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2011-02-07 21:07:59 UTC --- The Apple linker developer has looked at the failing eh-alloc-1.C case and had the following comments... Also, did you ever get a chance to look at the stackalign_testcase2.tar.bz2 test case from radar ID 6407474, stackalign failures for -O3 -g at -m32 with Xcode 3.1.2 and 3.2A number of gcc 4, in a debug version of the Snow Leopard unwinder? This bug is still very confusing. I just took a look at the eh-alloc.exe case. The case built with -g fails when running on Lion (with the darwin unwinder) and the case built without -g works fine. I stepped through the unwinding. The function foo() uses dynamic stack alignment and the dwarf unwind info uses expressions to specify where the CFA is. In the bad case (with -g) the expression has a push of register 5 (ESP) where as the good case has a push of register 4 (EBP) in the expression. I recall that some bug cropped up long ago with the register numbering for i386. Two register numbers were swapped. The end result is the eh_frame register numbering and DWARF debug info registering number are different. I suspect that using -g is forcing the eh_frame creation to use the DWARF debug info register numbering. You can see the difference with dwarfdump: [/tmp] dwarfdump --eh-frame stackalign_testcase2/stackalign_with_g/eh-alloca-1.exe | grep -A8 __Z3fooi start_addr: 0x1d20 __Z3fooi range_size: 0x00b8 (end_addr = 0x1dd8) LSDA address: 0x2094 Instructions: 0x1d20: CFA=esp+4 eip=[esp] DW_CFA_advance_loc4 (4) DW_CFA_def_cfa (ecx, 0) 0x1d24: CFA=ecx eip=[ecx-4] DW_CFA_advance_loc4 (7) DW_CFA_expression (esp, expr(esp0)) [/tmp] dwarfdump --eh-frame stackalign_testcase2/stackalign_without_g/eh-alloca-1.exe | grep -A8 __Z3fooi start_addr: 0x1d20 __Z3fooi range_size: 0x00b8 (end_addr = 0x1dd8) LSDA address: 0x2094 Instructions: 0x1d20: CFA=esp+4 eip=[esp] DW_CFA_advance_loc4 (4) DW_CFA_def_cfa (ecx, 0) 0x1d24: CFA=ecx eip=[ecx-4] DW_CFA_advance_loc4 (7) DW_CFA_expression (ebp, expr(ebp0)) [/tmp]
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614
Pat Haugen pthaugen at gcc dot gnu.org changed:
What|Removed |Added
Attachment #23248|0 |1
is obsolete||
--- Comment #7 from Pat Haugen pthaugen at gcc dot gnu.org 2011-02-07
21:18:35 UTC ---
Created attachment 23270
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23270
smaller testcase
A slightly smaller testcase.
Looking at the dumps, postreload is deleting the following insn in r169782.
(insn 95 392 89 3 (set (reg:DF 45 13 [orig:191 MEM[(real(kind=8)[0:]
*)D.1405_52] ] [191])
(mem:DF (pre_inc:DI (reg:DI 10 10 [orig:216 ivtmp.29 ] [216])) [2
MEM[(real(kind=8)[0:] *)D.1405_52]+0 S8 A64])) fail.f:9 392
{*movdf_hardfloat64}
(expr_list:REG_INC (reg:DI 10 10 [orig:216 ivtmp.29 ] [216])
(nil)))
[Bug lto/47225] [4.6 regression]: cross-compile fails while configuring libgcc with xgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47225
--- Comment #31 from Iain Sandoe iains at gcc dot gnu.org 2011-02-07 21:22:10
UTC ---
(In reply to comment #30)
(In reply to comment #29)
(In reply to comment #28)
(In reply to comment #26)
(In reply to comment #23)
Could you please test attached patch at
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00469.html that it works
for you?
I guess the bug I'm seeing must be different;
... applied the patch and still get:
hm. it's running on the host tho. OK - I'll have an investigate at some
point.
given that the fault was reported on darwin it's still likely to need this...
testing:
Index: gcc/config.host
===
--- gcc/config.host (revision 169878)
+++ gcc/config.host (working copy)
@@ -96,6 +96,7 @@ case ${host} in
# Generic darwin host support.
out_host_hook_obj=host-darwin.o
host_xmake_file=${host_xmake_file} x-darwin
+host_lto_plugin_soname=liblto_plugin.dylib
;;
esac
[Bug target/46997] new ia64 vector instructions are broken on HP-UX (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46997 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Steve Ellcey sje at cup dot hp.com 2011-02-07 21:32:26 UTC --- This is now fixed, all the tests that pass on Linux pass on HP-UX as well.
[Bug bootstrap/47534] [regression] avr libgcc.S fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47534 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org 2011-02-07 21:37:02 UTC --- On 02/07/2011 02:27 PM, Denis Chertykov wrote: 2011/2/7 Joel Sherrill joel.sherr...@oarcorp.com: There are two targets which cannot build C -- avr and lm32: + avr - http://gcc.gnu.org/PR47534 I have committed the fix r169896 Confirmed. avr-rtems now compiles. Thanks.
