[Bug libgcj/38298] libjava link failures.
--- Comment #10 from rwild at gcc dot gnu dot org 2009-09-27 06:49 --- Subject: Bug 38298 Author: rwild Date: Sun Sep 27 06:49:33 2009 New Revision: 152215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152215 Log: Fix library dependencies for -Wl,--as-needed. gcc/: PR bootstrap/40928 * configure.ac: Use $LIBS for '-ldl', not $LDFLAGS. * configure: Regenerate. libjava/: PR libgcj/38298 * Makefile.am (libgcj_tools_la_LIBADD): Add '-lm'. * Makefile.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38298
[Bug bootstrap/40928] build failure w/ -Wl,--as-needed - undefined references in plugin.c
--- Comment #1 from rwild at gcc dot gnu dot org 2009-09-27 06:49 --- Subject: Bug 40928 Author: rwild Date: Sun Sep 27 06:49:33 2009 New Revision: 152215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152215 Log: Fix library dependencies for -Wl,--as-needed. gcc/: PR bootstrap/40928 * configure.ac: Use $LIBS for '-ldl', not $LDFLAGS. * configure: Regenerate. libjava/: PR libgcj/38298 * Makefile.am (libgcj_tools_la_LIBADD): Add '-lm'. * Makefile.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40928
[Bug bootstrap/40928] build failure w/ -Wl,--as-needed - undefined references in plugin.c
--- Comment #2 from rwild at gcc dot gnu dot org 2009-09-27 06:53 --- Fixed -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40928
[Bug libgcj/38298] libjava link failures.
--- Comment #11 from rwild at gcc dot gnu dot org 2009-09-27 06:56 --- Fixed in trunk. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.2 |4.3.2 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38298
[Bug c++/41480] New: std::map.erase on cygwin
The program goto endless loops when run erase() in a for loop,as fallows:
#include map
#include stdio.h
std::mapint , int mymap;
int main() {
mymap[2] =3 ;
mymap[1] = 4;
printf(**test map.erase*\n);
std::mapint,int::iterator it;
it = mymap.begin();
for (; it != mymap.end() ; it++) {
mymap.erase((*it).first);
}
return 0;
}
I have try to delete the line printf(**test
map.erase*\n);,then it worked correctly!
The configure string is :
./configure --prefix=/usr/local/gcc-4.2.0 --program-suffix=-420
--enable-language=c,c++
--
Summary: std::map.erase on cygwin
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lifelong830114 at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41480
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
--- Comment #4 from irar at il dot ibm dot com 2009-09-27 08:06 ---
(In reply to comment #1)
The interesting thing is that data-ref analysis sees 128bit alignment but
the vectorizer still produces
vect_var_.24_59 = M*vect_p.20_57{misalignment: 0};
D.2564_12 = *D.2563_11;
vect_var_.25_61 = vect_var_.24_59 * vect_cst_.26_60;
D.2565_13 = D.2564_12 * 2.299523162841796875e+0;
M*vect_p.27_64{misalignment: 0} = vect_var_.25_61;
thus, unknown misalignment.
(instantiate_scev
(instantiate_below = 3)
(evolution_loop = 1)
(chrec = {i_10(D), +, 4}_1)
(res = {i_10(D), +, 4}_1))
base_address: i_10(D)
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
base_object: *i_10(D)
Creating dr for *D.2562_7
(res = {f_6(D), +, 4}_1))
base_address: f_6(D)
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
base_object: *f_6(D)
t2.i:5: note: === vect_enhance_data_refs_alignment ===
t2.i:5: note: Vectorizing an unaligned access.
t2.i:5: note: Vectorizing an unaligned access.
aligned to refers to the offset misalignment and not to the misalignment of
base.
attribute aligned works only for arrays, i.e., declarations, and not for
pointer arguments. For pointers the vectorizer only checks TYPE_ALIGN_UNIT of
the base type.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #54 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-09-27 09:03 --- (In reply to comment #51) For 4.4, the designers held two wrong assumptions: 1) the incoming stack is always aligned on -mincoming-stack-boundary (wrong for functions called from assembler or code generated by other compilers). 2) all the variables must be aligned on their alignment (wrong for double, long double, long long, mmx: the processor may accept them misaligned). The assumption 1) generates crashing code (for example Seamonkey). The assumption 2) generates suboptimal code (bug #40667). The assumption 1) can be trivially quashed with parameter -mincoming-stack-boundary=2, then the code will be non-crashing, but you will be hitting problem 2) and the code will be ugly and slow: any function containing double or long double variable will generate code for stack realigning and a frame pointer. (for long long this inefficiency was partially fixed in 4.4.1, but only partially, single long long variables don't trigger the alignment after 4.4.1 but structures with long long do, see bug #40667). So: to fix problem 1), gcc should assume that the incoming stack is 4-byte aligned. To fix problem 2), instead of single alignment, types and variables should have two alignments: preferred alignment and enforced alignment (so that you don't realign the stack if there is double on it, but you realign it if there is 16-byte SSE). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #55 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-09-27 09:07 --- If we assume incoming stack is 4byte aligned, we have to realign stack for every function due to #2, which isn't acceptable. No, you don't. All you have to do is to allocate the stack frame that is multiple of 16 bytes (gcc does that already). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug target/41481] New: missed optimization in cse
Compile following code with options -Os -march=armv5te -mthumb,
class A
{
public:
int ah;
unsigned field : 2;
};
void foo(A* p)
{
p-ah = 1;
p-field = 1;
}
We can get:
mov r3, #1 // A
str r3, [r0]
ldrbr3, [r0, #4]
mov r2, #3
bic r3, r3, r2
mov r2, #1 // B
orr r3, r3, r2
strbr3, [r0, #4]
@ sp needed for prologue
bx lr
Both instruction A and B load a constant 1 into register. We can load 1 into r1
in instruction A and use r1 when constant 1 is required. So instruction B can
be removed.
cse pass doesn't find this opportunity is because it needs all expressions to
be of the same mode. But in rtl level the first 1 is in mode SI and the second
1 is in mode QI. Arm doesn't has any physical register of QI mode, so all of
them are put into 32 bit physical register and causes redundant load of
constant 1.
--
Summary: missed optimization in cse
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41481
[Bug target/41481] missed optimization in cse
--- Comment #1 from carrot at google dot com 2009-09-27 09:13 --- Created an attachment (id=18662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18662action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41481
[Bug target/32187] Complex __float128 is rejected
--- Comment #7 from ktietz at gcc dot gnu dot org 2009-09-27 09:25 --- The new attribute basetype_mode (see http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could provide a way to solve this, as it makes sure that it is associated to the base type, instead of the current type declaration as mode attribute does. by defining __float128 as '#define __float128 float __attribute__ ((basetype_mode(DF)))' Constructs like '__complex__ DFtype z;' getting handled proper, too. Maybe this is a way to solve this issue. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug target/32187] Complex __float128 is rejected
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-09-27 09:28 --- (In reply to comment #7) The new attribute basetype_mode (see http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01907.html for patch) could provide a way to solve this, as it makes sure that it is associated to the base type, instead of the current type declaration as mode attribute does. by defining __float128 as '#define __float128 float __attribute__ ((basetype_mode(DF)))' Constructs like '__complex__ DFtype z;' getting handled proper, too. Err, I meant here of course '__complex__ __float128 z;' Maybe this is a way to solve this issue. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32187
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #56 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-09-27 09:36 --- As for this old code that assumes 16-byte alignment: this is wrong code generated by old versions of gcc. It only works as long as it is called from other gcc = 3 code (call it from gcc 3, icc or assembler and it crashes). So you don't have to realign the stack to make sure that the code works always (it doesn't, anyway). All you have to do with this old code is to make sure that you don't make things worse --- i.e. if it worked before, it should continue work after redesign. So all you need is to make a stack frame having a multiple of 16-bytes. No realign needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
--- Comment #5 from rguenther at suse dot de 2009-09-27 09:43 ---
Subject: Re: vector loads are unnecessarily
split into high and low loads
On Sun, 27 Sep 2009, irar at il dot ibm dot com wrote:
--- Comment #4 from irar at il dot ibm dot com 2009-09-27 08:06 ---
(In reply to comment #1)
The interesting thing is that data-ref analysis sees 128bit alignment but
the vectorizer still produces
vect_var_.24_59 = M*vect_p.20_57{misalignment: 0};
D.2564_12 = *D.2563_11;
vect_var_.25_61 = vect_var_.24_59 * vect_cst_.26_60;
D.2565_13 = D.2564_12 * 2.299523162841796875e+0;
M*vect_p.27_64{misalignment: 0} = vect_var_.25_61;
thus, unknown misalignment.
(instantiate_scev
(instantiate_below = 3)
(evolution_loop = 1)
(chrec = {i_10(D), +, 4}_1)
(res = {i_10(D), +, 4}_1))
base_address: i_10(D)
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
base_object: *i_10(D)
Creating dr for *D.2562_7
(res = {f_6(D), +, 4}_1))
base_address: f_6(D)
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
base_object: *f_6(D)
t2.i:5: note: === vect_enhance_data_refs_alignment ===
t2.i:5: note: Vectorizing an unaligned access.
t2.i:5: note: Vectorizing an unaligned access.
aligned to refers to the offset misalignment and not to the misalignment of
base.
Hmm, I believe it refers to base + offset + constant offset.
attribute aligned works only for arrays, i.e., declarations, and not for
pointer arguments.
I have to check that - I believe that in principle it should work.
For pointers the vectorizer only checks TYPE_ALIGN_UNIT of
the base type.
That should be ok. I guess I have to see what's going on here.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
[Bug middle-end/41475] common variables cannot be expected to be aligned
--- Comment #9 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-09-27 09:51 --- The common linker definitions were made to exactly to make code like this work and share the array between two object. So if you think it is undefined, don't support it (make -fno-common default and remove -fcommon at all). Or, if you want to support it, support it correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41475
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
--- Comment #6 from irar at il dot ibm dot com 2009-09-27 09:56 --- (In reply to comment #5) aligned to refers to the offset misalignment and not to the misalignment of base. Hmm, I believe it refers to base + offset + constant offset. tree-data-refs.h: /* Alignment information. ALIGNED_TO is set to the largest power of two that divides OFFSET. */ tree aligned_to; tree-dat-refs.c: DR_ALIGNED_TO (dr) = size_int (highest_pow2_factor (offset_iv.base)); attribute aligned works only for arrays, i.e., declarations, and not for pointer arguments. I have to check that - I believe that in principle it should work. For pointers the vectorizer only checks TYPE_ALIGN_UNIT of the base type. That should be ok. But we need TYPE_ALIGN_UNIT to be 16, and we are checking scalar type here, so without user defined alignment it will be 4. Ira I guess I have to see what's going on here. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
[Bug target/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
--- Comment #10 from ktietz at gcc dot gnu dot org 2009-09-27 09:59 --- Closed this bug. As it is solved. At least provide testcase doesn't ice with native gcc for w64 anymore. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug fortran/41478] function pack causes double free violation
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 09:59 --- I also see it on *-apple-darwin9 gcc 4.2.4, 4.3.4, 4.4.1, and trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug other/41234] Configure fails to find non-existent g++ preprocessor flag with syntax errors
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-27 10:03 --- I tested given scenario and g++ could find the headers in Stage 2 (using msys make). So this seems to be a configure/environment setup issue, if it still exists for you. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41234
[Bug fortran/41479] wrong code, mis-initialization
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 10:04 --- Regarding the intent(out) issue. I will defer to others. If the issue is valid, this a [4.3/4.4/4.5 Regression]. On *-apple-darwin9 GCC 4.2.4 gives: [ibook-dhum] f90/bug% gfc42 pr41479.f90 [ibook-dhum] f90/bug% a.out Initial state: value = 0 Modified state: value = 1 Initial state again: value = 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
[Bug bootstrap/41245] [4.5 Regression] Bootstrap broken on I386-apple-darwin9 at revision 151373
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2009-09-27 10:10 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41245
[Bug c++/41480] std::map.erase on cygwin
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-27 10:28 --- GCC 4.2 is no longer maintained. It works for me with GCC 4.2.4 on i?86-linux. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41480
[Bug fortran/41478] function pack causes double free violation
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-27 10:36 --- Confirmed on i?86-linux. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i386-32bit, MAC OS X Leopard| GCC host triplet|i386-32bit, MAC OS X Leopard| GCC target triplet|i386-32bit, MAC OS X Leopard| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug bootstrap/41473] [4.5 Regression] dsymutil Assertion failed ... since revision 151907
--- Comment #4 from dominiq at lps dot ens dot fr 2009-09-27 11:44 --- Running valgrind I got: --77271-- /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgfortran.3.dylib: --77271-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes --77271-- /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgcc_s.1.dylib: --77271-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes So I rerun valgrind with --auto-run-dsymutil=yes and got: --77275-- run: /usr/bin/dsymutil /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgfortran.3.dylib --77275-- run: /usr/bin/dsymutil /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgcc_s.1.dylib without error or warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug fortran/41478] function pack causes double free violation
--- Comment #6 from dominiq at lps dot ens dot fr 2009-09-27 11:45 --- Works for me on FreeBSD. Is anyone understanding why? valgrind gives: ==77290== Invalid free() / delete / delete[] ==77290==at 0x167FB: free (vg_replace_malloc.c:323) ==77290==by 0x2EAE: MAIN__ (in ./pr41478.ex) ==77290==by 0x2F0F: main (in ./pr41478.ex) ==77290== Address 0x3e15c0 is 0 bytes inside a block of size 4 free'd ==77290==at 0x167FB: free (vg_replace_malloc.c:323) ==77290==by 0x2E53: MAIN__ (in ./pr41478.ex) ==77290==by 0x2F0F: main (in ./pr41478.ex) ==77290== ==77290== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==77290== malloc/free: in use at exit: 448 bytes in 11 blocks. ==77290== malloc/free: 30 allocs, 20 frees, 3,482 bytes allocated. ==77290== For counts of detected errors, rerun with: -v ==77290== searching for pointers to 11 not-freed blocks. ==77290== checked 833,028 bytes. ==77290== ==77290== ==77290== 4 bytes in 1 blocks are definitely lost in loss record 1 of 4 ==77290==at 0x15516: malloc (vg_replace_malloc.c:193) ==77290==by 0x257B: MAIN__ (in ./pr41478.ex) ==77290==by 0x2F0F: main (in ./pr41478.ex) ==77290== ==77290== LEAK SUMMARY: ==77290==definitely lost: 4 bytes in 1 blocks. ==77290==indirectly lost: 0 bytes in 0 blocks. ==77290== possibly lost: 0 bytes in 0 blocks. ==77290==still reachable: 444 bytes in 10 blocks. ==77290== suppressed: 0 bytes in 0 blocks. ==77290== Reachable blocks (those to which a pointer was found) are not shown. ==77290== To see them, rerun with: --leak-check=full --show-reachable=yes -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-27 12:27 --- Target issue. r151907 is not the revision that caused this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target Keywords||build Summary|[4.5 Regression] dsymutil |[4.5 Regression] dsymutil |Assertion failed ... since|Assertion failed ... |revision 151907 | Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-27 12:32 --- Simple googling leads me to http://wiki.dwarfstd.org/index.php?title=Apple's_Lazy_DWARF_Scheme which in turn makes me think a recent libtool update may be the real cause of this, making this a libtool bug, not a gcc bug. 19259 - libtool: link: dsymutil .libs/libstdc++.6.dylib || : 19260 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line 3641. 19261 + ../libtool: line 7996: 53016 Abort trap dsymutil .libs/libstdc++.6.dylib look how libtool invokes dsymutil here which in turn might get confused by the dwarf from gcc 4.5 and leaves behind a state that in turn causes dSYM directory has wrong UUID. So in the end this is very likely still a dsymutil bug - no user program should run into assertions anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #34 from ubizjak at gmail dot com 2009-09-27 12:35 --- It is tree.o object of stage2 gcc that gets miscompiled when -fipa-sra is added to BOOT_CFLAGS. If tree.o is substituted with the one from the build without BOOT_CFLAGS, gcc is again able to compile hello.c without crashing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug fortran/41478] function pack causes double free violation
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-09-27 13:12 --- Different libc, different behavior on double-free -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug middle-end/41435] GCC doesn't fold complex int division
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-09-27 13:59 --- Fixed -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41435
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #35 from ubizjak at gmail dot com 2009-09-27 14:29 --- Bingo! It is build_function_type_list_1 from tree.c that makes problems: static tree build_function_type_list_1 (bool vaargs, tree return_type, va_list argp) This probably makes alpha specific bootstrap failure duplicate of PR41089. At least it explains, why other targets don't see the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug c/41476] [4.5 regression] __typeof__ expands to const type for function types
--- Comment #1 from schwab at gcc dot gnu dot org 2009-09-27 15:27 --- Subject: Bug 41476 Author: schwab Date: Sun Sep 27 15:27:08 2009 New Revision: 152220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152220 Log: PR c/41476 * c-typeck.c (build_conditional_expr): Use the readonly and volatile flags of the operand types, not of the operands itself. testsuite/: * gcc.dg/cond-constqual-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cond-constqual-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41476
[Bug c/41476] [4.5 regression] __typeof__ expands to const type for function types
--- Comment #2 from schwab at linux-m68k dot org 2009-09-27 15:44 --- Fixed. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41476
[Bug middle-end/41393] [4.5 Regression] ICE in get_eh_region_and_lp_from_rtx at except.c:1692
--- Comment #1 from danglin at gcc dot gnu dot org 2009-09-27 15:54 ---
(gdb) p *cfun-eh-region_array
$5 = {base = {num = 1, alloc = 4, vec = {0x0}}}
(gdb) p lp
$6 = (eh_landing_pad) 0x0
(gdb) p debug_rtx (insn)
(call_insn 6 5 8 3 /home/dave/gcc-4.5/gcc/gcc/testsuite/gcc.dg/20021014-1.c:12
(parallel [
(call (mem:SI (symbol_ref:SI (_mcount)) [0 S4 A32])
(const_int 8 [0x8]))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0x0]))
]) -1 (expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:SI 26 %r26))
(expr_list:REG_DEP_TRUE (use (reg:SI 25 %r25))
(nil
$7 = void
(gdb) p *cfun-eh
$8 = {region_tree = 0x0, region_array = 0x40337510, lp_array = 0x40337528,
throw_stmt_table = 0x0, ttype_data = 0x0, ehspec_data = {arm_eabi = 0x0,
other = 0x0}}
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P3
Target Milestone|4.5.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41393
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #36 from ubizjak at gmail dot com 2009-09-27 16:11 ---
This band-aid patch enables bootstrap with patch from comment #22 reverted to
proceed a bit further:
Index: tree.c
===
--- tree.c (revision 152218)
+++ tree.c (working copy)
@@ -7180,7 +7180,9 @@
function. If VAARGS is set, no void_type_node is appended to the
the list. ARGP muse be alway be terminated be a NULL_TREE. */
-static tree
+tree build_function_type_list_1 (bool, tree, va_list)
__attribute__((noinline));
+
+tree
build_function_type_list_1 (bool vaargs, tree return_type, va_list argp)
{
tree t, args, last;
However, it soon trips on a similar problem when building __mulvdi3. I don't
feel like chasing all va_list usages through the source of gcc, and since
patched gcc compiles hello.c successfully, this proves the problem.
So this bug heavily depends on PR41089 (blocker) as far as alpha is
concerned.
--
ubizjak at gmail dot com changed:
What|Removed |Added
BugsThisDependsOn||41089
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs
--- Comment #27 from ubizjak at gmail dot com 2009-09-27 16:12 --- Blocker, blocks bootstrap on alpha, see PR41395. -- ubizjak at gmail dot com changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug fortran/41479] [4.3/4.4/4.5 Regression] intent(out) for types with default initialization
--- Comment #5 from jv244 at cam dot ac dot uk 2009-09-27 17:03 --- target independent bug. -- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-32bit, MAC OS X Leopard| GCC host triplet|i386-32bit, MAC OS X Leopard| GCC target triplet|i386-32bit, MAC OS X Leopard| Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-09-27 17:03:28 date|| Summary|wrong code, mis-|[4.3/4.4/4.5 Regression] |initialization |intent(out) for types with ||default initialization Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
[Bug fortran/41479] [4.3/4.4/4.5 Regression] intent(out) for types with default initialization
--- Comment #6 from kargl at gcc dot gnu dot org 2009-09-27 17:20 ---
(In reply to comment #0)
The example below shows that besides the fact that declared as INTENT(OUT) the
component 'n' is not initialized per default the second time.
It's not initialized on the first call to INIT(), either.
Form -fdump-tree-original
init (struct container_t restrict container)
{
if (container != 0)
{
if (container-a.data != 0B)
{
__builtin_free ((void *) container-a.data);
}
container-a.data = 0B;
}
}
There is no assignment here. If we look at MAIN
MAIN__ ()
{
static struct container_t container = {.n=4242};
static void init (struct container_t restrict);
static void dump (struct container_t restrict);
container.a.data = 0B;
{
struct container_t D.1317;
struct container_t container_t.1;
container_t.1.n = 4242;
container_t.1.a.data = 0B;
D.1317 = container;
container = container_t.1;
if (D.1317.a.data != 0B)
{
__builtin_free ((void *) D.1317.a.data);
}
D.1317.a.data = 0B;
}
init (container);
dump (container);
container.n = 1;
dump (container);
init (container);
we see the n = 4242 (I changed the value to 4242) from the
original declaration statement.
On a side note, if
integer, dimension(:), allocatable :: a
is replaced with
integer, dimension(:), pointer :: a
we get
REMOVE:kargl[272] ./z
value = 4242
value = 1
value = 4242
and -fdump-tree-original shows
init (struct container_t restrict container)
{
if (container != 0)
{
{
struct container_t D.1311;
struct container_t container_t.1;
container_t.1.n = 4242;
D.1311 = container_t.1;
*container = D.1311;
}
}
}
I suspect that this has been broken since allocatable component
were introduced into gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
[Bug c/41440] SEG FAULT in CSE.C caused by bad RTL expansion
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2009-09-27 17:30
---
Created an attachment (id=18663)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18663action=view)
Patch to cfgrtl.c commit_one_edge_insertion()
The problem is in cfgrtl.c function commit_one_edge_insertion()
It does copy value for phi nodes to previous edge. If it find jump on edge it
places copy before it. It assumes that edge is fall thru edge.
For a fall thru edge, the last instruction can be anything - specifically a
jump just created by RTL expander.
The bug has been present since Rev 146817
I have attached patch that correct the problem.
Index: cfgrtl.c
===
--- cfgrtl.c(revision 152217)
+++ cfgrtl.c(working copy)
@@ -1482,8 +1482,9 @@
happens on the fr30 for example.
We know this block has a single successor, so we can just emit
-the queued insns before the jump. */
- if (JUMP_P (BB_END (bb)))
+the queued insns before the jump. Fallthru edges can have
+jumps created by RTL expander, so ignore these. */
+ if (!(e-flags EDGE_FALLTHRU) JUMP_P (BB_END (bb)))
before = BB_END (bb);
else
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41440
[Bug fortran/41044] internal compiler error: in gfc_conv_intrinsic_function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc-bugs at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41044
[Bug fortran/41479] [4.3/4.4/4.5 Regression] intent(out) for types with default initialization
--- Comment #7 from kargl at gcc dot gnu dot org 2009-09-27 18:18 ---
Checking the 4.2 branch and trans-expr.c in trunk, it appears that
this chunk of code in gfc_conv_function_call() has gone missing.
2148 /* If an INTENT(OUT) dummy of derived type has a default
2149initializer, it must be (re)initialized here. */
2150 if (fsym-attr.intent == INTENT_OUT
2151 fsym-ts.type == BT_DERIVED
2152 fsym-value)
2153 {
2154 gcc_assert (!fsym-attr.allocatable);
2155 tmp = gfc_trans_assignment (e, fsym-value, false);
2156 gfc_add_expr_to_block (se-pre, tmp);
2157 }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
[Bug libfortran/41482] New: ICE in libgfortran arm thumb multilib compile
Internal compiler error when compiling f2c_specifics.F90 function _gfortran_f2c_specific__cos_c8 with optimizations turned on for the thumb multilib directory. The non-thumb build compiles fine. Turning off the -O2 flag compiles fine (not sure if it works). I can reduce the test case removing all other functions from the file: here is the preprocessed file (only difference between f90 and F90 is the # 1 lines) # 1 f2c_specifics.F90 # 1 built-in # 1 command-line # 1 f2c_specifics.F90 subroutine _gfortran_f2c_specific__cos_c8 (res, parm); DOUBLE COMPLEX, intent (in) :: parm; DOUBLE COMPLEX, intent (out) :: res; res = cos (parm); end subroutine And the build results Reading specs from /opt/build/arm-none-elf/./gcc/specs Target: arm-elf Configured with: /opt/src/tooltrunk/configure --prefix=/opt/devtools --with-gmp=/opt/devtools --with-mpc=/opt/devtools --with-mpfr=/opt/devtools --with-ppl=/opt/devtools --with-cloog=/opt/devtools --enable-version-specific-runtime-libs --disable-rpath --disable-win32-registry --enable-languages=c,c++,fortran --disable-bootstrap --target=arm-elf Thread model: single gcc version 4.4.2 20090927 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B/opt/build/arm-none-elf/./gcc/' '-nostdinc' '-B/opt/build/arm-none-elf/arm-elf/thumb/newlib/' '-isystem' '/opt/build/arm-none-elf/arm-elf/thumb/newlib/targ-include' '-isystem' '/opt/src/tooltrunk/newlib/libc/include' '-B/opt/build/arm-none-elf/arm-elf/thumb/libgloss/arm' '-L/opt/build/arm-none-elf/arm-elf/thumb/libgloss/libnosys' '-L/opt/src/tooltrunk/libgloss/arm' '-B/opt/devtools/arm-elf/bin/' '-B/opt/devtools/arm-elf/lib/' '-isystem' '/opt/devtools/arm-elf/include' '-isystem' '/opt/devtools/arm-elf/sys-include' '-L/opt/build/arm-none-elf/./ld' '-DHAVE_CONFIG_H' '-I../thumb' '-I/opt/src/tooltrunk/libgfortran' '-I../thumb' '-iquote/opt/src/tooltrunk/libgfortran/io' '-I/opt/src/tooltrunk/libgfortran/../gcc' '-I/opt/src/tooltrunk/libgfortran/../gcc/config' '-I../../.././gcc' '-D_GNU_SOURCE' '-I' '../thumb' '-Wall' '-Werror' '-fno-underscoring' '-fallow-leading-underscore' '-g' '-O2' '-mthumb' '-c' '-o' 'f2c_specifics.o' /opt/build/arm-none-elf/./gcc/f951 f2c_specifics.F90 -cpp f2c_specifics.f90 -quiet -nostdinc -v -I../thumb -I/opt/src/tooltrunk/libgfortran -I../thumb -I/opt/src/tooltrunk/libgfortran/../gcc -I/opt/src/tooltrunk/libgfortran/../gcc/config -I../../.././gcc -I ../thumb -imultilib thumb -iprefix /opt/build/arm-none-elf/gcc/../lib/gcc/arm-elf/4.4.2/ -isystem /opt/build/arm-none-elf/./gcc/include -isystem /opt/build/arm-none-elf/./gcc/include-fixed -D__USES_INITFINI__ -DHAVE_CONFIG_H -D_GNU_SOURCE -isystem /opt/build/arm-none-elf/arm-elf/thumb/newlib/targ-include -isystem /opt/src/tooltrunk/newlib/libc/include -isystem /opt/devtools/arm-elf/include -isystem /opt/devtools/arm-elf/sys-include -iquote/opt/src/tooltrunk/libgfortran/io f2c_specifics.F90 -quiet -dumpbase f2c_specifics.F90 -mthumb -auxbase-strip f2c_specifics.o -g -O2 -Wall -Werror -version -fno-underscoring -fallow-leading-underscore -o f2c_specifics.s ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/arm-elf/4.4.2/include ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/arm-elf/4.4.2/include-fixed ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/arm-elf/4.4.2/../../../../arm-elf/sys-include ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/arm-elf/4.4.2/../../../../arm-elf/include ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/../../lib/gcc/arm-elf/4.4.2/include ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/../../lib/gcc/arm-elf/4.4.2/include-fixed ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/../../lib/gcc/arm-elf/4.4.2/../../../../arm-elf/sys-include ignoring nonexistent directory /opt/build/arm-none-elf/gcc/../lib/gcc/../../lib/gcc/arm-elf/4.4.2/../../../../arm-elf/include ignoring nonexistent directory ../thumb ignoring nonexistent directory ../thumb ignoring nonexistent directory ../thumb ignoring nonexistent directory /opt/devtools/arm-elf/include ignoring nonexistent directory /opt/devtools/arm-elf/sys-include #include ... search starts here: #include ... search starts here: /opt/src/tooltrunk/libgfortran /opt/src/tooltrunk/libgfortran/../gcc /opt/src/tooltrunk/libgfortran/../gcc/config ../../.././gcc /opt/build/arm-none-elf/./gcc/include /opt/build/arm-none-elf/./gcc/include-fixed /opt/build/arm-none-elf/arm-elf/thumb/newlib/targ-include /opt/src/tooltrunk/newlib/libc/include /opt/src/tooltrunk/libgfortran/io End of search list. GNU Fortran (GCC) version 4.4.2 20090927 (prerelease) (arm-elf) compiled by GNU C version 4.4.1 20090725 (Red Hat 4.4.1-2), GMP version 4.3.1, MPFR version 2.4.2-dev. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 f2c_specifics.F90: In function '_gfortran_f2c_specific__cos_c8': f2c_specifics.F90:2: internal compiler
[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs
--- Comment #28 from rguenth at gcc dot gnu dot org 2009-09-27 18:51 --- Uros, did you fix the alpha backend vaarg gimplification yet? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug target/41393] [4.5 Regression] ICE in get_eh_region_and_lp_from_rtx at except.c:1692
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41393
[Bug c/41483] New: gcc fails to elide indirect function call through immutable static variable
In the following code:
void h(void);
static void g()
{
h();
}
static void (*f)(void) = g;
void k(void)
{
f();
}
It is trivial to see that 'f' cannot change and thus the statement 'f();' can
be compiled as a direct call or jump. gcc however emits an indirect jump on
x86_64:
0: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 7 k+0x7
3: R_X86_64_PC32.rodata-0x4
7: ff e0 jmpq *%rax
Changing the initialization to 'f = h' produces the desired results:
k:
0: e9 00 00 00 00 jmpq 5 k+0x5
1: R_X86_64_PC32h-0x4
Both compiled with -O3 (though expected to work with -O2)
--
Summary: gcc fails to elide indirect function call through
immutable static variable
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avi at argo dot co dot il
GCC build triplet: x86_64-pc-linux
GCC host triplet: x86_64-pc-linux
GCC target triplet: x86_64-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41483
[Bug debug/41474] [4.5 Regression] 951116-1.c ICEs in mem_loc_descriptor, at dwarf2out.c:11279
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-09-27 19:15 --- Same for AVR target. Numerous example (though not same testcase) /home/andy/gccsvn/gcc/testsuite/gcc.c-torture/compile/pr38123.c:13:1: internal compiler error: in mem_loc_descriptor, at dwarf2out.c:11292 Was ok on September 12th and has been failing for a last week or so. -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added CC||hutchinsonandy at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41474
[Bug target/41393] [4.5 Regression] ICE in get_eh_region_and_lp_from_rtx at except.c:1692
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-09-27 19:30 --- Subject: Re: [4.5 Regression] ICE in get_eh_region_and_lp_from_rtx at except.c:1692 I'm testing the attached target fix. Dave --- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-09-27 19:30 --- Created an attachment (id=18664) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18664action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41393
[Bug c/41483] gcc fails to elide indirect function call through immutable static variable
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-27 19:39 ---
Try providing a real prototype for g:
static void g(void)
{
h();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41483
[Bug c/41483] gcc fails to elide indirect function call through immutable static variable
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-09-27 20:27 --- static void g() is weird in C, it really means g(...) . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41483
[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs
--- Comment #29 from ubizjak at gmail dot com 2009-09-27 21:09 --- (In reply to comment #28) Uros, did you fix the alpha backend vaarg gimplification yet? Hm, I'm not aware of anything broken with gimplification (judging by the fact that it worked until recent changes)... The only patch I have is the one from Comment 21, and doesn't make any difference with the problem, reported in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug c/41440] SEG FAULT in CSE.C caused by bad RTL expansion
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-27 21:19 --- As per private communication, you can't do it this way. You'd loose the effect of the inserted insn, as the jump jumps over it. You need to search backward from the jump to the cc0 setter and insert it in front of that one. Look at insert_insn_end_bb_new for an example. -- matz at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41440
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug middle-end/41485] New: [4.5 Regressions] ld: (Warning) Unsatisfied symbol gomp_tls_data
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/libgomp/testsuite/libgomp.c/appendix-a/a.15.1.c -B/test/gnu/gcc/ objdir/hppa64-hp-hpux11.11/./libgomp/ -I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11 /./libgomp -I/test/gnu/gcc/gcc/libgomp/testsuite/.. -fmessage-length=0 -fopenmp -O2 -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/.libs -lgomp -lm - o ./a.15.1.exe(timeout = 300) ld: (Warning) Unsatisfied symbol gomp_tls_data in file /test/gnu/gcc/objdir/hp pa64-hp-hpux11.11/./libgomp/.libs/libgomp.sl 1 warnings. output is: ld: (Warning) Unsatisfied symbol gomp_tls_data in file /test/gnu/gcc/objdir/hp pa64-hp-hpux11.11/./libgomp/.libs/libgomp.sl 1 warnings. FAIL: libgomp.c/appendix-a/a.15.1.c (test for excess errors) Excess errors: ld: (Warning) Unsatisfied symbol gomp_tls_data in file /test/gnu/gcc/objdir/hp pa64-hp-hpux11.11/./libgomp/.libs/libgomp.sl 1 warnings. Introduced between 151907 and 152186. The are no libgomp changes in this interval. -- Summary: [4.5 Regressions] ld: (Warning) Unsatisfied symbol gomp_tls_data Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41485
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #7 from developer at sandoe-acoustics dot co dot uk 2009-09-28 01:18 --- (In reply to comment #6) this issue was introduced by the changes in 151901. (I can obtain a successful bootstrap by reverting the changes of 151815, the dsymutil fail is then present, not present at 151900 with the changes of 151815 reverted). thanks for the pointer to possible libtool influence, however, the libtool-version listed in (e.g.) libgfortran claims not to have changed between 151000 and152000. So in the end this is very likely still a dsymutil bug - no user program should run into assertions anyway. agreed; however, at the moment I can't repeat this outside the GCC build process. running the command line (listed as failing in the log) manually on the freshly-built tree does not fail. dwarfdump -av *.o doesn't reveal any failures. if I build a lib by hand with the objects present and then run dsymutil on it - it doesn't fail. I'm also finding it difficult to check the dwarf-4 stuff since none of google, wiki or the gcc website are pointing to a DWARF4 spec to read. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/41480] std::map.erase on cygwin
--- Comment #2 from lifelong830114 at gmail dot com 2009-09-28 01:39 --- The error occured on cygwin not linux, and I referenced http://gcc.gnu.org/gcc-4.2/buildstat.html -- lifelong830114 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41480
[Bug bootstrap/41432] [4.5 Regression] Gcc is getting slower and slower
--- Comment #4 from hjl dot tools at gmail dot com 2009-09-28 02:22 --- Hardware went bad. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41432
[Bug middle-end/41357] libgomp build fail
--- Comment #31 from davek at gcc dot gnu dot org 2009-09-28 05:48 --- (In reply to comment #30) I still get /bin/sh ./libtool --tag CC --mode=link /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-Wall -Werror -Wc,-pthread -g -O2 -Wl,-O1 -o libgomp.la -version-info 1:0:0 -no-undefined -bindir /usr/local/gnu/bin -rpath /usr/local/gnu/lib/gcc/i686-pc-cygwin/4.5.0 alloc.lo barrier.lo critical.lo env.lo error.lo iter.lo iter_ull.lo loop.lo loop_ull.lo ordered.lo parallel.lo sections.lo single.lo task.lo team.lo work.lo lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo affinity.lo libtool: link: rm -fr .libs/libgomp.dll.a libtool: link: /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-shared .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o-pthread -Wl,-O1 -o .libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgomp.dll.a xgcc: unrecognized option '-pthread' Creating library file: .libs/libgomp.dll.a.libs/team.o:team.c:(.debug_info+0x1084): undefined reference to `_gomp_tls_data' collect2: ld returned 1 exit status make[4]: *** [libgomp.la] Error 1 Yeah, confirmed at r.152230; this bug is not yet fixed. Note that it's a different .o file from those mentioned in the original error. Haven't yet debugged it to see how it's going wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug c/41483] gcc fails to elide indirect function call through immutable static variable
--- Comment #3 from avi at argo dot co dot il 2009-09-28 05:51 --- Of course, sorry about the noise. Marking as invalid. -- avi at argo dot co dot il changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41483
