[Bug c++/41480] New: std::map.erase on cygwin
The program goto endless loops when run erase() in a for loop,as fallows:
#include
#include
std::map mymap;
int main() {
mymap[2] =3 ;
mymap[1] = 4;
printf("**test map.erase*\n");
std::map::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=18662&action=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=gcc&view=rev&rev=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=18663&action=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 "" # 1 "" # 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 .
[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
3: R_X86_64_PC32.rodata-0x4
7: ff e0 jmpq *%rax
Changing the initialization to 'f = h' produces the desired results:
:
0: e9 00 00 00 00 jmpq 5
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=18664&action=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 c/41484] New: Please add memory forms of pmovzx* (SSE4.1)
Hi, SSE4.1 introduced zero-extending and sign-extending loads, such as pmovzxbd (%rax), %mm0 which takes four bytes from (%rax), zero-extends them to four 32-bit dwords, and put them into %mm0. However, GCC's intrinsics support only the form pmovzxbd %mm1, %mm0 which take the lower 32 bits from %mm1 and does the same. This is reflected in the definition of the intrinsic (from the GCC 4.4.1 manual): v4si __builtin_ia32_pmovzxbd128 (v16qi) This makes it rather hard and indirect to load, say, 32 bits from an unaligned char* -- especially if you're not sure that the next 96 bits are readable. (Just casting the char* pointer to an v16qi* and dereferencing it in the intrinsic's argument causes GCC to emit an aligned load to a register, followed by a pmovzxbd reg/reg, at least in my program.) Could you please add the forms that take v2qi/v4qi/v8qi/v2hi/v4hi/v2si as well, for the entire pmovzx* and pmovsx* family? -- Summary: Please add memory forms of pmovzx* (SSE4.1) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgunderson at bigfoot dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[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
