On Tue, 2010-05-11 at 17:40 -0400, DJ Delorie wrote:
I discovered that if you build a plain arm-elf toolchain, the default
float-abis for gcc and gas don't match. I added this patch locally to
make it just work but it seems to me it would be better to have the
defaults match, although I'm
On 05/14/2010 03:40 PM, Richard Guenther wrote:
On Fri, May 14, 2010 at 3:34 PM, Toon Moenet...@moene.org wrote:
On 04/25/2010 01:24 PM, Toon Moene wrote:
Richard Guenther wrote:
[ Concerning this assert ]
It is checking that for one symbol we only have one definition.
You are using
--- Comment #16 from a14331990 at hotmail dot com 2010-05-15 06:01 ---
(In reply to comment #8)
I think this is a bug the MingW maintainers should handle.
While I understand Andrew's position, it seems to me that this is nevertheless
a definite regression from the user's
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-15 06:01 ---
Subject: Bug 44112
Author: jakub
Date: Sat May 15 06:01:20 2010
New Revision: 159429
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159429
Log:
PR debug/44112
* dwarf2out.c (resolve_one_addr):
--- 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 NULL
--- 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
template typename T struct S2
{
typedef const T t2;
t2 operator* () const {}
};
template typename T struct S3
{
typedef S2 T t5;
};
template typename T1, typename T2 T2 foo1 (T1 x, T2 y) { y (*x); }
template class T struct S4
{
T operator* () const;
};
struct S7 {};
struct S8
{
--- 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
--- 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 #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
--- 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 #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
--- 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: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 to
--- 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. a
--- 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 +386,7
--- 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=20662action=view)
enable auto-import in ld
This patch comes from a post by Dave Korn and is slightly modified by me
[PATCH] Silence
--- 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.
--
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:
--- 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=20663action=view)
don't emit dllexport'd inline functions
This patch is just a removal of nathan's code.
See
r147799 | nathan |
--- 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=20664action=view)
source code that shows the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44149
--- 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 sometimes
--- 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
--- 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=20665action=view)
testcase: main executable source
--
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=20666action=view)
testcase: dll source
--
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=20667action=view)
testcase: dll header
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- 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=20668action=view)
testcase: makefile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- 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 #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
--- 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 #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=20542action=view) [edit]
Looking at the dump of this code shows:
The $data component of int is being set
--- 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:
--- 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 bit
--- 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 #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 is as
--- 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
--- 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.
--
--- 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 ;-))
--
--- 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 #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 #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 #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 #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=gccview=revrev=159431
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR
--- 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=gccview=revrev=159431
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR
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 #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
--- 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 #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
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 #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
--- 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
--- 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=gccview=revrev=159434
Log:
2010-05-15 Richard Guenther rguent...@suse.de
PR
--- 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
--
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
) 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
GGC heuristics: --param ggc-min-expand=100 --param ggc-min
--- 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=20669action=view)
testcase for xshow.f -O2 -fipa-cp-clone -ftree-vectorize -fno-signed-zeros
-fno-trapping-math
--- 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 #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 #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_filebufchar,
std::char_traitschar ::xsgetn(char*, long) from .libs/misc-inst.o
ld: warning: cannot
--- 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 #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 #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.
--
--- 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 #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
--- 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 #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
--- 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 would
--- 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.
--
--- 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
+++
--- 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 #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]
--- 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
--- 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
$ 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
--- 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=20670action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44153
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:
--- 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=gccview=revrev=159443
Log:
PR c++/44148
* pt.c (tsubst): Unshare template
--- 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 #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 #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 #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 #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 at
--- 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 #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
--
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 #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_stringbufwchar_t,
std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() from
.libs/complex_io.o
...
are
--- 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=gccview=revrev=159445
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR
--- 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=gccview=revrev=159445
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR
--- 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 #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
--- 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 (which is
--- 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
--- 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 #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
--- 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.
--
--- 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
-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.8.1
--- 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=20671action=view)
Linux kernel configuration that fails with gcc-4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44129
98 matches
Mail list logo
