[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #9 from doko at ubuntu dot com 2010-05-27 06:22 --- (From update of attachment 20753) wrong attachment -- doko at ubuntu dot com changed: What|Removed |Added Attachment #20753|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #10 from doko at ubuntu dot com 2010-05-27 06:23 --- Created an attachment (id=20758) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20758action=view) preprocessed source preprocessed source, which builds with 4.3.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug tree-optimization/44290] New: arm linux kernel crahes when built with -fipa-sra
While trying to boot linux 2.6.34 built with gcc from latest gcc-4_5-branch the kernel would not boot. Same kernel would work fine with gcc 4.4.4 Reducing to individual optimization phases. So far I have seen that when compiled with -O2 the kernel crashes however when I change the flags to -O2 -fno-ipa-sra then it works well. I don't have a small test-case as of now. I am trying to reduce it but it might take some time. Meanwhile I wanted to open the bug so that if someone else has information on similar issue can chime in. -- Summary: arm linux kernel crahes when built with -fipa-sra Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-none-linux-uclibcgnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #11 from doko at gcc dot gnu dot org 2010-05-27 06:30 --- Subject: Bug 39580 Author: doko Date: Thu May 27 06:29:55 2010 New Revision: 159909 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159909 Log: 2010-05-27 Matthias Klose d...@ubuntu.com Backport from mainline: 2009-04-22 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/39580 * sel-sched-ir.c (insert_in_history_vect): Remove incorrect gcc_assert. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/sel-sched-ir.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug tree-optimization/44290] arm linux kernel crahes when built with -fipa-sra
--- Comment #1 from raj dot khem at gmail dot com 2010-05-27 07:06 --- Created an attachment (id=20759) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20759action=view) preprocessed testcase OK so here is one file which whic is compiled with -O2 -fno-ipa-sra and rest of kernel with -O2 and it works ok. So something is going wrong in this file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] arm linux kernel crahes when built with -fipa-sra
--- Comment #2 from raj dot khem at gmail dot com 2010-05-27 07:12 ---
here is diff of two assembly outputs
$ diff copypage-v4wb.s copypage-v4wb.no-ipa-sra.S -u
--- copypage-v4wb.s 2010-05-27 00:11:03.130607878 -0700
+++ copypage-v4wb.no-ipa-sra.S 2010-05-27 00:10:54.790615578 -0700
@@ -120,19 +120,30 @@
v4wb_copy_user_highpage:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
- stmfd sp!, {r4, lr}
- mov r1, sp
- bic r4, r1, #8128
+ stmfd sp!, {r4, r5, r6, lr}
+ mov ip, sp
+ bic r4, ip, #8128
bic r4, r4, #63
- ldr r1, [r4, #4]
- add r1, r1, #1
- str r1, [r4, #4]
- ldr r1, [r4, #4]
- add r1, r1, #1
- str r1, [r4, #4]
- ldr r1, [r3, #0]
- ldr r1, [r1, #332]
- tst r1, #1
+ ldr ip, [r4, #4]
+ add ip, ip, #1
+ str ip, [r4, #4]
+ ldr ip, .L8
+ ldr lr, [r4, #4]
+ ldr r6, [ip, #0]
+ add lr, lr, #1
+ rsb r6, r6, r0
+ mov r6, r6, asr #5
+ mov r6, r6, asl #12
+ add r6, r6, #-1073741824
+ str lr, [r4, #4]
+ ldr r5, [ip, #0]
+ ldr r0, [r3, #0]
+ rsb r5, r5, r1
+ ldr r0, [r0, #332]
+ mov r5, r5, asr #5
+ mov r5, r5, asl #12
+ tst r0, #1
+ add r5, r5, #-1073741824
beq .L6
bic r2, r2, #4080
bic r0, r2, #15
@@ -140,6 +151,8 @@
ldr r2, [r3, #20]
bl arm926_flush_user_cache_range
.L6:
+ mov r0, r6
+ mov r1, r5
bl v4wb_copy_user_page
ldr r3, [r4, #4]
sub r3, r3, #1
@@ -147,7 +160,11 @@
ldr r3, [r4, #4]
sub r3, r3, #1
str r3, [r4, #4]
- ldmfd sp!, {r4, pc}
+ ldmfd sp!, {r4, r5, r6, pc}
+.L9:
+ .align 2
+.L8:
+ .word mem_map
.size v4wb_copy_user_highpage, .-v4wb_copy_user_highpage
.global v4wb_user_fns
.section.init.data,aw,%progbits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug target/43892] PowerPC suboptimal add with carry optimization
--- Comment #17 from joakim dot tjernlund at transmode dot se 2010-05-27 07:33 --- (In reply to comment #16) You have no patience, now do you? Sure I do. It is just that its been almost a month and from the description it sounded like an easy fix: config/rs6000/rs6000.md would need to add a addmodecc expander No you do not have any patience; in fact, your comments are rather obnoxious, such as: its been almost a month. If you do not know what you are talking about, stop talking. No, it is not an easy fix. The high-level concept and description is simple, the implementation is extremely complex and tedious. Oops, sorry if I sounded obnoxious. Of course I don't know what I am talking about. I am not a gcc dev. and gcc is a complex piece of SW but I don't think I should just shut up either. Now that you have made it clear what is involved I will stop pestering you, I was hoping you would have a small patch for me to test but I see now that it won't happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-27 08:14 --- Subject: Bug 44287 Author: ktietz Date: Thu May 27 08:13:58 2010 New Revision: 159912 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159912 Log: gcc/cp/ 2010-05-27 Kai Tietz kai.ti...@onevision.com PR bootstrap/44287 * rtti.c (emit_support_tinfos): Check for NULL_TREE. * class.c (layout_class_type): Likewise. * decl.c (finish_enum): Likewise. * mangle.c (write_builitin_type): Likewise. gcc/ 2010-05-27 Kai Tietz kai.ti...@onevision.com PR bootstrp/44287 * c-lex.c (narrowest_unsigned_type): Check for NULL_TREE. (narrow_signed_type): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/c-lex.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/cp/rtti.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #2 from dg dot recrutement31 at gmail dot com 2010-05-27 08:31 --- (In reply to comment #1) I think your inline-asm is totally broken, the constraints you have don't mean the extended (32bit) registers. Humm... strange answer. Certainly, you've read too fast and too late in the evening. You think but it's better to demonstrate. How to explain the bug disappears when -g or -O0 turned on ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug bootstrap/44287] [4.6 Regression] Failed to bootstrap
--- Comment #12 from ktietz at gcc dot gnu dot org 2010-05-27 08:44 --- Fixed on trunk. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44287
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #3 from dg dot recrutement31 at gmail dot com 2010-05-27 09:03
---
(In reply to comment #2)
(In reply to comment #1)
I think your inline-asm is totally broken, the constraints you have don't
mean
the extended (32bit) registers.
Humm... strange answer. Certainly, you've read too fast and too late in the
evening.
You think but it's better to demonstrate.
How to explain the bug disappears when -g or -O0 turned on ?
To notice:
the bug disappears also if function toto is removed and its code moved in the
main function like this:
#include far_pointers.h
char u;
/*void toto(far_pointerunsigned char pt)
{
u = *pt;
}*/
int main(int argc, char **argv)
{
unsigned short dataSeg = 0;
asm (
\
.intel_syntax noprefix; \n\
mov %0, cs; \n\
: =r(dataSeg)
);
far_pointerunsigned char pt(dataSeg, (unsigned char*) main);
//toto(pt);
u = *pt;
return u;
}
The assembly is correctly generated:
.file main.cpp
.intel_syntax noprefix
.def___main;.scl2; .type 32; .endef
.text
.globl _main
.def_main; .scl2; .type 32; .endef
_main:
LFB30:
pushebp
LCFI0:
mov ebp, esp
LCFI1:
and esp, -16
LCFI2:
call___main
/APP
# 19 main.cpp 1
.intel_syntax
noprefix;
mov ax, cs;
# 0 2
# 59 far_pointers.h 1
.intel_syntax noprefix;
mov gs, ax;
mov al, gs:[OFFSET FLAT:_main];
# 0 2
/NO_APP
mov BYTE PTR _u, al
movsx eax, al
leave
LCFI3:
ret
LFE30:
.globl _u
.bss
_u:
.space 1
All these tests seem to demonstrate there is a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug target/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec
--- Comment #8 from ktietz at gcc dot gnu dot org 2010-05-27 09:48 --- Seems to be fixed by side-effect or by weird toolchain. I can't reproduce it anymore, too. So, I close this bug as works-for-me. Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-27 10:11 --- All the tests demonstrate is that you have buggy constraint, in particular you shouldn't use g constraint on something you use in gs:[%2]. g is any register (fine in that case), immediate (not fine) or memory (not fine either in this case). mov al, gs:[DWORD PTR [ebp+12]] is what you get when this-offset is memory at ebp+12, and that of course doesn't assemble. Just use r. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug middle-end/44276] [4.6 Regression]: gcc.dg/tls/alias-1.c
--- Comment #10 from iains at gcc dot gnu dot org 2010-05-27 10:12 --- (In reply to comment #4) This also occurs on hppa64-hp-hpux11.11. Does the patch @ comment #6 resolve this for you? If so, and there are no more targets reporting the issue, I will post to gcc-patches as a proposed fix. thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44276
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #5 from dg dot recrutement31 at gmail dot com 2010-05-27 10:18 --- It is the -ftree-ter option that causes this incorrect behavior. And this option, sole: Other optimizations options (O1, O2 and O3) together don't generate wrong assembly code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #31 from redi at gcc dot gnu dot org 2010-05-27 10:21 --- (In reply to comment #23) I can't see any 100% reliable way to prevent this problem, because the catch-all specialisation of iterator_traits can be instantiated with non-iterator types. I was under the impression that the default specialisation of iterator_traits was meant to be catch-all, but Alisdair Meredith described his implementation and I realised that the definition in [iterator.traits]/2 applies to type Iterator and [iterator.traits]/1 says if Iterator is the type of an iterator So now I believe that we can (and should) restrict that specialisation to types that really are iterators. If iterator_traitsNotAnIterator::difference_type doesn't exist then SFINAE will apply and std::next/std::prev will not cause invalid instantiations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-27 10:40 --- Can you paste the output of gcc when adding -v to the commandline used for compiling copypage-v4wb.i in the failing case? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Summary|arm linux kernel crahes when|[4.5 Regression] arm linux |built with -fipa-sra|kernel crahes when built ||with -fipa-sra Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug middle-end/44291] New: [4.6 regression] ICE in set_user_assembler_libfunc
Building (a cross compiler) for ARM Linux currently breaks whilst building
GLIBC. I believe this is due to the following patch (r159321):
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00766.html
From this commit, the ARM build initially failed in a way identical to #44197
(an ICE in varpool_remove_node). Unfortunately the patch in that PR does not
fix the issue for ARM: from r159629, I get the following error whilst building
GLIBC instead:
../include/stdlib.h:34:1: internal compiler error: in
set_user_assembler_libfunc, at optabs.c:6104
which is:
rtx
set_user_assembler_libfunc (const char *name, const char *asmspec)
{
tree id, decl;
void **slot;
hashval_t hash;
id = get_identifier (name);
hash = htab_hash_string (name);
slot = htab_find_slot_with_hash (libfunc_decls, id, hash, NO_INSERT);
gcc_assert (slot); // --- here
decl = (tree) *slot;
set_user_assembler_name (decl, asmspec);
return XEXP (DECL_RTL (decl), 0);
}
In the attached test case, if abort is renamed to abort2, the crash goes away,
which suggests the problem is related to the special handling of abort (and
friends) in builtins.c:set_builtin_user_assembler_name.
To reproduce: /path/to/cc1 -fpreprocessed init-first.i
--
Summary: [4.6 regression] ICE in set_user_assembler_libfunc
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jules at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44291
[Bug middle-end/44291] [4.6 regression] ICE in set_user_assembler_libfunc
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44291
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #32 from paolo dot carlini at oracle dot com 2010-05-27 10:51 --- You mean, in practice, we should only check that difference_type exists? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug middle-end/44291] [4.6 regression] ICE in set_user_assembler_libfunc
--- Comment #1 from jules at gcc dot gnu dot org 2010-05-27 10:44 --- Created an attachment (id=20760) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20760action=view) The test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44291
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #20 from redi at gcc dot gnu dot org 2010-05-27 10:55 --- I have a patch which causes an error if std::shared_ptr or std::tr1::shared_ptr is constructed with a pointer to incomplete type and no custom deleter. I'm not sure what the best approach is for auto_ptr. Technically it's invalid to instantiate auto_ptr with an incomplete type, but in practice only reset() and ~auto_ptr() need the complete type. I can make it an error to instantiate those members with an incomplete type, but that could break some invalid programs which previously compiled with a warning and ran (with undefined behaviour) For now I'll make the shared_ptr changes... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #6 from dg dot recrutement31 at gmail dot com 2010-05-27 11:18 --- (In reply to comment #4) All the tests demonstrate is that you have buggy constraint, in particular you shouldn't use g constraint on something you use in gs:[%2]. g is any register (fine in that case), immediate (not fine) or memory (not fine either in this case). mov al, gs:[DWORD PTR [ebp+12]] is what you get when this-offset is memory at ebp+12, and that of course doesn't assemble. Just use r. OK, thanks for the workaround. Nevertheless, this is a bug because: without -ftree-ter optimization option, -- the rtl-optimization module causes the following code, generated: mov edx, DWORD PTR [esp+24] mov edx, DWORD PTR [edx+4] /APP # 59 far_pointers.h 1 .intel_syntax noprefix; mov gs, ax; mov bl, gs:[edx]; with -ftree-ter : --- mov edx, DWORD PTR [esp+24] /APP # 59 far_pointers.h 1 .intel_syntax noprefix; mov gs, ax; mov bl, gs:[DWORD PTR [edx+4]]; (I don't want to enter in a philosophic debate) Nevertheless, with g directive, this is the responsability of the compiler to choose the good addressing mode because the developer can't know how to anticipate regarding code generated before inline assembly. Or, the g directive should be deleted from GCC specs. Thank you again for your suggestion. Regards, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-27 11:44 --- You are wrong. It is user's responsibility to choose correct constraints for the inline assembly, the compiler doesn't try to understand what the inline assembly is doing or even check its semantics, all it does is perform replacements in it (replacing %0, %1, %2 in this case). Not every constraint is suitable for every use in the assembly obviously, otherwise we wouldn't need multiple constraints. The g constraint allows a register, immediate or memory, all must be valid in the instruction and it is up to the compiler which one it chooses. g constraint is usable say for mov eax, %2; which can work well with registers, immediates or memory. But as you use [%2] instead, memory isn't valid, all that is valid is either a register or register + immediate or register + X*register2 + immediate (the usual i?86 addressing modes). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #33 from redi at gcc dot gnu dot org 2010-05-27 11:54 --- Alisdair checks for Iterator::iterator_category, which seems a very sensible way of checking if a type wants to be recognised by iterator_traits If iterator_category exists, then assume difference_type and the other nested types do too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #34 from paolo dot carlini at oracle dot com 2010-05-27 11:58 --- Ok, let's do this, seems definitely an improvement, and since affects only C++0x and enables more people to test it, I think should go in 4_5-branch too. By the way, if I remember correctly, Howard used to do something very similar. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #8 from dg dot recrutement31 at gmail dot com 2010-05-27 12:05 --- (In reply to comment #7) You are wrong. It is user's responsibility to choose correct constraints for the inline assembly, the compiler doesn't try to understand what the inline assembly is doing or even check its semantics, all it does is perform replacements in it (replacing %0, %1, %2 in this case). Not every constraint is suitable for every use in the assembly obviously, otherwise we wouldn't need multiple constraints. The g constraint allows a register, immediate or memory, all must be valid in the instruction and it is up to the compiler which one it chooses. g constraint is usable say for mov eax, %2; which can work well with registers, immediates or memory. But as you use [%2] instead, memory isn't valid, all that is valid is either a register or register + immediate or register + X*register2 + immediate (the usual i?86 addressing modes). Thank a lot, I fully understand my mistake. Sorry for disturbance Regards -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug lto/44230] Do not create need for multiple EH personalities
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-05-27 12:12 --- Recategorizing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |lto Ever Confirmed|0 |1 GCC build triplet|i386-pc-solaris2.11 | GCC host triplet|i386-pc-solaris2.11 | GCC target triplet|i386-pc-solaris2.11 | Last reconfirmed|-00-00 00:00:00 |2010-05-27 12:12:52 date|| Summary|Support multiple EH |Do not create need for |personalities without |multiple EH personalities |.cfi_personality| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44230
[Bug lto/44230] Do not create need for multiple EH personalities
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-05-27 12:13 --- Fixing. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-27 12:12:52 |2010-05-27 12:13:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44230
[Bug rtl-optimization/44288] [Extended inline asm] wrong assembly generation on IA32
--- Comment #9 from dg dot recrutement31 at gmail dot com 2010-05-27 12:21
---
(In reply to comment #7)
You are wrong. It is user's responsibility to choose correct constraints for
the inline assembly, the compiler doesn't try to understand what the inline
assembly is doing or even check its semantics, all it does is perform
replacements in it (replacing %0, %1, %2 in this case).
Not every constraint is suitable for every use in the assembly obviously,
otherwise we wouldn't need multiple constraints.
The g constraint allows a register, immediate or memory, all must be valid
in
the instruction and it is up to the compiler which one it chooses.
g constraint is usable say for mov eax, %2; which can work well with
registers, immediates or memory. But as you use [%2] instead, memory isn't
valid, all that is valid is either a register or register + immediate or
register + X*register2 + immediate (the usual i?86 addressing modes).
Yes, yes, but ...
I've (naively) delete [] of deferencing :
inline T operator*(void)
{
T item;
__asm__
(
\
.intel_syntax noprefix; \n\
mov gs, %1; \n\
mov %0, gs:%2; \n\
:=q(item)
:r(this-segmentSelector), g(this-offset)
);
return item;
}
The example works because of static parameter 'main'.
But, in some others cases, it tries to generate :
mov al, gs:eax
... Argh !!
So, the inline assembly can't fully participate to optimization.
Should be nice, if it did it.
I wonder if inline RTL would be better to use (if it was supported)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44288
[Bug fortran/44292] New: [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement
libgfortran/io/io.h defines the struct st_parameter_open with GFC_INTEGER_4 recl_in; However, the Fortran 95/2003/2008 standard allows any kind of integer expression and not only the default type. As http://gcc.gnu.org/ml/fortran/2010-05/msg00302.html shows, gfortran currently fails if the RECL= is larger than 2 GB. Expected: The size is increased to GFC_INTEGER_8 to allow large-record access. See also http://gcc.gnu.org/wiki/LibgfortranAbiCleanup -- Summary: [libgfortran ABI breakage] Increase internal size of RECL= of the OPEN statement Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44292
[Bug tree-optimization/44284] vectorization does not work for short variable
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-27 13:24 --- Subject: Bug 44284 Author: rguenth Date: Thu May 27 13:23:45 2010 New Revision: 159920 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159920 Log: 2010-05-27 Richard Guenther rguent...@suse.de PR tree-optimization/44284 * tree-vect-stmts.c (vectorizable_assignment): Handle sign-changing conversions as simple copy. * gcc.dg/vect/vect-118.c: New testcase. * gcc.dg/vect/bb-slp-20.c: Adjust. * gcc.dg/vect/no-section-anchors-vect-36.c: Likewise. * gcc.dg/vect/slp-9.c: Likewise. * gcc.dg/vect/slp-reduc-4.c: Likewise. * gcc.dg/vect/vect-10.c: Likewise. * gcc.dg/vect/vect-109.c: Likewise. * gcc.dg/vect/vect-12.c: Likewise. * gcc.dg/vect/vect-36.c: Likewise. * gcc.dg/vect/vect-7.c: Likewise. * gcc.dg/vect/vect-iv-8.c: Likewise. * gcc.dg/vect/vect-multitypes-10.c: Likewise. * gcc.dg/vect/vect-multitypes-13.c: Likewise. * gcc.dg/vect/vect-multitypes-14.c: Likewise. * gcc.dg/vect/vect-multitypes-15.c: Likewise. * gcc.dg/vect/vect-multitypes-7.c: Likewise. * gcc.dg/vect/vect-multitypes-8.c: Likewise. * gcc.dg/vect/vect-multitypes-9.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s16b.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s8a.c: Likewise. * gcc.dg/vect/vect-reduc-dot-s8b.c: Likewise. * gcc.dg/vect/vect-reduc-dot-u16b.c: Likewise. * gcc.dg/vect/vect-strided-a-u32-mult.c: Likewise. * gcc.dg/vect/vect-strided-u32-mult.c: Likewise. * gcc.dg/vect/vect-widen-mult-s16.c: Likewise. * gcc.dg/vect/vect-widen-mult-s8.c: Likewise. * gcc.dg/vect/vect-widen-mult-sum.c: Likewise. * gcc.dg/vect/vect-widen-mult-u16.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-118.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/bb-slp-20.c trunk/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-36.c trunk/gcc/testsuite/gcc.dg/vect/slp-9.c trunk/gcc/testsuite/gcc.dg/vect/slp-reduc-4.c trunk/gcc/testsuite/gcc.dg/vect/vect-10.c trunk/gcc/testsuite/gcc.dg/vect/vect-109.c trunk/gcc/testsuite/gcc.dg/vect/vect-12.c trunk/gcc/testsuite/gcc.dg/vect/vect-36.c trunk/gcc/testsuite/gcc.dg/vect/vect-7.c trunk/gcc/testsuite/gcc.dg/vect/vect-iv-8.c trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-10.c trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-13.c trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-14.c trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-15.c trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-7.c trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-8.c trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-9.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16a.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s16b.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8a.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8b.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8c.c trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-u16b.c trunk/gcc/testsuite/gcc.dg/vect/vect-strided-a-u32-mult.c trunk/gcc/testsuite/gcc.dg/vect/vect-strided-u32-mult.c trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-s16.c trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-s8.c trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-sum.c trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44284
[Bug tree-optimization/44284] vectorization does not work for short variable
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-27 13:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44284
[Bug middle-end/44293] New: [4.6 regression] FAIL: gcc.c-torture/compile/20040304-1.c
On Linux/x86, revision 159912 gave FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/20040304-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/20040304-1.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/20040304-1.c -O3 -g (test for excess errors) Revision 159873 is OK. -- Summary: [4.6 regression] FAIL: gcc.c-torture/compile/20040304- 1.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44293
[Bug middle-end/44293] [4.6 regression] FAIL: gcc.c-torture/compile/20040304-1.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-27 13:53 --- Revision 159899 is bad. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.6 regression] FAIL: |[4.6 regression] FAIL: |gcc.c- |gcc.c- |torture/compile/20040304-1.c|torture/compile/20040304-1.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44293
[Bug c++/44294] New: [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
On Linux/x86-64, revision 159912 gave FAIL: g++.dg/abi/bitfield12.C (test for warnings, line 3) Revision 159867 is good. -- Summary: [4.6 regression] FAIL: g++.dg/abi/bitfield12.C Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
[Bug lto/44230] Do not create need for multiple EH personalities
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-05-27 14:12 --- Subject: Bug 44230 Author: ebotcazou Date: Thu May 27 14:11:35 2010 New Revision: 159921 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159921 Log: PR lto/44230 * dwarf2out.c (dwarf2out_begin_prologue): Fix nits in sorry message. lto/ * lto.h (lto_eh_personality): New prototype. * lto.c: Include debug.h. (first_personality_decl): New static variable. (lto_materialize_function): Set it to DECL_FUNCTION_PERSONALITY of the first function for which it is non-null. (lto_eh_personality_decl): New static variable. (lto_eh_personality): New function. * lto-lang.c (LANG_HOOKS_EH_PERSONALITY): Redefine to above function. * Make-lang.in (lto/lto.o): Add dependency on debug.h. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/Make-lang.in trunk/gcc/lto/lto-lang.c trunk/gcc/lto/lto.c trunk/gcc/lto/lto.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44230
[Bug lto/44230] Do not create need for multiple EH personalities
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-05-27 14:14 --- They should pass now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||05/msg02076.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44230
[Bug c++/44294] [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
[Bug middle-end/44293] [4.6 regression] FAIL: gcc.c-torture/compile/20040304-1.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44293
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
--- Comment #7 from jbeniston at gcc dot gnu dot org 2010-05-27 15:06 --- Subject: Bug 43726 Author: jbeniston Date: Thu May 27 15:05:48 2010 New Revision: 159922 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159922 Log: PR 43726 * config/lm32/lm32.h: Remove definition of GO_IF_MODE_DEPENDENT_ADDRESS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/lm32/lm32.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug c/43553] libgcc built with -DHAVE_CC_TLS against xgcc when emutls in use
--- Comment #32 from mrs at gcc dot gnu dot org 2010-05-27 15:10 --- I'd like to hear what Jack has to say, otherwise, fine by me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43553
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-05-27 15:15 --- FWIW: I added your patch to the RTEMS lm32-gcc-4.5.0 toolchains. With this patch applied, the ICE during building RTEMS, I had experienced does not occur anymore. Compiling RTEMS at -O2 also seems to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug middle-end/44293] [4.6 regression] FAIL: gcc.c-torture/compile/20040304-1.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 15:37 --- It is caused by revision 159887: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00943.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-27 15:37:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44293
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #5 from rth at gcc dot gnu dot org 2010-05-27 15:44 --- The context in which stmt_can_throw_internal is being called is different pre- and post-inlining, so of course the answer could be different. This is neither surprising nor a bug. I even tend to doubt (without checking of course) whether this is a regression with the EH rewrite, since I would expect the same new EH edge to have appeared with the old EH code -- anything less would have been a bug in the old EH code. However, in order to see the bug one also needs the VTA code present, which means looking at the redhat-4.4 branch. So yes, Jakub, I think the inliner needs to do something to clean up the debug statement that would appear alone in that new block. I suppose such debug statements would have to be dropped to avoid changing the code due to changes in the CFG. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
--- Comment #9 from jbeniston at gcc dot gnu dot org 2010-05-27 15:45 --- Subject: Bug 43726 Author: jbeniston Date: Thu May 27 15:45:11 2010 New Revision: 159926 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159926 Log: 2010-05-27 Jon Beniston j...@beniston.com PR 43726 * config/lm32/lm32.h: Remove definition of GO_IF_MODE_DEPENDENT_ADDRESS. Update copyright year. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/lm32/lm32.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug c++/44294] [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-27 15:53 --- I saw this regression now for a long time for x86_64-w64-mingw32. Interesting is that it appeared now but not for x86, but I assume code is broken already for a long time. Maybe the code-change I did yesterday exposed this bug. See http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02088.html -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-27 15:53:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
[Bug c++/44294] [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 15:59 --- It is caused by revision 159879: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00935.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-27 16:06 --- Subject: Re: abi docs say that hppa-linux defaults to libgcc_s.so.2 Dave, when did the hppa-linux so version change from 2 to 4? I'd like to document that, rather than just say it's always 1 or 4 Oops, I have messed up. After some discussion, it was decided to revert the change. It was supposed to have been reverted on 2010-01-31, but the change apparently didn't work at least on the trunk. The original change was made on 2010-01-02. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #35 from paolo dot carlini at oracle dot com 2010-05-27 16:25 --- Note, plain pointers and pointers to const must be dealt with separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug objc/44140] ObjC lto/whopr fails
--- Comment #8 from iains at gcc dot gnu dot org 2010-05-27 16:28 --- Subject: Bug 44140 Author: iains Date: Thu May 27 16:28:13 2010 New Revision: 159929 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159929 Log: 2010-05-27 Iain Sandoe ia...@gcc.gnu.org PR ObjC/44140 * objc.dg/torture/tls/thr-init-2.m: Skip for -flto, -fwhopr. * objc.dg/torture/tls/thr-init-3.m: Ditto. * objc.dg/torture/tls/thr-init.m: Ditto. * objc.dg/torture/trivial.m: Ditto. * obj-c++.dg/torture/tls/thr-init-1.mm: Ditto. * obj-c++.dg/torture/tls/thr-init-2.mm: Ditto. * obj-c++.dg/torture/tls/thr-init-3.mm: Ditto. * obj-c++.dg/torture/trivial.mm: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/torture/tls/thr-init-1.mm trunk/gcc/testsuite/obj-c++.dg/torture/tls/thr-init-2.mm trunk/gcc/testsuite/obj-c++.dg/torture/tls/thr-init-3.mm trunk/gcc/testsuite/obj-c++.dg/torture/trivial.mm trunk/gcc/testsuite/objc.dg/torture/tls/thr-init-2.m trunk/gcc/testsuite/objc.dg/torture/tls/thr-init-3.m trunk/gcc/testsuite/objc.dg/torture/tls/thr-init.m trunk/gcc/testsuite/objc.dg/torture/trivial.m -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44140
[Bug target/44199] ppc64 glibc miscompilation
--- Comment #25 from bergner at gcc dot gnu dot org 2010-05-27 16:31 --- Subject: Bug 44199 Author: bergner Date: Thu May 27 16:31:05 2010 New Revision: 159930 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159930 Log: Backport from mainline: 2010-05-26 Jakub Jelinek ja...@redhat.com PR target/44199 * config/rs6000/rs6000.c (rs6000_emit_epilogue): If cfun-calls_alloca or total_size is larger than red zone size for non-V4 ABI, emit a stack_tie resp. frame_tie insn before stack pointer restore. * config/rs6000/rs6000.md (frame_tie): New insn. Modified: branches/ibm/gcc-4_4-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_4-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_4-branch/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-27 17:10 --- redhat/gcc-4_4-branch doesn't have a -fcompare-debug failure here, though, I see now that S::f3 doesn't end a basic block before inlining either, just inlining happens in a different order. So the question is now what to do with the debug stmts. Alex? Just dropping them on the floor might result in wrong debug, as older debug stmt expression would be still in place. Sometimes we could move/copy the debug stmts to the beginning of the successor bbs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug middle-end/44295] New: [4.6 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
On Linux/x86-64, revision 159912 failed to build 483.xalancbmk in SPEC CPU 2006: g++ -c -o DOMDocumentImpl.o -DSPEC_CPU -DNDEBUG -DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom -Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory -Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER -DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM -DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREADS -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX DOMDocumentImpl.cpp called by: virtual xercesc_2_5::DOMNodeList* xercesc_2_5::DOMDocumentImpl::getElementsByTagName(const XMLCh*) const/607 (1.00 per call) (inlined) (can throw external) calls: void* xercesc_2_5::DOMDocumentImpl::allocate(size_t)/724 (0.07 per call) (can throw external) xercesc_2_5::DOMDeepNodeListPoolTVal::DOMDeepNodeListPool(XMLSize_t, bool, XMLSize_t) [with TVal = xercesc_2_5::DOMDeepNodeListImpl, XMLSize_t = long unsigned int]/812 (0.07 per call) (can throw external) TVal* xercesc_2_5::DOMDeepNodeListPoolTVal::getByKey(const void*, const XMLCh*, const XMLCh*) [with TVal = xercesc_2_5::DOMDeepNodeListImpl, XMLCh = short unsigned int]/289 (inlined) (1.00 per call) (can throw external) void* xercesc_2_5::DOMDocumentImpl::allocate(size_t)/724 (0.10 per call) (can throw external) xercesc_2_5::DOMDeepNodeListImpl::DOMDeepNodeListImpl(const xercesc_2_5::DOMNode*, const XMLCh*)/982 (0.10 per call) (can throw external) XMLSize_t xercesc_2_5::DOMDeepNodeListPoolTVal::put(void*, XMLCh*, XMLCh*, TVal*) [with TVal = xercesc_2_5::DOMDeepNodeListImpl, XMLSize_t = long unsigned int, XMLCh = short unsigned int]/795 (0.10 per call) (can throw external) TVal* xercesc_2_5::DOMDeepNodeListPoolTVal::getById(XMLSize_t) [with TVal = xercesc_2_5::DOMDeepNodeListImpl, XMLSize_t = long unsigned int]/796 (inlined) (0.10 per call) (can throw external) References: Refering this function: DOMDocumentImpl.cpp:497:66: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake[3]: *** [DOMDocumentImpl.o] Error 1 specmake[3]: *** Waiting for unfinished jobs Revision 159789 is OK. -- Summary: [4.6 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44295
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #4 from raj dot khem at gmail dot com 2010-05-27 17:25 --- $ /home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/bin/arm-none-linux-uclibcgnueabi-gcc -O2 -fno-ipa-sra -S -v copypage-v4wb.i Using built-in specs. COLLECT_GCC=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/bin/arm-none-linux-uclibcgnueabi-gcc COLLECT_LTO_WRAPPER=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/lto-wrapper Target: arm-none-linux-uclibcgnueabi Configured with: /home/kraj/work/cross/arm-none-linux-uclibcgnueabi/../../gcc-4.5-20100520/configure --target=arm-none-linux-uclibcgnueabi --prefix=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools --with-sysroot=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/sysroot --enable-__cxa_atexit --disable-libssp --disable-libgomp --disable-libmudflap --enable-languages=c,c++ Thread model: posix gcc version 4.5.1 20100520 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-O2' '-fno-ipa-sra' '-S' '-v' /home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/cc1 -fpreprocessed copypage-v4wb.i -quiet -dumpbase copypage-v4wb.i -auxbase copypage-v4wb -O2 -version -fno-ipa-sra -o copypage-v4wb.s GNU C (GCC) version 4.5.1 20100520 (prerelease) (arm-none-linux-uclibcgnueabi) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.5.1 20100520 (prerelease) (arm-none-linux-uclibcgnueabi) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: acf86197000a593407366115824f5d00 COMPILER_PATH=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/libexec/gcc/arm-none-linux-uclibcgnueabi/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/../../../../arm-none-linux-uclibcgnueabi/bin/ LIBRARY_PATH=/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/tools/lib/gcc/arm-none-linux-uclibcgnueabi/4.5.1/../../../../arm-none-linux-uclibcgnueabi/lib/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/sysroot/lib/:/home/kraj/work/cross/arm-none-linux-uclibcgnueabi/sysroot/usr/lib/ COLLECT_GCC_OPTIONS='-O2' '-fno-ipa-sra' '-S' '-v' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #5 from raj dot khem at gmail dot com 2010-05-27 17:27 --- oops that was for good case. But just remove -fno-ipa-sra to make it a failing case :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug java/44296] New: libjavamath.so not using correct libgmp.so.3
I built gcc-4.5.0 by putting the gmp, mpc, mpfr trees in the gcc-4.5.0 directory. Then I proceeded with a make bootstrap. When it was done I did an ldd on all the files to make sure everything was found. In doing this I also checked for the gmp, mpc and mpfr library usage. I see this which I believe is wrong since it is not the one I put in the tree ./lib/gcj-4.5.0-11/libjavamath.so: libgmp.so.3 = /usr/lib/libgmp.so.3 (0x00721000) /tools/wdtgnu/gcc-4.5.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/tools/wdtgnu/gcc-4.5.0/bin/gcc COLLECT_LTO_WRAPPER=/tools/wdtgnu/gcc-4.5.0/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: /proj/wdtold/warrend/gnusrc_new/wdtV3/30-gcc-4.5.0/gcc-4.5.0/configure --prefix=/tools/wdtgnu/gcc-4.5.0 --with-local-prefix=/tools/wdtgnu/gcc-4.5.0 --enable-shared --with-gnu-as --with-as=/tools/wdtgnu/gcc-4.5.0/bin/i686-pc-linux-gnu-as --with-gnu-ld --with-ld=/tools/wdtgnu/gcc-4.5.0/bin/i686-pc-linux-gnu-ld --with-gnu-nm --with-nm=/tools/wdtgnu/gcc-4.5.0/bin/i686-pc-linux-gnu-nm --enable-threads=posix --enable-languages=all,ada,obj-c++ --disable-nls Thread model: posix gcc version 4.5.0 (GCC) -- Summary: libjavamath.so not using correct libgmp.so.3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: warren dot l dot dodge at tektronix dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44296
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #36 from paolo at gcc dot gnu dot org 2010-05-27 17:37 --- Subject: Bug 40497 Author: paolo Date: Thu May 27 17:37:11 2010 New Revision: 159933 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159933 Log: 2010-05-27 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/40497 * include/bits/cpp_type_traits.h (__is_iterator): Add. * include/bits/stl_iterator_base_funcs.h (next, prev): Use it. * testsuite/24_iterators/operations/40497.cc: New. Added: trunk/libstdc++-v3/testsuite/24_iterators/operations/40497.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/cpp_type_traits.h trunk/libstdc++-v3/include/bits/stl_iterator_base_funcs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #37 from paolo at gcc dot gnu dot org 2010-05-27 17:45 --- Subject: Bug 40497 Author: paolo Date: Thu May 27 17:44:59 2010 New Revision: 159934 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159934 Log: 2010-05-27 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/40497 * include/bits/cpp_type_traits.h (__is_iterator): Add. * include/bits/stl_iterator_base_funcs.h (next, prev): Use it. * testsuite/24_iterators/operations/40497.cc: New. Added: branches/gcc-4_5-branch/libstdc++-v3/testsuite/24_iterators/operations/40497.cc Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/include/bits/cpp_type_traits.h branches/gcc-4_5-branch/libstdc++-v3/include/bits/stl_iterator_base_funcs.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #38 from paolo dot carlini at oracle dot com 2010-05-27 17:46 --- Fixed for 4.5.1. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.4.5 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug middle-end/44297] New: Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
Tests are on amd-linux64 system with -O3 -fprefetch-loop-arrays Compare gcc-4.6-20100522.tar.bz2 to gcc-4.6-20100515.tar.bz2 459.GemsFDTD: -32.6% 434.zeusmp: -13.6% If I replace tree-ssa-loop-prefetch.c in gcc-4.6-20100522.tar.bz2 with the one in gcc-4.6-20100515.tar.bz2, The regression disappears. -- Summary: Big spec cpu2006 prefetch regressions on gcc 4.6 on x86 Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: changpeng dot fang at amd dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug libgcj/44296] libjavamath not using just built libgmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-27 18:05 --- That is because the classpath/libjava configure does not support the toplevel building of GMP yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|java|libgcj Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-27 18:05:47 date|| Summary|libjavamath.so not using|libjavamath not using just |correct libgmp.so.3 |built libgmp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44296
[Bug c++/44294] [4.6 regression] FAIL: g++.dg/abi/bitfield12.C
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-27 18:07 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02124.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||05/msg02124.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44294
Segmentation Fault with -march=core2 or -msse
I have a serious problem. I am currently working on a raytracer project where I'm using my own Vector-Header. The Vector-Header-File consists of classes (Vec2, Vec3, Vec4 etc.) that encapsulate the gcc-vector-intrinsics (e.g. typedef float _vec __attribute__((vector_size(16))); ). All methods (operators +, -, /, * ...) are realised as inline methods (no cpp-source-file), because they are all very short (not more than 3 lines of code per method). The Vector-Header was excessivly tested before and there was no error at all. In my new raytracer project however, if set the compiler switches -msse or -msse2 there is segmentation fault because of a movaps on unaligned data in a method that runs without error in any other test case. I'm currently using Mingw-gcc 3.4.5. Here is an debugger output from olly-debugger: 00402D44 | 8940 10/MOV DWORD PTR DS:[EAX+10],EAX 00402D47 |. 8940 14|MOV DWORD PTR DS:[EAX+14],EAX 00402D4A |. 8D48 04|LEA ECX,DWORD PTR DS:[EAX+4] 00402D4D |. 8948 18|MOV DWORD PTR DS:[EAX+18],ECX 00402D50 |. 8D48 08|LEA ECX,DWORD PTR DS:[EAX+8] 00402D53 |. 8948 1C|MOV DWORD PTR DS:[EAX+1C],ECX 00402D56 |. 0F2900 |MOVAPS DQWORD PTR DS:[EAX],XMM0 ---CRASH 00402D59 |. 83C2 20|ADD EDX,20 00402D5C |. 83C0 20|ADD EAX,20 00402D5F |. 81FA 0001 |CMP EDX,100 00402D65 |.^75 DD \JNZ SHORT SpeedTes.00402D44 At first i wanted to send this bug to the official GCC-Bug-List, but they don't want Sourcecode and because the Bug is not replicable without my source, i decided to post it here instead. Does anybody has an idea to overcome this problem without waiting for the next Mingw-GCC release? -- View this message in context: http://old.nabble.com/Segmentation-Fault-with-%22-march%3Dcore2%22-or-%22-msse%22-tp28698142p28698142.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
--- Comment #7 from jason at gcc dot gnu dot org 2010-05-27 18:32 --- This doesn't work with my 4.1 tree. Or with 3.2 for that matter. It does work with 2.95. -- jason at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.1.3 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
--- Comment #8 from jason at gcc dot gnu dot org 2010-05-27 18:36 --- Subject: Bug 43555 Author: jason Date: Thu May 27 18:36:22 2010 New Revision: 159938 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159938 Log: PR c++/43555 * decl.c (grokdeclarator) [cdk_pointer et al]: Force evaluation of anonymous VLA size. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/ext/vla9.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/decl.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
--- Comment #9 from jason at gcc dot gnu dot org 2010-05-27 18:39 --- Subject: Bug 43555 Author: jason Date: Thu May 27 18:39:28 2010 New Revision: 159939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159939 Log: PR c++/43555 * decl.c (grokdeclarator) [cdk_pointer et al]: Force evaluation of anonymous VLA size. Added: trunk/gcc/testsuite/g++.dg/ext/vla9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency
--- Comment #23 from jason at gcc dot gnu dot org 2010-05-27 18:40 --- Subject: Bug 42832 Author: jason Date: Thu May 27 18:39:46 2010 New Revision: 159940 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159940 Log: Revert: PR libstdc++/42832 * include/std/functional (function::swap): Perform bytewise swap of _M_functor. * include/tr1/functional (function::swap): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/functional trunk/libstdc++-v3/include/tr1/functional -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug c++/44298] New: code addressed only by label with it's address taken is ignored
The testcase below passes the entry point to 'lll' call as an address of the
label ll_def. printf line disappears completely.
Obviously people should only use such code when they really know what they are
doing. But compilation result here is complately wrong and isn't usable in any
way.
--- testcase ---
#include stdio.h
#include stdlib.h
__attribute__ ((noinline)) void lll(void*) {
}
void mainx() {
lll(ll_def);
return;
ll_def:
printf(default\n);
return;
}
--
Summary: code addressed only by label with it's address taken is
ignored
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298
[Bug middle-end/44295] [4.6 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-27 18:57 --- It is caused by revision 159907: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00963.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44295
[Bug c++/44298] code addressed only by label with it's address taken is ignored
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-27 18:57 --- Addresses of labels are only designed to work with computed gotos so if you don't have a computed goto in the function of mainx, then this will not work. See http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Labels-as-Values.html . One thing which is documented is You may not use this mechanism to jump to code in a different function. It is not about using labels as value extension only when they know what they are doing but rather using them as they are correctly documented as being working. They are only designed for computed gotos. Any other use will cause undefined behavior. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
--- Comment #10 from jason at gcc dot gnu dot org 2010-05-27 19:00 --- Subject: Bug 43555 Author: jason Date: Thu May 27 19:00:33 2010 New Revision: 159942 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159942 Log: PR c++/43555 * decl.c (grokdeclarator) [cdk_pointer et al]: Force evaluation of anonymous VLA size. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/vla9.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/decl.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
--- Comment #11 from jason at gcc dot gnu dot org 2010-05-27 19:10 --- Fixed for 4.4.6. I'm inclined not to apply the change to 4.3 just in case it causes problems somehow, but I could be convinced otherwise. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.3.6 |4.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct
--- Comment #2 from dodji at gcc dot gnu dot org 2010-05-27 19:30 --- Subject: Bug 44188 Author: dodji Date: Thu May 27 19:29:53 2010 New Revision: 159943 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159943 Log: Fix PR c++/44188 gcc/ChangeLog: PR c++/44188 * c-common.c (is_typedef_decl): Move this definition ... * tree.c (is_typedef_decl): ... here. (typdef_variant_p): Move definition here from gcc/cp/tree.c. * c-common.h (is_typedef_decl): Move this declaration ... * tree.h (is_typedef_decl): ... here. (typedef_variant_p): Move declaration here from gcc/cp/cp-tree.h * dwarf2out.c (is_naming_typedef_decl): New function. (gen_tagged_type_die): Split out of ... (gen_type_die_with_usage): ... this function. When an anonymous tagged type is named by a typedef, make sure a DW_TAG_typedef DIE is emitted for the typedef. (gen_typedef_die): Emit DW_TAG_typedef also for typedefs naming anonymous tagged types. gcc/cp/ChangeLog: PR c++/44188 * cp-tree.h (typedef_variant_p): Move this declaration to gcc/tree.h. * tree.c (typedef_variant_p): Move this definition to gcc/tree.c. * decl.c (grokdeclarator): Do not rename debug info of an anonymous tagged type named by a typedef. gcc/testsuite/ChangeLog: PR c++/44188 * g++.dg/debug/dwarf2/typedef3.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef3.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/tree.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct
--- Comment #3 from dodji at gcc dot gnu dot org 2010-05-27 19:36 --- Fixed in trunk (4.6). -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug bootstrap/44299] New: Bootstrap broken for cygwin and mingw targets
gcc -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DNATIVE_C ROSS -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototy pes -Wmissing-format-attribute -Wold-style-definition -fno-common -DHAVE_CONFIG _H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../ gcc/gcc/../libcpp/include -I/home/ktietz/source/gcc-head/buildw64/./gmp -I/home/ ktietz/source/gcc-head/gcc/gmp -I/home/ktietz/source/gcc-head/buildw64/./mpfr -I /home/ktietz/source/gcc-head/gcc/mpfr -I/home/ktietz/source/gcc-head/gcc/mpc/src -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libde cnumber -DCLOOG_PPL_BACKEND-I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../. ./gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/home/ktietz/source/gcc -head/buildw64/./gmp -I/home/ktietz/source/gcc-head/gcc/gmp -I/home/ktietz/sourc e/gcc-head/buildw64/./mpfr -I/home/ktietz/source/gcc-head/gcc/mpfr -I/home/ktiet z/source/gcc-head/gcc/mpc/src -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/. ./libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND \ ../../gcc/gcc/config/i386/winnt-cxx.c In file included from ../../gcc/gcc/config/i386/winnt-cxx.c:25: ../../gcc/gcc/rtl.h:22:9: attempt to use poisoned GCC_RTL_H -- Summary: Bootstrap broken for cygwin and mingw targets Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ktietz at gcc dot gnu dot org GCC target triplet: i?86-*-cygwin *-*-mingw* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.6 |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug c/44300] New: Spurious array subscript warning
In the following code, foo() properly guards the expression 'p[-1]' with a test
that p is a pointer to an element of a[] other than the first element. Yet,
when gcc analyzes array subscripts, it raises a warning because foo() is used
in a context where p points to the first element of b[].
Even if the compiler isn't sophisticated enough to optimize away the entire
body of foo(), it should have enough information to determine that 'p[-1]' is
valid in the context where it is used. Instead, it complains:
x.c: In function bar:
x.c:7: warning: array subscript is below array bounds
int a[10], b[10];
static inline void
foo(int *p)
{
if (p a p a + 10) {
p[-1] = 0;
}
}
void
bar(void)
{
foo(b);
}
% gcc -v -save-temps -c -O2 -Wall x.c
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.4
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.4
--enable-linux-futex --without-system-libunwind --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wall' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1 -E -quiet -v x.c -mtune=generic -Wall
-O2 -fpch-preprocess -o x.i
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/4.4/include
/usr/lib64/gcc/x86_64-suse-linux/4.4/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wall' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1 -fpreprocessed x.i -quiet -dumpbase
x.c -mtune=generic -auxbase x -O2 -Wall -version -o x.s
GNU C (SUSE Linux) version 4.4.1 [gcc-4_4-branch revision 150839]
(x86_64-suse-linux)
compiled by GNU C version 4.4.1 [gcc-4_4-branch revision 150839], GMP
version 4.3.1, MPFR version 2.4.1-p5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7c58d9f1f1af203b4391f1c94895405a
x.c: In function bar:
x.c:7: warning: array subscript is below array bounds
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wall' '-mtune=generic'
/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/as -V
-Qy -o x.o x.s
GNU assembler version 2.19.51 (x86_64-suse-linux) using BFD version (GNU
Binutils; openSUSE 11.2) 2.19.51.20090527-10.26.4
COMPILER_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/bin/
LIBRARY_PATH=/usr/lib64/gcc/x86_64-suse-linux/4.4/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/4.4/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-O2' '-Wall' '-mtune=generic'
--
Summary: Spurious array subscript warning
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jmattson at vmware dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug c/44300] Spurious array subscript warning
--- Comment #1 from jmattson at vmware dot com 2010-05-27 20:01 --- Created an attachment (id=20761) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20761action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
--- Comment #12 from jason at gcc dot gnu dot org 2010-05-27 20:02 --- Subject: Bug 43555 Author: jason Date: Thu May 27 20:02:10 2010 New Revision: 159945 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159945 Log: PR c++/43555 * decl.c (grokdeclarator) [cdk_pointer et al]: Force evaluation of anonymous VLA size. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/vla9.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/decl.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug c/44300] Spurious array subscript warning
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-27 20:03 --- b[0] a[0] is not well defined in C or C++. That is what it gets optimized to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
--- Comment #13 from jason at gcc dot gnu dot org 2010-05-27 20:04 --- On reflection, I went ahead and applied it to 4.3 since it only affects VLA code anyway. -- jason at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.4 4.4.2 4.5.0 |3.0 3.2 3.3 4.3.4 4.4.2 ||4.5.0 Known to work||2.95 Target Milestone|4.4.5 |4.3.7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #26 from iains at gcc dot gnu dot org 2010-05-27 20:11 --- Created an attachment (id=20762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762action=view) candidate fix that handles aliases as well. PR44276 revealed that I wasn't handling alias cases. The new attachment deal with this and is tested on i686-apple-darwin, cris-elf. TODO; gimplification of asm statements that include emuTLS vars. tree-profile.c -- iains at gcc dot gnu dot org changed: What|Removed |Added Attachment #20738|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug c/44300] Spurious array subscript warning
--- Comment #3 from jmattson at vmware dot com 2010-05-27 20:31 ---
Admittedly, foo() makes some assumptions about alignment as originally written.
A more pedantic version is:
static inline void
foo(int *p)
{
if (p = a + 1 p a + 10) {
p[-1] = 0;
}
}
gcc still generates a warning with this version.
Even if a[] and b[] overlap, the guard clause ensures that the expression
'p[-1]' is within the bounds of array a[].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44300
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-05-27 20:41 --- Subject: Bug 44299 Author: ktietz Date: Thu May 27 20:40:48 2010 New Revision: 159949 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159949 Log: 2010-05-27 Kai Tietz kai.ti...@onevision.com PR bootstrap/44299 * config/i386/winnt.c (IN_GCC_FRONTEND): Undefine. * config/i386/winnt-cxx.c (IN_GCC_FRONTEND): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt-cxx.c trunk/gcc/config/i386/winnt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- Comment #1 from changpeng dot fang at amd dot com 2010-05-27 20:49 --- The regressions are most likely from the patch that added non-constant step prefetching: * From: Andreas Krebbel krebbel at linux dot vnet dot ibm dot com * To: Christian Borntraeger borntraeger at de dot ibm dot com * Cc: gcc-patches gcc-patches at gcc dot gnu dot org * Date: Wed, 19 May 2010 12:40:51 +0200 * Subject: Re: [patch 4/4 v4] Allow loop prefetch code to speculatively prefetch non constant steps * tree-ssa-loop-prefetch.c (mem_ref_group): Change step to tree. * tree-ssa-loop-prefetch.c (ar_data): Change step to tree. * tree-ssa-loop-prefetch.c (dump_mem_ref): Adopt debug code to handle a tree as step. This also checks for a constant int vs. non-constant but loop-invariant steps. * tree-ssa-loop-prefetch.c (find_or_create_group): Change the sort algorithm to only consider steps that are constant ints. * tree-ssa-loop-prefetch.c (idx_analyze_ref): Adopt code to handle a tree instead of a HOST_WIDE_INT for step. * tree-ssa-loop-prefetch.c (gather_memory_references_ref): Handle tree instead of int and be prepared to see a NULL_TREE. * tree-ssa-loop-prefetch.c (prune_ref_by_self_reuse): Do not prune prefetches if the step cannot be calculated at compile time. * tree-ssa-loop-prefetch.c (prune_ref_by_group_reuse): Do not prune prefetches if the step cannot be calculated at compile time. * tree-ssa-loop-prefetch.c (issue_prefetch_ref): Issue prefetches for non-constant but loop-invariant steps. Applied to mainline. Thanks! -- changpeng dot fang at amd dot com changed: What|Removed |Added CC||borntraeger at de dot ibm ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug c++/44188] Fails to produce DW_AT_typedef for typedef of anonymous struct
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-27 20:50 --- Not 100% sure yet, but I believe this commit broke bootstrap on both x86_64-linux and i686-linux, e.g. in libobjc or in ada bits. One of the ICEs I'm seeing is: #0 fancy_abort (file=0x8d1d1e3 ../../gcc/dwarf2out.c, line=16990, function=0x8d21b15 add_byte_size_attribute) at ../../gcc/diagnostic.c:782 #1 0x0823486f in add_byte_size_attribute (die=0xf7d76a20, tree_node=value optimized out) at ../../gcc/dwarf2out.c:16990 #2 0x082568d3 in gen_struct_or_union_type_die (type=0xf7d52cc0, context_die=0xf7d633f0, usage=value optimized out) at ../../gcc/dwarf2out.c:19329 #3 gen_tagged_type_die (type=0xf7d52cc0, context_die=0xf7d633f0, usage=value optimized out) at ../../gcc/dwarf2out.c:19502 #4 0x08257e9a in gen_typedef_die (decl=0xf7d600d8, context_die=0xf7d633f0) at ../../gcc/dwarf2out.c:19430 #5 0x08255a59 in gen_decl_die (decl=0xf7d600d8, origin=value optimized out, context_die=0xf7d633f0) at ../../gcc/dwarf2out.c:20186 gen_typedef_die is called on: type_decl 0xf7d600d8 id type pointer_type 0xf7d52cc0 id type record_type 0xf7d52c00 objc_object asm_written type_0 SI size integer_cst 0xf7ce8258 constant 32 unit size integer_cst 0xf7ce8090 constant 4 align 32 symtab -136878016 alias set -1 canonical type 0xf7d52c00 fields field_decl 0xf7d62a6c class_pointer pointer_to_this pointer_type 0xf7d52cc0 id chain type_decl 0xf7d6 D.1196 asm_written unsigned SI size integer_cst 0xf7ce8258 32 unit size integer_cst 0xf7ce8090 4 align 32 symtab -136877536 alias set -1 canonical type 0xf7d52cc0 asm_written VOID file /usr/src/gcc/libobjc/objc/objc.h line 72 col 4 align 1 Given the comments, I wonder if: --- dwarf2out.c.jj3 2010-05-27 21:48:57.0 +0200 +++ dwarf2out.c 2010-05-27 22:50:22.0 +0200 @@ -19427,7 +19427,9 @@ gen_typedef_die (tree decl, dw_die_ref c generate that DIE right away. add_type_attribute called below will then pick (via lookup_type_die) that anonymous struct DIE. */ - gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE); + if (RECORD_OR_UNION_TYPE_P (type) + || TREE_CODE (type) == ENUMERAL_TYPE) + gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE); } add_type_attribute (type_die, type, TREE_READONLY (decl), isn't intended, calling gen_tagged_type_die on a POINTER_TYPE is weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44188
[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency
--- Comment #24 from paolo dot carlini at oracle dot com 2010-05-27 20:52 --- Can be closed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug libstdc++/42845] Want __gnu_cxx::uninitialized_aligned_{copy,swap}
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-27 20:53 --- Moot now. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42845
[Bug c++/43555] [4.3/4.4/4.5/4.6 Regression] wrong address calculation of multidimensional variable-length array element
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.7 |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43555
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- Comment #2 from changpeng dot fang at amd dot com 2010-05-27 20:55 --- To me, non-constant step prefetching seems not fit into the existing prefetching framework. non-constant stride prevent any reuse analysis, and thus prefetching is kind of blindly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #11 from mikpe at it dot uu dot se 2010-05-27 21:35 --- Created an attachment (id=20763) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20763action=view) preprocessed source for libiberty/cp-demangle.c Here's the preprocessed source for libiberty/cp-demangle.c as generated by gcc-4.6-20100522 on sparc64-unknown-linux. The same 4.6 snapshot built on x86 as a cross to sparc64-unknown-linux also fails with -m32 -g -fcompare-debug -O2: sparc64-unknown-linux-gcc -m32 -g -fcompare-debug -O2 -c cp-demangle.i sparc64-unknown-linux-gcc: cp-demangle.i: -fcompare-debug failure If you compile cp-demangle.i to .o first with -g0 and then with -g and compare the objdump -d output from those two object files, you'll find a single instruction difference at or near address 0x5080 in function cplus_demangle_type (). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-27 22:02 --- Can you explain the struct __emutls_object change? That is an ABI break (and I don't see anywhere any rationale for that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-27 22:09 --- Subject: Bug 44255 Author: jakub Date: Thu May 27 22:08:41 2010 New Revision: 159952 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159952 Log: PR bootstrap/44255 * combine.c (struct rtx_subst_pair): Define unconditionally. (propagate_for_debug_subst): Likewise. If not AUTO_INC_DEC, copy_rtx pair-to instead of cleanup_auto_inc_dec it. Call make_compound_operation on pair-to. (propagate_for_debug): Don't call make_compound_operation here. Always use simplify_replace_fn_rtx. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug middle-end/44295] [4.6 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 22:11 --- Created an attachment (id=20764) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20764action=view) A testcase for Linux/x86-64 [...@gnu-32 build_base_o3.]$ /export/gnu/import/rrs/159907/usr/bin/gcc -O3 pr44295.ii -S ... calls: void* operator new(size_t, xercesc_2_5::DOMDocument*)/252 (0.10 per call) (can throw external) xercesc_2_5::DOMDeepNodeListPoolTVal::DOMDeepNodeListPool(XMLSize_t, bool, XMLSize_t) [with TVal = xercesc_2_5::DOMDeepNodeListImpl, XMLSize_t = long unsigned int]/144 (0.10 per call) (can throw external) TVal* xercesc_2_5::DOMDeepNodeListPoolTVal::getByKey(const void*, const XMLCh*, const XMLCh*) [with TVal = xercesc_2_5::DOMDeepNodeListImpl, XMLCh = short unsigned int]/1 (inlined) (1.00 per call) (can throw external) References: Refering this function: pr44295.ii:3006:66: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-32 build_base_o3.]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44295
[Bug c++/44301] New: g++ ICE on complicated template code
g++ 4.5.0 produces an ICE (segmentation fault) on the code in the
How-To-Repeat section. The error is (the first non-blank line of the
example is line 1):
test.ii: In instantiation of âeintâ:
test.ii:19:8: instantiated from here
test.ii:16:32: internal compiler error: Segmentation fault
The errors are very fragile, however. Any of the following changes make
the code compile:
- Remove struct d, or the definition of x inside it.
- Remove the U template parameter to struct d.
- Replace the use of f in d with cT::type.
- Remove either of the uses of a (e.g., changing the second line of
struct d to typename f::type x;
- Remove either of the indirections through b or c (e.g., change the
body of c to typedef int type; and then replace the uses of
cT::type with cT).
- Remove the declaration of x in struct e.
- Remove the instantiation of struct e at the end of the file.
Changing struct e to a function or wrapping the declaration of x in
struct d in a member function does not work around this problem. The
code that this was trimmed down from works on earlier versions of g++
(the actual code is from
libs/graph_parallel/test/distributed_connected_components_test.cpp in
Boost trunk r62270), and this exact code compiles on 4.1.2.
Environment:
System: Linux flowerpot.osl.iu.edu 2.6.18-194.3.1.el5 #1 SMP Sun May 2 04:17:42
EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: ./configure --prefix=/u/jewillco/gcc45-install --enable-lto
--with-mpc=/u/jewillco/gcc45-install --with-mpfr=/u/jewillco/gcc45-install
--with-gmp=/u/jewillco/gcc45-install --with-ppl=/u/jewillco/gcc45-install
--with-cloog=/u/jewillco/gcc45-install --with-libelf=/u/jewillco/gcc45-install
How-To-Repeat:
Try to compile the following code (no flags required, but I tested with
-c; -fsyntax-only will also suffice to reproduce the problem):
template class T struct a {};
struct b {typedef int type;};
template typename T
struct c {typedef b type;};
template typename T, typename U
struct d {
typedef typename cT::type f;
atypename f::type x;
};
template typename T
struct e {
atypename cT::type::type x;
};
eint y;
--- Comment #1 from jewillco at osl dot iu dot edu 2010-05-27 22:15 ---
Fix:
See description section for workarounds.
--
Summary: g++ ICE on complicated template code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jewillco at osl dot iu dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44301
[Bug bootstrap/44302] New: [4.6 Regression] Failed to bootstrap
On Linux/ia32, revision 159949 failed to bootstrap: gcc-test/src-trunk/libobjc/objc/Object.h:29:0, from /export/gnu/import/svn/gcc-test/src-trunk/libobjc/linking.m:27: /export/gnu/import/svn/gcc-test/src-trunk/libobjc/objc/objc.h:72:1: internal compiler error: in add_byte_size_attribute, at dwarf2out.c:16990 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[5]: *** [linking.lo] Error 1 Revision 159936 is OK. -- Summary: [4.6 Regression] Failed to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44302
[Bug bootstrap/44302] [4.6 Regression] Failed to bootstrap
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-27 22:47 --- It is caused by revision 159943: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01000.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dodji at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44302
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #28 from iains at gcc dot gnu dot org 2010-05-27 22:52 --- (In reply to comment #27) Can you explain the struct __emutls_object change? That is an ABI break (and I don't see anywhere any rationale for that). I did it for two reasons; 1/ to prove that I'd got a handle on everywhere it was being used. 2/ to put the pointer at 0 offset in the structure. However, it's easily reversed if there is felt to be no benefit from 2. I also moved a chunk of code in varasm to collect the emutls code together - again that is not important to the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug bootstrap/44302] [4.6 Regression] Failed to bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-27 22:58 --- This patch: --- Index: dwarf2out.c === --- dwarf2out.c (revision 159943) +++ dwarf2out.c (working copy) @@ -19427,7 +19427,8 @@ gen_typedef_die (tree decl, dw_die_ref c generate that DIE right away. add_type_attribute called below will then pick (via lookup_type_die) that anonymous struct DIE. */ - gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE); + if (is_naming_typedef_decl (decl)) + gen_tagged_type_die (type, context_die, DINFO_USAGE_DIR_USE); } add_type_attribute (type_die, type, TREE_READONLY (decl), --- seems to work. But I don't know if it is correct. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44302
