--- Comment #1 from jv244 at cam dot ac dot uk 2010-05-16 06:57 ---
reduced testcase:
module mod_tetgen
use iso_c_binding
type tetgenio
double precision, pointer :: pointlist(:,:)
integer :: numberoffacets = 0
end type tetgenio
contains
subroutine tetgenf( in, out )
--- Comment #9 from bdubbs at linuxfromscratch dot org 2010-05-16 06:38
---
I have traced the problem file for this bug to the kernel file
arch/x86/kernel/tsc.c
I have two source trees for the 2.6.33.4 kernel, one compiled with gcc-4.4.1
which works and gcc version 4.5.1 20100514 (pre
--- Comment #8 from bdubbs at linuxfromscratch dot org 2010-05-16 05:55
---
Created an attachment (id=20671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20671&action=view)
Linux kernel configuration that fails with gcc-4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4412
ilt-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=gcc/dev/20100515/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../src/gcc-dev/configure --prefix=gcc/dev/20100515/
--with-gmp=gmp/4.3.2/ --with-mpfr=mpfr/2.4.2/ --with-mpc=mpc/0.
--- Comment #4 from wilson at gcc dot gnu dot org 2010-05-16 02:07 ---
The testcase fails with -O2 -funroll-loops. It works with -O2.
The problem occurs in main at line 89, which is the second doit call. We get a
segfault when dereferencing a null pointer.
The code is wrong because o
--- Comment #14 from iains at gcc dot gnu dot org 2010-05-16 00:56 ---
in the compilation of eh_globals.cc:
the i686-apple-darwin9 compiler does *not* produce any emutls refs (at m32 or
m64) - but rather all the thread stuff is handled via pthread interfaces.
--
http://gcc.gnu.or
--- Comment #13 from iains at gcc dot gnu dot org 2010-05-16 00:24 ---
(In reply to comment #12)
> ld: codegen problem, can't use rel32 to external symbol
> ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in
> ___cxa_get_globals_fast
> from ../libsupc++/.libs/libsupc++convenience.a
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-15 23:04 ---
Why is flag_exceptions not just streamed out/in with other options?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-15 22:49 ---
OK, here's what's going wrong:
The LTO design is such that EH is only enabled if we encounter a function with
an EH personality.
With -fwhopr we process one translation unit at a time, so when we look at
20081109_1.C
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-15 22:29 ---
(In reply to comment #7)
> For the automatic deallocation there is be a problem remaining:
>
> In comment #0, "a" itself is now automatically deallocated, but not "a%d" any
> more.
This is fixed by this patchlet (whi
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 22:16 ---
r159445 should fix all the initialization trouble. Comment #2/#3 has been
included as a test case.
For the automatic deallocation there is be a problem remaining:
In comment #0, "a" itself is now automatically deall
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-15 22:05 ---
(In reply to comment #2)
> This PR looks related to pr42647.
Thanks for the remark, Dominique. I think they're pretty much identical. The
commit (r159445) includes PR42647 comment #2/#3 as a test case.
--
janus at
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 22:03 ---
Subject: Bug 42647
Author: janus
Date: Sat May 15 22:03:09 2010
New Revision: 159445
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159445
Log:
2010-05-15 Janus Weil
PR fortran/44154
PR for
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-15 22:03 ---
Subject: Bug 44154
Author: janus
Date: Sat May 15 22:03:09 2010
New Revision: 159445
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159445
Log:
2010-05-15 Janus Weil
PR fortran/44154
PR for
--- Comment #12 from dominiq at lps dot ens dot fr 2010-05-15 21:50 ---
I have looked to my logs and the warnings
ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from
.libs/complex_io.o
...
are already in my make log for revision 1546
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-15 21:25 ---
See also pr44154.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-15 21:24 ---
This PR looks related to pr42647.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44154
--- Comment #14 from dominiq at lps dot ens dot fr 2010-05-15 21:21 ---
(In reply to comment #13)
> AFAICT revision 159366 (fix of pr35779) has the side effect of fixing the ICE
> reported in comment #0 without patching gcc/fortran/simplify.c as in comment
> comment #0.
No longer true a
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-15 20:43 ---
Here is the fix:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 159433)
+++ gcc/fortran/trans-decl.c(working copy)
@@
--- Comment #4 from schwab at linux-m68k dot org 2010-05-15 20:35 ---
*** Bug 44151 has been marked as a duplicate of this bug. ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
---
--- Comment #2 from schwab at linux-m68k dot org 2010-05-15 20:35 ---
*** This bug has been marked as a duplicate of 44103 ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-15 20:29 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-15 20:24 ---
Subject: Bug 44148
Author: jakub
Date: Sat May 15 20:23:59 2010
New Revision: 159443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159443
Log:
PR c++/44148
* pt.c (tsubst): Unshare template ar
Reported by Steve Kargl:
FAIL: gfortran.dg/class_19.f03 -O0 execution test
Reduced/modified test case:
implicit none
type foo
integer, allocatable :: int(:)
end type
type(foo),allocatable :: try
allocate(try)
end
This gives (with 4.5 and trunk):
Fortran runtime error: A
--- Comment #1 from pluto at agmk dot net 2010-05-15 20:04 ---
Created an attachment (id=20670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20670&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44153
$ LANG=C make clean all LTOFLAGS=-fwhopr
rm -f *.o *.s *.ii m
g++ -Wall -g0 -O3 -fwhopr a.cpp -c
g++ -Wall -g0 -O3 -fwhopr m.cpp -c
g++ -Wall -g0 -O3 -fwhopr a.o m.o -o m
lto1: internal compiler error: in cgraph_mark_functions_to_output, at
cgraphunit.c:1194
--
Summary: ICE in cgraph_
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-15 20:02 ---
Here is a slightly reduced test case:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type
type :: myclass
type(inner) :: slice
end type
contain
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-15 19:53 ---
A few comments:
(1) adding -flto or -fwhopr solves the linking problem for the polyhedron tests
and the reduced one in comment #1.
(2) the test in comment #4 is different as it shows up for -fwhole-file and is
not s
--- Comment #15 from ubizjak at gmail dot com 2010-05-15 19:43 ---
This PR was fixed somewhere between r158731 [1] and r158736 [2].
The only relevant commit in this range is [3, 4].
[1] http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02458.html
[2] http://gcc.gnu.org/ml/gcc-testresults
--- Comment #11 from dominiq at lps dot ens dot fr 2010-05-15 19:27 ---
(In reply to comment #10)
> Suppressed as by reverting r159371 with...
Confirmed at revision 159435.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-05-15
18:48 ---
Suppressed as by reverting r159371 with...
diff -uNr gcc-4.6-20100514/gcc/varpool.c gcc-4.6-20100514.hubicka/gcc/varpool.c
--- gcc-4.6-20100514/gcc/varpool.c 2010-05-14 19:37:24.0 -0400
+++ g
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-05-15 18:13
---
I suggest you give a chat to Richard Guenther who seems quite up on the
optimisation aspects of things. If we are creating a temporary in the front
end I think that would be the least optimal approach.
--
ht
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-15 18:01 ---
> If we can improve dependency analysis in the front end, where we (potentially)
> have some more information, it should not hurt the middle-end.
>
> OTOH, if somebody is already doing work in this direction, it woul
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-05-15 17:30 ---
(In reply to comment #4)
> > It is an interesting problem.
>
> Should not it be handled by the middle-end, possibly with the help of
> graphite?
If we can improve dependency analysis in the front end, where we (po
--- Comment #4 from dominiq at lps dot ens dot fr 2010-05-15 17:05 ---
> It is an interesting problem.
Should not it be handled by the middle-end, possibly with the help of graphite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-15 16:52 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #4 from hjl dot tools at gmail dot com 2010-05-15 16:51 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from dominiq at lps dot ens dot fr 2010-05-15 16:43 ---
AFAICT revision 159366 (fix of pr35779) has the side effect of fixing the ICE
reported in comment #0 without patching gcc/fortran/simplify.c as in comment
#0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-15 16:08 ---
AFAICT -fwhole-file is enough to get the ICE: '-O2 -fipa-cp-clone
-ftree-vectorize -fno-signed-zeros -fno-trapping-math -fassociative-math
-fwhole-file'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44152
--- Comment #3 from tkoenig at gcc dot gnu dot org 2010-05-15 15:55 ---
I'm working on this (designing an algorithm so far).
It is an interesting problem.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-15 15:45 ---
The failure is back at revision 159433, now with:
ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long) from .libs/misc-inst.o
ld: warning: cannot export hidden symbol __gnu_cx
--- Comment #21 from iains at gcc dot gnu dot org 2010-05-15 15:40 ---
updated:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43602
--- Comment #13 from iains at gcc dot gnu dot org 2010-05-15 15:40 ---
see: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01119.html for a workaround
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-05-15
15:21 ---
Created an attachment (id=20669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20669&action=view)
testcase for xshow.f -O2 -fipa-cp-clone -ftree-vectorize -fno-signed-zeros
-fno-trapping-math -fassoc
ls for shared libraries .. done
GNU Fortran (GCC) version 4.6.0 20100515 (experimental) [trunk revision 159301]
(x86_64-apple-darwin10.3.0)
compiled by GNU C version 4.6.0 20100515 (experimental) [trunk revision
159301], GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
--
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=44150
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-15 15:10 ---
Should be fixed with r159414.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Tar
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-15 15:07 ---
Subject: Bug 44038
Author: rguenth
Date: Sat May 15 15:06:47 2010
New Revision: 159434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159434
Log:
2010-05-15 Richard Guenther
PR tree-optimization/
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-15 15:07 ---
Fixed on the trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Know
--- Comment #3 from mikereape at onetel dot com 2010-05-15 15:07 ---
Subject: Re: Bootstrap error about elf_getshdrstrndx
when configure script does not detect elf_getshdrstrndx
On 05/15/2010 03:53 AM, soni dot sandeepb at gmail dot com wrote:
> --- Comment #2 from soni dot sandee
Revision 159325 breaks libjava on powerpc. The variable
java::lang::Class::class$ is wrongly put in the read-only section.
--
Summary: [4.6 regression] non-const variable in read-only section
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 14:18 ---
r159431 fixes the problems with allocatable scalar class variables in comment
#1 and #2, and also the wording of the error message reported in comment #5.
However, the ALLOCATED intrinsic still gives a gimplification
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-15 14:08 ---
r159431 fixes the ICE. Comment #0 is now accepted without an error message.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-15 14:00 ---
It is caused by revision 159428:
http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00480.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
On Linux/ia32, revision 159428 gave:
FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2
-fwhopr
Revision 159421 is OK.
--
Summary: [4.6 regression] g++.dg/lto/20081109
cp_lto_20081109_0.o-cp_lto_20081109_1.o
Product: gcc
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 13:52 ---
Subject: Bug 43207
Author: janus
Date: Sat May 15 13:52:33 2010
New Revision: 159431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159431
Log:
2010-05-15 Janus Weil
PR fortran/43207
PR for
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 13:52 ---
Subject: Bug 43969
Author: janus
Date: Sat May 15 13:52:33 2010
New Revision: 159431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159431
Log:
2010-05-15 Janus Weil
PR fortran/43207
PR for
--- Comment #12 from hubicka at ucw dot cz 2010-05-15 13:49 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
> I guess, otherwise, we have to intercept every circumstance where a __thread
> var might be used .. and interpose the exchange.
Hmm,
--- Comment #11 from hubicka at ucw dot cz 2010-05-15 13:48 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
> I'd rather go with the DECL_PRESERVE_P hack for now.
Problem with this is that emultls is still broken with LTO. As soon as we
merge
--- Comment #9 from davek at gcc dot gnu dot org 2010-05-15 13:48 ---
FTR: Patch posted at http://sourceware.org/ml/binutils/2010-05/msg00171.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #20 from a14331990 at hotmail dot com 2010-05-15 13:24 ---
(In reply to comment #19)
> Should not the options -fvisibility-inlines-hidden or -fvisibility=hidden fix
> this problem? Option found on http://gcc.gnu.org/wiki/Visibility.
> Note: The MinGW GCC 4.5.0-1 does not make
--- Comment #8 from dougsemler at gmail dot com 2010-05-15 13:03 ---
Done
cf. http://sourceware.org/bugzilla/show_bug.cgi?id=11603
(note to self, pay more attention to specs and less attention to de facto
behavior of toolsets ;-))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=441
--- Comment #10 from iains at gcc dot gnu dot org 2010-05-15 11:57 ---
hmm - that certainly looks simpler...
I guess, otherwise, we have to intercept every circumstance where a __thread
var might be used .. and interpose the exchange.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #19 from stahta01 at students dot ipfw dot edu 2010-05-15
11:53 ---
Should not the options -fvisibility-inlines-hidden or -fvisibility=hidden fix
this problem? Option found on http://gcc.gnu.org/wiki/Visibility.
Note: The MinGW GCC 4.5.0-1 does not make smaller DLLs using ab
--- Comment #5 from sfilippone at uniroma2 dot it 2010-05-15 11:33 ---
(In reply to comment #4)
> Turns out that fixing this one is completely trivial, once you actually have a
> look at it :)
>
> The ALLOCATED intrinsic was just not adjusted to handle CLASS variables yet.
> The patch i
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-15 11:32 ---
I'd rather go with the DECL_PRESERVE_P hack for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
--- Comment #8 from iains at gcc dot gnu dot org 2010-05-15 11:24 ---
(In reply to comment #7)
> Subject: Re: [4.6 Regression] emutls is broken under a
> range of circumstances.
> Correct fix is to lower emultls earlier so both ipa-ref and LTO understands
> it.
> This might be
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-15 10:46 ---
Turns out that fixing this one is completely trivial, once you actually have a
look at it :)
The ALLOCATED intrinsic was just not adjusted to handle CLASS variables yet.
The patch is as simple as this:
Index: gcc/for
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-15 10:25 ---
(In reply to comment #1)
> Created an attachment (id=20542)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20542&action=view) [edit]
Looking at the dump of this code shows:
The $data component of int is being se
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 10:21 ---
(In reply to comment #5)
> Wild shot: has this anything to do with 43969?
Actually I don't think so. At least the patch I posted yesterday does not fix
PR43969:
http://gcc.gnu.org/ml/fortran/2010-05/msg00155.html
--- Comment #7 from davek at gcc dot gnu dot org 2010-05-15 09:45 ---
So... I think now we just need to figure out how to tell LD that some export
directives contain dots because they're exporting a symbol containing a dot.
Actually, that's probably all we need to do: when we find an ex
--- Comment #8 from dominiq at lps dot ens dot fr 2010-05-15 09:43 ---
> confirmed on an un-patched tree - I think this can be closed.
I would prefer to leave it open until the causes of the breakage and the fix
are known.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
--- Comment #6 from davek at gcc dot gnu dot org 2010-05-15 09:38 ---
Created an attachment (id=20668)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20668&action=view)
testcase: makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #5 from davek at gcc dot gnu dot org 2010-05-15 09:38 ---
Created an attachment (id=20667)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20667&action=view)
testcase: dll header
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #4 from davek at gcc dot gnu dot org 2010-05-15 09:37 ---
Created an attachment (id=20666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20666&action=view)
testcase: dll source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #3 from davek at gcc dot gnu dot org 2010-05-15 09:37 ---
Created an attachment (id=20665)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20665&action=view)
testcase: main executable source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #7 from hubicka at ucw dot cz 2010-05-15 09:35 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
Hi,
we can either go with DECL_PRESERVE that is kind of hack but makes situation no
worse.
Correct fix is to lower emultls earlier so bo
--- Comment #2 from davek at gcc dot gnu dot org 2010-05-15 09:34 ---
(In reply to comment #1)
> In other words, I don't think the runtime loader actually keys off the
> presence
> of a dot in the exported symbol, but where the EAT entry points to. If we can
> persuade ld that sometim
--- Comment #1 from toon at moene dot org 2010-05-15 09:32 ---
Created an attachment (id=20664)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20664&action=view)
source code that shows the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- Comment #18 from a14331990 at hotmail dot com 2010-05-15 09:31 ---
Created an attachment (id=20663)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20663&action=view)
don't emit dllexport'd inline functions
This patch is just a removal of nathan's code.
See
r147799 | nathan | 20
The attached subroutine is compiled as follows:
gfortran -c -flto -O2 -fwhole-program bkfconv.F90
and then the object file is placed in a library of its own:
ar rv x.a bkfconv.o
Subsequently, a main program, b.f:
call deep_convection
end
is linked with this library, as follows:
g
--- Comment #7 from iains at gcc dot gnu dot org 2010-05-15 09:29 ---
(In reply to comment #6)
> The bootstrap failure of x86_64-apple-darwin10 seems gone at revision 159429
> (now building libjava).
confirmed on an un-patched tree - I think this can be closed.
--
http://gcc.gnu.or
--- Comment #17 from a14331990 at hotmail dot com 2010-05-15 09:29 ---
Created an attachment (id=20662)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20662&action=view)
enable auto-import in ld
This patch comes from a post by Dave Korn and is slightly modified by me
[PATCH] Silenc
--- Comment #6 from iains at gcc dot gnu dot org 2010-05-15 09:25 ---
(In reply to comment #5)
> Index: gcc/varasm.c
> ===
> --- gcc/varasm.c(revision 159429)
> +++ gcc/varasm.c(working copy)
> @@ -386,6 +38
--- Comment #1 from davek at gcc dot gnu dot org 2010-05-15 09:06 ---
(In reply to comment #0)
> Windows targets that use emutls add a "." character as a separator from the
> _emutls_{t,v} and the true symbol name. However, exporting these symbol names
> from a DLL is problematic (i.e.
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-15 08:59 ---
(In reply to comment #4)
> Subject: Re: [4.6 Regression] emutls is broken under a
> range of circumstances.
>
> The problem is because emultls is handling declarations in a way so references
> are not visible
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-15 08:53 ---
The bootstrap failure of x86_64-apple-darwin10 seems gone at revision 159429
(now building libjava).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-15 08:47 ---
(In reply to comment #3)
> The actual failure is:
> ld: codegen problem, can't use rel32 to external symbol
> ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in
> ___cxa_get_globals_fast
> from ../libsupc++/.lib
--- Comment #4 from hubicka at ucw dot cz 2010-05-15 08:41 ---
Subject: Re: r159371 breaks bootstrap on
x86_64-apple-darwin10
> It appears that only darwin uses the set_user_assembler_name() call so we
> ought to be able to restore the previous behavior with...
Does this help
--- Comment #4 from hubicka at ucw dot cz 2010-05-15 08:39 ---
Subject: Re: [4.6 Regression] emutls is broken under a
range of circumstances.
The problem is because emultls is handling declarations in a way so references
are not visible to
middle end. I guess we need to put DE
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-15 08:29 ---
note fails are for O > 0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
--- Comment #2 from iains at gcc dot gnu dot org 2010-05-15 08:25 ---
as of 159429 - m32 seems to be fixed (and m64 improved):
=== libgomp Summary for unix/-m32 ===
# of expected passes2490
# of unsupported tests 2
=== libgomp Summa
template struct S2
{
typedef const T &t2;
t2 operator* () const {}
};
template struct S3
{
typedef S2 t5;
};
template T2 foo1 (T1 x, T2 y) { y (*x); }
template struct S4
{
T &operator* () const;
};
struct S7 {};
struct S8
{
typedef::S3 >::t5 t6;
t6 m1 () const;
};
template struct
--- Comment #3 from dominiq at lps dot ens dot fr 2010-05-15 07:36 ---
The actual failure is:
libtool: compile: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/bin/ -B/opt/gcc/gcc4.6w/x86_64-a
pple-darwin10.3.0/lib/ -isystem
/opt/gcc/g
--- Comment #5 from sfilippone at uniroma2 dot it 2010-05-15 07:19 ---
(In reply to comment #4)
> When removing the NULL initialization in comment #3, the dump shows:
>
> static struct .class.parent.p this = {.$data=0B};
>
> Zeroing the $data pointer is probably not needed without NU
96 matches
Mail list logo
