Hi Honza,
On 23 Jun 2014, at 18:36, Jan Hubicka wrote:
The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin
with
/opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
definitions not supported in Mach-O; ignored
I think they should be protected
Hello Kai,
On 28 May 2014, at 09:43, Kai Tietz wrote:
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c(revision 210985)
+++ gcc/config/i386/i386.c(working copy)
@@ -38893,7 +38893,16 @@ x86_output_mi_thunk
Hi Ed,
On 2 Nov 2014, at 01:48, Ed Smith-Rowland wrote:
CL_feat_nsdmi.txtpatch_feat_nsdmi.txt
please take a look at PR63834, as
https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00307.html
breaks bootstrap on x86064-darwin12,
the reproducer also segvs on x86-64-linux.
(It looks like the commit was
back-porting?
Iain
libatomic:
* config/darwin/host-config.h New.
* config/darwin/lock.c New.
* configure.tgt (DEFAULT_X86_CPU): New, (target): New entry for darwin.
From fdbf91b9fb20992231a370f0e5cd803085b4f69e Mon Sep 17 00:00:00 2001
From: Iain Sandoe i
Hello Richard, Joseph,
Thanks for your reviews,
On 13 Nov 2014, at 07:40, Richard Henderson wrote:
On 11/12/2014 10:18 PM, Iain Sandoe wrote:
# ifndef USE_ATOMIC
#define USE_ATOMIC 1
# endif
Why would USE_ATOMIC be defined previously?
This was left-over from a mode where I
Hello Richard,
On 14 Nov 2014, at 08:01, Richard Henderson wrote:
On 11/13/2014 09:34 PM, Iain Sandoe wrote:
Um, surely not LOCK_SIZE, but CACHELINE_SIZE. It's the granularity of the
target region that's at issue, not the size of the lock itself.
The algorithm I've used is intentionally
On 14 Nov 2014, at 08:25, Richard Henderson wrote:
On 11/14/2014 09:12 AM, Iain Sandoe wrote:
my locks are only 4 bytes [whereas they are
rounded-up-to-n-cachlines(sizeof(pthreads mutext)) for the posix
implementation].
The items that they are locking are of arbitrary size (at least up
On 24 Nov 2014, at 17:02, FX wrote:
Bootstrap is currently broken on ppc-darwin due to PR63703
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703).
This is also broken on 4.9, and actually made it into the 4.9.2 release.
This patch fixes it, restores bootstrap (well, it gets cc1 to
Hi David,
On 3 Oct 2014, at 20:15, David Malcolm wrote:
On Fri, 2014-10-03 at 11:02 -0400, David Malcolm wrote:
The main function for the driver in gcc.c has grown from ~200 lines
in its original form (way back in r262) to ~1000 lines today, with a
dozen locals (if we include the params).
Hi FX,
On 4 Oct 2014, at 14:51, FX wrote:
We have a -static-libgfortran option, but on targets where we support
quad-prec math through libquadmath, we didn’t have an equivalent
-static-libquadmath so far. This patch adds it, in what I think is a rather
straightforward manner.
The only
Hi FX,
On 9 Oct 2014, at 11:39, FX wrote:
Version 2 of the patch, now handling the darwin case (thanks Iain) and
expressely noting in the documentation the implications on redistribution
(thanks Joseph).
Bootstrapped and regtested on x86_64-apple-darwin14.
OK to commit?
I need a
Hi Bill,
On 21 Mar 2014, at 02:05, Bill Schmidt wrote:
For convenience of those who have kindly agreed to test the patch
series, here is the entire series as a single compressed patch. Note
that this does not include patch 15/26, which we've agreed to submit
separately.
To assess this on
Hi Jeff,
On 7 Nov 2014, at 20:28, Jeff Law wrote:
On 11/06/14 06:01, Evgeny Stupachenko wrote:
Now I see that equiv reload could be special for PIC register. Let's
apply more conservative patch.
Darwin bootstrap passed with the patch applied on r216304 (along with
already committed to
On 8 Nov 2014, at 15:41, Jakub Jelinek wrote:
On Sat, Nov 08, 2014 at 04:31:28PM +0100, Dominique d'Humières wrote:
I am still unable to bootstrap darwin14 without revision r216964 reverted.
Executing the simplified command
/opt/gcc/build_w/gcc/xg++ -B/opt/gcc/build_w/gcc/
Jack, Dominique,
I think we have two issues here - let's make sure we don't derail dealing with
the first one.
On 8 Nov 2014, at 22:08, Jack Howarth wrote:
That is curious. I wouldn't have thought that the compiler
selection would have had such a radical effect on the linkage flags
Hi Jack,
comments below apply also to the patch for PR63699
On 7 Nov 2014, at 17:13, Jack Howarth wrote:
The attached revised patch eliminates the compilation error...
error: use of undeclared
identifier 'do_not_use_toupper_with_safe_ctype'
on x86_64-apple-darwin14 when
Hi Mike,
On 15 Sep 2014, at 08:33, Mike Stump wrote:
On Sep 14, 2014, at 5:43 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
On Sun, Sep 14, 2014 at 02:38:45PM -0700, Mike Stump wrote:
+ SIBLING_CALL_P (tmp) = 1;
+ SIBLING_CALL_P (tmp) = 1;
The second time is to make
Hi Jeff,
On 15 Sep 2014, at 16:42, Jeff Law wrote:
On 09/15/14 05:25, FX wrote:
Perhaps it would be safer simply to revert that hunk of the original patch
unless/until (1) and (2) above are addressed?
Given that the original patch addresses “only” a missed-optimization (and
causes
Hello Kai, all,
I am not concerned solely about Darwin here, certainly we can make a patch to
fix the problem there.
My concern is for the general state of this code:
On 18 Sep 2014, at 22:26, Kai Tietz wrote:
it isn't true that I didn't replied to Iant.
( iains ;) )
I did this on IRC.
Hello Jeff, all,
On 19 Sep 2014, at 05:14, Jeff Law wrote:
On 09/18/14 16:20, Iain Sandoe wrote:
1. There has been a change made to make the upper path like the lower path
(as you said on IRC).
- apparently (from our conversation) you don't expect this to be a general
optimisation
On 6 Feb 2013, at 17:20, Jack Howarth wrote:
On Wed, Feb 06, 2013 at 05:37:12PM +0100, Patrick Marlier wrote:
Hi Jack,
Thanks for having a look at this.
However I don't understand why you need this:
Index: gcc/config/i386/darwin.h
On 11 Feb 2013, at 15:55, Jack Howarth wrote:
Iain Sandoe discovered that on intel darwin9, the asan testsuite suffers
hundreds of
failures due to the absence of dispatch calls (Grand Central Dispatch) prior
to darwin10.
The attached patch disables building libsanitizer on darwin8
On 21 Sep 2011, at 15:58, Dominique Dhumieres wrote:
I am not sure to understand the sentence:
There is apparently an ACATS failure on x86-64/Darwin, but I've
installed the
testcase as gnat.dg/opt19.adb in the tree.
The only failure I had was pr50433, now fixed by revision 179046.
With
Following Eric's fix to the stack-check output for rs6000/Darwin, I
think we can enable this function for the port.
bootstrapped/tested (including Java, Ada), on *-darwin9, x86-64-
darwin10.
OK for trunk?
Iain
gcc:
* config/darwin9.h (STACK_CHECK_STATIC_BUILTIN): Enable for
It appears that the number of sections in a mach-o file is to be
limited to 256.
Whilst we all (probably) agree that the documentation is not clear
about this, there is likely little point in jumping up and down...
It's a show-stopper for LTO with current darwin tool-chains where 'as'
No functional change, just factor out the common LIBGNAT_TARGET_PAIRS
across the port.
OK for trunk?
Iain
ada:
* gcc-interface/Makefile.in (Darwin): Factor LIBGNAT_TARGET_PAIRS
across the port.
Index: gcc/ada/gcc-interface/Makefile.in
Hello Ian,
I'll re-jig with the typographical changes (sorry that were so
many ... )
... and re-post - but I'd like to clear up a couple of points first.
On 30 Sep 2011, at 00:00, Ian Lance Taylor wrote:
-#define GNU_SECTION_NAMES __section_names
Are we sure it is OK to drop support for
On 29 Sep 2011, at 15:37, Arnaud Charlet wrote:
No functional change, just factor out the common LIBGNAT_TARGET_PAIRS
across the port.
OK for trunk?
OK
regrettably, I'd allowed my ppc and x86 trees to get out of sync, and
the applied patch was not correct on powerpc.
corrected by a
On 13 Oct 2011, at 11:22, Arnaud Charlet wrote:
An operator can be declared Import (Intrinsic) only if the current
view of the
operand type (s) is a numeric type. With this patch the compiler
properly
rejects the pragma if the operand type is private or incomplete.
Compiling mysystem.ads
.. this looks like an (almost) obvious fix for the bootstrap breakage...
OK for trunk?
Iain
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 179865)
+++ gcc/config/darwin.c (working copy)
@@ -2957,10 +2957,11 @@
On 13 Oct 2011, at 23:22, Mike Stump wrote:
+/* Add $LDBL128 suffix to long double builtins for ppc darwin. */
static void
-darwin_patch_builtin (int fncode)
+darwin_patch_builtin (enum built_in_function fncode)
This is a property of the target machine. DARWIN_PPC is a property
of the
On 13 Oct 2011, at 23:38, Iain Sandoe wrote:
On 13 Oct 2011, at 23:22, Mike Stump wrote:
+/* Add $LDBL128 suffix to long double builtins for ppc darwin. */
static void
-darwin_patch_builtin (int fncode)
+darwin_patch_builtin (enum built_in_function fncode)
This is a property
and
+ * a copy of the GCC Runtime Library Exception along with this program;
+ * see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+ * http://www.gnu.org/licenses/.
+ */
+
+/* Contributed by Iain Sandoe ia...@gcc.gnu.org */
+
+/* Like their FP and VEC counterparts, these routines
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 Ralf commented on the
previous version, I'd like to give
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 common.
OK for trunk?
Iain
gcc/ada:
PR
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
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 to read
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
On 21 Oct 2011, at 10:31, Jan Hubicka wrote:
Date: Fri, 21 Oct 2011 00:19:32 +0200
From: Jan Hubicka hubi...@ucw.cz
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,
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 Ralf
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
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
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)),
Hi H.J.
On 31 Mar 2012, at 20:24, Jack Howarth wrote:
The latest gcc-pr52784-2.patch patch also allows current gcc trunk
to
bootstrap on i386-apple-darwin10.
Despite the fact that bootstrap is restored, there remain problems
with this patch and some more work is needed.
(a)
On 8 Apr 2012, at 15:54, H.J. Lu wrote:
Despite the fact that bootstrap is restored, there remain problems
with this
patch and some more work is needed.
(a) [trivial] the option 'mx32' is in i386.opt, which means it is
exposed to
all sub-targets, even if they don't support it.
$
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
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):
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:
Hi Andrew,
On 21 Jul 2012, at 17:43, Andrew Pinski wrote:
On Sat, Jul 21, 2012 at 9:12 AM, Iain Sandoe i...@codesourcery.com 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. Verified on a cross
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 bug.
Hum, do you have
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 enough,
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 you got?
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 you
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 i...@codesourcery.com wrote:
The following patch was been in use internally, for some time, to handle
two further cases where the processor does not have
On 7 Jul 2011, at 00:15, Bernd Schmidt wrote:
On 07/03/11 22:01, Richard Henderson wrote:
Bernd's original patch to optimize dwarf2 cfi for shrink-wrapping
is difficult to analyze because that optimization was done via a
random debugging hook during final, and the cfi notes are deleted
at the
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
On 19 Jun 2012, at 13:53, Dominique Dhumieres wrote:
On Tue, 19 Jun 2012, Richard Guenther wrote:
Richard Guenther rguent...@suse.de 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
On 19 Jun 2012, at 22:41, Mike Stump wrote:
On Jun 19, 2012, at 12:22 PM, Iain Sandoe i...@codesourcery.com wrote:
On 19 Jun 2012, at 13:53, Dominique Dhumieres wrote:
On Tue, 19 Jun 2012, Richard Guenther wrote:
Richard Guenther rguent...@suse.de writes:
We are too eager to bump
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 i...@codesourcery.com wrote:
On 19 Jun 2012, at 13:53, Dominique Dhumieres wrote:
On Tue, 19 Jun 2012
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 genuine.
Fixed as below.
OK for trunk
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
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
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 hjl.to...@gmail.com 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 an issue
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 Darwin 8 and earlier;
That will take
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 testing perspective
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.
ppc-darwin 8 tests are still running
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 the
===
--- gcc/ada/ChangeLog (revision 180612)
+++ gcc/ada/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2011-10-28 Iain Sandoe ia...@gcc.gnu.org
+ Eric Botcazou ebotca...@adacore.com
+
+ PR target/50678
+ * init.c (Darwin/__gnat_error_handler): Apply a work-around
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
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
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 ia...@gcc.gnu.org
+
+ PR target/47997
On 2 Nov 2011, at 17:18, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner berg...@vnet.ibm.com
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);
+
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, :\n
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 changes
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
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.
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
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
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
you? I
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 previous
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 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
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 to me
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
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 by
testing
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: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 even going to
think
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-only flags
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 libitm/config
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 the alias
1 - 100 of 1690 matches
Mail list logo
