http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #71 from Jack Howarth 2011-02-08
03:58:46 UTC ---
I passed Dominique's observations upstream to the compiler-rt PR for this which
is the important thing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #70 from Mike Stump 2011-02-08
03:44:09 UTC ---
If you would like to change the comments to clarify the nasty details, I'll
pre-approve it; though, I think it is unnecessary, as that work references this
bug report, and this bug repor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #69 from Dominique d'Humieres
2011-02-07 22:58:33 UTC ---
> So, what you are saying is that the system routine produces an answer that
> isn't correct down to the last digit of precision for at least 1 input?
I have not looked in det
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #68 from Mike Stump 2011-02-07
22:20:11 UTC ---
So, what you are saying is that the system routine produces an answer that
isn't correct down to the last digit of precision for at least 1 input?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
m...@gcc.gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #66 from mrs at gcc dot gnu.org 2011-02-07
21:46:12 UTC ---
Author: mrs
Date: Mon Feb 7 21:46:10 2011
New Revision: 169905
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169905
Log:
2011-02-07 Iain Sandoe
PR target/47
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #65 from Dominique d'Humieres
2011-02-07 20:55:31 UTC ---
> /* The system ___divdc3 routine in libSystem on darwin10 is not
> accurate to 1ulp, ours is, so we avoid ever using the system name
> for this routine and instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #64 from Iain Sandoe 2011-02-07 20:52:40
UTC ---
(In reply to comment #63)
> Author: mrs
> Date: Mon Feb 7 20:41:50 2011
> New Revision: 169902
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169902
> Log:
> PR target/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #63 from mrs at gcc dot gnu.org 2011-02-07
20:41:54 UTC ---
Author: mrs
Date: Mon Feb 7 20:41:50 2011
New Revision: 169902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169902
Log:
PR target/47558
Add __ieee_divdc3 e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #62 from Dominique d'Humieres
2011-02-05 19:23:09 UTC ---
> ... FYI, I don't
> see why getting ___divdc3 fixed in time for Lion should be that difficult.
>From the audit trail of PR42333, this is not a bug but a choice of speed over
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #61 from Jack Howarth 2011-02-05
19:04:18 UTC ---
Actually the two issues are entirely intertwined. PR47558 was due to not
prioritizing symbols from libSystem over those from libgcc_ext. FYI, I don't
see why getting ___divdc3 fixed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #60 from Iain Sandoe 2011-02-05 18:57:20
UTC ---
(In reply to comment #59)
> I can confirm that the patch in Comment 58 both eliminates the failure in the
> reduced test case from Comment 56 as well as the failure in the dipCoup test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #59 from Jack Howarth 2011-02-05
18:40:15 UTC ---
I can confirm that the patch in Comment 58 both eliminates the failure in the
reduced test case from Comment 56 as well as the failure in the dipCoup test in
xplor-nih. I am less certa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #58 from Iain Sandoe 2011-02-05 12:21:51
UTC ---
The response from Nick indicates that the documentation for -flat_namespace and
two-level namespaces is correct and up to date - so we should proceed with a
fix.
>From a general specs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #57 from Jack Howarth 2011-02-04
15:16:42 UTC ---
For the testcase in Comment 56 using my proposed patch from Comment 45...
gcc-4 -dynamiclib -o libtestcall.dylib -flat_namespace -undefined suppress
-single_module test_call.c
gcc-4 -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #56 from Jack Howarth 2011-02-04
15:11:29 UTC ---
The following works as a testcase for PR47558
test_main.c
--
void main (void)
{
extern int unwindcall(void);
int i;
i=unwindcall();
}
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #55 from Jack Howarth 2011-02-04
12:31:28 UTC ---
Moved conversation upstream for definitive answer from the Apple linker
developer...
http://lists.apple.com/archives/darwin-dev//2011/Feb/msg0.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #54 from Jack Howarth 2011-02-04
12:02:18 UTC ---
Test results for proposed patch in Comment 45 at
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg00416.html.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #53 from Iain Sandoe 2011-02-04 11:26:14
UTC ---
(In reply to comment #52)
> ain,
> I think the key misassumption you are making is that the internal linker
> and dyld behavior for 10.5 is valid under 10.6. Remember that unlike un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #52 from Jack Howarth 2011-02-04
11:02:02 UTC ---
ain,
I think the key misassumption you are making is that the internal linker
and dyld behavior for 10.5 is valid under 10.6. Remember that unlike under
Leopard, where /usr/lib/lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #51 from Iain Sandoe 2011-02-04 10:57:39
UTC ---
(In reply to comment #37)
> Let me know when the dust settles and you guys agree on the path forward and I
> will decloak... I've been trying to avoid reading/understanding the issue...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #50 from Iain Sandoe 2011-02-04 10:52:38
UTC ---
(In reply to comment #49)
> (In reply to comment #38)
>
> [ you might want to re-check
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html would work with
> -flat_namespace - it'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #49 from Iain Sandoe 2011-02-04 10:21:27
UTC ---
(In reply to comment #38)
> This would avoid the need for reverting r163267.
I'd rather not revert r163267 because of the behavior described in comment #35.
However, I think that lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #48 from Jack Howarth 2011-02-04
05:53:00 UTC ---
Both...
[MacPro:~] howarth% gcj --main=testme -O testme.java
[MacPro:~] howarth% ./a.out
Hello
and
[MacPro:~] howarth% gcj -m32 --main=testme -O testme.java
ld: warning: in /sw/lib/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #47 from Jack Howarth 2011-02-04
05:44:50 UTC ---
When the proposed patch goes into gcc trunk we should probably XFAIL
gcc.dg/torture/builtin-math-7.c for darwin10 as it is highly unlikely to be
fixed for Snow Leopard. See...
http://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #46 from Jack Howarth 2011-02-04
05:42:13 UTC ---
Note that with the proposed patch we will pick up the failures in...
FAIL: gcc.dg/torture/builtin-math-7.c -O0 execution test
FAIL: gcc.dg/torture/builtin-math-7.c -O1 execution t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #45 from Jack Howarth 2011-02-04
04:59:06 UTC ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00274.html.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #44 from Jack Howarth 2011-02-04
04:48:21 UTC ---
The patch proposed in Comment 42 eliminates the exception traceback problems
when -flat_namespace is used in xplor-nih and changes our linkage to...
/usr/lib/libSystem.B.dylib (co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #43 from Jack Howarth 2011-02-04
03:24:02 UTC ---
I would also argue, in support of the patch in Comment 42, that it may be wrong
to assume that Apple's linker handles stubs for libgcc_s.1.dylib for
mmacosx-version-min=10.6 in the sam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #42 from Jack Howarth 2011-02-04
03:16:44 UTC ---
The patch in Comment 40 is insufficient to eliminate the exception traceback
failures in xplor-nih and it still back traces into FSF libgcc's unwinder when
it crashes. I believe...
1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #41 from Jack Howarth 2011-02-04
02:39:45 UTC ---
Note that clang also precedes -lgcc with -lSystem. For
-mmacosx-version-min=10.6, it produces...
-lSystem -lgcc
(without the final -lSystem) but for -mmacosx-version-min=10.5, clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #40 from Jack Howarth 2011-02-04
01:47:16 UTC ---
Opps. It should be...
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h(revision 169820)
+++ gcc/config/darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #39 from Jack Howarth 2011-02-04
01:31:30 UTC ---
Also note that on Snow Leopard...
gcc -v -mmacosx-version-min=10.5 himenoBMTxpa.c
produces...
-lgcc_s.10.5 -lgcc -lSystem
so perhaps we just need...
Index: gcc/config/darwin.h
===
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #38 from Jack Howarth 2011-02-04
01:20:05 UTC ---
Actually, I think I see the problem here. Looking at how gcc-4.2 in Snow
Leopard links, I see...
gcc -v himenoBMTxpa.c
...
/usr/libexec/gcc/i686-apple-darwin10/4.2.1/collect2 -dynamic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #37 from Mike Stump 2011-02-04
00:43:50 UTC ---
Let me know when the dust settles and you guys agree on the path forward and I
will decloak... I've been trying to avoid reading/understanding the issue...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #36 from Jack Howarth 2011-02-04
00:30:30 UTC ---
No regressions on x86_64-apple-darwin10 from...
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h(revision 169
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #35 from Iain Sandoe 2011-02-03 14:29:25
UTC ---
(In reply to comment #34)
> (In reply to comment #33)
> > (In reply to comment #32)
> >
> > > So either
> > >
> > > 1/revert 163267 as proposed,
> > > Are we sure that it has no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #34 from Iain Sandoe 2011-02-03 14:21:32
UTC ---
(In reply to comment #33)
> (In reply to comment #32)
>
> > So either
> >
> > 1/revert 163267 as proposed,
> > Are we sure that it has no effect on any other (esp. Java) test-cas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #33 from Jack Howarth 2011-02-03
13:57:23 UTC ---
(In reply to comment #32)
> So either
>
> 1/revert 163267 as proposed,
> Are we sure that it has no effect on any other (esp. Java) test-cases?
>
I'll regression test option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #31 from Jack Howarth 2011-02-02
02:54:50 UTC ---
I can confirm that adding -flat_namespace to the linkage of xplor using stock
gcc trunk is insufficient to eliminate the crashes in the FSF libgcc unwinder.
So we do need both the patc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #30 from Jack Howarth 2011-02-02
02:22:37 UTC ---
(In reply to comment #29)
> If linking the final exe is done with -flat_namespace does it work?
Yes, adding -flat_namespace solves the problem. I didn't realize that option
was usabl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #29 from Iain Sandoe 2011-02-01 23:53:31
UTC ---
(In reply to comment #28)
> Strangely this is insufficient to eliminate the crash (which still ends up in
> the FSF libgcc unwinder)...
> In fact, the only thing left which doesn't hav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #28 from Jack Howarth 2011-02-01
20:08:51 UTC ---
Strangely this is insufficient to eliminate the crash (which still ends up in
the FSF libgcc unwinder)...
-- POWELL -- step= 5 --- stepsize= 0.020455 --- energy evals=2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #27 from Jack Howarth 2011-02-01
19:10:35 UTC ---
I am testing the patch proposed in Comment 24 on darwin10 now.
Don't we also have to handle Zforce_flat_namespace?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #26 from Iain Sandoe 2011-02-01 18:40:53
UTC ---
(In reply to comment #25)
> Again, I would note Nick's original comments on these issues...
> So for compatibility with any Apple gcc built software, we should never
> allow the FSF g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #25 from Jack Howarth 2011-02-01
18:22:45 UTC ---
Again, I would note Nick's original comments on these issues...
This may be that the libgcc_s.dylib based unwinder is incompatible
with the darwin unwinder. You cannot mix and ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #24 from Iain Sandoe 2011-02-01 17:49:34
UTC ---
(In reply to comment #23)
> (In reply to comment #22)
> > My only comment is that the likely users of FSF gcc are also likely
> > builders of
> > ported unix code. So gcc 4.6 needs a b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #23 from Iain Sandoe 2011-02-01 17:28:36
UTC ---
(In reply to comment #22)
> My only comment is that the likely users of FSF gcc are also likely builders
> of
> ported unix code. So gcc 4.6 needs a big fat warning that existing porte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #22 from Jack Howarth 2011-02-01
16:57:04 UTC ---
My only comment is that the likely users of FSF gcc are also likely builders of
ported unix code. So gcc 4.6 needs a big fat warning that existing ported unix
code will have to be vett
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #21 from Iain Sandoe 2011-02-01 16:40:17
UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #16)
> > > (In reply to comment #15)
> In the short-term, we can either revert the patch or apply the al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #20 from Iain Sandoe 2011-02-01 16:32:13
UTC ---
(In reply to comment #19)
> (In reply to comment #16)
> > (In reply to comment #15)
> >
> >
> > > Perhaps r163267 is fragile to certain combination of linker flags (like
> > > -flat_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #19 from Jack Howarth 2011-02-01
15:59:30 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
>
>
> > Perhaps r163267 is fragile to certain combination of linker flags (like
> > -flat_namespace)?
>
> "fragile" LOL...
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #18 from Iain Sandoe 2011-02-01 15:57:30
UTC ---
(In reply to comment #17)
> I guess you could make the requirement to link libSystem before (and after)
> libgcc_ext explicit like this:
you would also need to ensure that libSystem wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #17 from Iain Sandoe 2011-02-01 15:50:44
UTC ---
I guess you could make the requirement to link libSystem before (and after)
libgcc_ext explicit like this:
Index: gcc/config/darwin10.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #16 from Iain Sandoe 2011-02-01 15:26:15
UTC ---
(In reply to comment #15)
> Perhaps r163267 is fragile to certain combination of linker flags (like
> -flat_namespace)?
"fragile" LOL...
man ld:
-flat_namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #15 from Jack Howarth 2011-02-01
15:11:51 UTC ---
DYLD_LIBRARY_PATH is unset when xplor is started. Also remember that your test
case in comment 9 is insufficient to reproduce the behavior of xplor-nih. The
code calling the unwinder s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #14 from Iain Sandoe 2011-02-01 14:37:39
UTC ---
the difference caused by including a reference to "/usr/libgcc_s.xxx" is to
allow a libgcc_s appearing in a DYLD_LIBRARY_PATH (or a fallback path in the
compiler's list) to over-ride ..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #13 from Jack Howarth 2011-02-01
13:56:18 UTC ---
It was be true for the simple case that the reduced linkage is fine but somehow
the xplor-nih building is exposing a corner case we haven't thought of. I have
uploaded a full build log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #12 from Jack Howarth 2011-02-01
13:53:18 UTC ---
Created attachment 23196
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23196
otool -L output for xplor-nih binaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #11 from Jack Howarth 2011-02-01
13:51:52 UTC ---
Created attachment 23195
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23195
build log for xplor-nih 2.2.7 under gcc trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #10 from Iain Sandoe 2011-02-01 13:25:31
UTC ---
two more minor points.
1/ the trunk lib specs do the same as gcc-4.2.1(apple local)
2/ there are no exported symbols for 10.6 in /usr/lib/libgcc_s.10.5.dylib (they
are all $add$os10.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #9 from Iain Sandoe 2011-02-01 09:08:53
UTC ---
Jack,
The linkage of libs (with trunk darwin.h) is like this:
libgcc_ext.dylib ---> exports our additional symbols (ONLY)**
libSystem > contains the annotated system symbols.
**
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #8 from Jack Howarth 2011-02-01
06:10:32 UTC ---
Actually a backtrace confirms that current gcc trunk is broken and the missing
linkage on /usr/lib/libgcc_s.1.dylib is causing the wrong unwinder to be
used...
howarth% ../bin/xplor -d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #7 from Jack Howarth 2011-02-01
04:01:52 UTC ---
Also note that on darwin10...
lrwxr-xr-x 1 root wheel 17 Nov 4 19:37 libgcc_s.1.dylib ->
libSystem.B.dylib
lrwxr-xr-x 1 root wheel 19 Nov 4 20:32 libgcc_s.10.4.dylib ->
l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #6 from Jack Howarth 2011-02-01
03:55:13 UTC ---
We should be very concerned about the fact that on the darwin10 builds of gcc
trunk, we don't prefix the same symbols in the FSF gcc's libgcc_s.1.dylib with
$ld$hide$os10.4$, $ld$hide$o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #5 from Jack Howarth 2011-02-01
00:32:07 UTC ---
Iain,
I think you are confused about what reverting r163267 achieves. I believe
the remaining change in r163267 was left in place because we were under the
impression that the magic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #4 from Jack Howarth 2011-02-01
00:14:17 UTC ---
(In reply to comment #3)
> we keep going round this loop --- by making this change; you are replacing the
> unwinder in libSystem with the one in FSF libgcc_s.
Why do you say that? I a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #3 from Iain Sandoe 2011-01-31 23:49:31
UTC ---
we keep going round this loop --- by making this change; you are replacing the
unwinder in libSystem with the one in FSF libgcc_s.
This might well work for stand-alone code -- but it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #2 from Jack Howarth 2011-01-31
23:42:04 UTC ---
Created attachment 23190
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23190
differences in xplor-nih linkages from r163266 to r163267
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #1 from Jack Howarth 2011-01-31
23:36:35 UTC ---
The following patch reverting the remainder of r163267 eliminates the dipCoup
testcase failure in xplor-nih 2.27 when built with current gcc trunk on
x86_64-apple-darwin10...
Index: gc
71 matches
Mail list logo
