The audit trail in the PR contains the detective work (mostly by Eric)
that concludes we have a long-standing bug in the Darwin x86-64
sigtramp unwind data.
This has been filed as radar #10302855, but we need a work-around
until that is resolved (possibly forever on older systems).
OK for t
On 30 Sep 2011, at 00:33, Iain Sandoe wrote:
I'll re-jig with the typographical changes (sorry that were so
many ... )
I've addressed your points in :
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01974.html
specifically (other than typographical issues_
o we retain the ability
On 18 Oct 2011, at 13:22, Arnaud Charlet wrote:
The audit trail in the PR contains the detective work (mostly by
Eric) that
concludes we have a long-standing bug in the Darwin x86-64 sigtramp
unwind
data.
This has been filed as radar #10302855, but we need a work-around
until
that is res
On 21 Oct 2011, at 10:31, Jan Hubicka wrote:
Date: Fri, 21 Oct 2011 00:19:32 +0200
From: Jan Hubicka
Yes, if we scan assembler, we likely want -fno-fat-lto-objects.
then IIUC you need to patch *all* torture tests that use
scan-assembler and scan-assembler-not. Alternatively, patch
somewher
On 14 Oct 2011, at 10:36, Iain Sandoe wrote:
As per the PR audit trail, there is no reason to retain this special-
casing for Darwin.
(given that current GCC is not build-able using Darwin toolsets of
the vintage that required the case).
Mike has OK'd this off-list - but, since
On 14 Oct 2011, at 10:37, Iain Sandoe wrote:
As per the PR audit trail, there is no reason to retain this in the
building of GCC.
As for its use as a general option in tool-builds;
With current darwin toolsets it has the potential to cause issues
when using convenience libs containing
Hi Jonathan,
On 22 Oct 2011, at 22:54, Jonathan Wakely wrote:
I've committed this, if I've broken anything for non-POSIX platforms
there will be time to fix it before 4.7
At present, (180333-180339) these tests seem to be failing on *-
darwin{9,10} (which are posix) - with the failure owing
The following patch still needs a libiberty maintainer's review.
(it has been reviewed viz-a-viz Darwin).
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01622.html
Hi Richard,
On 25 Oct 2011, at 01:17, Richard Henderson wrote:
The Idea with this patch set is to re-arrange vector permutation
so that it can be used to implement other patterns automatically.
In particular, Altivec, SPU currently have (and Sparc VIS would need)
a large amount of boilerplate
On 26 Oct 2011, at 17:01, Richard Henderson wrote:
On 10/26/2011 07:30 AM, Ulrich Weigand wrote:
This fails since for u == 4 and mode == V4SFmode it attempts to
expand
a V4SFmode shift, which is unsupported.
Shouldn't this be using the mode of the selector rather than the mode
of the result
On 27 Oct 2011, at 11:33, Eric Botcazou wrote:
The crash is in find_valid_class() called from push_reload(), via
this
code block around line 1184 of reload.c:
enum reg_class in_out_class
= find_valid_class (outmode, GET_MODE (SUBREG_REG (out)),
subreg
On 14 Oct 2011, at 10:29, Mike Stump wrote:
On Oct 14, 2011, at 2:05 AM, Iain Sandoe wrote:
This implements their use and also the GPRs - the latter makes an
appreciable reduction in code size,
OK for trunk?
Ok. Watch for problems with async stack walking (hitting sample in
Activity
/ChangeLog
===
--- gcc/ada/ChangeLog (revision 180612)
+++ gcc/ada/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2011-10-28 Iain Sandoe
+ Eric Botcazou
+
+ PR target/50678
+ * init.c (Darwin/__gnat_error_handler): Apply a work-around to the
+ bug [filed as radar #103028
Since this is approved by Mike, if there is no further comment by
Monday, I plan to apply it.
On 22 Oct 2011, at 08:36, Iain Sandoe wrote:
On 14 Oct 2011, at 10:36, Iain Sandoe wrote:
As per the PR audit trail, there is no reason to retain this
special-casing for Darwin.
(given that
This is unreviewed for 2 weeks.
I am sure that this issue will be affecting Ada on Darwin10/11 with
the latest toolchains.
It might be subtle without LTO - OTOH when LTO is engaged it breaks
things completely.
On 22 Oct 2011, at 08:37, Iain Sandoe wrote:
On 14 Oct 2011, at 10:37
The sizes of items represented in s-oscons.ads can (and do) change
with the multi-lib on targets that support libada as a multi-lib.
At present, s-oscons.ads is only built once (in gcc/ada) and sym-
linked to rts*/
This is causing a bunch of failures on i686-darwin9 where the m64
multi-li
As approved on the PR thread,
Iain
Index: gcc/objc/ChangeLog
===
--- gcc/objc/ChangeLog (revision 180650)
+++ gcc/objc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2011-10-29 Iain Sandoe
+
+ PR target/47997
+ * objc
On 2 Nov 2011, at 17:18, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner
wrote:
+/* Fills in the label name that should be used for a 476 link
stack thunk. */
+
+void
+get_ppc476_thunk_name (char name[32])
+{
+ gcc_assert (TARGET_LINK_STACK);
+
+ if (HAVE_GAS_HIDDE
On 2 Nov 2011, at 18:34, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
also in macho_branch_islands () :
if (TARGET_LINK_STACK)
{
char name[32];
get_ppc64_thunk_name (name);
strcat (tmp_buf, &quo
On 2 Nov 2011, at 19:05, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
I'll investigate a bit further later...
So you didn't start your build from scratch? I'll keep my
fingers crossed that a fresh build fixing things for you.
Otherwise, let m
On 2 Nov 2011, at 19:39, Peter Bergner wrote:
On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
I'm going to try this
char name[32];
- get_ppc64_thunk_name (name);
+ get_ppc476_thunk_name (name);
This (together with the change
On 3 Nov 2011, at 19:42, Tom G. Christensen wrote:
Latest results for 4.6.x
-tgc
Testresults for 4.6.2:
arm-unknown-rtemseabi4.11 (2)
hppa2.0w-hp-hpux11.11
hppa64-hp-hpux11.11
i386-pc-solaris2.8
i686-apple-darwin9
i686-pc-linux-gnu (2)
powerpc-apple-darwin8.11.0
powerpc-apple-darwin9
On 4 Nov 2011, at 14:09, Arnaud Charlet wrote:
This patch inhibits the generation of exception push/pop nodes if
restriction No_Exception_Handlers is active (when they are always
useless), or in CodePeer mode (where they are never needed and can
intefere with the analysis).
this latest series
Hello Alan,
On 4 Nov 2011, at 13:07, Alan Modra wrote:
Lots of bugs here. Most of them in TARGET_SPE_ABI code, but some also
for other ABIs.
1) Marking an instruction setting up r11 for use by _save64gpr_* as
frame-related results in r11 being set as the cfa for the rest of the
function. Tha
On 28 Oct 2011, at 13:57, Richard Guenther wrote:
We fail to keep the cannot-inline flag up-to-date when turning
indirect to direct calls. The following patch arranges to do
this during statement folding (which should always be called
when that happens). It also makes sure to copy the update
On 5 Nov 2011, at 03:24, Jason Merrill wrote:
After my previous patch for 48370 which adds extend_ref_init_temps,
it is straightforward to fix this issue as well by extending ref
init mem-initializers to match the lifetime of 'this'.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 30
On 5 Nov 2011, at 21:30, Jason Merrill wrote:
On 11/05/2011 10:32 AM, Iain Sandoe wrote:
either this or the previous patch has broken (or exposed a problem
which
has broken) bootstrap on i686-darwin9 with:
I've mostly reverted the previous patch, does that fix bootstrap for
yo
On 5 Nov 2011, at 21:32, Iain Sandoe wrote:
On 5 Nov 2011, at 21:30, Jason Merrill wrote:
On 11/05/2011 10:32 AM, Iain Sandoe wrote:
either this or the previous patch has broken (or exposed a problem
which
has broken) bootstrap on i686-darwin9 with:
I've mostly reverted the pre
On 7 Nov 2011, at 09:53, Olivier Hainque wrote:
On Nov 4, 2011, at 2:07 PM, Alan Modra wrote:
Lots of bugs here. Most of them in TARGET_SPE_ABI code, but some
also
for other ABIs.
...
Another bug we're running into here is an unwarranted move of the sp
restore prior to register fetches
On 28 Oct 2011, at 19:01, Iain Sandoe wrote:
The sizes of items represented in s-oscons.ads can (and do) change
with the multi-lib on targets that support libada as a multi-lib.
At present, s-oscons.ads is only built once (in gcc/ada) and sym-
linked to rts*/
This is causing a bunch of
On 7 Nov 2011, at 12:17, Richard Guenther wrote:
This tries to find a way to prepend explicitly set command-line
options
by those implicitly set by the frontend (-fexceptions in this case).
Unfortunately we don't seem to have a good way to extract this
information
easily, so for -fexcept
On 7 Nov 2011, at 12:40, Richard Guenther wrote:
On Mon, 7 Nov 2011, Iain Sandoe wrote:
It would also be nice to preserve the Objective-C flavor (GNU/
NeXT), since we
have to make a guess for this in darwin.c when in lto.
How is the default selected (that's not obvious
On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
This provides a working thread::hardware_concurrency on platforms that
support pthread_num_processors_np or the "hw.ncpu" sysctl, but by
testing for the features in configure rather than hardcoding OS macro
tests in thread.cc
if the system suppo
On 7 Nov 2011, at 14:16, Jonathan Wakely wrote:
On 7 November 2011 14:10, Iain Sandoe wrote:
On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
This provides a working thread::hardware_concurrency on platforms
that
support pthread_num_processors_np or the "hw.ncpu" sysctl, but
On 7 Nov 2011, at 14:23, Iain Sandoe wrote:
On 7 Nov 2011, at 14:16, Jonathan Wakely wrote:
On 7 November 2011 14:10, Iain Sandoe wrote:
On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
This provides a working thread::hardware_concurrency on platforms
that
support
On 7 Nov 2011, at 14:38, Jonathan Wakely wrote:
On 7 November 2011 14:23, Iain Sandoe wrote:
On 7 Nov 2011, at 14:16, Jonathan Wakely wrote:
On 7 November 2011 14:10, Iain Sandoe wrote:
On 7 Nov 2011, at 13:45, Jonathan Wakely wrote:
This provides a working thread::hardware_concurrency
On 7 Nov 2011, at 14:52, Jonathan Wakely wrote:
On 7 November 2011 14:40, Iain Sandoe wrote:
so there's a reason to use the systlbyname (and use hw.logicalcpu or
similar, maybe).
[unless that's just a buggy sysconf]
Well if that's how they want to play it then I'm not
On 8 Nov 2011, at 00:21, Joseph S. Myers wrote:
On Mon, 7 Nov 2011, Iain Sandoe wrote:
How is the default selected (that's not obvious to me).
flag_next_runtime
doesn't use options mechanisms it seems, that's bad. Both
-fgnu-runtime and -fnext-runtime are frontend-o
Hi Chaps
On 8 Nov 2011, at 18:22, Richard Henderson wrote:
On 11/08/2011 09:56 AM, Pedro Alves wrote:
On Tuesday 08 November 2011 17:31:45, Richard Henderson wrote:
On 11/08/2011 09:26 AM, Pedro Alves wrote:
On Tuesday 08 November 2011 16:33:52, Richard Henderson wrote:
toplevel/
On 8 Nov 2011, at 21:29, Richard Henderson wrote:
On 11/08/2011 01:20 PM, Iain Sandoe wrote:
is it expected for libitm to work on x86 darwin?
Yes.
OK, I'll persevere ;-)
Iain
Hi Richard,
On 8 Nov 2011, at 21:29, Richard Henderson wrote:
On 11/08/2011 01:20 PM, Iain Sandoe wrote:
is it expected for libitm to work on x86 darwin?
Yes.
hmmm...
powerpc-darwin is not affected (doesn't auto configure because there's
no powerpc directory under lib
On 9 Nov 2011, at 17:01, Richard Henderson wrote:
On 11/09/2011 08:14 AM, Iain Sandoe wrote:
On i686-darwin9 it fails with "target only supports weak alias"
(I need to understand better where that comes from - but the
machine is tied up right now).
This is fixed. I removed th
As discussed in:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00927.html
This puts "flag_next_runtime" into the global options structure
-- hopefully this will pave the way for extracting the information
from objects when doing LTO and making sure that it is (a) consistent
- and (b) that
On 9 Nov 2011, at 18:39, Richard Henderson wrote:
I'll hang on .. and test stuff ;-)
Try now. I've committed the following.
sjlj.S now builds ...
... similar issues are showing in x86_sse.S (I will try and look at
those, if you have not already started).
Iain
Hi Mike,
just want to state my understanding to allow you to comment if I'm
off
On 10 Nov 2011, at 16:12, Mike Stump wrote:
On Nov 10, 2011, at 1:35 AM, Richard Guenther
wrote:
flag_exceptions also triggers middle-end behavior - without it no
statement can possibly throw
Actually,
On 10 Nov 2011, at 17:12, Richard Henderson wrote:
On 11/10/2011 12:16 AM, Jakub Jelinek wrote:
On Wed, Nov 09, 2011 at 04:32:58PM -0800, Richard Henderson wrote:
Not pretty at all. But given the corresponding irritation in
writing assembler
wrapper functions, it seems like it's about a wa
On 10 Nov 2011, at 20:33, Patrick Marlier wrote:
On 11/10/2011 03:25 PM, Iain Sandoe wrote:
libtool: link: /GCC/gcc-4-7-trunk-build/./gcc/xgcc
-B/GCC/gcc-4-7-trunk-build/./gcc/
-B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/
-B/GCC/gcc-4-7-install/i686-apple-darwin9/lib/ -isystem
/GCC/gcc-4-7
On 10 Nov 2011, at 20:43, Iain Sandoe wrote:
The symbol _ITM_malloc is in libitm. Maybe the problem is an extra
_ before the _ITM_malloc?
Actually, I think the missing symbol is
___emutls_v._ZN3GTM12_gtm_thr_tlsE
and (although the m32 lib builds OK - the symbol is also missing
there
On 11 Nov 2011, at 00:30, Mike Stump wrote:
On Nov 10, 2011, at 9:40 AM, Iain Sandoe wrote:
Thanks for catching that --- brainstorm on my part ... the code
under discussion should have been #ifndef OBCPLUS
There is no prohibition against C having exceptions, so, doesn't
matter i
This corrects a mistake I made when splitting the runtime code up -
which causes the GNU eh personality routine to be specified for NeXT
ABI 0&1.
This causes a linkage error if "-fexceptions" is specified for NeXT @
m32
(although there's no functional effect, since there is no ZCE
impleme
An update .. in case anyone is following...
On 11 Nov 2011, at 00:21, Richard Henderson wrote:
On 11/10/2011 03:29 PM, Iain Sandoe wrote:
The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup
FAOD, Is there some reason that this library needs to resolve symbols
from some
On 11 Nov 2011, at 14:33, Rainer Orth wrote:
Iain Sandoe writes:
however, most of the suite fails on darwin9 - with an undefined
reference
to delete(void*).
Could this be the same issue I've been seeing on Tru64 UNIX, i.e. lack
of weakdef support?
http://gcc.gnu.org/m
This probably qualifies as obvious - but having discussed some of the
background with Mike ..
.. there are other ways of solving the problem - although probably
rather heavy-weight for this problem.
.. So, I'll let him have the say...
OK for trunk?
Iain
testsuite:
PR testsuite/5105
On 14 Aug 2012, at 19:59, Diego Novillo wrote:
>
> After the merge is in, I will send an announcement and request major branch
> merges to wait for another 24 hrs to allow testers the chance to pick up this
> merge.
The following patch (mimicking what has been done elsewhere at r190402)
resto
Hello Michael,
On 12 Sep 2012, at 23:43, Michael Meissner wrote:
> It would be nice to know if this doesn't break the other ppc
> environments (AIX, Darwin) before I commit it. Are there any problems with
> this patch?
For powerpc-darwin9, there are a couple of issues which I've hacked aroun
Hi,
When building for, say, mips-linux-gnu, the build of objects from fixed-bit.c
produces a lot of "set but not used" warnings for min_high & min_low.
looking at the code, these appear to be genuine.
Fixed as below.
OK for trunk?
Iain
libgcc:
* fixed-bit.c (SATFRACT): Adjust declarati
On 19 Jun 2012, at 13:53, Dominique Dhumieres wrote:
> On Tue, 19 Jun 2012, Richard Guenther wrote:
>>
>>> Richard Guenther writes:
We are too eager to bump alignment of some decls when vectorizing.
The fix is to not bump alignment of decls the user explicitely
aligned or that ar
On 19 Jun 2012, at 22:41, Mike Stump wrote:
> On Jun 19, 2012, at 12:22 PM, Iain Sandoe wrote:
>> On 19 Jun 2012, at 13:53, Dominique Dhumieres wrote:
>>
>>> On Tue, 19 Jun 2012, Richard Guenther wrote:
>>>>
>>>>> Richard Guenther writes
Hi,
On 20 Jun 2012, at 09:23, Richard Guenther wrote:
> On Tue, 19 Jun 2012, Iain Sandoe wrote:
>
>>
>> On 19 Jun 2012, at 22:41, Mike Stump wrote:
>>
>>> On Jun 19, 2012, at 12:22 PM, Iain Sandoe wrote:
>>>> On 19 Jun 2012, at 13:53, Dominiqu
ping.
On 15 Jun 2012, at 14:31, Iain Sandoe wrote:
> Hi,
>
> When building for, say, mips-linux-gnu, the build of objects from fixed-bit.c
> produces a lot of "set but not used" warnings for min_high & min_low.
>
> looking at the code, these appear to be genuin
Hello,
While working on mips recently, I noticed that all the execute tests fail for
simulator.
This appears to be caused by an oversight in the move from gcc/config =>
libgcc, where t-elf defined extra parts including crt{begin,end}.o but these
have been omitted from the re-built libgcc/confi
i...@il.ibm.com
Maciej W. Rozycki ma...@linux-mips.org
Silvius Rusr...@google.com
Matthew Sachs msa...@apple.com
-Iain Sandoeia...@gcc.gnu.org
+Iain
Hello H.J.
i686-Darwin, m32, ObjC is still broken from the patch to "Add
OPTION_MASK_ISA_X86_64 and support TARGET_BI_ARCH == 2"
As I pointed out in [1], in the case of the NeXT runtime, the ABI and
exceptions model depend on the multi-lib.
Currently, the exceptions model is set from C_COMMON_
As described in the PR thread, Darwin was already using the TARGET_FOLD_BUILTIN
hook to process CFstrings.
The patch fixes the breakage by calling a SUBTARGET_FOLD_BUILTIN where defined
(following similar patterns for other items that require sub-target handling).
OK for trunk?
Iain
gcc:
Hi Steven,
On 7 Jul 2012, at 16:34, Steven Bosscher wrote:
> On Sat, Jul 7, 2012 at 5:06 PM, H.J. Lu wrote:
>> Are you sure this the right patch? -fno-tree-dominator-opts is still here.
>
> I am sure it is not the right patch :-)
> Thanks!
>
> Index: libgcc/config/t-darwin
> ==
On 9 Jul 2012, at 09:11, Iain Sandoe wrote:
>> crt3.o: $(srcdir)/config/darwin-crt3.c
> regstrapped (all+ada+objc++) on i686-darwin9 with no regressions.
.. but, now I re-check, crt3 is only used on Darwin 8 and earlier;
That will take somewhat longer to check, machine availability is
Hi Steven,
On 9 Jul 2012, at 09:21, Iain Sandoe wrote:
> On 9 Jul 2012, at 09:11, Iain Sandoe wrote:
>>> crt3.o: $(srcdir)/config/darwin-crt3.c
>
>> regstrapped (all+ada+objc++) on i686-darwin9 with no regressions.
>
> .. but, now I re-check, crt3 is only used on Da
On 11 Jul 2012, at 00:01, Iain Sandoe wrote:
> Anyway, although i686-Darwin 8 is sadly in need of some TLC, the proposed
> patch causes no regressions.
> ppc-darwin 8 tests are still running, but it bootstrapped (500M G4, > 24hrs
> for c/c++ build & test).
FAOD, from a testi
On 14 Jul 2012, at 00:21, Mike Stump wrote:
> On Jul 13, 2012, at 12:28 AM, Iain Sandoe wrote:
>> On 11 Jul 2012, at 00:01, Iain Sandoe wrote:
>>> Anyway, although i686-Darwin 8 is sadly in need of some TLC, the proposed
>>> patch causes no regressions.
>>>
Hello Arnaud,
On 12 Jul 2012, at 11:43, Arnaud Charlet wrote:
> The optimization of the expansion of protected procedure for the lock-free
> implementation brings the following changes:
> - Several renamings in order to match GCC built-in function wordings.
> - Expected_Comp declaration moved to
Hi,
The PPC port can handle -mcpu=native.
The patch below enables its use at config time,
OK for trunk?
thanks,
Iain
gcc:
* config.gcc (powerpc*-*-* | rs6000-*-*): Allow 'native' as a
valid configured CPU choice.
Index: gcc/config.gcc
Hi,
The following patch was been in use internally, for some time, to handle two
further cases where the processor does not have lwsync. Verified on a cross
from i686-linux-gnu to powerpc-linux-gnu.
OK for trunk?
thanks,
Iain
gcc/
* config/rs6000/rs6000.h (TARGET_NO_LWSYNC): E
Hi,
At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do)
generate 64 bit register usage for m32 code. This appears to be a
long-standing bug.
OK for trunk & all open branches?
Iain
gcc/
* config/rs6000/darwin.h (OS_MISSING_POWERPC64): New.
Index: gcc/c
Hi Andrew,
On 21 Jul 2012, at 17:43, Andrew Pinski wrote:
> On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe wrote:
>> Hi,
>>
>> The following patch was been in use internally, for some time, to handle two
>> further cases where the processor does not have lwsync. V
Hi Mike,
On 21 Jul 2012, at 18:27, Mike Stump wrote:
> On Jul 21, 2012, at 9:12 AM, Iain Sandoe wrote:
>> At present, if a G5 or 970 processor is selected (-mcpu=), we can (and do)
>> generate 64 bit register usage for m32 code. This appears to be a
>> long-standing
On 21 Jul 2012, at 19:02, Andrew Pinski wrote:
>> If there's a different mechanism for enforcing what's implied above, then we
>> could use
>
> Yes HARD_REGNO_CALL_PART_CLOBBERED should work. If that is not
> working there is a bug somewhere else in the compiler.
thanks, that looks solid enoug
Hi Arnaud,
On 23 Jul 2012, at 09:02, Arnaud Charlet wrote:
> This patch implements a check in the runtime library that determines whether
> the current target supports the atomic primitives up to 64 bits.
If I understand the name of the flag, it looks like an "all or nothing" for
atomic primiti
On 23 Jul 2012, at 15:27, Arnaud Charlet wrote:
>> With the following, bootstrap completed on powerpc-apple-darwin9, and
>> make check-ada shows no new fails.
>> Should I apply it?
>
> Looks good to me, go ahead, although I'm a bit surprised that you got an
> error,
> can you clarify what error
On 23 Jul 2012, at 15:57, Arnaud Charlet wrote:
>> The swicth is defaulted to be False in Targparm.
>> However, as far as I understood in Targparm, the switch must be present in
>> all system.ads packages but I may be wrong.
>
> That sounds wrong and isn't how other flags work.
>
> Vincent, can
On 21 Jul 2012, at 18:04, Iain Sandoe wrote:
> On 21 Jul 2012, at 17:43, Andrew Pinski wrote:
>> On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe wrote:
>>> The following patch was been in use internally, for some time, to handle
>>> two further cases where the pro
On 17 May 2012, at 21:16, Mike Stump wrote:
On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:
On 05/17/2012 09:47 PM, Jason Merrill wrote:
On 05/17/2012 05:06 AM, Paolo Carlini wrote:
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am still puzzled by why we need to assert, as opposed to
On 26 Aug 2011, at 11:27, Ralf Wildenhues wrote:
* Jack Howarth wrote on Fri, Aug 12, 2011 at 01:27:21AM CEST:
The following patch addresses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42554#c15
by extending the logic used in...
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=15756
On 31 Aug 2011, at 16:53, Joseph S. Myers wrote:
On Wed, 31 Aug 2011, Arnaud Charlet wrote:
+===GNAT BUG
DETECTED==+
| 4.7.0 20110831 (experimental) [trunk revision 161655]
(x86_64-unknown-linux-gnu) |
| Storage_Error stack overflow or erron
On 31 Aug 2011, at 16:57, Arnaud Charlet wrote:
(x86_64-unknown-linux-gnu) |
| Storage_Error stack overflow or erroneous memory
access |
| Error detected at system.ads:
175:5 |
+
=
=
=
=
=
=
===
On 31 Aug 2011, at 17:34, Arnaud Charlet wrote:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x001c4fa0 in lib__writ__write_ali ()
(gdb) bt
#0 0x001c4fa0 in lib__writ__write_ali ()
#1 0x0036799a in _ada_gnat1drv ()
#2
On 31 Aug 2011, at 20:07, Iain Sandoe wrote:
Same for revision 178311
will set this going .. prob. tomorrow before a report.
fails with:
"exp_light.ali" not found "exp_light.adb" must be compiled
(that issue was already reported by Richi).
so .. not much p
On 31 Aug 2011, at 20:07, Iain Sandoe wrote:
On 31 Aug 2011, at 17:34, Arnaud Charlet wrote:
In particular I'd be curious to know if revision 178376 has the
failure or not.
different failure;
built with BOOT_CFLAGS="-O0 -g" ..
.. it fails debug-compare (ada/exp_ch6.o).
the following was approved on the PR thread.
cheers,
Iain
gcc:
PR debug/49901
* config/darwin.h (DEBUG_MACRO_SECTION): New macro.
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 178509)
+++ gcc/conf
There are a couple of typos in ada/gcc-infterface/Makefile.in that
result in many fails of x86_64-darwin10 bootstrap for the m32 lib
variant (thus breaking bootstrap with default switches)..
the attached removes a duplicated section of text and corrects the
target variants.
OK for trunk?
ld needs to be passed the correct arch flag when building shared libs.
This means that the multi-libs built for 4.6.x and trunk contain junk
(essentially all the input objects are rejected as having the wrong
arch).
The attached corrects this.
OK for trunk and 4.6 (since this is a wrong-co
Well, this was two needles in a haystack ...
... AFAICT from googling, powerpc-darwin9 has never bootstrapped ADA
(I see questions but no resolution).
Perhaps Adacore has a version ... but I was unable to find any
starting point - so this was somewhat tough to debug.
Anyway, there are
Darwin8 does not have _SC_NPROCESSORS_ONLN defined.
OK for trunk & 4.6?
Iain
Index: gcc/ada/adaint.c
===
--- gcc/ada/adaint.c(revision 178554)
+++ gcc/ada/adaint.c(working copy)
@@ -2460,7 +2460,10 @@ __gnat_number_of_cpus (
Hi Arno,
On 5 Sep 2011, at 20:04, Arnaud Charlet wrote:
Darwin8 does not have _SC_NPROCESSORS_ONLN defined.
Is Darwin8 still active/supported?
it works - and I test from time to time.
.. feedback from fink in the form of bug reports suggests that it is
still being used in the wild too.
"-lm" is a symlink to libSystem.dylib on all recent Darwin and
therefore not required (as libSystem is automatically provided by gcc).
Using -lm (especially when in conjunction with "-flat_namespace") can
cause unexpected differences in behavior between Darwin 9 -> Darwin10
(where the unw
Hello Eric,
On 6 Sep 2011, at 08:41, Eric Botcazou wrote:
- it doesn't seem reasonable to force -fexceptions - until we can
build ada with ZCE.
Or change the SJLJ scheme.
Hm. I'm probably being a bit dumb here - but not clear about which
scheme/where in the code-base you have in mind.
I applied the following under the 'obvious' rule.
config/darwin10.h no longer modifies LIB_SPEC and thus the one in it
was just a duplicate of the one in darwin.h.
tidied.
cheers,
Iain
gcc:
* config/darwin10.h Remove duplicate LIB_SPEC.
Index: gcc/config/darwin10.h
==
Hi Eric,
On 6 Sep 2011, at 17:17, Mike Stump wrote:
On Sep 6, 2011, at 1:12 AM, Eric Botcazou wrote:
That's a good question, and one that I haven't got to the bottom
of -
but the exclusion was there in the original code-base [still in the
vendor's tree too].
(also, the rs6000 pro/epilogue co
The "-flat_namespace" linker flag defeats one of Darwin's nicer
features (two-level library namespaces).
AFAIU, it was habitually applied to unix projects in the early
versions of darwin to cater for assumptions about library ordering
made in such projects.
However, it is rarely needed th
This doesn't actually make any functional change to x86 darwin, but it
does group all the darwin versions together.
Current PPC darwin (like x86) should use the GCC unwinder.
(no Ada regression on *-darwin9, x86-64-darwin10)
OK for trunk/ 4.6 when the PPC changes are in?
cheers
Iain
ada:
I found myself building a lot of X's and native X's recently - linux -
> darwin; i686-darwin -> ppc-darwin ; i686-darwin9 -> x86_64-darwin10.
Amongst other issues (primarily wrong auto-host.h decisions) there is
an issue that the target headers (and some GCC code) make use of
__ENVIRONMENT_M
1301 - 1400 of 1929 matches
Mail list logo
