Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc
On 1 Jun 2011, at 20:40, Mike Stump wrote: On Jun 1, 2011, at 10:51 AM, Rainer Orth wrote: I can certainly do it this way for now, but if we could do away with the tests completely, that would be cleaner. Agreed, though, I don't believe the test is superfluous. You still haven't answered my question wrt. Darwin 8 vs. 64-bit on PowerPC. Perhaps we can do away with DARWIN_LIBSYSTEM_HAS_UNWIND completely? To quote my previous email: I don't believe the test is superfluous. This means that I can't say for sure that is is unneeded. There was 64-bit support on darwin 8 as I recall. It was working last time I checked (around 3-ish months ago)...
Re: objc/objc++: switch all testcases to Modern Objective-C runtime API
On 6 Jun 2011, at 18:21, Nicola Pero wrote: This patch switches all the testcases in the ObjC/ObjC++ testsuite to use the Modern Objective-C runtime API when executing with the GNU runtime. This will allow me to complete removing the Traditional Objective-C runtime API from libobjc. :-) ... I tested this on GNU/Linux i686, and on Apple 10.6.7 64-bit. That tests both the GNU runtime and a recent NeXT runtime. I'd like to test with an older NeXT runtime, but I don't have any access to an Apple machine with Mac OS X < 10.5. testing at m32 should exercise all the post 10.4 stuff - and would be a good indicator of any major hassles. I'll try and do a 10.4 test during the week ... (assuming trunk still bootstrap on it). Iain
Re: objc/objc++: switch all testcases to Modern Objective-C runtime API
On 6 Jun 2011, at 21:07, Nicola Pero wrote:
On x86_64-apple-darwin10 I have the following failures with -m32
darwin10 is Mac OS X 10.6, right ? I have access to that. So, how
do you test with -m32 ?
I thought the testsuite would do that (test both with -m32 and -m64
if they are available) automatically,
but clearly it doesn't, because I never saw these failures ;-)
It doesn't...
.. if you want to be pedantic the following should cover all bases on
a given platform > 10.4:
make -k check-objc check-obj-c++ RUNTESTFLAGS="--target_board=unix\{-
m32,-m32/-fabi-version=1,-m64\} "
I am doing this on i686-darwin9 at the moment with your original path
- will re-try your re-posted patch.
As a far as my opinion, if it passes OK @m32 on darwin9 (10.5.x) - I'm
with Mike that we have time to sort out any problems on darwin8
(10.4.x).
cheers
Iain
Re: objc/objc++: switch all testcases to Modern Objective-C runtime API
On 6 Jun 2011, at 21:23, IainS wrote:
It doesn't...
.. if you want to be pedantic the following should cover all bases
on a given platform > 10.4:
make -k check-objc check-obj-c++ RUNTESTFLAGS="--target_board=unix\{-
m32,-m32/-fabi-version=1,-m64\} "
duh.. I should check my typing before hitting send..
.. make that -fobjc-abi-version=1.
Iain
Re: objc/objc++: switch all testcases to Modern Objective-C runtime API
On 6 Jun 2011, at 22:37, Mike Stump wrote: On Jun 6, 2011, at 1:32 PM, Dominique Dhumieres wrote: The revamped patch in attach should fix them. :-) It does, thanks, Ok, Iain chimed in that he's ok with it going in sooner, and since - m32 now works, I think this work can go in now, thanks. Thanks for the testing help Dominique! I checked on i686-darwin9 with both m32 and m32/abi=1 the only difference I see is the XPASSes for m64 torture/forward-1.m for gnu runtime. I will try to test on darwin8 during the week - but time v. limited. cheers Iain
Re: [build] Define HAVE_GAS_HIDDEN on Darwin
On 8 Jun 2011, at 10:29, Rainer Orth wrote:
Darwin seems to be exceedingly unreliable under load: tests randomly
time out and work again the next time.
If you mean random timeouts in dejagnu - I suspect (but have not yet
proved) that the culprit is insufficient stack allocation in some
component of tcl or expect itself.
One used to find that non-parallel "make check" would be quite
reliable - but parallel very unreliable.
I use the following local (not submitted, unofficial) patch to dejagnu
on Darwin9 - which retries tests that timeout (once) - this has been
enough to eliminate the frustration for me...
YMMV, of course.
cheers
Iain
--- dejagnu-1.4.4/lib/remote.exp2003-10-11 07:42:46.0 +0100
+++ dejagnu-1.4.4-installed/lib/remote.exp 2010-03-12 09:32:49.0
+
@@ -74,7 +74,7 @@
# or output is redirected. If the program needs to be killed, /bin/sh and
# the kill command will be invoked.
#
-proc local_exec { commandline inp outp timeout } {
+proc one_local_exec { commandline inp outp timeout } {
# Tcl's exec is a pile of crap. It does two very inappropriate things
# firstly, it has no business returning an error if the program being
# executed happens to write to stderr. Secondly, it appends its own
@@ -155,7 +155,7 @@
set got_eof 0
set output ""
-
+set status 0
# Wait for either $timeout seconds to elapse, or for the program to
# exit.
expect {
@@ -163,16 +163,19 @@
append output $expect_out(buffer)
if { [string length $output] < 512000 } {
exp_continue -continue_timer
+ } else {
+ warning "one_local_exec: (output string overflow)"
}
}
timeout {
- warning "program timed out."
+# warning "one_local_exec: program timed out."
+ set status -2
}
eof {
set got_eof 1
}
}
-
+
# Uuugh. Now I'm getting really sick.
# If we didn't get an EOF, we have to kill the poor defenseless program.
# However, Tcl has no kill primitive, so we have to execute an external
@@ -207,12 +210,16 @@
set res "wait failed"
}
}
+
if { $r2 != 0 || $res != "" || ! $got_eof } {
verbose "close result is $res"
- set status 1
+ if { $status != -2 } {
+ set status 1
+ }
} else {
set status 0
}
+
verbose "output is $output"
if { $outp == "" } {
return [list $status $output]
@@ -221,6 +228,29 @@
}
}
+proc local_exec { commandline inp outp timeout } {
+set res [one_local_exec $commandline $inp $outp $timeout]
+set stat [lindex $res 0]
+# OK?
+if { $stat != -2 } {
+ return $res
+}
+# nope...
+#warning "local_exec $commandline timed out : retrying"
+verbose -log "RE-TRIED: (timeout = $timeout) : $commandline "
+if { $timeout < 150 } {
+ set timeout [expr {$timeout} * 2]
+}
+set res [one_local_exec $commandline $inp $outp $timeout]
+set stat [lindex $res 0]
+if { $stat == -2 } {
+ set msg ""
+ warning "TIMED OUT: $commandline timed out after retry"
+ verbose -log "TIMED OUT: $commandline (timeout = $timeout)"
+}
+return $res
+}
+
#
# Execute the supplied program on HOSTNAME. There are four optional arguments
# the first is a set of arguments to pass to PROGRAM, the second is an
@@ -1090,7 +1120,8 @@
}
}
timeout {
- warning "program timed out."
+ warning "standard_wait: program timed out"
+ set status -2
}
eof {
if [board_info $dest exists fileid_origid] {
Re: [PATCH]: Pass -no_pie on SYSTEMSPEC for darwin11
Hi Jack,
On 17 Jun 2011, at 03:21, Jack Howarth wrote:
The gcj compiler needs to pass -no_pie for linkage on darwin11 due
to the new -pie
default of the linker. The attached patch accomplishes this by
passing -no_pie on SYSTEMSPEC
for *-*-darwin[12]*. Since Darwin10 supports -no_pie in its linker,
I included it in the
triplet match to simplify the syntax. Bootstrap and tested on x86_64-
apple-darwin11.
Okay for gcc trunk?
Jack
2011-06-16 Jack Howarth
* libjava/configure.ac (SYSTEMSPEC): Pass -no_pie for darwin11.
* libjava/configure: Regenerate.
I would like to see some more analysis of what the underlying reasons
for failure are.
-fpie works fine with darwin 9 and darwin 10 libjava [XCode 3.1.4 and
3.2.5 respectively, bootstrap w/4.2.1]
(modulo suppressing it when building test-suite .dylibs *** - which
is a testsuite options handling issue - not a fundamental problem).
so:
make -k check-target-libjava "RUNTESTFLAGS=--target_board=unix/-fpie\{-
m32,-m64\} "
passes without regression (re the no pie case) given that pie is
suppressed for dylibs.
-
So is your proposed patch a work-around for (as yet unreleased)
darwin 11 tool-chain bugs or ... ?
Iain
===
kludge to suppress pie for for dylibs (use in place of the darwin9.h
hunk from the attachment on PR49371).
Index: gcc/config/darwin9.h
===
--- gcc/config/darwin9.h(revision 175110)
+++ gcc/config/darwin9.h(working copy)
@@ -35,6 +35,12 @@ along with GCC; see the file COPYING3. If not see
/* Tell collect2 to run dsymutil for us as necessary. */
#define COLLECT_RUN_DSYMUTIL 1
+#undef PIE_SPEC
+#define PIE_SPEC \
+ "%{fpie|pie|fPIE: %{!Zdynamiclib: \
+ %{mdynamic-no-pic: %n'-mdynamic-no-pic' overrides '-pie', '-
fpie' or '-fPIE'; \
+ :-pie}}}"
+
#undef ASM_OUTPUT_ALIGNED_COMMON
#define ASM_OUTPUT_ALIGNED_COMMON(FILE, NAME, SIZE,
ALIGN) \
do
{ \
Re: [PATCH]: Pass -no_pie on SYSTEMSPEC for darwin11
Hi Mike, Jack, On 17 Jun 2011, at 20:24, Jack Howarth wrote: On Fri, Jun 17, 2011 at 10:43:07AM -0700, Mike Stump wrote: On Jun 16, 2011, at 7:21 PM, Jack Howarth wrote: The gcj compiler needs to pass -no_pie for linkage on darwin11 due to the new -pie default of the linker. The attached patch accomplishes this by passing -no_pie on SYSTEMSPEC for *-*-darwin[12]*. Since Darwin10 supports -no_pie in its linker, I included it in the triplet match to simplify the syntax. Bootstrap and tested on x86_64-apple-darwin11. Okay for gcc trunk? The darwin aspects of this seem right to me. I'm less familiar with the SYSTEMSPEC bit in libjava, someone want to give a quick comment on if this is the right knob to twist? Since SYSTEMSPEC in configure.ac is setting system specific options for libgcj.spec.in, it seemed the most rational place to append -no_pie to (and we already had a darwin entry in the case statement). FYI, I also tried a different approach of not appending -no_pie SYSTEMSPEC on darwin but instead using... maybe I need more coffee .. and the gcc gathering was very sociable... but... ... It seems to me that switching pie off in libjava spec == switching pie off for every java program. (i.e. it doesn't seem equivalent to BOOT_CFLAGS, but maybe I'm still missing something). Roughly, there are unresolved issues with position independent code with the garbage collector (or was it a problem with some unknown bit in the compiler), and this just turns off a new OS default for java to work around the issue. I hope that's an at least half way accurate description. We're aiming to have the default for C be - fpie, but for java, no pie. For the C compiler, we must build the compiler without -pie in order for PCH to work. It is reasonable to turn off pie in the java compiler as well. Jack, do we have a PR number for this? If so, please include in the changelog in the usual spot. I plan on opening a PR shortly, but I was hoping to be able to reproduce the same failures under linux using a bootstrap with the compiler defaulted to -fPIC code generation and the inverse change applied to linux of... The thing that is not clear is this. libjava (and boehm-gc) with pie passes on d9 and d10 (modulo a test- suite related kludge); so it doesn't seem that there's a fundamental problem. (c.f. PCH, which won't work with pie, by definition from its design). AFAIR ecj1 is not involved in the libjava tests - because they don't actually compile from .java. (I'm not debating that there is a problem with ecj1 - but maybe that needs to be solved in the explicit build instructions for that executable). So is this 'fix' a work-around for a tool bug... or is there really a lurking problem in boehm-gc/libjava that is uncovered by darwin11? we seem to be switching off pie without actually pointing at the reason for doing so... Iain
Re: [PATCH]: Pass -no_pie on SYSTEMSPEC for darwin11
Hi Jack,
On 18 Jun 2011, at 03:57, Jack Howarth wrote:
On Fri, Jun 17, 2011 at 12:04:34PM +0100, IainS wrote:
Hi Jack,
===
kludge to suppress pie for for dylibs (use in place of the darwin9.h
hunk from the attachment on PR49371).
Iain,
This change should be unncessary since -pie on the linker only
operates
on executables (hence the name PIE).
On darwin < 11 .. which don't default to linking pie:
As stated, it's a kludge to allow fpie to be put as a test-suite
option...
... since the options are passed verbatim to library builds, all the
dylib builds fail otherwise ...
if there is an alternate way of filtering 'fpie/fPIE' out of dylib
builds, that could be more globally applied the to the test suite,
that would be a good fix to make.
(the kludge is expedient to test the hypothesis that pie works with
libjava on darwin 9 & 10 -- FAOD: I am not suggesting it for trunk)...
Iain
Index: gcc/config/darwin9.h
===
--- gcc/config/darwin9.h(revision 175110)
+++ gcc/config/darwin9.h(working copy)
@@ -35,6 +35,12 @@ along with GCC; see the file COPYING3. If not see
/* Tell collect2 to run dsymutil for us as necessary. */
#define COLLECT_RUN_DSYMUTIL 1
+#undef PIE_SPEC
+#define PIE_SPEC \
+ "%{fpie|pie|fPIE: %{!Zdynamiclib: \
+ %{mdynamic-no-pic: %n'-mdynamic-no-pic' overrides '-pie', '-
fpie'
or '-fPIE'; \
+ :-pie}}}"
+
#undef ASM_OUTPUT_ALIGNED_COMMON
#define ASM_OUTPUT_ALIGNED_COMMON(FILE, NAME, SIZE,
ALIGN) \
do
{ \
Re: [PATCH] prune warn_compact_unwind warnings on darwin
On 19 Mar 2011, at 06:22, Mike Stump wrote: On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote: Xcode 4.0's linker now defaults on... -warn_compact_unwind So, if this is a flag, and we can turn the warning off, and we truly don't care about the warnings, why not just use - no_warn_compact_unwind? That would be preferable, I think. 1/ Hm. AFAIK we set "-no_compact_unwind", when the target is 10.6 #define LINK_GCC_C_SEQUENCE_SPEC \ "%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \ - it would seem to be a tool bug to flag a warning for something specifically excluded. 2/ unless "-no_compact_unwind" is now ignored? 3/ maybe we are going to have to follow clang et. al in having a tools version runtime flag (this would especially ease the issues in making canadians to early Darwin versions). OSX ld and cctools version are detectable at runtime for native builds - say: -mmacosx-ld-version= - mmacosx-cctools-version= ... so we don't ask people to put this for the native case (we can also pick sensible defaults for other systems).[trunk clang uses -target-linker-version xx.yy.zz - but that's not consistent with our general scheme]. (I know Mike hates additional flags - and tool capabilities can, of course, be detected at runtime for native builds - but we also cater - by design - for cross-builds to earlier versions of the OS) cheers Iain
Re: fix for 48208 and 48260 on darwin
Hi Christian,
On 28 Mar 2011, at 04:55, Christian Schüler wrote:
F
-C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
after %qs)
+Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing
path after \
%qs)
-F Add to the end of the main framework include path
This looks right (but I cannot approve it).
+++ gcc-4.6.0-RC-20110321-patched/gcc/config/darwin-driver.c
2011-03-26
07:01:02.0 +0100
@@ -161,6 +161,13 @@
continue;
switch ((*decoded_options)[i].opt_index)
{
+#if DARWIN_X86
+ case OPT_arch:
+ if (!strcmp ((*decoded_options)[i].arg, "i386"))
+ generate_option (OPT_m32, NULL, 1, CL_DRIVER, &(*decoded_options)
[i]);
+ else if (!strcmp ((*decoded_options)[i].arg, "x86_64"))
+ generate_option (OPT_m64, NULL, 1, CL_DRIVER, &(*decoded_options)
[i]);
+ break;
+#endif
Hm - this doesn't quite cover the scenario - what about people using
GCC on powerpc*-darwin9?
(or people on x86-darwin10 targeting powerpc on darwin9)?
Normally, the "arch" option is recognized (and swallowed) by the
"Apple way" 'driverdriver.c' program which then emits the right driver
lines for the arch (and deals with cross-compiler lines for ppc).
driverdriver.c is available from the Apple Local GCC open source
releases (e.g. http://opensource.apple.com/source/gcc/gcc-5646/driverdriver.c)
- it's at the top of the source tree
- it builds OK against gcc-4.5 headers - which is OK, since it's a
stand-alone program that just manipulates command lines (doesn't
compile against gcc-4.6 headers because of the changes in option
handling)
[I guess someone should cook up one for gcc/contrib that works with
our new system].
One then builds the {ppc,x86}-apple-darwin* compilers, installs them
and you have a working set that does the "Apple way" layer on top of
GCC.
This works (at least a few weeks ago) - since I managed to get pre-
release 4.6 going within XCode - but needs a couple more small patches
to deal with other options.
---
-- ping me off list, if you would like to try this and I'll try and
send more detailed instructions and a couple of additional patches
that are "work in progress" ...
--
however, I can neither approve nor reject your patches ;-)
cheers
Iain
