Hi,
Julian Brown once posted a patch fixing ARM EABI violation, which I think
also essential to 4.6 branch.
I created a patch against 4.6 branch as attached. Is it ok to back port?
You can refer following link for original patch.
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00260.html
Thanks
gcc
On 02/07/2012 04:47 AM, Joseph S. Myers wrote:
For C++ the width may depend on a template parameter so the integer value
can't be determined immediately at parse time.
Right. But we don't do any layout in templates, so it should be ok to
do different things for template and non-template cases
On 02/07/2012 02:23 AM, Richard Guenther wrote:
There are still corner-cases I also pointed out in the existing
get_bit_range code, namely if you consider tail-padding re-use
with C++ inheritance (I didn't try hard to construct a testcase yet).
The C++ memory model folks have not yet expressed th
On Tue, 7 Feb 2012, Jakub Jelinek wrote:
> On Tue, Feb 07, 2012 at 04:01:31PM +, Jonathan Wakely wrote:
> > > What would it have said for -fabi-version=1 where for
> > > we place s.i and s.d into the same byte?
> >
> > I think it says they shouldn't be in the same byte :-)
>
> They don't, ex
On Tue, 7 Feb 2012, Hans-Peter Nilsson wrote:
> On Tue, 7 Feb 2012, Richard Guenther wrote:
> > The following patch rewrites the bitfield handling of the C++ memory
> > model and enables it unconditionally to fix PR52080. As I suggested
> > earlier at some point this moves computation of what the
More traffic on PR 51675 demonstrates that my earlier patch didn't fix
the whole problem. This patch improves handling of user-defined
constructors.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2ebb9d76963c08ebb009a1b6eb8f576eb9e671c0
Author: Jason Merrill
Date: Mon Feb 6 14:47:50
The issue here is that when we go to instantiate QVector::insert,
we use the out-of-class definition which uses the typedef rather than
the in-class declaration which uses plain int. But we haven't
instantiated the typedef yet, so when we look for the instantiation we
get nothing and end up ju
The pragma Simple_Storage_Pool is provided for designating a library-level
limited private or limited record type as a simple storage pool type.
This provides an alternative to Ada's standard Storage_Pools, where
the pool type is not required to be tagged or have associated finalization
actions, el
On Tue, 7 Feb 2012, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we hit two bugs during cfglayout merge_blocks.
>
> One is that b->il.rtl->header has some jumptable in it, followed by
> barrier. We call emit_insn_after_noloc to insert the whole b's header
> after BB_END (a) and then
No test as no change in behavior. This is for gprbuild.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-02-08 Pascal Obry
* prj.ads, prj.adb (For_Project_And_Aggregated_Context): New
generic routine with a context parameter.
Index: prj.adb
=
No change in behavior. This is for gprbuild.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-02-08 Pascal Obry
* prj.adb (Compute_All_Imported_Projects): Use new
For_Project_And_Aggregated_Context to ensure proper context is
used for encapsulated aggregate libra
On 02/02/2012 11:27 PM, Jakub Jelinek wrote:
Anyway, here is the tweaking all the symbols that demangle the same
equally patch (untested so far) as an alternative. On the example it
unfortunately causes also the D2 dtor into the link which wasn't there
otherwise (and with -Wl,--no-demangle). Wh
On Tue, Feb 7, 2012 at 10:11 PM, Eric Botcazou wrote:
> This breaks LTO bootstrap because of warnings for apparently incompatible
> types
> at the interface between C and Ada. Given that it's very likely not possible
> to fix them all, let's keep accepting them.
>
> Tested on i586-suse-linux, ap
This patch causes -gnatwA to suppress the warning was intended.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-02-08 Bob Duff
* warnsw.adb (Set_Warning_Switch): Set Warn_On_Suspicious_Modulus_Value
False for '-gnatwA', to suppress these warnings.
Index: warnsw.adb
===
This change marks Exceptional_Complete_Rendezvous No_Return, which can
be useful for code generation purposes, and can also help static analyzers.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-02-08 Arnaud Charlet
* s-tasren.adb, s-tasren.ads (Internal_Complete_Rendezvous): N
This fixes an internal error in the gimplifier when it is trying to generate
code for a CONSTRUCTOR of a record type with a component whose type contains
a variant part.
The handling of this kind of CONSTRUCTORs is delicate and the front-end has a
special circuitry to pre-decompose them (or rather
No functionality modified.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-02-08 Vincent Celier
* gcc-interface/Make-lang.in: Add g-byorma.o to gnatbind objects
(g-buorma is now imported by sinput).
Update dependencies.
* scn.adb (Initialize_Scanner): Ca
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-02-08 Vincent Pucci
* impunit.adb: Dimension package names updated
* Makefile.rtl: s-dim added
* sem_dim.adb (Is_Procedure_Put_Call): minor changes
(Is_Dim_IO_Package_Instantiation): minor changes
*
On Wed, Feb 08, 2012 at 10:27:42AM +0100, Richard Guenther wrote:
> Isn't it cheaper to do that before we scan all the sequences? Thus,
> I'd expect BLOCK_FOR_INSN to be NULL if the insn is in a sequence?
> Like simply
Actually, on a third look, the emit-rtl.c changes aren't needed,
apparently NE
On 02/07/2012 05:32 AM, Aldy Hernandez wrote:
struct A {
virtual void f();
int f1 : 1;<--- bit 64
};
struct B : public A {
int f2 : 1; // { dg-warning "ABI" }<--- bit 65
int : 0;
int f3 : 4;
int f4 : 3;
};
It is my understanding that f1 and f2 must be in distinct memory
regions. So
On Wed, 8 Feb 2012, Jakub Jelinek wrote:
> On Wed, Feb 08, 2012 at 10:27:42AM +0100, Richard Guenther wrote:
> > Isn't it cheaper to do that before we scan all the sequences? Thus,
> > I'd expect BLOCK_FOR_INSN to be NULL if the insn is in a sequence?
> > Like simply
>
> Actually, on a third loo
On 07/02/12 22:19, Ramana Radhakrishnan wrote:
I find it interesting that cond_exec's in this form survive all the
way till reload and "work". AFAIK we could never have cond_exec's
before reload . The documentation doesn't appear to mention this,
therefore I would like to see if the cond_exec's
Hi Patrick,
thanks for looking at this ..
On 8 Feb 2012, at 03:36, Patrick Marlier wrote:
The problem in this PR is that with PIE, getsectdata does not return
the position of tm_clone_table after the relocation.
While _dyld_get_image_vmaddr_slide(0) is enough for PIE, this is not
enough for
On 02/07/2012 11:33 PM, Steven Bosscher wrote:
> On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
> wrote:
>> Hi Andrew
>>
>> I find it interesting that cond_exec's in this form survive all the
>> way till reload and "work". AFAIK we could never have cond_exec's
>> before reload .
>
> There
On Wed, Feb 8, 2012 at 1:02 PM, Bernd Schmidt wrote:
> On 02/07/2012 11:33 PM, Steven Bosscher wrote:
>> On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
>> wrote:
>>> Hi Andrew
>>>
>>> I find it interesting that cond_exec's in this form survive all the
>>> way till reload and "work". AFAIK
On Wed, Feb 08, 2012 at 11:55:52AM +0100, Richard Guenther wrote:
> > I'll bootstrap/regtest now just that single hunk, is that ok for
> > trunk/4.6/4.5?
>
> Yes.
Thanks, this is what I've committed after bootstrap/regtest on x86_64-linux
and i686-linux:
2012-02-08 Jakub Jelinek
PR r
Hi!
build_var in coverage.c doesn't strip_name_encoding, therefore happily
puts in characters like leading * into the __gcov* variable names.
Fixed thusly, additionally I'm changing the last _ to . or $ when possible
to avoid failures if user code e.g. contains variables like __gcov__foo
(yeah, I
On 02/08/2012 01:12 PM, Richard Guenther wrote:
> On Wed, Feb 8, 2012 at 1:02 PM, Bernd Schmidt wrote:
>> On 02/07/2012 11:33 PM, Steven Bosscher wrote:
>>> On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
>>> wrote:
Hi Andrew
I find it interesting that cond_exec's in this for
On Tue, Feb 07, 2012 at 11:41:03PM -1000, Jason Merrill wrote:
> Hmm, I wrote up something quite similar on the plane. One
> difference is that mine synchronizes .rpo files that start with some
> variants chosen and others not. Does this make sense to you?
You mean the maybe_tweak change? Not s
On 02/07/2012 07:55 PM, Mike Stump wrote:
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread simulation
test
FAIL: gcc.
We can enter simplify_plus_minus with integer vector mode operands
and thus we shouldn't use constm1_rtx when canonicalizing ~a but
CONSTM1_RTX (mode).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-02-08 Richard Guenther
PR rtl-optimization/521
On Wed, Feb 8, 2012 at 1:37 PM, Jakub Jelinek wrote:
> Hi!
>
> build_var in coverage.c doesn't strip_name_encoding, therefore happily
> puts in characters like leading * into the __gcov* variable names.
> Fixed thusly, additionally I'm changing the last _ to . or $ when possible
> to avoid failure
On Wed, Feb 8, 2012 at 1:41 PM, Bernd Schmidt wrote:
> On 02/08/2012 01:12 PM, Richard Guenther wrote:
>> On Wed, Feb 8, 2012 at 1:02 PM, Bernd Schmidt
>> wrote:
>>> On 02/07/2012 11:33 PM, Steven Bosscher wrote:
On Tue, Feb 7, 2012 at 11:19 PM, Ramana Radhakrishnan
wrote:
> Hi An
On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod wrote:
> On 02/07/2012 07:55 PM, Mike Stump wrote:
>>
>> On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
>>>
>>> Currently we are failing...
>>>
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
>>> simulation test
>>> FAIL: gcc.d
On 8 Feb 2012, at 13:33, Richard Guenther wrote:
On Wed, Feb 8, 2012 at 2:11 PM, Andrew MacLeod
wrote:
On 02/07/2012 07:55 PM, Mike Stump wrote:
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
On 02/08/2012 08:37 AM, Iain Sandoe wrote:
Well - it depends. You don't know whether the test will eventually
terminate,
but yes, you could interpret "UNRESOLVED" as exactly what that is. A
definite finishes-never would be a FAIL of course. The question is
on which
side to err.
There w
On Wed, Feb 08, 2012 at 09:00:00AM -0500, Andrew MacLeod wrote:
> On 02/08/2012 08:37 AM, Iain Sandoe wrote:
>>
>>> Well - it depends. You don't know whether the test will eventually
>>> terminate,
>>> but yes, you could interpret "UNRESOLVED" as exactly what that is. A
>>> definite finishes-ne
This is a vectorizer patch I inherited from Ira. As with the fix for
PR50969, it handles problems with excessive permutes by adjusting the
cost model. In this case the permutes comes from type
promotion/demotion, which is now modeled with a new vec_cvt cost.
This restores the lost performance fo
On 02/08/2012 09:27 AM, Jack Howarth wrote:
On Wed, Feb 08, 2012 at 09:00:00AM -0500, Andrew MacLeod wrote:
On 02/08/2012 08:37 AM, Iain Sandoe wrote:
Well - it depends. You don't know whether the test will eventually
terminate,
but yes, you could interpret "UNRESOLVED" as exactly what that is
We found a scheduler problem while testing Coldfire targets. The
prune_ready_list function I introduced doesn't take SCHED_GROUPs into
account, which can lead to a random insn being scheduled between a cc0
setter and user. The patch below fixes it, OK? (Bootstrapped & tested
i686-linux).
Bernd
When investigating an issue on arm, I discovered a bug that needs fixing.
If there is no atomic_load pattern for data which is larger than the
native word size, we try to issue a compare_and_swap loop. Problem is
there is no check to see if it succeeded or failed. If the compare-swap
loop i
On Wed, Feb 8, 2012 at 3:39 PM, William J. Schmidt
wrote:
> This is a vectorizer patch I inherited from Ira. As with the fix for
> PR50969, it handles problems with excessive permutes by adjusting the
> cost model. In this case the permutes comes from type
> promotion/demotion, which is now mode
On Wed, Feb 8, 2012 at 4:16 PM, Andrew MacLeod wrote:
> When investigating an issue on arm, I discovered a bug that needs fixing.
>
> If there is no atomic_load pattern for data which is larger than the native
> word size, we try to issue a compare_and_swap loop. Problem is there is no
> check t
transform_to_exit_first_loop of the parloops pass can appearantly
not handle (certain?) loops that were not header-copied. Thus, better
assert we face a do-while-style loop before parallelizing it.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-03-08 Rich
Still looking for review. It's been about a month and a half.
Thanks,
Walter
On 1/27/2012 12:47 PM, Walter Lee wrote:
Ping? It's been a month. Seeing more feedback or status update.
Thanks,
Walter Lee
On 12/30/2011 7:30 PM, Walter Lee wrote:
I'm resubmitting the gcc ports to TILE-Gx and T
On 02/08/2012 09:47 AM, Andrew MacLeod wrote:
I propose increasing the time to 20 seconds and reduce the log file.
I believe the timeout as made really short because of the size of the
log file when the timeout was needed. I htink it was an arbitrary
number. Doubling the execution time and
On 08/02/12 11:18, Andrew Stubbs wrote:
I've tried to do this, but it can't be done by a straight translation
because we don't have the insns available to do it. As I understand it,
all "predicable" instructions automatically get a cond_exec variant, but
the only if_then_else I could find (it's h
7
Running target unix/-m64
=== gcc Summary for unix/-m64 ===
# of expected passes57
# of unsupported tests 3
=== gcc Summary ===
# of expected passes 106
# of unsupported tests 10
/sw/src/fink.build/gcc47-4.7.0-1/darwin_objd
On Wed, 2012-02-08 at 16:18 +0100, Richard Guenther wrote:
> On Wed, Feb 8, 2012 at 3:39 PM, William J. Schmidt
> wrote:
> > This is a vectorizer patch I inherited from Ira. As with the fix for
> > PR50969, it handles problems with excessive permutes by adjusting the
> > cost model. In this case
On 02/08/2012 11:43 AM, Jack Howarth wrote:
So something like the following changes:
I'm running a testsuite run on x86-64 right now, I'll try arm as well
shortly. Presuming that it runs properly, is this OK for mainline?
Andrew,
I can confirm that this eliminates the unexpected failu
Currently PR49536 still exists in gcc-4_6-branch. The following
patch backports r175475 for the gcc 4.6.3 release. This will be helpful
to dragonegg users (http://llvm.org/bugs/show_bug.cgi?id=10042) as
dragonegg currently doesn't build against FSF gcc trunk yet. Regression
tested on x86_64-appl
Hi all,
this patch is a follow up to the recent patch on RESHAPE with an
allocatable LHS. It turned out that if the LHS is not allocated or has
the wrong shape, the bounds are not correctly set. Or to be precise: The
just internally used* "stride" is not set correctly.
Result: Either the wro
On Wed, Feb 08, 2012 at 06:46:03PM +0100, Tobias Burnus wrote:
>
> this patch is a follow up to the recent patch on RESHAPE with an
> allocatable LHS. It turned out that if the LHS is not allocated or has
> the wrong shape, the bounds are not correctly set. Or to be precise: The
> just internal
Hi!
emit_note_insn_var_location already had code to ensure that
non-NOTE_DURING_CALL_P notes emitted EMIT_NOTE_BEFORE_INSN
with NEXT_INSN (call_insn) are put after all the NOTE_DURING_CALL_P
notes after the call, but if there is NOTE_INSN_CALL_ARG_LOCATION
note there too, this code doesn't trigger
The master Go math library uses assembler code on 386 processors to take
advantage of 387 instructions. This patch lets gccgo do the same thing,
by compiling the math library with -funsafe-math-optimizations. I also
pass -mfancy-math-387, although that is the default. It would not be
appropriate
Hello world,
I committed the attached test case after verifying that it passes and
that only real(4) variables occur (so the requiredment on vect_float
should be correct.)
Thomas
2012-02-08 Thomas Koenig
PR fortran/32380
* gfortran.dg/vect/pr32380.f90: New test.
! {
On 02/08/2012 04:59 AM, Jonathan Wakely wrote:
Should they be?
How's this look for a news item and the changes file? Formatting seems
fine.
Is there no changelog for docs?
Andrew
Index: index.html
===
RCS file: /cvs/gcc/wwwdoc
On Feb 7, 2012, at 7:36 PM, Patrick Marlier wrote:
> The problem in this PR is that with PIE, getsectdata does not return the
> position of tm_clone_table after the relocation.
> If tests passed, ok for 4.7?
Ok. Thanks for all your hard work. If you want to change it to include the
header an
On Feb 8, 2012, at 5:11 AM, Andrew MacLeod wrote:
> On 02/07/2012 07:55 PM, Mike Stump wrote:
>> On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
>>> Currently we are failing...
>>>
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
>>> simulation test
>>> FAIL: gcc.dg/simulate
On Feb 8, 2012, at 8:02 AM, Andrew MacLeod wrote:
> Presuming that it runs properly, is this OK for mainline?
Ok.
2012/1/11 Richard Guenther :
>
> count despite being declared volatile and only loaded once in the source
> is loaded twice in gimple. If it were a HW register which destroys the
> device after the 2nd load without an intervening store you'd wrecked
> the device ;)
>
> Richard.
Thanks for explain
On 08/02/2012, Andrew MacLeod wrote:
> On 02/08/2012 04:59 AM, Jonathan Wakely wrote:
>> Should they be?
> How's this look for a news item and the changes file? Formatting seems
> fine.
The news item is missing a + in C++
It's not critical for the changes.html page since it's not likely to
be p
On 02/08/2012 04:22 PM, Mike Stump wrote:
On Feb 8, 2012, at 5:11 AM, Andrew MacLeod wrote:
On 02/07/2012 07:55 PM, Mike Stump wrote:
On Dec 7, 2011, at 10:43 AM, Jack Howarth wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
test
On Tue, 20 Dec 2011, Magnus Granberg wrote:
> Hi
>
> This patch make -D and -U work in the spec language, bug pr48524.
> Tested on x86_64-unknown-linux-gnu snapshot 4.7-20111217
Thanks. I've fixed up the whitespace and the ChangeLog entry formatting
and applied this patch now the copyright ass
Ping
2012/2/2 Kai Tietz :
> Hello,
>
> this patch fixes an issue about current used boehm-gc tree in gcc.
> The issue is that _DLL macro is used for Windows-targets wrong. It is
> assumed that it would mean to build a shared object (DLL), but it just
> indicates that built DLL/Exectuable is using
On 02/08/2012 04:30 PM, Jonathan Wakely wrote:
On 08/02/2012, Andrew MacLeod wrote:
On 02/08/2012 04:59 AM, Jonathan Wakely wrote:
Should they be?
How's this look for a news item and the changes file? Formatting seems
fine.
The news item is missing a + in C++
It's not critical for the cha
Hi,
the following patch enables DLL build for x64 windows target.
ChangeLog
2012-02-08 Kai Tietz
* configure.ac (AM_LTLDFLAGS): Add -no-undefine for x64
windows target.
* configure: Regenerated
Tested for x86_64-w64-mingw32. Ok for apply?
Regards,
Kai
Index: configure
This patch fixes a typo in an //extern comment. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 419efb0adfa7 libgo/go/os/dir_regfile.go
--- a/libgo/go/os/dir_regfile.go Wed Feb 08 11:30:14 2012 -0800
+++ b/libgo/go/os/dir_regfile.go Wed Feb 08 1
On SVID-based systems, when certain math functions encounter an
exceptional condition they call a magic function named matherr. That
function is permitted to change the result which the math functions will
return. a program is permitted to provide its own version of matherr.
Solaris works this w
On 8 February 2012 21:49, Andrew MacLeod wrote:
> That's what I get for following the same pattern as those TM jokers.
Heh :)
> OK, hows this look? I added a link in the news as well.
Looks great to me.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.7-b20120128.de.po', h
Joseph S. Myers wrote:
> On Mon, 5 Dec 2011, Jakub Jelinek wrote:
>
> > 2011-12-05 Jakub Jelinek
> >
> > PR c/51339
> > * c-decl.c (c_finish_incomplete_decl, finish_decl): Call
> > relayout_decl instead of layout_decl.
> >
> > * gcc.dg/gomp/pr51339.c: New test.
>
> OK.
The f
Hi Andrew,
On Wed, 8 Feb 2012, Andrew MacLeod wrote:
OK, hows this look? I added a link in the news as well.
Index: index.html
===
+ Atomic memory model support
+ [2011-11-06]
+ C++11/C11 http://gcc.gnu.org/wiki/Atomic/GCCMM"
On 02/08/2012 06:19 PM, Gerald Pfeifer wrote:
This news item on the main page is quite long if you compare it with
the others and probably fills most of that column on page 1; could you
cut this signficantly and instead link to the gcc-4.7/changes.html and
have
some of the good general backg
* doc/xml/manual/status_cxx2011.xml: Update C++11 status table.
Committed to trunk.
commit 4e7bd98694de0aa098bd68ca0122bad65ca7d7a8
Author: Jonathan Wakely
Date: Wed Feb 8 23:46:22 2012 +
* doc/xml/manual/status_cxx2011.xml: Update C++11 status table.
diff --git a/libstdc+
* doc/xml/manual/documentation_hacking.xml: Fix invalid attribute.
Also committed to trunk. Tested with 'make doc-xml-validate-docbook doc-html'
commit 3947c1646119ea4319a57cd401f1736ff5cd76f2
Author: Jonathan Wakely
Date: Wed Feb 8 23:57:04 2012 +
* doc/xml/manual/document
On 02/08/2012 04:14 PM, Mike Stump wrote:
On Feb 7, 2012, at 7:36 PM, Patrick Marlier wrote:
The problem in this PR is that with PIE, getsectdata does not return the
position of tm_clone_table after the relocation.
If tests passed, ok for 4.7?
Ok. Thanks for all your hard work. If you w
The following patch fixes an ICE when we try and generate a compare of
decimal float variables when we are not compiling for a cpu with dfp
hardware support. This is a regression from gcc 4.4. The patch below
bootstrapped and regression tested with no regressions on trunk, 4.6
and 4.5. Is this o
On Wed, 2012-02-08 at 20:34 -0600, Peter Bergner wrote:
> The following patch fixes an ICE when we try and generate a compare of
> decimal float variables when we are not compiling for a cpu with dfp
> hardware support. This is a regression from gcc 4.4. The patch below
> bootstrapped and regress
On 02/08/2012 12:12 AM, Jack Howarth wrote:
I believe the remaining libitm.c++/eh-1.C execution test failures are due to
the weakref linker bug currently in Xcode 4.x (radr://10466868) which I hae been
told will be fixed in the next Xcode release after Xcode 4.3.
Jack
Humm... I
Uros Bizjak writes:
> Some more debugging reveal the difference between alpha and x86_64.
> Alpha does not implement split stacks, so soon after
> "runtime.MemStats.Alloc = 0" line, we allocate exactly 2MB fake stack
> via:
Thanks for tracking this down.
> So, short of XFAILing the test on non-
81 matches
Mail list logo
