--- Comment #2 from iains at gcc dot gnu dot org 2010-04-06 20:53 ---
(In reply to comment #1)
Basically I think breaking up functions inside sections/segments in object
files is a broken way of doing dead stripping.
hmm I think this is related to hot/cold partitioning rather than
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-06 23:39 ---
according to PP50 of
http://developer.apple.com/Mac/library/documentation/DeveloperTools/Conceptual/LowLevelABI/100-32-bit_PowerPC_Function_Calling_Conventions/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438-SW20
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-07 10:40 ---
Subject: Bug 41594
Author: iains
Date: Wed Apr 7 10:40:06 2010
New Revision: 158052
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158052
Log:
2010-04-07 Iain Sandoe ia...@gcc.gnu.org
PR driver
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-07 10:40 ---
2010-04-07 Iain Sandoe ia...@gcc.gnu.org
PR driver/41594
* gcc.c: Add -static-libstdc++ to list of recognized options.
MChangeLog
Mgcc.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-07 10:44 ---
sorry about the double message.. I know now ;)
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from iains at gcc dot gnu dot org 2010-04-07 16:20 ---
Subject: Bug 23716
Author: iains
Date: Wed Apr 7 16:20:08 2010
New Revision: 158076
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158076
Log:
fix PR23716
2010-04-07 Iain Sandoe ia...@gcc.gnu.org
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-07 19:58 ---
Subject: Bug 35996
Author: iains
Date: Wed Apr 7 19:57:46 2010
New Revision: 158083
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158083
Log:
gcc/objc/Changelog:
2010-04-07 Iain Sandoe ia...@gcc.gnu.org
--- Comment #8 from iains at gcc dot gnu dot org 2010-04-07 20:05 ---
AFAICT, this should be fixed now.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-08 08:59 ---
(In reply to comment #1)
Created an attachment (id=20331)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331action=view) [edit]
gcc46-pr43681.patch
Untested patch.
yes, thanks that works.
- I couldn't see
--- Comment #5 from iains at gcc dot gnu dot org 2010-09-17 17:05 ---
(In reply to comment #4)
Ok ... I fixed the testcase in trunk.
Is there not a simpler way to fix the test with dejagnu directives?
Probably. :-)
well that's why I added the /torture dir under objc.dg
--- Comment #6 from iains at gcc dot gnu dot org 2010-09-21 13:01 ---
(In reply to comment #5)
Thus, I would say middle-end? However, certainly doesn't happen on Linux, for
some reason... Honza, in case please recategorize.
This happens also on i686-darwin9 at m32 m64.
However
--- Comment #9 from iains at gcc dot gnu dot org 2010-09-21 14:13 ---
Subject: Bug 45645
Author: iains
Date: Tue Sep 21 14:12:58 2010
New Revision: 164479
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164479
Log:
2010-09-21 Jonathan Wakely r...@gcc.gnu.org
Jack
--- Comment #4 from iains at gcc dot gnu dot org 2010-09-23 09:34 ---
this appears to be to do with the driver construction of a default
macosx-version-min.
./gcc/xgcc -Bgcc -dumpspecs = bus error
./gcc/xgcc -Bgcc -dumpspecs -mmacosx-version-min=10.5 = completes normally.
Initial
--- Comment #5 from iains at gcc dot gnu dot org 2010-09-23 10:35 ---
if the array was intended to be an array of structs then this fixes:
Index: gcc/config/darwin-driver.c
===
--- gcc/config/darwin-driver.c (revision
/6 fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-apple
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-08 15:07 ---
bootstrapped {powerpc,i686}-apple-darwin9.
this is fixed.
(other 'set but not used' issues at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43684 remain)
--
iains at gcc dot gnu dot org changed:
What
--- Comment #11 from iains at gcc dot gnu dot org 2010-04-09 10:48 ---
Created an attachment (id=20345)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20345action=view)
Provide template args to structure tags for ObjC++ encode.
Re Comment #1
It seems to me that, whilst there might
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-09 11:30 ---
Created an attachment (id=20346)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20346action=view)
Remove (or wrap, as necessary) set but unused vars.
this replaces and consolidates the patches referenced above
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-09 13:34 ---
Subject: Bug 43684
Author: iains
Date: Fri Apr 9 13:34:33 2010
New Revision: 158164
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158164
Log:
gcc/
2010-04-09 Iain Sandoe ia...@gcc.gnu.org
PR
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-09 14:02 ---
as of 10-04-09 bootstrapping w/apple 4.0.1.
thor:gcc-4-4-branch-build $ ./gcc/xgcc -v
Using built-in specs.
Target: powerpc64-apple-darwin9
Configured with: ../gcc-4-4-branch/configure --target=powerpc64-apple
: [4.6 Regression] gcc.c-torture/execute/ashldi-1.c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
--- Comment #12 from iains at gcc dot gnu dot org 2010-04-09 17:42 ---
(In reply to comment #11)
The http://gcc.gnu.org/viewcvs?root=gccview=revrev=126068
patch adds OPTION_static, but nothing ever returns that value, so the code
setting static_linking is clearly dead code
--- Comment #13 from iains at gcc dot gnu dot org 2010-04-09 19:04 ---
Created an attachment (id=20349)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20349action=view)
check for -static in lookup_option.
PR bootstrap/31400
* gfortranspec.c (lookup_option): Check
--- Comment #14 from iains at gcc dot gnu dot org 2010-04-09 19:06 ---
(In reply to comment #10)
Any chance to ever get -static-libgomp? Otherwise this PR can probably be
closed?!
On Darwin - I made it so that if -static-* is given for {stdc++,cc, fortran}
the specs cause
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-09 19:24 ---
(In reply to comment #1)
Guess setting DECL_READ_P at the same spot as TREE_USED in config/darwin-c.c
could fix this.
Yes, it does thanks the head up.
... is TREE_USED() redundant in this case?
(I've left
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-09 19:36 ---
bootstrap completed on {powerpc,i686}-apple-darwin9 and x86_64-apple-darwin10
@r158165
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #32 from iains at gcc dot gnu dot org 2010-04-09 20:45 ---
(In reply to comment #21)
As a workaround in gcc I suggest to strip -lm in the darwin specific specs
processing.
I think this is our best way forward.
We should not accept -lm if it could alter the behavior
--- Comment #16 from iains at gcc dot gnu dot org 2010-04-09 21:19 ---
(In reply to comment #15)
(In reply to comment #14)
On Darwin - I made it so that if -static-* is given for {stdc++,cc, fortran}
the specs cause a substitution for static libgomp. Would that work for you
--- Comment #18 from iains at gcc dot gnu dot org 2010-04-09 21:51 ---
(In reply to comment #17)
Question being, is there a difference between darwin and, say, our average
linux box, that allows static linking with the one, but not with the other?
yes, there is a significant
--- Comment #35 from iains at gcc dot gnu dot org 2010-04-09 22:30 ---
(In reply to comment #34)
I thought we were going to wait for the vendor (Apple) to fix their complex
math subroutines.
We shouldn't be affected by the bug - so, great if it gets fixed, but we still
need to make
--- Comment #5 from iains at gcc dot gnu dot org 2010-04-10 21:15 ---
(In reply to comment #4)
I can't get it to bootstrap with the following:
/bin/rm -rf *; ../../gcc-4_4-branch/configure CC='/pkgs/gcc-4.3.2-64/bin/gcc
As you pointed out in comment #2 and as I say in comment #3
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-10 22:13 ---
(In reply to comment #6)
I wrote
And I get the same error if I use your configure line.
which means using gcc-4.0.1; I used *exactly* your configure line.
Did you have the gmp and mpfr sources in the gcc-4_4
--- Comment #8 from iains at gcc dot gnu dot org 2010-04-10 22:32 ---
(In reply to comment #6)
And I get the same error if I use your configure line.
$ ./config.status --version
config.status
configured by ../gcc-4-4-branch/configure, generated by GNU Autoconf 2.59,
with options
--- Comment #36 from iains at gcc dot gnu dot org 2010-04-11 10:18 ---
(In reply to comment #33)
(In reply to comment #32)
Note that when using the patch in comment #22 triggers pr43254: another side
effect of -lm is to prevent the run of dsymutil even with -g.
my 0,02 euro...
1
--- Comment #9 from iains at gcc dot gnu dot org 2010-04-11 10:29 ---
(In reply to comment #6)
I wrote
which means using gcc-4.0.1; I used *exactly* your configure line.
Did you have the gmp and mpfr sources in the gcc-4_4-branch source directory?
1. I re-tried with the current gmp
--- Comment #39 from iains at gcc dot gnu dot org 2010-04-11 15:10 ---
(In reply to comment #38)
Interestingly, while the change in Comment 37 eliminates the failures in
gcc.dg/torture/builtin-math-7.c, it introduces the failures...
FAIL: gcc.c-torture/execute/20020412-1.c
--- Comment #5 from iains at gcc dot gnu dot org 2010-04-11 22:52 ---
It's possible that the message from dsymutil is misleading:
Is this correct ?
I'm very new to dwarf - but it looks like the DW_AT_upper_bound is missing a
value?
.byte 0x6 # uleb128 0x6; (DIE (0x10d
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-12 00:55 ---
this causes the message at any optimization 0.
which kinda points to variable length arrays as the issue (wherever that issue
is).
extern long random(void);
int main(int ac,char *av[])
{
int n = random();
int x
--- Comment #10 from iains at gcc dot gnu dot org 2010-04-12 06:43 ---
(In reply to comment #9)
I confirmed with the dsymutil maintainer that my reading of his response was
correct. Indeed, the warning may or may not be significant and has to be
checked for each instance. So if all
--- Comment #11 from iains at gcc dot gnu dot org 2010-04-12 06:57 ---
(In reply to comment #9)
checked for each instance. So if all four test cases are actually emitting
valid dwarf, we can drop the usage of -lm on darwin[921]
The two things are totally unrelated - AFAICT
--- Comment #13 from iains at gcc dot gnu dot org 2010-04-12 13:28 ---
Created an attachment (id=20364)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20364action=view)
hack wrapper for dsymutil
This is a simple script that edits one specific warning out of the output from
dsymutil
--- Comment #14 from iains at gcc dot gnu dot org 2010-04-12 13:36 ---
Created an attachment (id=20365)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20365action=view)
sort out some nits with config/{*,}/darwin*.h and hack in a solution for
dsymtuil
The dsymutils issue
--- Comment #15 from iains at gcc dot gnu dot org 2010-04-12 13:39 ---
(In reply to comment #12)
GCC would ICE if the referenced DIE wasn't being output on:
gcc_assert (AT_ref (a)-die_offset);
in output_die.
thanks Jakub,
for now we need to work around this ..
(a) until dsymutils
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-12 18:53 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00584.html
for an updated patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25766
--- Comment #42 from iains at gcc dot gnu dot org 2010-04-13 01:07 ---
actually,
The logic in libgcc_s/libgcc_ext is working properly - libgcc_s.10.5 =
/usr/libgcc_s.1.dylib = /usr/libSystem.dylib. The function is named in
/usr/lib/libgcc_s.10.5.
What is happening is Bad [at least
--- Comment #19 from iains at gcc dot gnu dot org 2010-04-13 11:37 ---
Subject: Bug 31400
Author: iains
Date: Tue Apr 13 11:37:34 2010
New Revision: 158262
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158262
Log:
gcc/fortran:
2010-04-13 Iain Sandoe ia...@gcc.gnu.org
--- Comment #48 from iains at gcc dot gnu dot org 2010-04-13 16:52 ---
give me a day or two guys...
and I'll post a composite patch that
(a) cleans up some of the nits in config{,/*}/darwin*.h
(b) gets rid of -lgcc [well, moves it to the only places it's still needed]
(c) sorts out
at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-*-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-14 09:06 ---
I'll take this for now - since I've got a patch in progress that ought to fix
it.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-14 09:49 ---
(In reply to comment #2)
Does FSF gcc-4.2 exhibit the problem? Maybe the OSX compiler has local changes
in the specs processing.
OK, it's not a regression - it never worked ;)
FSF 4.2 does not have the dsymutil
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-14 15:08 ---
see :
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00535.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43708
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-14 15:03 ---
see http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00563.html and its follow up.
section anchors are assumed for powerpc-*-* in target supports - so the
require-effective-target won't clear the problem unless we
: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43753
--- Comment #6 from iains at gcc dot gnu dot org 2010-04-14 16:56 ---
(In reply to comment #1)
With checking enabled, anything can happen. Try without.
Hmm, OK I guess this is bogus - from the other comments - so I'll mark the bug
as resolved ...
.. .. but FWIW:
I rebuilt
--- Comment #7 from iains at gcc dot gnu dot org 2010-04-14 16:58 ---
(In reply to comment #5)
The testcase is chosen to be quite large (and is expensive mainly for i?86
-m32, not -m64), if it is much smaller than even unfixed gcc wouldn't start
eating all available RAM. For me
--- Comment #16 from iains at gcc dot gnu dot org 2010-04-14 17:37 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html
for a proposed resolution to this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-14 17:37 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html
for a proposed resolution to this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #50 from iains at gcc dot gnu dot org 2010-04-14 17:38 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html
for a proposed work-around for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
--- Comment #9 from iains at gcc dot gnu dot org 2010-04-14 17:44 ---
(In reply to comment #8)
Are you speaking of gcc/testsuite/gcc.dg/pr43058.c?
yes - as per Comments #4 and # 5, you will find that this is less troublesome
m64
(on the same machine 10x faster at m64 = I get around 6
--- Comment #16 from iains at gcc dot gnu dot org 2010-04-17 10:17 ---
Created an attachment (id=20407)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20407action=view)
alter deprecation tests to eliminate duplicate warnings.
There are actually several constructs that have
.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: *-*-*
http://gcc.gnu.org
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-17 12:19 ---
It seems that
/* { dg-warning } */
Is eating all lines where occurs together with the line on which the
warning is declared.
Otherwise, we'd get an excess errors (which would be perfectly fine as a way
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-17 13:16 ---
similarly.
it would seem that:
typedef int INT1 __attribute__((deprecated));
struct __attribute__((deprecated)) s_rec {
int x;
INT1 y ; /* { dg-bogus 'INT1' is deprecated } */
} ;
or
struct s_rec {
int x
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-18 15:17 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00585.html
and:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00131.html
--
iains at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-18 19:03 ---
(In reply to comment #2)
warnings should be issued when a
deprecated entity is used and not when that deprecation is declared.
it is not that deprecation that is declared in your examples but a
deprecation
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: ia32-pc-linux, i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797
--- Comment #3 from iains at gcc dot gnu dot org 2010-04-19 16:19 ---
(In reply to comment #2)
The reason is the regexp that dejagnu uses to match the output
/usr/share/dejagnu/dg.exp
...
It would be nice if this were configurable or if we could override it.
yeah - I've just found
--- Comment #5 from iains at gcc dot gnu dot org 2010-04-19 18:26 ---
(In reply to comment #4)
Subject: Re: Testsuite cannot detect duplicated
error/warning messages
In this case, I think this will work:
/* { dg-bogus foo bar } */ /* { dg-warning foo } */
no?
well
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-19 18:38 ---
Created an attachment (id=20422)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20422action=view)
fix PR43797
I think we need to be consistent about adding the attributes and use a null
value to determine
--- Comment #2 from iains at gcc dot gnu dot org 2010-04-19 18:46 ---
Created an attachment (id=20423)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20423action=view)
fix PR43797
sorry, first version of the patch had a hunk unrelated to this PR.
--
iains at gcc dot gnu dot org
: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
--- Comment #1 from iains at gcc dot gnu dot org 2010-04-20 17:06 ---
Created an attachment (id=20446)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20446action=view)
comparison between asm files without an with -feliminate-dwarf2-dups
the main difference seems to be moving
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-30 16:57 ---
(In reply to comment #3)
see:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00585.html
and:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00131.html
I think this should be cleared now - by:
http://gcc.gnu.org/ml
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: i686-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44120
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 16:48 ---
Created an attachment (id=20659)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20659action=view)
fix PR44120
this is a quick-fix,
FWIW we seem to be getting an ever-increasing number of #ifdef OBJCPLUS - I
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 18:47 ---
also:
FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors)
Excess errors:
/GCC/gcc-live-trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/wchar_t/1.cc:53:1:
error: Inline clone
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-13 19:41 ---
(In reply to comment #4)
libstdc++ tests are clean on Linux/ia32 as of revision 159368:
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg01212.html
fails also on powerpc-apple-darwin9
last pass from regress:
Date
: unassigned at gcc dot gnu dot org
ReportedBy: iains at gcc dot gnu dot org
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44125
--- Comment #8 from iains at gcc dot gnu dot org 2010-05-13 20:31 ---
(In reply to comment #7)
Yes, we need the help of people running darwin, on x86_64-linux (-m64) too the
problem cannot be reproduced.
I've just built a reghunt tree ;-)
starting a successive approx. @159348
--- Comment #10 from iains at gcc dot gnu dot org 2010-05-13 21:59 ---
(In reply to comment #9)
Thanks.
between 159348 and 159356
will try and refine - but those changes look kinda connected
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--- Comment #11 from iains at gcc dot gnu dot org 2010-05-13 22:52 ---
(In reply to comment #10)
(In reply to comment #9)
Thanks.
between 159348 and 159356
will try and refine - but those changes look kinda connected
looks like it is 159354.
159353 is OK and the logs
--- Comment #2 from iains at gcc dot gnu dot org 2010-05-13 23:39 ---
fixed by r159377
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 06:22 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01030.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43689
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 06:39 ---
r159321 caused this.
I think this is a case where we are generating initialization of a class -
maybe we're not marking something the way that is expected?
ccing Jan.
--
iains at gcc dot gnu dot org changed
--- Comment #2 from iains at gcc dot gnu dot org 2010-05-14 06:42 ---
the working output (const-str-9.s) is:
.lazy_reference .objc_class_name_NSConstantString
.comm __NSConstantStringClassReference,4,2
.const
.align 2
LC0:
.ascii MyApp\0
is broken under a range of
circumstances.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iains
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 08:17 ---
this was caused by r159370, 72 or 72.
(CC ing Jan Hubika).
in case it's relevant, the emutls control vars are not finalized .
I have a patch to do this
(http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00824.html
--- 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 #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++/.libs
--- 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 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 #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.org
--- 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 #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 #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
1 - 100 of 295 matches
Mail list logo
