[Bug fortran/45636] Failed to fold simple Fortran string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45636 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.27 06:16:20 date|| CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-09-27 06:16:20 UTC --- (In reply to comment #6) Created attachment 21891 [details] patch for comment#5 This patch fixes the issue in comment #5 in the Fortran front end. ... but also causes regressions. I'll investigate. Confirmed, BTW.
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2010-09-27 06:34:09 UTC --- (In reply to comment #7) (In reply to comment #6) Basic implementation works. Remains to do: ... (c) CLASS_INQUIRY instead of CLASS_IMPURE? (d) Documentation in intrinsic.texi
[Bug target/45807] New: Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45807 Summary: Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++ Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amo...@gmail.com Created attachment 21893 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21893 testcase from Allan Pratt akpr...@netflix.com In the eh_frame description for _Unwind_Resume_or_Rethrow, I see 12a0 007c 12a4 FDE cie= pc=100712c0..100714f8 DW_CFA_advance_loc: 4 to 100712c4 DW_CFA_def_cfa_offset: 3216 DW_CFA_advance_loc: 164 to 10071368 DW_CFA_offset_extended_sf: r2 at cfa+40 [snip] but, r2 is not saved by this function, at least, not before _Unwind_RaiseException is called. So the lie that r2 is saved at cfa+40 once we are past 10071368 can cause the unwinder to return a bad value for r2 when unwinding through _Unwind_Resume_or_Rethrow from _Unwind_RaiseException. r2 won't be saved if _Unwind_Resume_of_Rethrow is called statically from the same toc group, but this bug is often covered by the fact that a previous call into exception handling functions has written the correct r2 value to the stack. 100712c0 ._Unwind_Resume_or_Rethrow: 100712c0: f8 21 f3 71 stdur1,-3216(r1) 100712c4: 7d 80 00 26 mfcrr12 100712c8: 7c 08 02 a6 mflrr0 100712cc: d9 c1 0c 00 stfdf14,3072(r1) 100712d0: d9 e1 0c 08 stfdf15,3080(r1) 100712d4: f8 01 0c a0 std r0,3232(r1) 100712d8: da 01 0c 10 stfdf16,3088(r1) 100712dc: da 21 0c 18 stfdf17,3096(r1) 100712e0: da 41 0c 20 stfdf18,3104(r1) 100712e4: da 61 0c 28 stfdf19,3112(r1) 100712e8: da 81 0c 30 stfdf20,3120(r1) 100712ec: da a1 0c 38 stfdf21,3128(r1) 100712f0: da c1 0c 40 stfdf22,3136(r1) 100712f4: da e1 0c 48 stfdf23,3144(r1) 100712f8: db 01 0c 50 stfdf24,3152(r1) 100712fc: db 21 0c 58 stfdf25,3160(r1) 10071300: db 41 0c 60 stfdf26,3168(r1) 10071304: db 61 0c 68 stfdf27,3176(r1) 10071308: db 81 0c 70 stfdf28,3184(r1) 1007130c: db a1 0c 78 stfdf29,3192(r1) 10071310: db c1 0c 80 stfdf30,3200(r1) 10071314: db e1 0c 88 stfdf31,3208(r1) 10071318: f9 c1 0b 70 std r14,2928(r1) 1007131c: f9 e1 0b 78 std r15,2936(r1) 10071320: fa 01 0b 80 std r16,2944(r1) 10071324: fa 21 0b 88 std r17,2952(r1) 10071328: fa 41 0b 90 std r18,2960(r1) 1007132c: fa 61 0b 98 std r19,2968(r1) 10071330: fa 81 0b a0 std r20,2976(r1) 10071334: fa a1 0b a8 std r21,2984(r1) 10071338: fa c1 0b b0 std r22,2992(r1) 1007133c: fa e1 0b b8 std r23,3000(r1) 10071340: fb 01 0b c0 std r24,3008(r1) 10071344: fb 21 0b c8 std r25,3016(r1) 10071348: fb 41 0b d0 std r26,3024(r1) 1007134c: fb 61 0b d8 std r27,3032(r1) 10071350: fb 81 0b e0 std r28,3040(r1) 10071354: fb a1 0b e8 std r29,3048(r1) 10071358: fb c1 0b f0 std r30,3056(r1) 1007135c: fb e1 0b f8 std r31,3064(r1) 10071360: e8 03 00 10 ld r0,16(r3) 10071364: 7c 7f 1b 78 mr r31,r3 10071368: 2f a0 00 00 cmpdi cr7,r0,0 1007136c: f8 61 0b 50 std r3,2896(r1) 10071370: f8 81 0b 58 std r4,2904(r1) 10071374: f8 a1 0b 60 std r5,2912(r1) 10071378: f8 c1 0b 68 std r6,2920(r1) 1007137c: 91 81 0c 98 stw r12,3224(r1) 10071380: 40 9e 00 e0 bne-cr7,10071460 ._Unwind_Resume_or_Rethrow+0x1a0 10071384: 4b ff f8 0d bl 10070b90 ._Unwind_RaiseException
[Bug other/45806] gcc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45806 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.09.27 09:13:07 date|| Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-09-27 09:13:07 UTC --- (In reply to comment #0) checking for suffix of object files... configure: error: in `/home/tjf/InstallTrees/gcc-4.5.1-build/i686-pc-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. Like it says, see config.log for more details, it could be a number of things.
[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-09/msg02097.htm ||l AssignedTo|unassigned at gcc dot |hp at gcc dot gnu.org |gnu.org | --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-09-27 09:16:59 UTC --- I'd better take it, now that I have a patch. Bernd, I certainly don't mind if you grab this PR for yourself, definitely if you don't like the patch.
[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792 --- Comment #3 from Bernd Schmidt bernds at gcc dot gnu.org 2010-09-27 09:32:14 UTC --- Looking at it now.
[Bug target/45808] New: FreeBSD: -pthread is handled incompletely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45808 Summary: FreeBSD: -pthread is handled incompletely Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: a...@icyb.net.ua On recent (and maintained) versions of FreeBSD it is required that shared libraries using pthread functions are linked to libpthread. This was not the case in older and now unsupported versions of the OS. So, currently GCC on FreeBSD expands -pthread option to -lpthread only when target is a final binary. When compilation target is a shared library -pthread is ignored. This needs to be fixed in -pthread specifications for FreeBSD.
[Bug lto/45790] 1308 new GCC h...@164592 regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org, ||rguenther at suse dot de --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-09-27 09:42:21 UTC --- This pr seems to be due to revision 164591: Author:rguenth Date:Fri Sep 24 13:21:30 2010 UTC (2 days, 19 hours ago) Changed paths:5 Log Message: 2010-09-24 Richard Guenther rguent...@suse.de * c-decl.c (pop_scope): Always set file-scope DECL_CONTEXT. Make sure to not call set_type_context with error_mark_node. * langhooks.c (lhd_set_decl_assembler_name): Use DECL_FILE_SCOPE_P. * gcc.dg/lto/20091006-2_0.c: Prune warnings. Changed paths: PathDetails trunk/gcc/ChangeLogmodified , text changed trunk/gcc/c-decl.cmodified , text changed trunk/gcc/langhooks.cmodified , text changed trunk/gcc/testsuite/ChangeLogmodified , text changed trunk/gcc/testsuite/gcc.dg/lto/20091006-2_0.cmodified , text changed If I revert it at revision 164604, the failures are gone.
[Bug preprocessor/45809] New: Canonicalize file names output during dependency generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45809 Summary: Canonicalize file names output during dependency generation Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: konrad.schw...@siemens.com I have a make file responsible for files in several directories (say main_dir, other_dir). The files in these directories include header files using relative paths: other_dir/source.c # include ../main_dir/header.h GCC, invoked with -MMD, produces dependency files of the form other_dir/source.d ../other_dir/source.o:\ ../other_dir/../main_dir/header.h These dependency files are included via Makefile -include ../other_dir/*.d If header.h is generated using a rule of the form Makefile header.h: header.m4 m4 header.m4 header.h (GNU) make fails to realize that a change to header.m4 requires a rebuild of ../other_dir/source.o, since make uses string compares to identify targets with prerequisites. Pseudo-targets in Make require this sort of comparison. Were GCC to canonicalize the file names in the dependency files it generates: other_dir/source.d ../other_dir/source.o:\ header.h this problem would be solved.
[Bug lto/45790] 1308 new GCC h...@164592 regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790 Jie Zhang jiez at gcc dot gnu.org changed: What|Removed |Added CC||jiez at gcc dot gnu.org --- Comment #2 from Jie Zhang jiez at gcc dot gnu.org 2010-09-27 10:07:21 UTC --- The same issue was found on arm-none-eabi: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02004.html
[Bug lto/45810] New: 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 Summary: 40% slowdown when using LTO for a single-file program Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org That's on a Intel Core(TM)2 Duo CPU E8400 @ 3.00GHz and using CentOS Linux 5.5 (x86-64) with glibc-2.5-49.el5_5.2, binutils-2.17.50.0.6-14.el5 and gcc version 4.6.0 20100921 (experimental) [trunk revision 164472] (GCC) The performance for fatigue of the Polyhedron test case drops by 40% if one enables LTO (using -fwhole=program): gfortran -march=native -ffast-math -funroll-loops -fwhole-program -fno-protect-parens -O3 real0m5.115s / user0m5.071s / sys 0m0.015s gfortran -march=native -ffast-math -funroll-loops -flto -fwhole-program -fno-protect-parens -O3 real0m7.225s / user0m7.129s / sys 0m0.017s For the other test cases, the results are mostly similar w/ and w/o LTO though in tendency, the non-LTO version seems to be slightly slower (but also other programs are running now thus the results are not 100% comparable with my previous ones at https://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/iff/ )
[Bug target/45807] Lying eh_frame r2 save info causes crashes with static libgcc_eh and libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45807 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.09.27 10:27:49 date|| Ever Confirmed|0 |1
[Bug lto/45790] 1308 new GCC h...@164592 regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-09-27 10:31:13 UTC --- On powerpc64-unknown-linux-gnu, this problem seems to only affect the gcc.dg/vmx/* tests (see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02397.html ).
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch changed: What|Removed |Added CC||Joost.VandeVondele at pci ||dot uzh.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2010-09-27 10:39:05 UTC --- I have observed similar 40% slowdown in CP2K as a result of LTO. I haven't yet investigated.
[Bug lto/45810] 40% slowdown when using LTO for a single-file program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-27 10:48:33 UTC --- For single-file programs -fwhole-program and -flto should be basically equivalent if the Frontend provides correctly merged decls. I suppose it does not and thus we do less inlining with -fwhole-program compared to -flto.
[Bug other/45808] FreeBSD: -pthread is handled incompletely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45808 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-27 10:49:36 UTC --- Patches should be posted to gcc-patc...@gcc.gnu.org
[Bug target/45804] ARM: unnecessary sign extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45804 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||arm-*-* Component|c |target Severity|normal |enhancement
[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45801 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c++/45799] ICE + segfault when compiling Qt's WebKit JavaScriptCore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45799 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-27 11:07:26 UTC --- This has been fixed and there is a duplicate bug about this. I just can't find it because bugzilla is slow these days.
[Bug c++/45799] ICE + segfault when compiling Qt's WebKit JavaScriptCore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45799 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-27 11:08:35 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45580 it was.
[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-27 11:10:21 UTC --- Dup *** This bug has been marked as a duplicate of bug 44561 ***
[Bug c++/44561] using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44561 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-09-27 11:10:21 UTC --- *** Bug 45789 has been marked as a duplicate of this bug. ***
[Bug objc++/35551] internal compiler error: in encode_gnu_bitfield, at objc/objc-act.c:8175
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35551 --- Comment #3 from Lucas schnorr at gmail dot com 2010-09-27 11:52:44 UTC --- I am also having a problem to uncompact this file. Unfortunately, I no longer have the original source file that caused that error with gcc.
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Known to work||4.5.0 Target Milestone|4.5.2 |4.4.6
[Bug other/45806] gcc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45806 --- Comment #3 from terry at chem dot gu.se 2010-09-27 12:23:45 UTC --- I could see nothing in config.log that looked to my untrained eye like the problem, so I didn't attach it before. Here it is. What am I missing here?
[Bug web/45811] New: bugzilla: editing search loses host/target/build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45811 Summary: bugzilla: editing search loses host/target/build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org Editing a search involving the host/target/build custom fields loses the search string in those fields. http://gcc.gnu.org/bugzilla/query.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDcf_gcctarget=m68kcf_gcctarget_type=allwordssubstrcf_known_to_fail_type=allwordscf_known_to_work_type=allwordsquery_format=advanced
[Bug other/45806] gcc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45806 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-09-27 12:31:53 UTC --- That looks like the top-level log, the problem is while configuring libgcc, so you need to look in i686-pc-linux-gnu/libgcc/config.log
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445 --- Comment #22 from Bernd Schmidt bernds at gcc dot gnu.org 2010-09-27 12:45:36 UTC --- Thanks, that's very well done. I've investigated a bit, and it seems the sequence mark_pseudo_regno_live (REGNO (reg)); mark_pseudo_regno_live (REGNO (dreg)); mark_pseudo_regno_dead (REGNO (reg)); mark_pseudo_regno_dead (REGNO (dreg)); in make_pseudo_conflict is breaking lifetimes of subwords of one of the DImode registers. Not entirely sure yet how to fix it, but I'll think of something.
[Bug other/45806] gcc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45806 terry at chem dot gu.se changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #5 from terry at chem dot gu.se 2010-09-27 13:13:43 UTC --- OK, this is a bit strange. The offending error is: /home/tjf/InstallTrees/gcc-4.5.1-build/./gcc/cc1: error while loading shared libraries: libmpc.so.2: cannot open shared object file: No such file or directory Now libmpc.so.2 - libmpc.so.2.0.0 both exist in /usr/local/lib, along with all the other libraries that are regularly linked to. Back up in the top-level config.log we have configure:5665: gcc -o conftest -g -O2conftest.c -lmpc -lmpfr -lgmp 5 which worked happily. /usr/local/lib is listed in /etc/ld.so.conf.d/libc.conf and usually works. LD_LIBRARY_PATH is unset. Explicitly setting LD_LIBRARY_PATH to /usr/local/lib has gcc compiling past this point as we speak. I've never before had library path issues on this machine. On a very similar x86_64 machine (that has LD_LIBRARY_PATH explicitly set by default) 4.5.1 compiled without issue. I'll close this now, but will nonetheless welcome any comments anyone wants to make that might shed light on why my configuration appears to have gone selectively bung.
[Bug other/45806] gcc build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45806 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 2010-09-27 14:02:11 UTC --- Perhaps you didn't run /sbin/ldconfig after installing libmpc.so.2 into /usr/local/lib ?
[Bug other/44803] LIBRARY_PATH should work on cross-compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44803 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Component|c |other --- Comment #3 from Felipe Contreras felipe.contreras at gmail dot com 2010-09-27 01:28:24 UTC --- Is this not clear? It would be useful to cross-compile like this: export C_INCLUDE_PATH=/opt/arm/ffmpeg/include export LIBRARY_PATH=/opt/arm/ffmpeg/lib But LIBRARY_PATH is ignored.
[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #5 from Atsushi Nemoto anemo at mba dot ocn.ne.jp 2010-09-27
15:48:32 UTC ---
Here is a similar test case with packed attribute, which still produces bad
result.
Four load-byte instructions are generated instead of one load-word.
struct st {
int ptr;
} __attribute__ ((packed));
int foo(struct st *st)
{
int v = *(volatile int *)st-ptr;
return v 0xff;
}
gcc 4.4.4 works fine (same result with the first test case)
gcc 4.6.0 20100927 (or 4.5.2 20100927) generates:
lbu$2,0($4)
lbu$3,1($4)
andi$2,$2,0x00ff
lbu$3,2($4)
lbu$3,3($4)
j$31
nop
I do not know this should be another PR or not.
[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #6 from rguenther at suse dot de rguenther at suse dot de
2010-09-27 15:54:06 UTC ---
On Mon, 27 Sep 2010, anemo at mba dot ocn.ne.jp wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #5 from Atsushi Nemoto anemo at mba dot ocn.ne.jp 2010-09-27
15:48:32 UTC ---
Here is a similar test case with packed attribute, which still produces bad
result.
Four load-byte instructions are generated instead of one load-word.
struct st {
int ptr;
} __attribute__ ((packed));
int foo(struct st *st)
{
int v = *(volatile int *)st-ptr;
return v 0xff;
}
gcc 4.4.4 works fine (same result with the first test case)
gcc 4.6.0 20100927 (or 4.5.2 20100927) generates:
lbu$2,0($4)
lbu$3,1($4)
andi$2,$2,0x00ff
lbu$3,2($4)
lbu$3,3($4)
j$31
nop
I do not know this should be another PR or not.
It should be as this is likely a problem with unaligned access
support. I think you can't generally expect unaligned volatile
accesses to work (on ia64 for example they certainly wouldn't).
[Bug debug/45088] pointer type information lost in debuginfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45088 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #2 from Ulrich Weigand uweigand at gcc dot gnu.org 2010-09-27 16:19:31 UTC --- Any update on this bug? I'm seeing this in 4.5 as well ...
[Bug c/45779] pointer difference error/ptrdiff_t representability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45779 --- Comment #1 from Alexander aklauer at rumms dot uni-mannheim.de 2010-09-27 16:20:48 UTC --- While fiddling around a bit more I found that gcc normally doesn't let me create objects whose size exceeds PTRDIFF_MAX. For objects of size at most PTRDIFF_MAX, the bug cannot be triggered. The only function I found which does create such large objects is malloc(). Presumably, its companions calloc() and realloc() do so as well. In this light, the best fix for this bug seems to be for malloc() and companions to simply return NULL upon a request for an object whose size exceeds PTRDIFF_MAX.
[Bug debug/45088] pointer type information lost in debuginfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45088 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-09-27 16:22:18 UTC --- is this another dup of PR 43628? should be fixed if it is
[Bug debug/45088] pointer type information lost in debuginfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45088 --- Comment #4 from Ulrich Weigand uweigand at gcc dot gnu.org 2010-09-27 16:25:01 UTC --- (In reply to comment #3) is this another dup of PR 43628? should be fixed if it is No, unfortunately it's not. In mainline and 4.5 (which have the 43628) fix, all other GDB C++ test suite regressions over 4.4 are fixed, *except* for the one described in this bug report.
[Bug target/45804] ARM: unnecessary sign extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45804 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rearnsha at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2010-09-27 16:30:35 UTC --- This particular case is invalid. The ARM ABI requires that short and char result types are extended to 32 bits (using signed or unsigned extension as appropriate) before being returned. Since the compiler can't see inside the asm block to work out what is being done it cannot remove the uxth instruction on the result. This does not mean that some of your x-refed reports are invalid though.
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.09.24 18:33:22 date|| Ever Confirmed|0 |1 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-24 18:33:22 UTC --- Waiting for feedback asked for in comment #1. --- Comment #5 from Frank Ch. Eigler fche at redhat dot com 2010-09-27 16:34:50 UTC --- test test test
[Bug web/45782] bugzilla internal error trying to update existing PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45782 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added CC||fche at redhat dot com, ||LpSolit at netscape dot net See Also||https://bugzilla.mozilla.or ||g/show_bug.cgi?id=599890 --- Comment #2 from Frédéric Buclin LpSolit at netscape dot net 2010-09-27 16:39:16 UTC --- About the error being thrown, we do it intentionally, but I agree we shouldn't. I filed bug 599890 upstream. About java-prs, I don't see why it only fails with this email recipient. http://gcc.gnu.org/ml/java-prs/2010-q3/ indeed shows that no bugmail has been sent to this mailing-list since I upgraded Bugzilla. Looks like the move from Qmail to SMTP is blocked for this recipient for some reason.
[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.09.24 18:33:22 date|| Ever Confirmed|0 |1 Frank Ch. Eigler fche at redhat dot com changed: What|Removed |Added CC||fche at redhat dot com --- Comment #4 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-24 18:33:22 UTC --- Waiting for feedback asked for in comment #1. --- Comment #5 from Frank Ch. Eigler fche at redhat dot com 2010-09-27 16:34:50 UTC --- test test test --- Comment #6 from Frank Ch. Eigler fche at redhat dot com 2010-09-27 17:05:17 UTC --- test test test
[Bug libgcj/44341] [4.6 Regression] libjava cross build fails when configured with --with-gmp=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44341 Chris Faylor cgf at gcc dot gnu.org changed: What|Removed |Added CC||cgf at gcc dot gnu.org --- Comment #1 from Chris Faylor cgf at gcc dot gnu.org 2010-09-27 17:18:01 UTC --- additional comment to check mail to java-prs.
[Bug libgcj/44341] [4.6 Regression] libjava cross build fails when configured with --with-gmp=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44341 --- Comment #2 from Chris Faylor cgf at gcc dot gnu.org 2010-09-27 17:23:18 UTC --- once again. sorry for the noise.
[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2010-09/msg02097.htm |atches/2010-09/msg02117.htm |l |l --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-09-27 17:34:15 UTC --- For the record, updated patch URL to point to Bernds patch.
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #18 from Rainer Orth ro at gcc dot gnu.org 2010-09-27 17:44:09 UTC --- *-*-solaris2* is equally affected. There doesn't even exist a static libm.a. For other LTO tests, this is handled by lib/lto.exp (lto_init) which temporarily removes -lm from the link.
[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45658 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2010-09-27 17:46:29 UTC --- Jan, this bug is now open for two weeks with no indication of any progress. It breaks Ada bootstrap on a primary platform, so please fix or revert your patch. Rainer
[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45612 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2010-09-27 17:48:14 UTC --- Jan, again, no progress at all for 2 1/2 weeks on a bootstrap failure on a primary platform. Please fix or revert. Rainer
[Bug web/45802] [bugzilla] driver component description needs updating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45802 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Last reconfirmed||2010-09-27 date|| Resolution||FIXED AssignedTo|unassigned at gcc dot |LpSolit at netscape dot net |gnu.org | --- Comment #1 from Frédéric Buclin LpSolit at netscape dot net 2010-09-27 17:50:18 UTC --- done.
[Bug web/45811] bugzilla: editing search loses host/target/build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45811 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.27 17:52:19 date|| CC||LpSolit at netscape dot net Ever Confirmed|0 |1 --- Comment #1 from Frédéric Buclin LpSolit at netscape dot net 2010-09-27 17:52:19 UTC --- Hum yes, indeed.
[Bug objc/27377] [4.3/4.4 Regression] false compiler warnings generated in Objective-C code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27377 --- Comment #13 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 18:04:14 UTC --- Author: nicola Date: Mon Sep 27 18:04:09 2010 New Revision: 164655 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164655 Log: In gcc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. Removed small change in build_conditional_expr that had been added when fixing PR objc/27377 and which did the same check in a less complete way. 2005-12-15 Fariborz Jahanian fjahan...@apple.com Radar 4229905 * c-typeck.c (build_conditional_expr): Call objc_have_common_type when looking for objective-c common pointer types. 2005-06-22 Ziemowit Laski zla...@apple.com Radar 4154928 * c-typeck.c (build_conditional_expr): For two ObjC pointer types, use their ObjC common type. In gcc/c-family: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. 2005-12-15 Fariborz Jahanian fjahan...@apple.com Radar 4229905 * c-common.h (objc_have_common_type): New declaration. * stub-objc.c (objc_have_common_type): New stub. 2005-06-22 Ziemowit Laski zla...@apple.com Radar 4154928 * c-common.h (objc_common_type): New prototype. * stub-objc.c (objc_common_type): New stub. In gcc/objc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. 2005-12-15 Fariborz Jahanian fjahan...@apple.com Radar 4229905 * objc-act.c (objc_have_common_types): New function. 2005-06-22 Ziemowit Laski zla...@apple.com Radar 4154928 * objc-act.c (objc_common_type): New function. In gcc/cp/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from apple/trunk branch on FSF servers: 2005-12-15 Fariborz Jahanian fjahan...@apple.com Radar 4229905 * typeck.c (composite_pointer_type): Call objc_have_common_type when comparing two objective-c pointer types. 2005-06-22 Ziemowit Laski zla...@apple.com Radar 4154928 * call.c (standard_conversion): Allow for a pointer conversion between any two ObjC pointer types. * typeck.c (composite_pointer_type): Determine common type for two ObjC pointer types. In gcc/testsuite/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. Renamed const-str-12.m to constr-str-12b.m to avoid conflicts. 2005-12-15 Fariborz Jahanian fjahan...@apple.com Radar 4229905 * obj-c++.dg/warn5.mm: New 2005-06-22 Ziemowit Laski zla...@apple.com Radar 4154928 * obj-c++.dg/const-str-12.mm: New. * objc.dg/const-str-12.m: New. Added: trunk/gcc/testsuite/obj-c++.dg/const-str-12.mm trunk/gcc/testsuite/obj-c++.dg/warn5.mm trunk/gcc/testsuite/objc.dg/const-str-12b.m Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c-family/stub-objc.c trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/typeck.c trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c trunk/gcc/testsuite/ChangeLog
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.09.27 18:12:02 date|| CC||iains at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2010-09-27 18:12:02 UTC --- A reghunt revealed that this patch 2010-06-09 Iain Sandoe ia...@gcc.gnu.org PR bootstrap/43170 * tls.m4 (GCC_CHECK_TLS): Add volatile qualifier to the test references. Move the main () test reference ahead of pthread_create(). Add a comment to explain the requirements of the test. is the culprit. After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 has TLS support. I've yet to determine how the change could have this effect.
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-27 18:14:21 UTC --- After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 has TLS support. No it should be detected that way as it has emulated TLS support.
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2010-09-27 18:21:04 UTC --- --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-27 18:14:21 UTC --- After it, libstdc++-v3/configure incorrectly concludes that alpha-dec-osf5.1 has TLS support. No it should be detected that way as it has emulated TLS support. But that support was present before, and still GCC_CHECK_TLS didn't detect it before Iain's patch. Something is certainly fishy here... Rainer
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2010-09-27 18:26:54 UTC --- (In reply to comment #3) But that support was present before, and still GCC_CHECK_TLS didn't detect it before Iain's patch. Something is certainly fishy here... His patch was explicitly to fix checking for TLS when emulated TLS was used. Sometimes it would detect it as working and other times it would not.
[Bug target/45805] VFP/Neon double precision register expected -- `vmovl.s16 q2,s8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 --- Comment #2 from Khem Raj raj.khem at gmail dot com 2010-09-27 18:33:58 UTC --- (In reply to comment #1) Created attachment 21897 [details] Fix register specifier in instruction template for vmovl. I tried similar patch locally before submitting the bug (changed only vmovl pattern) but I got an ICE which is again same I am getting with this patch too $ arm-none-linux-gnueabi-gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon a.c -O3 a.c: In function ‘try_8x8basis_c’: a.c:14:1: internal compiler error: output_operand: invalid operand for code 'P'
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 2010-09-27 18:34:46 UTC --- (In reply to comment #4) (In reply to comment #3) But that support was present before, and still GCC_CHECK_TLS didn't detect it before Iain's patch. Something is certainly fishy here... His patch was explicitly to fix checking for TLS when emulated TLS was used. Sometimes it would detect it as working and other times it would not. As I recall, the patch was to circumvent a race condition - which manifest most frequently in the decision as to whether libgomp used TLS or not. It's odd that after this time a problem should show in libstdc++ (which was never, AFAIR flagged up in the original problem series). As for a platform with TLS - Darwin is regularly testing libstdc++ on powepc, and x86 .. so there must be some corner case at work.
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2010-09-27 18:40:36 UTC --- As I recall, the patch was to circumvent a race condition - which manifest most frequently in the decision as to whether libgomp used TLS or not. I see no indications of this sort of problem here: before your patch, TLS support was reliably/consistently detected to be missing, now it's reliably found to be present. It's odd that after this time a problem should show in libstdc++ (which was never, AFAIR flagged up in the original problem series). I had noticed the problem (all C++ EH tests failing on Tru64 UNIX) before, but only now found the time to investigate. There are no other serious testsuite regressions caused by the patch as far as I can see. As for a platform with TLS - Darwin is regularly testing libstdc++ on powepc, and x86 .. so there must be some corner case at work. As is Solaris 8 and 9 without GNU as, which use emutls as well.
[Bug target/45804] ARM: unnecessary sign extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45804 --- Comment #2 from Felipe Contreras felipe.contreras at gmail dot com 2010-09-27 19:02:19 UTC --- (In reply to comment #1) This particular case is invalid. The ARM ABI requires that short and char result types are extended to 32 bits (using signed or unsigned extension as appropriate) before being returned. Since the compiler can't see inside the asm block to work out what is being done it cannot remove the uxth instruction on the result. What do you mean by returned? This is an inline function, so it depends entirely on what the referencing code is doing whether or not this value is returned, as function return. Say: if ((read16_be(data) 0xfffe) == 0xfff8) This does not mean that some of your x-refed reports are invalid though. Come again?
[Bug web/45811] bugzilla: editing search loses host/target/build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45811 Frédéric Buclin LpSolit at netscape dot net changed: What|Removed |Added See Also||https://bugzilla.mozilla.or ||g/show_bug.cgi?id=599953 --- Comment #2 from Frédéric Buclin LpSolit at netscape dot net 2010-09-27 19:04:36 UTC --- This is an upstream bug.
[Bug objc/25464] objc_sizeof_type vs zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25464 --- Comment #6 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 19:22:17 UTC --- Author: nicola Date: Mon Sep 27 19:22:13 2010 New Revision: 164659 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164659 Log: In gcc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com * doc/objc.texi (Type encoding): Added the new 'long double' (D) code. Added byref, which was missing in the list of codes. Explain that enumeration values are encoded as the integer type that the compiler uses to store them. Explain and make examples of how 'const' interacts with pointers, and the complication of the encoding of 'const char *'. (Legacy type encoding): New subsection, explaining that GCC emits incorrect type encodings for the NeXT runtime for compatibility reasons. (@@encode): New subsection, explaining @encode and particularly that protocol qualifiers are not recognized inside an @encode() expression. (Method signatures): New subsection, explaining how method signatures are encoded. In gcc/objc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/45763 PR objc/25450 PR objc/25464 * objc-act.c: Improved comments for encoding functions. (encode_aggregate_within): For the GNU runtime, rewritten some obsfuscated code to clarify the various cases. (encode_aggregate): Function removed. (encode_array): Generate an error if asked to encode an incomplete array as part of generating instance variables. Else, when encoding an incomplete array inside a structure, encode it as an array of zero size. (encode_pointer): For the GNU runtime, fixed encoding 'BOOL *' as '^c' instead of '*'. (encode_gnu_bitfield): Encode enumerated types exactly in the same type as integer types instead of using a hardcoded 'i'. If asked to encode a non-integer type as a bitfield, do not abort compilation immediately; instead generate an error, then skip the type. (encode_type): Use a 'switch' instead of a sequence of 'if's. Added a 'default' clause that gets executed if the type can not be matched, and that encodes it as '?' (unknown) and produces a warning. For the GNU runtime, encode enumerated types exactly in the same way as integer types instead of using a hardcoded 'i'. Encode long double as 'D'. Encode 128-bit integers as 'T' or 't'. Encode C++ reference types as pointers. Call encode_vector to encode vectors. (encode_vector): New function. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. I modified the changes to be used only when compiling for the NeXT runtime. 2005-10-10 Fariborz Jahanian fjahan...@apple.com Radar 4301047 * objc-act.c (encode_type): Remove the hack. 2005-07-20 Ziemowit Laski zla...@apple.com Radar 4136935 * objc-act.c (pointee_is_readonly): New function. (encode_pointer, encode_aggregate_within, encode_type): Attempt to emulate GCC 3.3 when generating type encodings. In gcc/testsuite/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/25464 * objc.dg/type-size-3.m: New test. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/45763 * objc.dg/encode-1.m: Execute the test with the GNU runtime as well. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/25450 * objc.dg/encode-3.m: Updated for fix of encoding of enums. * objc.dg/type-size-2.m: Same change. * obj-c++.dg/encode-5.mm: Same change. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. The original Changelogs are below. * objc.dg/encode-6.m: Execute the test only with the GNU runtime. * objc.dg/encode-6-next.m: New file (from encode-6.m in the branch). * objc.dg/encode-7-next.m: New file (from encode-7.m in the branch). * objc.dg/encode-7-next-64bit.m: New file (from encode-7-64bit.m in the branch). * objc.dg/proto-qual-1.m: Test the 3.3 ABI on NeXT (from proto-qual-1.m in the branch) and the normal ABI on GNU. * objc.dg/threedotthree-abi-1.m: New file (from the branch). Run the test only with the NeXT runtime. * obj-c++/encode-1.mm: Execute the test only with the GNU runtime. * obj-c++/encode-1-next.mm: New file (from encode-1.mm in the branch). * obj-c++.dg/threedotthree-abi-1.mm: New file (from the branch). Run the test only with the NeXT runtime. 2006-03-30 Fariborz Jahanian fjahan...@apple.com
[Bug objc/45763] incorrect @encode(BOOL *)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45763 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 19:22:17 UTC --- Author: nicola Date: Mon Sep 27 19:22:13 2010 New Revision: 164659 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164659 Log: In gcc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com * doc/objc.texi (Type encoding): Added the new 'long double' (D) code. Added byref, which was missing in the list of codes. Explain that enumeration values are encoded as the integer type that the compiler uses to store them. Explain and make examples of how 'const' interacts with pointers, and the complication of the encoding of 'const char *'. (Legacy type encoding): New subsection, explaining that GCC emits incorrect type encodings for the NeXT runtime for compatibility reasons. (@@encode): New subsection, explaining @encode and particularly that protocol qualifiers are not recognized inside an @encode() expression. (Method signatures): New subsection, explaining how method signatures are encoded. In gcc/objc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/45763 PR objc/25450 PR objc/25464 * objc-act.c: Improved comments for encoding functions. (encode_aggregate_within): For the GNU runtime, rewritten some obsfuscated code to clarify the various cases. (encode_aggregate): Function removed. (encode_array): Generate an error if asked to encode an incomplete array as part of generating instance variables. Else, when encoding an incomplete array inside a structure, encode it as an array of zero size. (encode_pointer): For the GNU runtime, fixed encoding 'BOOL *' as '^c' instead of '*'. (encode_gnu_bitfield): Encode enumerated types exactly in the same type as integer types instead of using a hardcoded 'i'. If asked to encode a non-integer type as a bitfield, do not abort compilation immediately; instead generate an error, then skip the type. (encode_type): Use a 'switch' instead of a sequence of 'if's. Added a 'default' clause that gets executed if the type can not be matched, and that encodes it as '?' (unknown) and produces a warning. For the GNU runtime, encode enumerated types exactly in the same way as integer types instead of using a hardcoded 'i'. Encode long double as 'D'. Encode 128-bit integers as 'T' or 't'. Encode C++ reference types as pointers. Call encode_vector to encode vectors. (encode_vector): New function. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. I modified the changes to be used only when compiling for the NeXT runtime. 2005-10-10 Fariborz Jahanian fjahan...@apple.com Radar 4301047 * objc-act.c (encode_type): Remove the hack. 2005-07-20 Ziemowit Laski zla...@apple.com Radar 4136935 * objc-act.c (pointee_is_readonly): New function. (encode_pointer, encode_aggregate_within, encode_type): Attempt to emulate GCC 3.3 when generating type encodings. In gcc/testsuite/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/25464 * objc.dg/type-size-3.m: New test. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/45763 * objc.dg/encode-1.m: Execute the test with the GNU runtime as well. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/25450 * objc.dg/encode-3.m: Updated for fix of encoding of enums. * objc.dg/type-size-2.m: Same change. * obj-c++.dg/encode-5.mm: Same change. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. The original Changelogs are below. * objc.dg/encode-6.m: Execute the test only with the GNU runtime. * objc.dg/encode-6-next.m: New file (from encode-6.m in the branch). * objc.dg/encode-7-next.m: New file (from encode-7.m in the branch). * objc.dg/encode-7-next-64bit.m: New file (from encode-7-64bit.m in the branch). * objc.dg/proto-qual-1.m: Test the 3.3 ABI on NeXT (from proto-qual-1.m in the branch) and the normal ABI on GNU. * objc.dg/threedotthree-abi-1.m: New file (from the branch). Run the test only with the NeXT runtime. * obj-c++/encode-1.mm: Execute the test only with the GNU runtime. * obj-c++/encode-1-next.mm: New file (from encode-1.mm in the branch). * obj-c++.dg/threedotthree-abi-1.mm: New file (from the branch). Run the test only with the NeXT runtime. 2006-03-30 Fariborz Jahanian fjahan...@apple.com
[Bug objc/25450] Enums are encoded incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25450 --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 19:22:17 UTC --- Author: nicola Date: Mon Sep 27 19:22:13 2010 New Revision: 164659 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164659 Log: In gcc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com * doc/objc.texi (Type encoding): Added the new 'long double' (D) code. Added byref, which was missing in the list of codes. Explain that enumeration values are encoded as the integer type that the compiler uses to store them. Explain and make examples of how 'const' interacts with pointers, and the complication of the encoding of 'const char *'. (Legacy type encoding): New subsection, explaining that GCC emits incorrect type encodings for the NeXT runtime for compatibility reasons. (@@encode): New subsection, explaining @encode and particularly that protocol qualifiers are not recognized inside an @encode() expression. (Method signatures): New subsection, explaining how method signatures are encoded. In gcc/objc/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/45763 PR objc/25450 PR objc/25464 * objc-act.c: Improved comments for encoding functions. (encode_aggregate_within): For the GNU runtime, rewritten some obsfuscated code to clarify the various cases. (encode_aggregate): Function removed. (encode_array): Generate an error if asked to encode an incomplete array as part of generating instance variables. Else, when encoding an incomplete array inside a structure, encode it as an array of zero size. (encode_pointer): For the GNU runtime, fixed encoding 'BOOL *' as '^c' instead of '*'. (encode_gnu_bitfield): Encode enumerated types exactly in the same type as integer types instead of using a hardcoded 'i'. If asked to encode a non-integer type as a bitfield, do not abort compilation immediately; instead generate an error, then skip the type. (encode_type): Use a 'switch' instead of a sequence of 'if's. Added a 'default' clause that gets executed if the type can not be matched, and that encodes it as '?' (unknown) and produces a warning. For the GNU runtime, encode enumerated types exactly in the same way as integer types instead of using a hardcoded 'i'. Encode long double as 'D'. Encode 128-bit integers as 'T' or 't'. Encode C++ reference types as pointers. Call encode_vector to encode vectors. (encode_vector): New function. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. I modified the changes to be used only when compiling for the NeXT runtime. 2005-10-10 Fariborz Jahanian fjahan...@apple.com Radar 4301047 * objc-act.c (encode_type): Remove the hack. 2005-07-20 Ziemowit Laski zla...@apple.com Radar 4136935 * objc-act.c (pointee_is_readonly): New function. (encode_pointer, encode_aggregate_within, encode_type): Attempt to emulate GCC 3.3 when generating type encodings. In gcc/testsuite/: 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/25464 * objc.dg/type-size-3.m: New test. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/45763 * objc.dg/encode-1.m: Execute the test with the GNU runtime as well. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com PR objc/25450 * objc.dg/encode-3.m: Updated for fix of encoding of enums. * objc.dg/type-size-2.m: Same change. * obj-c++.dg/encode-5.mm: Same change. 2010-09-27 Nicola Pero nicola.p...@meta-innovation.com Merge from 'apple/trunk' branch on FSF servers. The original Changelogs are below. * objc.dg/encode-6.m: Execute the test only with the GNU runtime. * objc.dg/encode-6-next.m: New file (from encode-6.m in the branch). * objc.dg/encode-7-next.m: New file (from encode-7.m in the branch). * objc.dg/encode-7-next-64bit.m: New file (from encode-7-64bit.m in the branch). * objc.dg/proto-qual-1.m: Test the 3.3 ABI on NeXT (from proto-qual-1.m in the branch) and the normal ABI on GNU. * objc.dg/threedotthree-abi-1.m: New file (from the branch). Run the test only with the NeXT runtime. * obj-c++/encode-1.mm: Execute the test only with the GNU runtime. * obj-c++/encode-1-next.mm: New file (from encode-1.mm in the branch). * obj-c++.dg/threedotthree-abi-1.mm: New file (from the branch). Run the test only with the NeXT runtime. 2006-03-30 Fariborz Jahanian fjahan...@apple.com
[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45693 --- Comment #7 from Iain Sandoe iains at gcc dot gnu.org 2010-09-27 19:24:17 UTC --- (In reply to comment #6) As I recall, the patch was to circumvent a race condition - which manifest most frequently in the decision as to whether libgomp used TLS or not. I see no indications of this sort of problem here: before your patch, TLS support was reliably/consistently detected to be missing, now it's reliably found to be present. IIUC, comment #2 indicates that the platform should show as having (emulated) TLS. If that is so, the situation is that the problem you now see was masked by a faulty configure macro, fixed by the patch. I will try and dig out the test code we used to stress the TLS implementation - it might be worth running that on the alpha to see whether is shows a difference. (it's probably attached to 43170). IIRC the fix was quite heavily discussed on patches - there might be something useful in those threads.
[Bug objc++/35551] internal compiler error: in encode_gnu_bitfield, at objc/objc-act.c:8175
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35551 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #4 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 19:32:48 UTC --- Thanks - I'll close the bug as we can't reproduce it :-( If you manage to reproduce it, please open a new bug! :-) Thanks
[Bug objc/45763] incorrect @encode(BOOL *)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45763 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 19:33:55 UTC --- Fixed on trunk, including a testcase to test that it is fixed. ;-) Thanks
[Bug objc/25450] Enums are encoded incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25450 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 19:34:59 UTC --- Fixed in trunk. Thanks
[Bug objc/25464] objc_sizeof_type vs zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25464 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Nicola Pero nicola at gcc dot gnu.org 2010-09-27 19:35:46 UTC --- Fixed in trunk. Thanks
[Bug target/43358] [4.5 Regression] IRA: internal compiler error: in pool_free, at alloc-pool.c:335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43358 --- Comment #11 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2010-09-27 19:48:18 UTC --- Author: rsandifo Date: Mon Sep 27 19:48:13 2010 New Revision: 164660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164660 Log: gcc/ PR rtl-optimization/43358 * ira-lives.c (process_single_reg_class_operands): Adjust the costs of a single hard register, using simplify_subreg_regno to decide what that register should be. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/ira-lives.c
[Bug target/43764] -mrelax-pic-calls fails with complex types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43764 --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2010-09-27 19:48:39 UTC --- Author: rsandifo Date: Mon Sep 27 19:48:35 2010 New Revision: 164662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164662 Log: gcc/ Backport from mainline: 2010-05-19 James E. Wilson wil...@codesourcery.com PR target/43764 * config/mips/mips.c (mips_call_expr_from_insn): New arg second_call. Set it. (mips_annotate_pic_calls): Pass new arg to mips_call_expr_from_insn. Use it. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/mips/mips.c
[Bug target/43358] [4.5 Regression] IRA: internal compiler error: in pool_free, at alloc-pool.c:335
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43358 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2010-09-27 19:53:44 UTC --- Fixed in trunk and 4.5 branch.
[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-09-27 19:55:31 UTC --- Author: hp Date: Mon Sep 27 19:55:29 2010 New Revision: 164663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164663 Log: PR rtl-optimization/45792 * cfgcleanup.c (try_head_merge_bb): New rtx vector nextptr. If not all insns are to be merged, for each edge, stash the next candidate after the to-be-merged insns before doing the merge, and use them for the retry at the new insertion point. Handle CC0 targets when retrying. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c
[Bug rtl-optimization/45792] [4.6 Regression]: cris-elf build failure (hangs) due to fix for PR44374
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45792 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-09-27 19:58:07 UTC --- committed
[Bug bootstrap/44621] syntax error in gcc-4.5.0/configure for ksh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44621 --- Comment #5 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-09-27 20:19:48 UTC --- Author: rwild Date: Mon Sep 27 20:19:41 2010 New Revision: 164668 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164668 Log: Fix unportable shell quoting. /: PR bootstrap/44621 * configure.ac: Fix unportable shell quoting. * configure: Regenerate. config/: * po.m4 (AM_PO_SUBDIRS): Fix unportable shell quoting. contrib/reghunt/: * bin/gcc-svn-ids: Fix unportable shell quoting. * date_based/reg_periodic: Likewise. * date_based/reg_search: Likewise. intl/: PR bootstrap/44621 * configure: Regenerate. Modified: trunk/ChangeLog trunk/config/ChangeLog trunk/config/po.m4 trunk/configure trunk/configure.ac trunk/contrib/reghunt/ChangeLog trunk/contrib/reghunt/bin/gcc-svn-ids trunk/contrib/reghunt/date_based/reg_periodic trunk/contrib/reghunt/date_based/reg_search trunk/intl/ChangeLog trunk/intl/configure
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868 Fraxinas andreas.fri...@multimedia-labs.de changed: What|Removed |Added CC||andreas.fri...@multimedia-l ||abs.de --- Comment #12 from Fraxinas andreas.fri...@multimedia-labs.de 2010-09-23 22:36:05 UTC --- Hi Ralf, i tried destilling your rev 163580 patches into one accumulated backport to gcc-4.4.4. in our openembedded cross development toolchain. http://pastebin.com/pU3zF6MP the patch actually does apply correctly, but during compile time, fails in the libjava directory: ... libtool: link: ( cd .libs rm -f libgcj_bc.la ln -s ../libgcj_bc.la libgcj_bc.la ) /bin/bash: GCC_FOR_ECJX@: command not found turns out that the generated Makefile has the line GCC_FOR_ECJX = @GCC_FOR_ECJX@ in it, so the variable wasn't substituted correctly during configure, even though config.log says GCC_FOR_ECJX='x86_64-linux-gcc' i probably need to backport other parts to be able to apply this patch correctly on gcc release 4.4.4. but unfortunately the revision log http://gcc.gnu.org/viewcvs/trunk/libjava/configure.ac?view=logpathrev=163580 doesn't have information about the releases is there an easy way to find out what else i need? greetings, fraxinas --- Comment #13 from Andrew Haley aph at redhat dot com 2010-09-24 07:54:17 UTC --- On 23/09/10 23:36, andreas.fri...@multimedia-labs.de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868 Fraxinas andreas.fri...@multimedia-labs.de changed: What|Removed |Added CC||andreas.fri...@multimedia-l ||abs.de --- Comment #12 from Fraxinas andreas.fri...@multimedia-labs.de 2010-09-23 22:36:05 UTC --- Hi Ralf, i tried destilling your rev 163580 patches into one accumulated backport to gcc-4.4.4. in our openembedded cross development toolchain. http://pastebin.com/pU3zF6MP the patch actually does apply correctly, but during compile time, fails in the libjava directory: ... libtool: link: ( cd .libs rm -f libgcj_bc.la ln -s ../libgcj_bc.la libgcj_bc.la ) /bin/bash: GCC_FOR_ECJX@: command not found turns out that the generated Makefile has the line GCC_FOR_ECJX = @GCC_FOR_ECJX@ in it, so the variable wasn't substituted correctly during configure, even though config.log says GCC_FOR_ECJX='x86_64-linux-gcc' i probably need to backport other parts to be able to apply this patch correctly on gcc release 4.4.4. but unfortunately the revision log http://gcc.gnu.org/viewcvs/trunk/libjava/configure.ac?view=logpathrev=163580 doesn't have information about the releases is there an easy way to find out what else i need? It's hard to say. I'd just import libgcj from gcc trunk. Andrew.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #30 from Cesar Strauss cestrauss at gmail dot com 2010-09-27 02:00:39 UTC --- (In reply to comment #29) Dear Vadim The difference in number of sections seems to correspond to the fact that 4.5 now generates one section per method of any exported class used by the object file instead of just one section per class as in 4.4. Sorry, but I do not completely agree with this assessment. If you run objdump -h object | c++filt you will see that 4.4 still generates one section per method, not per class (the name of the method is reveled by c++filt). In my view, the difference is only that 4.5 emits a section for every inline method of every dllexported class in sight. 4.4 only emitted those which the code actually needed. Why there is one section for each emitted inline method? As I understand it, since the same inline method can be exported by multiple object files, there would be a danger of having multiple definitions at link time. To avoid this, they reside in separate sections marked as LINK_ONCE_DISCARD, so the linker can discard these multiple copies and keep just the first one encountered. To avoid all these copies in the first place, the idea from Yu Simin in comment #26 seems to be a good one. Regards, Cesar
[Bug target/45804] ARM: unnecessary sign extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45804 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2010-09-27 21:52:38 UTC --- (In reply to comment #2) What do you mean by returned? This is an inline function, so it depends entirely on what the referencing code is doing whether or not this value is returned, as function return. You didn't cite any context of the use. Just a single function.
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868 --- Comment #15 from Fraxinas andreas.fri...@multimedia-labs.de 2010-09-27 21:57:43 UTC --- (In reply to comment #14) Created attachment 21898 [details] backport This is the backport I use against gcc-4.4 dear dima, thanks for that patch but it's not sufficient. it even applies and configures right but too many things had changed between release 4.4.4 and revision 163580. so the resulting generated makefile is faulty and leaves the variable @GCC_FOR_ECJX@ unsubtituted which causes compile to fail. instead, i did it like Andrew proposed and simply imported the entire libjava directory from svn head with which it works correctly. now i am struggeling to cross compile statically linked mipsel java code with a c++ .so linked to it...
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868 --- Comment #16 from Dima dmitrij.ledkov at ubuntu dot com 2010-09-27 22:13:18 UTC --- (In reply to comment #15) (In reply to comment #14) Created attachment 21898 [details] [details] backport This is the backport I use against gcc-4.4 dear dima, thanks for that patch but it's not sufficient. it even applies and configures right but too many things had changed between release 4.4.4 and revision 163580. so the resulting generated makefile is faulty and leaves the variable @GCC_FOR_ECJX@ unsubtituted which causes compile to fail. This patch does apply against snapshot gcc-4.4 branch 26-09-2010. And does build libgcj java cross-compiler from i386|x86_64-gnu-linux to i686-w64-mingw32. After the patch is applied you do need to rerun correct autoreconf (2.59). Buildlog - http://launchpadlibrarian.net/56490712/buildlog_ubuntu-lucid-i386.w64-toolchain_1.0b%2B201009260029-0w2228g93841b22110p11~lucid1_FULLYBUILT.txt.gz
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #31 from Vadim Zeitlin vz-gcc at zeitlins dot org 2010-09-27 22:42:55 UTC --- (In reply to comment #30) Sorry, but I do not completely agree with this assessment. If you run objdump -h object | c++filt you will see that 4.4 still generates one section per method, not per class (the name of the method is reveled by c++filt). This is somewhat off topic but unfortunately (MinGW) c++filt doesn't work for me, e.g.: % echo '.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe .text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv I don't know what could be wrong with it but, anyhow, you're right, of course, and I was wrong (I managed to look at the classes whose methods were not used by the object file I was checking...), sorry for misinformation and thanks for correcting it! In my view, the difference is only that 4.5 emits a section for every inline method of every dllexported class in sight. 4.4 only emitted those which the code actually needed. Yes, exactly. Why there is one section for each emitted inline method? Excellent question which I'm unfortunately totally unable to answer.
[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677 --- Comment #11 from Dan Witte dwitte at gmail dot com 2010-09-27 23:40:05 UTC --- Jakub -- did you commit this fix to gcc's libffi? If not, I'll push upstream to Anthony.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #32 from Cesar Strauss cestrauss at gmail dot com 2010-09-28 00:16:48 UTC --- (In reply to comment #31) This is somewhat off topic but unfortunately (MinGW) c++filt doesn't work for me, e.g.: % echo '.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe .text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv Try echo '__ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe Anyway, look at the end of each line of objdump -h object | c++filt, where it says 'COMDAT name of method'. Why there is one section for each emitted inline method? Excellent question which I'm unfortunately totally unable to answer. When two or more source files include the same header, the exported inline functions end up duplicated in both object files. When linking these objects together in the final DLL, the linker would give an error because of the multiple definitions. To avoid this, each exported inline function is placed in a separate section, identified by the COMDAT name. When the linker sees two or more sections with the same COMDAT name, it can safely keep one of them and discard the rest.
[Bug tree-optimization/45656] [4.6 Regression]: gfortran.dg/forall_4.f90 -O3, wrong code with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45656 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Summary|[4.5 Regression]: |[4.6 Regression]: |gfortran.dg/forall_4.f90|gfortran.dg/forall_4.f90 |-O3, wrong code with -g |-O3, wrong code with -g --- Comment #10 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-09-28 00:40:30 UTC --- Any chance of the tested patch being submitted to gcc-patches soon? (Also, corrected title).
[Bug rtl-optimization/45813] New: alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813
Summary: alias analysis problem ?
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: darrenrjenk...@gmail.com
I think I am having some wrong code generated due to a compiler bug.
I am compiling for ARM/Thumb.
USB_INT16U ReadLE16U ( volatile USB_INT08U *pmem )
{
USB_INT16U val;
USB_INT08U *bytes = (USB_INT08U *)val;
bytes[0] = pmem[0];
bytes[1] = pmem[1];
return (val);
}
gives me
B580push {r7, lr}
B081sub sp, #4
AF00add r7, sp, #0
1CBBadds r3, r7, #2
7802ldrb r2, [r0, #0]
701Astrb r2, [r3, #0]
7842ldrb r2, [r0, #1]
8818ldrh r0, [r3, #0]
46BDmov sp, r7
B001add sp, #4
BC80pop {r7}
BC02pop {r1}
4708bx r1
Which reads the second byte into r2 but does not store it on the stack, so the
second byte of val is returned uninitialized.
It looks like the alias analysis knows that bytes points to val but doesn't
know that bytes+1 points to a part of val also, so optimizes it away.
Yell out if you need any more information
[Bug target/45814] New: ICE in extract_insn, at recog.c:2127
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45814 Summary: ICE in extract_insn, at recog.c:2127 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: i686-linux-gnu Target: arm-unknown-linux-gnu Build: i686-linux-gnu Created attachment 21900 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21900 preprocessed source $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnu Configured with: ../configure --target=arm-unknown-linux-gnu --prefix=/home/ryan/x-tools/arm-unknown-linux-gnu --with-headers=/home/ryan/x-tookls/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include --with-local-prefix=/home/ryan/xtools/arm-unknown-linux-gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --enable-shared --enable-c99 --enable-long-long --enable-checking=all Thread model: posix gcc version 4.6.0 20100928 (experimental) [trunk revision 164675] (GCC) $ ./xgcc -B. -march=armv6 -mfpu=vfp -mfloat-abi=softfp -O3 ~/ice.i -mapcs-frame /home/ryan/ice.i: In function 'SendTg': /home/ryan/ice.i:25:7: warning: incompatible implicit declaration of built-in function 'memset' [enabled by default] /home/ryan/ice.i:39:1: error: unrecognizable insn: (insn 155 154 156 6 (set (reg:HI 4 r4) (reg:SI 77 s14)) /home/ryan/ice.i:30 -1 (nil)) /home/ryan/ice.i:39:1: internal compiler error: in extract_insn, at recog.c:2127 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Also happens with gnueabi and -mapcs-frame (I can't imagine why anyone would want to do that).
[Bug other/45808] FreeBSD: -pthread is handled incompletely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45808 --- Comment #3 from Andriy Gapon avg at icyb dot net.ua 2010-09-28 05:26:24 UTC --- (In reply to comment #2) Patches should be posted to gcc-patc...@gcc.gnu.org And, in fact, I did that a (short?) while ago: http://thread.gmane.org/gmane.comp.gcc.patches/217482/focus=217484 But it seems that nobody has picked it so far. Perhaps I am the one to blame for that given the incorrect attachments.
