--- Comment #84 from aldot at gcc dot gnu dot org 2008-09-24 09:51 ---
The fix doesn't seem to work for me on arm:
$ cat pr-weak.c
/* tell the compiler that the count isn't in the small data section if the arch
* has one (eg: FRV)
*/
extern const unsigned long kallsyms_num_syms
--- Comment #81 from hp at gcc dot gnu dot org 2008-09-22 01:55 ---
Subject: Bug 37170
Author: hp
Date: Mon Sep 22 01:54:03 2008
New Revision: 140539
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140539
Log:
PR middle-end/37170
PR middle-end/37280
*
--- Comment #82 from hp at gcc dot gnu dot org 2008-09-22 01:56 ---
Subject: Bug 37170
Author: hp
Date: Mon Sep 22 01:54:41 2008
New Revision: 140540
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140540
Log:
PR middle-end/37170
PR middle-end/37280
*
--- Comment #83 from hp at gcc dot gnu dot org 2008-09-22 02:06 ---
committed
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #79 from hp at gcc dot gnu dot org 2008-09-02 10:18 ---
Any news on the hppa testing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #80 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-02
14:06 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
Any news on the hppa testing?
I didn't do anything further with the 32-bit port. I did do a
hppa64-hpux11.11 build with your change. I went through
--- Comment #75 from hp at gcc dot gnu dot org 2008-08-31 20:33 ---
(In reply to comment #74)
Patch, take 6.
This one is a significant improvement. In the C testsuite, I'm
seeing a few failures like this one:
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc
--- Comment #76 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-31
21:31 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
Is this really a regression?
Yes, but it may not have anything to do with your change. Looking
through my test results, I see it started failing
--- Comment #77 from hp at gcc dot gnu dot org 2008-08-31 22:51 ---
(In reply to comment #76)
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
Is this really a regression?
I mean regression, compared to unpatched.
Yes, but it may not have anything to do with your change.
--- Comment #78 from hp at gcc dot gnu dot org 2008-09-01 01:42 ---
FWIW, the results in
http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02792.html certainly look
clean enough to be usable as a baseline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #71 from hp at gcc dot gnu dot org 2008-08-30 06:27 ---
Created an attachment (id=16169)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169action=view)
Patch, take 6.
Sigh. This just moves the TREE_STATIC check from the early-return to the
weak-test, since it's wrong
--- Comment #72 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30
18:19 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
It shouldn't matter for Darwin (which doesn't define ASM_OUTPUT_EXTERNAL,
right?) but will fix the test-case for hppa2.0w-hp-hpux11.11, which BTW
--- Comment #73 from hp at gcc dot gnu dot org 2008-08-30 18:45 ---
(In reply to comment #72)
SUPPORTS_WEAK is defined on hppa2.0w-hp-hpux11.11 depending on GAS
support. See som.h.
Good to know. It can't be compiled cross out of the box though, and the
default is off:
/bin/sh
--- Comment #74 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-31
03:19 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #71 from hp at gcc dot gnu dot org 2008-08-30 06:27 ---
Created an attachment (id=16169)
--
--- Comment #61 from andreast at gcc dot gnu dot org 2008-08-29 17:16
---
Created an attachment (id=16165)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165action=view)
preprocessed source from hppa2.0w-hp-hpux11.11
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #62 from hp at gcc dot gnu dot org 2008-08-29 20:51 ---
Looks like the HPPA port, like Darwin, transforms the original symbol_refs upon
seeing them, such that output_operand doesn't see all required,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-29
22:39 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
Looks like the HPPA port, like Darwin, transforms the original symbol_refs
upon
seeing them, such that output_operand doesn't see all required,
If
--- Comment #64 from hp at gcc dot gnu dot org 2008-08-30 00:39 ---
(In reply to comment #63)
If the encoding for function names is getting stripped, then
ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
Not sure what you meant by that comment; that's not what happens
--- Comment #65 from hp at gcc dot gnu dot org 2008-08-30 01:05 ---
If the extern references had been sort -u:ed, they'd had looked like this,
diff from unpatched to patched for the attachment in comment #61, compiled with
-O2:
--- ../../../comboo/hppa2/gcc/hppa2.s 2008-08-29
--- Comment #66 from hp at gcc dot gnu dot org 2008-08-30 01:08 ---
(In reply to comment #61)
Created an attachment (id=16165)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165action=view) [edit]
preprocessed source from hppa2.0w-hp-hpux11.11
Could you please dig out the
--- Comment #67 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30
01:19 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
If the extern references had been sort -u:ed, they'd had looked like this,
diff from unpatched to patched for the attachment in comment #61, compiled
--- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca 2008-08-30
02:48 ---
Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c
If the encoding for function names is getting stripped, then
ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
Not sure what you
--- Comment #69 from hp at gcc dot gnu dot org 2008-08-30 03:20 ---
(In reply to comment #64)
Not sure what you meant by that comment; that's not what happens here AFAICT.
I stated that output_operand does not see the same symbol_ref as was passed to
the rtl insn expander, so
--- Comment #70 from hp at gcc dot gnu dot org 2008-08-30 03:37 ---
(In reply to comment #67)
- .IMPORT _ZNSoD1Ev,CODE
If any of these functions is present in the .s, then there's a problem.
The default for a 32-bit HP-UX symbol that isn't imported is DATA.
The problem
--- Comment #60 from eric dot weddington at atmel dot com 2008-08-28 21:05
---
(In reply to comment #59)
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02037.html.
Patch still works on AVR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #56 from hp at gcc dot gnu dot org 2008-08-27 14:52 ---
(In reply to comment #55)
Just in case, I am bootstraping gcc on ppc darwin9 with the patch. It should
finish tonight (GMT+2) and regtesting results available tomorrow morning. I'll
report any problem.
Thanks. Any
--- Comment #57 from dominiq at lps dot ens dot fr 2008-08-27 15:23 ---
I'll report any problem.
Thanks. Any news on the ppc-darwin and i686-darwin test results?
I meant: no news == good news == nothing to report, but success on both
platforms!-)
--
--- Comment #58 from hp at gcc dot gnu dot org 2008-08-27 15:40 ---
(In reply to comment #57)
I meant: no news == good news == nothing to report, but success on both
platforms!-)
Thanks for telling and for testing. (Really, I try to avoid interpreting lack
of information as other
--- Comment #59 from hp at gcc dot gnu dot org 2008-08-27 16:33 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02037.html.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #55 from dominiq at lps dot ens dot fr 2008-08-26 11:57 ---
FeaPR-creep is strictly frowned upon: open a new PR.
This now pr37241.
With the patch in comment #54 all the failures reported in comment #40 are gone
without regressions
(currently regtesting gfortran).
Thanks
--- Comment #38 from dominiq at lps dot ens dot fr 2008-08-25 09:56 ---
With the patch in comment #37 I bootstraped
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man
--- Comment #39 from dominiq at lps dot ens dot fr 2008-08-25 11:44 ---
More good news, the weak gcc tests pass now for 32 and 64 bit modes.
Also bad news, I have extra failures in the g++ tests (32-bit mode so far),
e.g.:
[ibook-dhum] f90/bug% g++44
--- Comment #40 from dominiq at lps dot ens dot fr 2008-08-25 13:35 ---
Here is the list of new g++ failures (32 and 64 bit modes, except
g++.dg/abi/empty7.C):
FAIL: g++.dg/abi/empty7.C (test for excess errors)--- 32-bit mode only
FAIL: g++.dg/abi/layout2.C (test for excess
--- Comment #41 from eric dot weddington at atmel dot com 2008-08-25 15:12
---
(In reply to comment #37)
Created an attachment (id=16141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141action=view) [edit]
Patch, take 4.
snip
Please, test on darwin and avr.
Testing started
--- Comment #42 from eric dot weddington at atmel dot com 2008-08-25 16:51
---
(In reply to comment #41)
(In reply to comment #37)
Created an attachment (id=16141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141action=view) [edit]
Patch, take 4.
snip
Please, test on
--- Comment #43 from dominiq at lps dot ens dot fr 2008-08-25 17:10 ---
Patch #4 still fixes all weak test regressions on avr.
Did you test g++?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #44 from eric dot weddington at atmel dot com 2008-08-25 17:20
---
(In reply to comment #43)
Patch #4 still fixes all weak test regressions on avr.
Did you test g++?
Yes. I build and test for c, c++, ada, and objc (yes, it actually builds for
AVR). I have 2 less
--- Comment #45 from dominiq at lps dot ens dot fr 2008-08-25 17:25 ---
I have 2 less fails now on c++
On Darwin there is one test which now passes:
g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov
but several new failures (comment #40).
--
--- Comment #46 from hp at gcc dot gnu dot org 2008-08-25 17:58 ---
(In reply to comment #39)
More good news, the weak gcc tests pass now for 32 and 64 bit modes.
Also bad news, I have extra failures in the g++ tests (32-bit mode so far),
/var/tmp//ccLGtbMk.s:unknown:Undefined
--- Comment #47 from dominiq at lps dot ens dot fr 2008-08-25 18:12 ---
To help shorten the number of iterations, can you please verify that the
failures all look as above in the .log files?
You have to realize that I am C* illiterate. So I need more precise directives.
For instance,
--- Comment #48 from dominiq at lps dot ens dot fr 2008-08-25 18:17 ---
I get:
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/empty7.C
/var/tmp//ccCa6HmC.s:unknown:Undefined symbol: __ZTV2S3 can't be a
weak_definition
/var/tmp//ccCa6HmC.s:unknown:Undefined
--- Comment #49 from hp at gcc dot gnu dot org 2008-08-25 18:35 ---
(In reply to comment #48)
I get:
(many X.s:unknown:Undefined symbol: Y can't be a weak_definition elided)
Yes, those look sufficiently similar. (No C or C++ knowledge required. :)
Good to know that it's probably just
--- Comment #50 from pinskia at gcc dot gnu dot org 2008-08-25 18:58
---
I think the C++ failures are related to PR 37167.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #51 from hp at gcc dot gnu dot org 2008-08-25 19:16 ---
(In reply to comment #50)
I think the C++ failures are related to PR 37167.
Depends on how you define related. Maybe the patch for this bug will include
the fix for it (see proposed varasm.c:assemble_external
--- Comment #52 from dominiq at lps dot ens dot fr 2008-08-25 20:23 ---
While we are at the weak arcanes on Darwin, we have also the following since
at least revision 136913 (revision 136903 seems the most likely candidate, the
others being 136899, 136905, and 136912):
FAIL:
--- Comment #53 from hp at gcc dot gnu dot org 2008-08-25 21:36 ---
(In reply to comment #52)
While we are at the weak arcanes on Darwin, we have also the following since
at least revision 136913 (revision 136903 seems the most likely candidate, the
others being 136899, 136905, and
--- Comment #54 from hp at gcc dot gnu dot org 2008-08-26 02:00 ---
Created an attachment (id=16146)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16146action=view)
Patch, take 5.
Removing the TREE_CODE (decl) == FUNCTION_DECL ... part helped to elide
the bogus weak declarations
--- Comment #33 from dominiq at lps dot ens dot fr 2008-08-24 16:46 ---
All the results for 32-bit mode only, but I am pretty confident that they will
hold with -m64.
This is wrong: the tests pass in 32-bit mode, but fail with -m64.
--
--- Comment #34 from dominiq at lps dot ens dot fr 2008-08-24 16:50 ---
[ibook-dhum] f90/bug% gfc -m64 -S -fno-common
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/weak/weak-2.c
[ibook-dhum] f90/bug% grep ffoo1a weak-2.s
movq[EMAIL PROTECTED](%rip), %rax
--
--- Comment #35 from hp at gcc dot gnu dot org 2008-08-25 01:26 ---
Created an attachment (id=16139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16139action=view)
Testcase exposing the (on darwin) breaking aspect of prims.ii
See comments in the test-case. The test-case breaks
--- Comment #36 from hp at gcc dot gnu dot org 2008-08-25 01:48 ---
Created an attachment (id=16140)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16140action=view)
Weak testing weak: testing weak stronger.
I was missing tests that referenced a weak address, but offset, and the
--- Comment #37 from hp at gcc dot gnu dot org 2008-08-25 02:09 ---
Created an attachment (id=16141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141action=view)
Patch, take 4.
Fourth time's a charm.
The difference is just strengthening the early-return in assemble_external so
--- Comment #31 from andreast at gcc dot gnu dot org 2008-08-23 08:17
---
/Volumes/development/gcc/head/objdir-x86_64/./gcc/cc1plus -fpreprocessed
prims.ii -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase prims.cc
-mmacosx-version-min=10.5.4 -mtune=generic -auxbase-strip
--- Comment #32 from hp at gcc dot gnu dot org 2008-08-23 18:38 ---
Thanks, I got everything I need.
The problem seen for the Darwin bootstrap is caused not by the output_operand
call to assemble_external, but by another call, in cp/decl2.c:mark_used.
Plainly treating that (as now)
--- Comment #15 from dominiq at lps dot ens dot fr 2008-08-22 11:48 ---
I don't think this has anything to do with your patch.
Unfortunately it has (at least on i686-apple-darwin9). Reverting the patch for
gcc/varasm.c I have bootstrapped without any problem and the good news it that
--- Comment #16 from dominiq at lps dot ens dot fr 2008-08-22 11:51 ---
Note the patch in comment #12 minus the varasm.c part fixes also
FAIL: g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov
All the results for 32-bit mode only, but I am pretty confident that they will
--- Comment #17 from hp at gcc dot gnu dot org 2008-08-22 13:14 ---
Could one (or both) please attach preprocessed code and command line so I can
reproduce the ICE you see with the *whole* patch applied? I don't see it for
neither cris-elf nor native and I don't see where it comes
--- Comment #18 from dominiq at lps dot ens dot fr 2008-08-22 13:20 ---
Could one (or both) please attach preprocessed code and command line so I can
reproduce the ICE you see with the *whole* patch applied? I don't see it for
neither cris-elf nor native and I don't see where it
--- Comment #19 from eric dot weddington at atmel dot com 2008-08-22 13:44
---
(In reply to comment #17)
Could one (or both) please attach preprocessed code and command line so I can
reproduce the ICE you see with the *whole* patch applied? I don't see it for
neither cris-elf nor
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #20 from hp at gcc dot gnu dot org 2008-08-22 14:18 ---
(In reply to comment #18)
My command line is:
../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9
--- Comment #21 from eric dot weddington at atmel dot com 2008-08-22 14:51
---
Created an attachment (id=16128)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16128action=view)
Preprocessed source of ICE from building with patch.
--
--- Comment #22 from eric dot weddington at atmel dot com 2008-08-22 14:52
---
ICE from building gcc target=avr with patch:
Reading specs from /usr/local/avrdev/gcc/build/./gcc/specs
Target: avr
Configured with: ../gcc/configure --prefix=/usr/local/avr-test --target=avr
--- Comment #23 from dominiq at lps dot ens dot fr 2008-08-22 14:53 ---
Here is the command line and its result from directory
/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libgcc:
[ibook-dhum] x86_64/libgcc% /opt/gcc/i686-darwin/./gcc/xgcc -v -save-temps
-B/opt/gcc/i686-darwin/./gcc/
--- Comment #24 from dominiq at lps dot ens dot fr 2008-08-22 14:54 ---
Created an attachment (id=16129)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16129action=view)
libggc2.i for i686-apple-darwin9
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #25 from hp at gcc dot gnu dot org 2008-08-22 15:25 ---
Created an attachment (id=16130)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16130action=view)
Patch, take 3.
Thanks for your reports!
I stupidly forgot to move out the tree type checks from inside the #ifdef
--- Comment #26 from dominiq at lps dot ens dot fr 2008-08-22 17:09 ---
Bootstrap fails at
[ibook-dhum] x86_64/libjava% /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc
-B/opt/gcc/i686-darwin/./gcc -nostdinc++
-L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src
--- Comment #27 from hp at gcc dot gnu dot org 2008-08-22 17:18 ---
(In reply to comment #26)
Bootstrap fails at
Gosh darn.
Please attach preprocessed code and I'll try to figure out what's going on...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #28 from eric dot weddington at atmel dot com 2008-08-22 18:06
---
Well, a bit of good news: patch #3 fixes all test case regressions regarding
weak for the AVR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #29 from hp at gcc dot gnu dot org 2008-08-22 18:18 ---
(In reply to comment #28)
Well, a bit of good news: patch #3 fixes all test case regressions regarding
weak for the AVR.
Thanks for testing! Hopefully I can get that preprocessed code soon and with a
bit of luck the
--- Comment #30 from andreast at gcc dot gnu dot org 2008-08-22 18:42
---
Created an attachment (id=16132)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16132action=view)
preprocessed source prims.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #4 from dominiq at lps dot ens dot fr 2008-08-21 09:15 ---
Same thing here on i686-apple-darwin9.
Does the patch work for you?
No! I still get:
FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo
--- Comment #5 from hp at gcc dot gnu dot org 2008-08-21 13:28 ---
(In reply to comment #4)
Same thing here on i686-apple-darwin9.
But was the failures you see too introduced with r139233?
I can't tell myself because I see no test-results for
i686-apple-darwin on gcc-testresults@
--- Comment #6 from dominiq at lps dot ens dot fr 2008-08-21 15:33 ---
But was the failures you see too introduced with r139233?
It is not in r139096, but appeared in r139293. So it is the right window, but I
don't have anything in between. From what I have seen it looks more like a
--- Comment #7 from eric dot weddington at atmel dot com 2008-08-21 17:07
---
Patch did not fix any those regressions for the AVR:
FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL: gcc.dg/weak/weak-12.c
--- Comment #8 from eric dot weddington at atmel dot com 2008-08-21 17:13
---
(In reply to comment #7)
Patch did not fix any those regressions for the AVR:
Stupid me: There were problems when it tried to patch that I didn't notice.
Fixing that and retesting...
--
--- Comment #9 from eric dot weddington at atmel dot com 2008-08-21 19:04
---
(In reply to comment #7)
Patch did not fix any those regressions for the AVR:
FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL:
--- Comment #10 from dominiq at lps dot ens dot fr 2008-08-21 19:06 ---
I have had a closer look to the failures on i686-apple-darwin9 and they are due
to the replacement of '.weak_definition' with '.indirect_symbol' in the
assembly code (the regexp problem seems related to different
--- Comment #11 from hp at gcc dot gnu dot org 2008-08-21 20:05 ---
Ok, I see why it doesn't work for you guys now: there's another bug; the weak
handling is buggily put inside code gated by #ifdef ASM_OUTPUT_EXTERNAL.
Simply moving it after that hunk should work. But I also see a wart
--- Comment #12 from hp at gcc dot gnu dot org 2008-08-22 02:16 ---
Created an attachment (id=16125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16125action=view)
Patch, take 2.
Against r139233.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--- Comment #13 from hp at gcc dot gnu dot org 2008-08-22 02:24 ---
Patch in comment #12 is as previously mentioned, except because of Darwin's
weird symbol handling, the symbol_ref's didn't pass through the same way as
other operands, so it has to mark weak references manually. (No,
--- Comment #14 from eric dot weddington at atmel dot com 2008-08-22 03:37
---
I tried testing with 139423, but I'm getting a separate error during build:
../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__mulsc3':
../../../../gcc/libgcc/../gcc/libgcc2.c:1831: internal compiler
--- Comment #1 from hp at gcc dot gnu dot org 2008-08-20 15:30 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01407.html.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from eric dot weddington at atmel dot com 2008-08-21 00:26
---
This test also fails recently for avr-unknown-elf.
Also fails: weak-2.c, weak-3.c, weak-4.c, weak-5.c, weak-12.c.
May be related: also fails on gcc.dg/attr-weakref-1.c.
These tests are known fail revision
--- Comment #3 from hp at gcc dot gnu dot org 2008-08-21 00:33 ---
(In reply to comment #2)
This test also fails recently for avr-unknown-elf.
Does the patch work for you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org
87 matches
Mail list logo
