Hello all,
Supplement to :
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00543.html
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00542.html
Since this is not (AFAICT) reported by test summary;
Most of it seems to be (presumably harmless) differences in white space.
However note at the
On 10 Jun 2008, at 17:11, FX wrote:
I opted to call the static library libgfortran_static and to
leave the shared name unchanged.
I'd suggest -static instead of using an underscore, to follow
libstdc++, but that's a minor point.
A minor point maybe, but, as you say, there seem to be
On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
Hello,
* FX wrote on Tue, Jun 10, 2008 at 05:59:36PM CEST:
De : IainS [EMAIL PROTECTED]
I opted to call the static library libgfortran_static and to leave
the shared name unchanged.
It would be great if libtool could be persuaded to change
On 10 Jun 2008, at 20:58, Ralf Wildenhues wrote:
* IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:
On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:
Can the driver use path/to/libgfortran.a instead of '-Lpath/to
-lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic
I came across a gotcha whilst trying to test the static
implementation of libgfortran on PPC64-apple-darwin8.
Thanks to Tobias B for pointing me at 99% of the solution.
Probably the number of affected systems is small ;) - but, FWIW,
here's HOWTO and a fix.
-
If you host on {powerpc,
Thanks for all the helpful suggestions made in response to :
http://gcc.gnu.org/ml/gcc/2008-06/msg00244.html
--
Here is version 2 of the patch.
This is now conditional on darwin* as the host.
(I guess, in principle, it should really depend on LD_FOR_TARGET, but
I couldn't see how to
hi,
a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc.
However, I'm finding a huge number of failures with g++ caused by the
fact that __Unwind_GetIPInfo is not defined.
When 'make checking', I conventionally move the built libgcc_s.
1.dylib and libgcc_s.10.4.dylib to
Hello Jack,
On 21 Nov 2008, at 18:35, Jack Howarth wrote:
On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote:
When 'make checking', I conventionally move the built libgcc_s.
1.dylib
and libgcc_s.10.4.dylib to one side prior to testing (so that the
Apple-supplied system version is used
On 27 Nov 2008, at 01:13, Geoff Keating wrote:
On 26/11/2008, at 4:16 PM, Jack Howarth wrote:
On Wed, Nov 26, 2008 at 01:22:35PM -0800, Geoffrey Keating wrote:
Jack Howarth [EMAIL PROTECTED] writes:
Iain,
The use of the system libgcc simply won't work on Mac OS X 10.4.
The
Hello all,
The implication of the opening statement of http://gcc.gnu.org/
install/test.html is that make check could (or even should) be done
before make install
Is this a correct interpretation of policy?
tia,
Iain
Hi,
following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html
should I expect
--enable-tls
to produce a functional result on {intel,powerpc}-*-darwin{8,9}
or should all testcases with thread local requirements be wrapped with
{ dg-require-effective-target tls_runtime }
thanks,
Iain
On 8 Dec 2008, at 21:09, Andrew Pinski wrote:
On Mon, Dec 8, 2008 at 1:04 PM, IainS [EMAIL PROTECTED]
acoustics.co.uk wrote:
following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html
As I mentioned; it is emulated. So it works, by default, though it is
hm. At the moment
A little additional info:
PPC darwin8 (if configured --enable-tls --enable-threads) fails the
check_effective_target_{tls, tls_runtime, tls_native} with a compiler
ICE
viz, for example:
tls_native7888.c:3: internal compiler error: in
rs6000_legitimize_tls_address, at
Hi all,
ref: http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html, PR32765 and
http://gcc.gnu.org/ml/fortran/2008-12/ msg00118.html
NOTE to gurus: the whole libgcc_eh, libgcc_s.{10.x, 1} thing is
quite hard to understand.
I searched gcc.pdf, gccint.pdf (0 hits) and the list (not much) ...
On 10 Dec 2008, at 14:43, Jack Howarth wrote:
shipped by Apple with its OS releases. I think what you want to do
make sure you are using the FSF libgcc's and not the system ones
while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter
step will cause the unversioned libgcc to be
On 10 Dec 2008, at 18:10, Mike Stump wrote:
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the stock system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...}
On 10 Dec 2008, at 19:05, Jack Howarth wrote:
On Wed, Dec 10, 2008 at 06:23:18PM +, IainS wrote:
On 10 Dec 2008, at 18:10, Mike Stump wrote:
On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated
versions of
libgcc
On 10 Dec 2008, at 19:46, Jack Howarth wrote:
Since your objections are entirely related to the testsuite when
FSF has not been installed,
hm. I'm not entirely sure that's the whole case... although that was
the trigger for this chain of investigation.
I'm also wondering what
On 10 Dec 2008, at 19:58, Mike Stump wrote:
emulation package, which has nothing to do with eh, right?)
that thought had crossed my mind a few times ;-)
can be found. Another possibility, would be to split out the tls
emulation package from gcc_eh. We avoid gcc_eh, so as to not pull
Thanks Geoff,
that's v. useful doc.
On 10 Dec 2008, at 22:36, Geoff Keating wrote:
On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:
On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote:
snip
To use the 'unversioned set' implies that you're compiling for a
version of Mac OS that Apple
that the problems are fundamentally resolvable).
On 11 Dec 2008, at 00:13, Geoff Keating wrote:
On Dec 10, 2008, at 3:24 PM, IainS wrote:
On 10 Dec 2008, at 22:36, Geoff Keating wrote:
On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:
On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote:
snip
To use
On 11 Dec 2008, at 13:51, Jack Howarth wrote:
On Thu, Dec 11, 2008 at 12:38:11PM +, IainS wrote:
...
I have a hunch that this is, at least partially, the origin of
sporadic
failures in crayptr2 (which has been one of the very few tests
using tls
so far - because all the rest have
Hi,
I've noticed that there are a few symbols that appear T from
libgcc.a and t from libgcc_s.1.dylib.
(the exact set depends on ppc/intel and 32/64)
for example, on darwin9 (32 bit libs) the following;
___copysigntf3
___fabstf2
___udiv_w_sdiv
___unordtf2
Is there some specific reason
On 20 Dec 2008, at 03:51, Mike Stump wrote:
Yes, libgcc_s is carefully built with carefully controlled exports.
They are controlled by:
gcc/libgcc-std.ver
when someone wants to export one of the symbols, they can just add
it to the list.
OK, my question was phrased poorly;
I
Hi,
I need to make a test expanded from ASM_OUTPUT_LABEL_REF that is
language dependent (on objc/objcxx).
It's not clear where the best/proper place to put the code is.
if I put it in {stub,act}-objc.c that's fine for c, c++, objc and
objc++ ...
... but it means that stub-objc then needs
On 15 Jan 2009, at 01:44, Ian Lance Taylor wrote:
I need to make a test expanded from ASM_OUTPUT_LABEL_REF that is
language dependent (on objc/objcxx).
It's pretty hard to think of any reason why something as low-level as
ASM_OUTPUT_LABEL_REF would want to look at anything in the frontend.
Hi,
it seems that there's no trivial.m in gcc/testsuite/objc/execute
a copy of that in gcc/testsuite/objc/execute/exceptions would work
Iain.
#import objc/Object.h
int main(void)
{
[Object class];
return 0;
}
On 15 Jan 2009, at 20:40, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:13 PM, IainS
develo...@sandoe-acoustics.co.uk wrote:
Hi,
it seems that there's no trivial.m in gcc/testsuite/objc/execute
Hmm, this is only needed if execute.exp is run only I think.
that's true, and generally it's
On 15 Jan 2009, at 20:57, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:51 PM, IainS
develo...@sandoe-acoustics.co.uk wrote:
This doesn't seem quite right - because you get different results for
--target_board=unix\{-m32,-m64\} and --target_board=unix\{-
m64,-m32\}
You should not get
for the sake of keeping information segregated in log files (and
balancing out test times)
I tried the following (from within a regression testing script):
'make -k check-gcc-c RUNTESTFLAGS=$runTEST ${STATE}/$svnRevision-
check-c-log.txt 21'
(sleep 2) 'make -k check-gcc-c++
On 9 Mar 2010, at 12:10, Rainer Orth wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
Am I trying something that is unsupported - or is this is a bug?
===
make -k -j8 check is not particularly helpful (a) because it tests
gmp/mpfr/mpc every time (b) any redirected output is hard
On 9 Mar 2010, at 12:46, Rainer Orth wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
Instead, run make mail-report.log afterwards and check that.
... snip
suite in parallel, which isn't bad either.
As I wrote before, I'm going to use this on an (effectively) 64-core
machine
On 9 Mar 2010, at 19:13, Janis Johnson wrote:
To run all of the compiler tests in parallel you can do make -jn -k
check-gcc from the top level and let the existing build machinery
take care of running chunks of tests in parallel and putting the
results back together.
that's fine (I
On 9 Mar 2010, at 19:31, NightStrike wrote:
On Tue, Mar 9, 2010 at 2:27 PM, IainS develo...@sandoe-acoustics.co.uk
wrote:
I do build gmp/mpfr/mpc in-tree...
How? Last I tried, it didn't work, as mpc used the system gmp/mpfr,
not the just-built in-tree versions. Therefore, it's not really
On 9 Mar 2010, at 19:36, Rainer Orth wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
.. I don't seem to get the bus errors on a 4CPU g5 or a Core 2
duo .. but
.. the 8-core machine is faster .. so ... race conditions are more
likely
to manifest there.
But race conditions don't
On 10 Mar 2010, at 09:12, Rainer Orth wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
that's really neat indeed - I should have spotted the potential
looking at
the code in contrib
... although the site.exp is hardwired in btest.sh at present ;
I guess one might be able to use
cleared the problem.
On 10 Mar 2010, at 09:47, Rainer Orth wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
I've got some local patches for btest-gcc.sh which allow just that
(e.g. support for Ada testing), which I'll submit once I'm
reasonably
confident they are general enough.
OK
what is the expected behavior of ?
%{.c|.cc|.for|.F90: foo }
.. as I read gcc/gcc.c I would expect to get foo for command lines
with files with these suffixes:
.c
.cc
.for
.F90
but not otherwise (since it says . binds more strongly than |) ;
Iain
On Darwin we follow the collect2 phase with a call to dsymutil which
post-processes the object to collect debug info into a separate module.
At present this is done by tricking the driver into calling ld
followed by dsymutils by appending the dsymutils call onto the end of
On 12 Apr 2010, at 23:24, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
what is the expected behavior of ?
%{.c|.cc|.for|.F90: foo }
.. as I read gcc/gcc.c I would expect to get foo for command lines
with files with these suffixes:
.c
.cc
.for
.F90
On 12 Apr 2010, at 23:30, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
If I want to install a script (wrapper) that will end up installed in
the same dir as
snip
. If this program will only ever be
run by the gcc driver, then you should install it in either
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
yeah .. we use it in Darwin's dsymutil spec.
%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
%{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
if you put -lm on the c/l dsymutil doesn't get called.
Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver. It doesn't know the source
language of a .o file. So if you are linking, and
On 13 Apr 2010, at 19:05, Peter O'Gorman wrote:
gcc hello.c -g -o hc = dsymutils gets run (not expected from the
syntax, assuming that sources are irrelevant)
gcc hello.o -g -o hc = no dsymutils (expected from the absence of
'.o'
in the list)
We don't want to run dsymutil if there
I feel in my bones that this will probably have been discussed
before ... but.
On my platform of choice when abort() is called it tries to
a) generate a coredump
b) formats and saves a cute crashdump to allow non-expert users to
forward failure info to application writers or the system
On 14 Apr 2010, at 21:42, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
So... I wonder what does abort() offer to the testsuite?
that, for example, _exit(-(__LINE__)) ;
doesn't?
The testsuite can be run on embedded systems over serial ports, where
is sometimes
consider :
typedef int INT1 ;
int func (INT1 x) ;
now if I am in grokparms() parsing INT1 x and I want to issue a
nice diagnostic for x...
I can't seem to find the right magic that gets me back to that DECL
for INT1
(I actually want any attributes attached to it and an
On 19 Apr 2010, at 14:18, Manuel López-Ibáñez wrote:
On 19 April 2010 15:03, IainS develo...@sandoe-acoustics.co.uk
wrote:
consider :
typedef int INT1 ;
int func (INT1 x) ;
now if I am in grokparms() parsing INT1 x and I want to issue a
nice
diagnostic for x...
Can I ask
On darwin (powerpc only at present, but potentially i686 too) we use -
mdynamic-no-pic to build the compiler.
config/mh-ppc-darwin:
# The -mdynamic-no-pic ensures that the compiler executable is built
without
# position-independent-code -- the usual default on Darwin. This fix
speeds
#
Hi Ian,
On 12 May 2010, at 21:00, Ian Lance Taylor wrote:
IainS develo...@sandoe-acoustics.co.uk writes:
.. this seems a bit strange : -fPIC is not a ld flag...
LDFLAGS is flags that are passed to the compiler when linking. It is
not flags passed directly to the linker. I don't know why
No Asbestos required - but .. I do have some observations..
I write pretty much all my serious (day-job) code in ObjC and..
... I have stated that it's an intention to make *that*, at least
work at V2 on FSF.
Having said that:
a) I have not anything like as much attachment to ObjC++ ...
On 21 May 2010, at 10:12, Richard Guenther wrote:
On Thu, May 20, 2010 at 10:20 PM, Steven Bosscher stevenb@gmail.com
wrote:
On Thu, May 20, 2010 at 9:54 PM, IainS develo...@sandoe-acoustics.co.uk
wrote:
No Asbestos required - but .. I do have some observations..
I write pretty much
Hi,
In the Obj{C,C++} testsuite we have cases where we want to check for
reasonably long ascii strings in generated data.
At present, this is done in some places by dg-final/scan-assembler
constructs, but these can (and do) fail when the target assembler
breaks long strings into shorter
I'd like to compile a complete list of targets affected by changes in
emulated TLS.
*-*-darwin*
hppa64-hp-hpux11.11
cris-*-elf
I think also;
*-*-mingw
*-*-cygwin
could people please add to the list/confirm as appropriate?
thanks
Iain
Hi,
I want to do this:
RUNTESTFLAGS=--target_board=unix/-foo/-bar/--sysroot=/path/to/
somewhere
I've tried escaping the path with \ ' inverting the and ' .. all to
no avail ..
what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere ..
google hasn't helped..
anyone know
On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote:
On 9 July 2010 16:55, Doug Semler dougsem...@gmail.com wrote:
On Fri, Jul 9, 2010 at 9:12 AM, IainS develo...@sandoe-acoustics.co.uk
wrote:
Hi,
I want to do this:
RUNTESTFLAGS=--target_board=unix/-foo/-bar/--sysroot=/path/to/
somewhere
On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote:
RUNTESTFLAGS=CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere
--target_board=unix/-foo/-bar
Please, once you find out, add this info to http://gcc.gnu.org/wiki/Testing_GCC
done (and amended the sim. section to refer to the second simulator
Richard,
On 29 Mar 2009, at 12:08, Richard Guenther wrote:
On Sun, Mar 29, 2009 at 1:00 PM, FX fxcoud...@gmail.com wrote:
Hi all,
This mail is a request for some help from our local build machinery
experts... We have a patch under testing for libgfortran to add
runtime
memleaks checking,
uname -mrs
Darwin 8.11.0 Power Macintosh
../gcc-4-5-regtest/configure --prefix=/Volumes/ScratchCS/gcc-4-5-
install --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --
build=powerpc-apple-darwin8 --enable-languages=c,objc,c++,obj-c+
+,fortran --enable-version-specific-runtime-libs
Hi Ralf,
On 24 Aug 2009, at 18:47, Ralf Wildenhues wrote:
Hello Iain,
* IainS wrote on Mon, Aug 24, 2009 at 07:16:05PM CEST:
uname -mrs
Darwin 8.11.0 Power Macintosh
configure: WARNING: decimal float is not supported for this target
configure: WARNING: fixed-point is not supported
Thanks Ralf,
On 24 Aug 2009, at 19:52, Ralf Wildenhues wrote:
* IainS wrote on Mon, Aug 24, 2009 at 08:17:37PM CEST:
the configure that's failing is GMP rather than gcc... maybe I've
missed a requirement to update?
configure:11139: /lib/cpp -DNO_ASM conftest.cc
/Volumes/ScratchCS/gcc-4-5
uname -prs
Darwin 8.11.0 powerpc
Updating SVN tree
At revision 151374.
config:
../gcc-4-5-regtest/configure --prefix=/Volumes/ScratchCS/gcc-4-5-
install --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --
build=powerpc-apple-darwin8 --enable-languages=c,objc,c++,obj-c+
+,fortran
$ uname -v
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386
$ more stage_current
stage3
superficial error is:
$ make -j8 bootstrap build-log.txt 2err-log.txt
$ tail err-log.txt
configure: error: cannot compute sizeof (long long)See `config.log'
Hi,
In the case that a compiler flag in common.opt would best be served
with different default values on different targets.
I.E. a target-dependent Init()
Where can this be effected in the machinery ?
I can see how to make an override - but not a default.
cheers,
Iain
Hi Dominique,
I would expect you to need -gstrict-dwarf in CFLAGS_FOR_TARGET also
but the point of my question is to find a way of having this on by
default on Darwin (which is what we currently seem to need).
(more research is need on the latter - to determine whether the
problem lies
Hello,
I have this scenario:
using dwarfdump --debug-frame in a very simple object generated
with current trunk.
I am trying to figure out (with the dwarf3 spec) wether the problem
is in the tool (dwarfdump), or what we're emitting.
Can anyone more knowledgeable comment?
Iain.
I'm trying to formulate a bug report for tools used to examine/
process debug output.
looking specifically at the _debug_frame.
for this source:
---
int testfunc(void)
{
int i;
i = 1;
return i;
}
===
using -save-temps -dA -g -O0 -fverbose-asm (-gstrict-dwarf, on 4.5)
On 24 Sep 2009, at 10:27, Dominique Dhumieres wrote:
With revision 152076 on i686-apple-darwin9 bootstrapped as described
in comment#61 of pr41405, I get:
[ibook-dhum] bug/debug% gcc45 -c -save-temps -dA -g -O0 -fverbose-
asm -gno-strict-dwarf simplistic.c
[ibook-dhum] bug/debug% dwarfdump
On 24 Sep 2009, at 15:54, Jack Howarth wrote:
On Thu, Sep 24, 2009 at 03:01:12PM +0100, IainS wrote:
So, this particular bug appears to be cleared at
Iain,
What do you mean by the 'bug appears to be cleared'? Can you
map which versions of Xcode on Intel darwin exhibit this bug
and which
when libgcc multilibs are built the Makefile forces two vars to be
empty during the build phase viz:
slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)
unfortunately, libsubdir is used in configure.ac like this.
AC_ARG_WITH(slibdir,
[ --with-slibdir=DIR shared libraries in DIR
Hi.
On Darwin we've got some difficulties with the guality testsuite
components.
first there are a couple of changes needed to get the basic
check_gualityXXX.exe to run
(a) we have to detect Darwin in the same category as unix for the
redirect.
(b) we need -save-temps to find the debug
When doing native bootstraps things are nice and easy ... the target
spec definitions are also appropriate for the host.
===
I've been doing some canadian X-s (specifically darwin 9 = darwin 7).
So, ... when doing B == H != T the specs might need to be different
from B != H == T (or
On 28 Sep 2010, at 17:29, Ian Lance Taylor wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
Does the new split stack feature in gcc trunk absolutely require
additional
libc support to function or can it be made to work on other targets
like
darwin with just changes to libgcc? Thanks
On 29 Oct 2010, at 09:56, Dave Korn wrote:
This implements an object file reader/writer which does everything
required by LTO and gccgo. The ELF code works. I have not tested
the
Mach-O and COFF code at all beyond compiling it; I hope that somebody
else can test those targets and fix them.
Hi,
On Darwin, we have a number of gcc.c-torture fails reported for both
ppc and i386 which are bogus (nothing to do with gcc - but simply
warning output from a system tool).
For dg-based tests these are pruned - I wonder if it would be worth
adding a prune capability to the torture
Hi Rainer,
On 23 Mar 2011, at 18:45, Rainer Orth wrote:
On Darwin, we have a number of gcc.c-torture fails reported for
both ppc
and i386 which are bogus (nothing to do with gcc - but simply
warning
output from a system tool).
For dg-based tests these are pruned - I wonder if it would
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 dir Add dir to the end of the main framework include path
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. :-)
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
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
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,
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #4 from Iain Sandoe iains at gcc dot gnu.org 2012-11-13 13:54:52
UTC ---
(In reply to comment #3)
You can find these files in..
http://llvm.org/svn/llvm-project/compiler-rt/branches/release_32/lib/interception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55289
--- Comment #45 from Iain Sandoe iains at gcc dot gnu.org 2012-11-15 17:58:21
UTC ---
(In reply to comment #35)
Is that certain to be soon enough
Not 100%. I am just warning you.
apologies for not much input to this - somewhat tied
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083
--- Comment #13 from Iain Sandoe iains at gcc dot gnu.org 2012-11-19 21:33:51
UTC ---
(In reply to comment #12)
This is will never be fixable for darwin9 short of using a newer linker as the
weak linking works perfectly on Darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083
--- Comment #15 from Iain Sandoe iains at gcc dot gnu.org 2012-11-19 21:53:54
UTC ---
(In reply to comment #14)
Would this be needed for darwin8 as well?
I don't recall the status of D8,
.. I suspect that, in this case, it is as per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54800
--- Comment #3 from Iain Sandoe iains at gcc dot gnu.org 2013-01-04 18:36:01
UTC ---
(In reply to comment #2)
I think the correct patch is the following, but I have no way to test it.
this looks fine for all darwin,
I've tested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #21 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 08:44:45
UTC ---
(In reply to comment #20)
crttme.o comes from libgcc/config/darwin-crt-tm.c, which has:
/* Provide dummy functions to satisfy linkage for versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #24 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 13:33:15
UTC ---
(In reply to comment #23)
(In reply to comment #21)
... I don't have darwin11 or 12 (yet) - but should do soon.
The test also fails on darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #32 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 19:59:40
UTC ---
(In reply to comment #31)
solution on darwin is to mark the duplicate symbols in crttme.o as weak.
seems reasonable - can you try that?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #33 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 20:14:26
UTC ---
(In reply to comment #32)
(In reply to comment #31)
solution on darwin is to mark the duplicate symbols in crttme.o as weak.
seems reasonable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #34 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 20:35:47
UTC ---
(In reply to comment #24)
However, in this case, the references *are* present on the link line (lstdc++)
but also a duplicate in crttme.o
since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #37 from Iain Sandoe iains at gcc dot gnu.org 2013-01-23 22:16:10
UTC ---
Created attachment 29262
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29262
test, supply the dummy functions from a static archive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #39 from Iain Sandoe iains at gcc dot gnu.org 2013-01-24 11:34:20
UTC ---
(In reply to comment #38)
Tested proposed patch from Comment 37 on x86_64-apple-darwin11 and
x86_64-apple-darwin12 with Xcode 4.5.2 on both systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Attachment #26366|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34311
--- Comment #4 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Anthony Green from comment #3)
(In reply to Iain Sandoe from comment #2)
However, there is no guarantee in the Darwin m32 ABI that the stacked
version of the structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160
--- Comment #7 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #6)
If your change passes on, say...Linux, OK as obvious.
That's the critical point: I cannot test the patch on, say...Linux.
I'll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59160
--- Comment #9 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
I'll check it out on Linux.
Thanks. BTW the test fails also on powerpc-apple-darwin9 (it was indeed
expected).
no difference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59496
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
1 - 100 of 3074 matches
Mail list logo
