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 be
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 suites
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.
On 28 Sep 2010, at 17:29, Ian Lance Taylor wrote:
Jack Howarth 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 in advance for any
clari
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 B
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 simulato
On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote:
On 9 July 2010 16:55, Doug Semler wrote:
On Fri, Jul 9, 2010 at 9:12 AM, IainS > wrote:
Hi,
I want to do this:
RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/
somewhere "
I've tried escaping the path
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 w
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,
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 c
On 21 May 2010, at 10:12, Richard Guenther wrote:
On Thu, May 20, 2010 at 10:20 PM, Steven Bosscher > wrote:
On Thu, May 20, 2010 at 9:54 PM, IainS > wrote:
No Asbestos required - but .. I do have some observations..
I write pretty much all my serious (day-job) code in ObjC and..
...
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++ ...
b
Hi Ian,
On 12 May 2010, at 21:00, Ian Lance Taylor wrote:
IainS 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 -fPIC is
there, b
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
# co
On 19 Apr 2010, at 14:18, Manuel López-Ibáñez wrote:
On 19 April 2010 15:03, IainS
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 what you mean
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 expand_
On 14 Apr 2010, at 21:42, Ian Lance Taylor wrote:
IainS 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 limited communication avai
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 vendo
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
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 p
On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:
IainS 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*:%*}%{!
o:
On 12 Apr 2010, at 23:30, Ian Lance Taylor wrote:
IainS writes:
If I want to install a script (wrapper) that will end up installed in
the same dir as
. If this program will only ever be
run by the gcc driver, then you should install it in either the
directory where cc1 is installed
On 12 Apr 2010, at 23:24, Ian Lance Taylor wrote:
IainS 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
but not otherwise (since it says .
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
LINK_COMMAND_SPEC
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
have cleared the problem.
On 10 Mar 2010, at 09:47, Rainer Orth wrote:
IainS 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 - (but I'm
On 10 Mar 2010, at 09:12, Rainer Orth wrote:
IainS 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 .dejagnurc - just need to che
On 9 Mar 2010, at 19:36, Rainer Orth wrote:
IainS 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 manifest themselv
On 9 Mar 2010, at 19:31, NightStrike wrote:
On Tue, Mar 9, 2010 at 2:27 PM, IainS > 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 an
"in-tr
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 cou
On 9 Mar 2010, at 12:46, Rainer Orth wrote:
IainS writes:
Instead, run make mail-report.log afterwards and check that.
...
suite in parallel, which isn't bad either.
As I wrote before, I'm going to use this on an (effectively) 64-core
machine and hope to achieve to use al
On 9 Mar 2010, at 12:10, Rainer Orth wrote:
IainS 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 to scan for
proble
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 2>&1' &
(sleep 2) 'make -k check-gcc-c++ RUNTESTFLAGS=
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 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 [LIBD
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
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 --
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)
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.
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 in
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
$ 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 2>err-log.txt
$ tail err-log.txt
configure: error: cannot compute sizeof (long long)See `config.log'
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 -
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/Scratch
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 for
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 -
Richard,
On 29 Mar 2009, at 12:08, Richard Guenther wrote:
On Sun, Mar 29, 2009 at 1:00 PM, FX 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, and it uses libiberty
On 15 Jan 2009, at 20:57, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:51 PM, IainS
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 dif
On 15 Jan 2009, at 20:40, Andrew Pinski wrote:
On Thu, Jan 15, 2009 at 12:13 PM, IainS
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
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
int main(void)
{
[Object class];
return 0;
}
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.
You
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 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 understa
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 reaso
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
nced gcc runtime set
onto darwinX
(assuming 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
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 +0000, IainS wrote:
To use the 'unversioned set' implies that you're compiling for a
version of M
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
i
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 instru
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 that are not
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 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 us
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) ...
a
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 config/rs6000/rs6000.
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 mom
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,
Iai
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
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 mis
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 versi
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
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 achiev
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,
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/-Bdynam
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
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
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 en
76 matches
Mail list logo
