From: David Miller
Date: Wed, 26 Oct 2011 23:07:11 -0400 (EDT)
> From: Alan Modra
> Date: Thu, 27 Oct 2011 13:29:56 +1030
>
>> Some recent patch has exposed a reload bug. I'm seeing
>
> I think this might be a side effect or Eric's recent changes,
> CC:'d.
Eric, I'm seeing a similar segmenta
Hi,
this patch is for a specific case in RTX simplification where infinite
recursion ensues, causing the out-of-stack segfault in PR49720.
Tracking back the origin of this bug, the exact revision causing this
was rev.92429, back in 2004.
The clause in simplify-rtx.c:simplify_relational_operation_
Hello!
See comment above inline_secondary_memory_needed function in i386.c.
2011-08-27 Uros Bizjak
PR target/37191
* config/i386/sse.md (*vec_extract_v4sf_mem): Avoid combining registers
from different units in a single alternative.
Tested on x86_64-pc-linux-gnu {,-m3
On 10/26/2011 07:00 PM, Paolo Carlini wrote:
.. maybe my message wasn't clear, sorry, I'm a bit tired (here it's
late): I meant to say that the non_reference tweak fixes the
non-template impl class case, but something more is needed for a
template impl (thus the new testcase). And, additionally,
Rainer Orth writes:
> the problem is another one: using /usr/xpg4/bin/awk, I find:
>
> /usr/xpg4/bin/awk: line 47 (NR=32): wrong number of arguments to function "m"
>
> nawk(1) only documents match(s,ere) (i.e. two args), and the gawk docs
> state:
>
> `match(STRING, REGEXP [, ARRAY])'
> [...]
>
More extensive testing showed that we have to force the usage of
v9 scc patterns when comparing DImode values with comparison codes
other than EQ and NE.
Soon we'll be able to add exceptions this this, because VIS3 has addxc
and addxccc instructions which test the 64-bit carry condition.
Committ
From: Alan Modra
Date: Thu, 27 Oct 2011 13:29:56 +1030
> Some recent patch has exposed a reload bug. I'm seeing
I think this might be a side effect or Eric's recent changes,
CC:'d.
Some recent patch has exposed a reload bug. I'm seeing
libtool: compile: /home/amodra/build/gcc-curr/./gcc/xgcc
-B/home/amodra/build/gcc-curr/./gcc/ -B/home/amodra/gnu/powerpc-linux/bin/
-B/home/amodra/gnu/powerpc-linux/lib/ -isystem
/home/amodra/gnu/powerpc-linux/include -isystem
/home/amod
This patch fixes some of the problems we had with cgraph nodes for
merged functions. When merging a function that had a cgraph node emitted
for it, we were ICEing during cgraph allocation because the reader
was not checking whether the node already existed for that function.
Additionally, the p
Committed to trunk.
gcc/testsuite/
* gcc.target/sparc/fmaf-1.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180551
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsuite/ChangeLog |2 +
gcc/testsuite/gcc.target/sparc/fmaf-1.c | 51 ++
This makes sure the addx/subx sequence is used even when v9 conditional
moves are available.
It also shows the compiler that the setcc instructions emitting
-1, 0, or 1 all extend to DImode.
I left all the "*x_{plus,minus}_foo" and related patterns alone for
now, I'll get to those and add approp
PR libstdc++/50862
* include/std/condition_variable (condition_variable_any::wait): Avoid
terminating if relocking user mutex throws during stack-unwinding.
* testsuite/30_threads/condition_variable_any/50862.cc: Add dg-require.
Fixes two more issues pointed out in
Hi,
I've been asked by Maxim Kuvyrkov to revive the following patch which
has not made it to 4.6. Currently, when type based devirtualization
detects a potential type change, it simply gives up on gathering any
information on the object in question. This patch adds an attempt to
actually detect
.. maybe my message wasn't clear, sorry, I'm a bit tired (here it's
late): I meant to say that the non_reference tweak fixes the
non-template impl class case, but something more is needed for a
template impl (thus the new testcase). And, additionally, this issue is
a [4.6/4.7 Regression], thus,
On 10/27/2011 12:48 AM, Jason Merrill wrote:
On 10/26/2011 06:20 PM, Paolo Carlini wrote:
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea st
On 10/26/2011 06:20 PM, Paolo Carlini wrote:
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea still
works, fwiw.
- object_type = TREE
On 10/24/2011 05:53 PM, Fabien Chêne wrote:
After looking into it a bit more, I now see things differently. The
target_decl is in fact put into the CLASSTYPE_METHOD_VEC at
instantiation time, via handle_using_decl, with the correct access.
Great.
The problem is that while parsing the template
... forgot the testcase, sorry.
Paolo.
//
// PR c++/50870
// { dg-options "-std=gnu++0x" }
template
struct impl
{
template static T create();
};
template ::template create()
-> impl::template create())>
struct tester { };
tester*, int, float> ti;
templa
On Wed, 26 Oct 2011, Kai Tietz wrote:
> Hi,
>
> patch looks fine for mingw 32-bit. With a small nit new test passes
> for 64-bit mingw version, too. The cygwin-part looks like the mingw
> one.
I've committed my original patch as what I can test - you may wish to
commit followups after testing
On 10/26/2011 06:27 PM, Jason Merrill wrote:
OK.
I re-opened this one because: 1- We may want to fix it in 4_6-branch
too, it's a regression there too; 2- We are still handling incorrectly
the template impl case. For the latter a variant of my old idea still
works, fwiw.
Thanks,
Paolo.
On Oct 26, 2011, at 2:17 PM, Joseph S. Myers wrote:
> The test gcc.dg/graphite/run-id-1.c requires more stack space than
> Windows targets provide by default. This patch arranges for the
> appropriate -Wl,--stack option (as in config/mh-mingw and
> config/mh-cygwin) to be used by this test on thos
On Oct 26, 2011, at 6:10 AM, Richard Guenther wrote:
> This completely rewrites LTO option merging.
> Any comments?
Wondering if It breaks darwin?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876
We have:
%{Zmultiply_defined*:-multiply_defined %*}
in LINK_SPEC.
and:
; Various linker o
2011/10/26 Joseph S. Myers :
> The test gcc.dg/graphite/run-id-1.c requires more stack space than
> Windows targets provide by default. This patch arranges for the
> appropriate -Wl,--stack option (as in config/mh-mingw and
> config/mh-cygwin) to be used by this test on those targets. Tested
> wi
Hi,
patch looks fine for mingw 32-bit. With a small nit new test passes
for 64-bit mingw version, too. The cygwin-part looks like the mingw
one.
2011/10/26 Joseph S. Myers :
> gcc.dg/tls/thr-cse-1.c tests that there are not two calls to
> __emutls_get_address in the output. Normally this just
Hi!
This patch implements gather vectorization with -mavx2, if
dr_may_alias (which apparently doesn't use tbaa :(( ) can figure out
there is no overlap with stores in the loop (if any).
The testcases show what is possible to get vectorized.
I chose to add 4 extra (internal only) gather builtins i
On 10/26/2011 10:35 PM, Paolo Carlini wrote:
On 10/26/2011 10:30 PM, Paolo Carlini wrote:
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after ->.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b->A::B::i;
I was also trying to construct su
On Oct 26, 2011, at 2:18 PM, Joseph S. Myers wrote:
> gcc.target/i386/pad-4.c expects particular results from PIC code
> generation - PIC in the sense of a GOT and a PLT, which is different
> from the sense in which Windows code is always PIC. This patch
> arranges for it to be skipped on Windows
On Oct 26, 2011, at 2:18 PM, Joseph S. Myers wrote:
> gcc.target/i386/pr37843-4.c tests for the form calls to a function
> "foo" take in the output. On Windows targets this function has a
> leading underscore and so the test fails.
> OK to commit?
Ok.
The background is that I was putting together some test cases for
gcc.target/sparc that make sure the most optimal setcc sequences
are being generated.
When v9, and thus conditional moves, are enabled we sometimes fall
back to conditional moves even when the addx/subx sequence is more
efficient.
gcc.target/i386/pr37843-4.c tests for the form calls to a function
"foo" take in the output. On Windows targets this function has a
leading underscore and so the test fails. This patch allows for that
underscore in the test. Tested with cross to i686-mingw32. OK to
commit?
2011-10-26 Joseph M
gcc.target/i386/pad-4.c expects particular results from PIC code
generation - PIC in the sense of a GOT and a PLT, which is different
from the sense in which Windows code is always PIC. This patch
arranges for it to be skipped on Windows targets, similarly to other
tests such as gcc.target/i386/pi
gcc.dg/tls/thr-cse-1.c tests that there are not two calls to
__emutls_get_address in the output. Normally this just checks for
emutls_get_address.*emutls_get_address, but on some targets where the
compiler output declares the functions called in some way the testcase
has more specific tests. i?86
The test gcc.dg/graphite/run-id-1.c requires more stack space than
Windows targets provide by default. This patch arranges for the
appropriate -Wl,--stack option (as in config/mh-mingw and
config/mh-cygwin) to be used by this test on those targets. Tested
with cross to i686-mingw32. OK to commit
The merge broke base/complete dtor transactional clones that we
originally implemented here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00590.html
First, ipa_tm_execute() was putting __comp_dtor's into tm_callees, which
wasn't happening pre-merge. Handling this __comp_dtor caused an ICE
tr
Steve,
> Surely, you have Halloween across the Pond, ie., the Grim Reaper. :-)
And what, pray, does the Grim Reaper hold???
The patch is OK.
Thanks
Paul
>
>>
>> On Wed, Oct 26, 2011 at 7:53 PM, Steve Kargl
>> wrote:
>> > On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl wrote:
>> >> The
This is an internal error on the elaboration variable generated for an array of
discriminated record type whose discriminant is constraint by a dynamic upper
bound in -gnatct mode. In this mode, the compiler doesn't generate code and
gigi is invoked only to lay out types and back-annotate type
On Wed, Oct 26, 2011 at 09:55:09PM +0200, Paul Richard Thomas wrote:
> Dear Steve,
>
> Reaping implies that there is something about it that you want to keep
> :-) Surely, weeding or herbicide spraying is better than reaping?
Surely, you have Halloween across the Pond, ie., the Grim Reaper. :-)
The compiler aborts on a record type which contains a component of an unchecked
union type whose size is smaller than 64 bits and which is subject to a
representation clause that causes it not to start on a byte boundary.
We already have the machinery to handle this kind of composite component,
On 10/26/2011 10:30 PM, Paolo Carlini wrote:
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after ->.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b->A::B::i;
I was also trying to construct such kind of example myself... but my
patch doe
The compiler should issue the "atomic access cannot be guaranteed" error twice
on the attached testcase, but it only issues it for the stand-alone variable.
Fixed thusly, tested on i586-suse-linux, applied on the mainline.
2011-10-26 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu
Hi,
At a glance, it looks too early; it's valid to have
namespace-qualified names after ->.
namespace A
{
struct B
{
int i;
};
};
A::B* b;
int i = b->A::B::i;
I was also trying to construct such kind of example myself... but my
patch does not regress on the testcase you wrote down.
On 10/26/2011 04:04 PM, Paolo Carlini wrote:
The below tries to catch the problem very early, in
cp_parser_postfix_dot_deref_expression and apparently works fine, passes
the testsuite, etc. Is it too early? Is the check tight enough?
At a glance, it looks too early; it's valid to have namespace
On 10/26/2011 04:11 PM, 3dw...@verizon.net wrote:
Thank you Jason and Tom for your help in getting this together an putting up
with my slowness.
Thanks for all your work on this!
Jason
Any questions on these patches? Are they ok for the trunk?
On 20 October 2011 12:37, Michael Zolotukhin
wrote:
> And, finally, part with the tests.
>
> On 20 October 2011 12:36, Michael Zolotukhin
> wrote:
>> Back-end part of the patch is attached here.
>>
>> On 20 October 2011 12:35, Michael Zo
Oct 26, 2011 03:39:09 PM, ja...@redhat.com wrote:
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
> The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused "suffix" parameter to
interpret_integer. So I've fixed that error. I also added a
Hi,
one more / RFC, for the ICE on invalid part of these issues with '->'.
The below tries to catch the problem very early, in
cp_parser_postfix_dot_deref_expression and apparently works fine, passes
the testsuite, etc. Is it too early? Is the check tight enough?
Thanks,
Paolo.
Dear Steve,
Reaping implies that there is something about it that you want to keep
:-) Surely, weeding or herbicide spraying is better than reaping?
On Wed, Oct 26, 2011 at 7:53 PM, Steve Kargl
wrote:
> On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl wrote:
>> The attach patch reaps some
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 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused "suffix" parameter to
interpret_integer. So I've fixed that error. I also added a couple of
comments, and implemented the change to ch
Hi,
Honza requested that we do attempt to produce pass-through jump
functions even when the actual formal parameter that is being passed
on is addressable - provided that we can prove it has not changed
value, of course. The following patch does this, hopefully the
limitations of our parameter-no
Hi,
I've worked with the parameter-has-not-been-modified mechanism in
ipa-prop.c after not seeing for quite some time and found the original
"infos" and temporary "parm_infos" confusing. Thus I at least renamed
all the parm_infos (which are deallocated after the analysis ends and
which have type
Hi,
I've noticed that a test in g++.dg/tree-ssa/pr45605.C is Xfailed, even
though early FRE now does the devirtualization that it tests for.
True, the current scan happens over the SSA dump (which implies the
front-end was somehow supposed to do it?) but I think that given we do
perform the optimi
This RFC patch implements conversion of COND_EXEC instructions to control flow
for pre-RA selective scheduler. Something like this is needed to employ
predication support before reload.
Each COND_EXEC is converted separately to a new basic block with the
unconditional variant of the instruction,
On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl wrote:
> The attach patch reaps some code that is now dead
> due to my recent changes for ishftc in check.c.
> Regression tested on i686-*-freebsd.
>
> 2011-10-22 Steevn G. Kargl
>
> * simplify.c (gfc_simplify_ishftc): Reap dead code.
This patch contains the implementation of predication support.
The selective scheduler is adjusted to recognize COND_EXEC instructions. They
can be renamed like normal assignments. Selective scheduler itself will add
predicated variants of instructions in availability sets when computing them
on
In my earlier patch to add support for --with-native-system-header-dir,
I messed up the case of a cross-compiler when not using --with-sysroot.
In that case the compiler was incorrectly searching /usr/include. This
patch restores the logic to what it used to be before my patch. As the
patch is st
OK.
Jason
On 10/25/2011 04:38 PM, Michael Meissner wrote:
> On Tue, Oct 25, 2011 at 03:01:37PM -0700, Richard Henderson wrote:
>> Now that expand_binop handles lowering vec_extract_even to vec_perm,
>> we can remove the last two unnecessary vec_extract patterns from the
>> Altivec backend.
>>
>> Ok?
>
> Jus
On 10/25/2011 06:45 PM, Andrew MacLeod wrote:
> * builtins.c (expand_builtin_atomic_fetch_op): External calls for
> 'op_fetch' builtins need to instead call 'fetch_op' externals and issue
> correction code.
> (expand_builtin): Provide proper builtin name for external call a
On 10/26/2011 12:41 PM, Paolo Carlini wrote:
we have an inconsistent mix: shall we do the below?
Sure, why not.
Jason
On 10/26/2011 10:25 AM, Andrew MacLeod wrote:
> hum. I suppose that wouldn't hurt. I don't think it should make any
> difference since Im not modifying whats in the table, but I can give
> it a shot. If it bootstraps, which I presume it will, I'll check it
> in with the original decl replaced.
The
(Note, this is a prerequisite for predication support but also is an
improvement on its own. This patch can be installed separately.)
This patch implements transformation replay mechanism (redo_transformations).
Currently, after choosing an expression to schedule and finding its original
express
On 10/26/2011 01:19 PM, Richard Henderson wrote:
!resolved to an instriction sequence. */
"instruction"
no no, its a mashup of "restricted instruction".
ok, maybe not.
! gcc_assert (TREE_OPERAND (addr, 0) == fndecl);
! TREE_OPERAND (addr, 0) = builtin_decl_explicit(ext_call);
I do
Hello,
This patch series implements predication support for the selective scheduler.
It is implemented as a transformation similar to speculative execution, but
simpler in some aspects (e.g. does not require recovery code). On ia64,
combining speculation and conditional execution is supported. C
Hi,
we have an inconsistent mix: shall we do the below? Test in progress on
x86_64-linux.
Thanks,
Paolo.
//
2011-10-26 Paolo Carlini
* typeck.c (cp_build_addr_expr_1): Use BASELINK_P.
* class.c (instantiate_type): Likewise.
* pt.c (convert_nontype_a
I am hoping that too:) Yes, I will try to do it when I find some time.
David
On Wed, Oct 26, 2011 at 1:37 AM, Richard Guenther
wrote:
> On Tue, Oct 25, 2011 at 9:30 PM, Xinliang David Li wrote:
>>
>>
>> On Tue, Oct 25, 2011 at 1:02 AM, Richard Guenther
>> wrote:
>>>
>>> On Mon, Oct 24, 2011 at
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 in any cas
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 in any case?
Yes, it should use the mode of th
On 10/26/2011 05:27 PM, Jason Merrill wrote:
On 10/26/2011 10:39 AM, Paolo Carlini wrote:
I'm trying to fix this PR, ice on valid, which Daniel kindly filed while
we were triaging PR50864. In short, in tsubst_copy_and_build, for
COMPONENT_REF, we call tsubst_baselink with an object which in this
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
> So you would mean that memory dereferencing shouldn't be considered as
> side-effect at all?
No. I haven't said this at all. Of course it's a side-effect, but we're
allowed to remove existing ones (under some circumstances). We're not
allowed to
Rainer Orth writes:
> the problem is another one: using /usr/xpg4/bin/awk, I find:
>
> /usr/xpg4/bin/awk: line 47 (NR=32): wrong number of arguments to function "m"
>
> nawk(1) only documents match(s,ere) (i.e. two args), and the gawk docs
> state:
>
> `match(STRING, REGEXP [, ARRAY])'
> [...]
>
On 10/26/2011 10:39 AM, Paolo Carlini wrote:
I'm trying to fix this PR, ice on valid, which Daniel kindly filed while
we were triaging PR50864. In short, in tsubst_copy_and_build, for
COMPONENT_REF, we call tsubst_baselink with an object which in this case
is an ARROW_EXPR, thus its TREE_TYPE is
2011/10/26 Michael Matz :
> Hi,
>
> On Wed, 26 Oct 2011, Kai Tietz wrote:
>
>> well, if such a function is used as inline and we know for it that j has
>> value != 2, then we have here a big difference. For your first example,
>> we still have to do the memory access to *i, even if we are not
>> i
Ian,
> Hmmm, I don't have a copy of nawk. Is it possible that it doesn't like
> " *" == *? You could try "[ ]*".
the problem is another one: using /usr/xpg4/bin/awk, I find:
/usr/xpg4/bin/awk: line 47 (NR=32): wrong number of arguments to function "m"
nawk(1) only documents match(s,ere) (i.e.
On Wed, 26 Oct 2011, Richard Guenther wrote:
> Index: trunk/gcc/opts-global.c
> ===
> *** trunk.orig/gcc/opts-global.c 2011-10-26 13:46:24.0 +0200
> --- trunk/gcc/opts-global.c 2011-10-26 13:48:42.0 +0200
>
On Wed, Oct 26, 2011 at 03:59:36PM +0200, Bernd Schmidt wrote:
> On 10/26/11 15:54, Alan Modra wrote:
> > I guess the tradeoff between the classic shrink-wrap epilogue scheme
> > and my duplicate tail idea is whether duplicating tail blocks adds
> > more code than duplicating epilogues. From what
Hi,
I'm trying to fix this PR, ice on valid, which Daniel kindly filed while
we were triaging PR50864. In short, in tsubst_copy_and_build, for
COMPONENT_REF, we call tsubst_baselink with an object which in this case
is an ARROW_EXPR, thus its TREE_TYPE is NULL_TREE. I'm trying to fix
this be
Richard Henderson wrote:
> Fix typos in the names of vec_extract & vec_interleave tree codes.
> Change vec_perm checking and expansion level.
> Implement interleave via permutation.
> spu: Remove vec_extract_even/odd and vec_interleave expanders.
> rs6000: Remove some vec_extract_even/od
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
> well, if such a function is used as inline and we know for it that j has
> value != 2, then we have here a big difference. For your first example,
> we still have to do the memory access to *i, even if we are not
> interested in result.
Actually we
On 26/10/11 14:54, Andrew Stubbs wrote:
> On 25/10/11 15:16, Richard Earnshaw wrote:
>> The difficulty on R profile is that although BE-32 mode is obsolete,
>> there is a config bit that can be set to make the CPU byte-swap the
>> instruction stream to make it behave largely like it is running in B
On 10/26/11 15:54, Alan Modra wrote:
> On Wed, Oct 26, 2011 at 03:01:01PM +0200, Bernd Schmidt wrote:
>> On 10/26/11 14:27, Alan Modra wrote:
>>> Committed revision 180522. It turns out that shrink-wrapping isn't as
>>> effective as it used to be with the 20110915 based sources I was using
>>> ori
On 25/10/11 15:16, Richard Earnshaw wrote:
The difficulty on R profile is that although BE-32 mode is obsolete,
there is a config bit that can be set to make the CPU byte-swap the
instruction stream to make it behave largely like it is running in BE-32
mode.
I think really we should be pushing t
On Wed, Oct 26, 2011 at 03:01:01PM +0200, Bernd Schmidt wrote:
> On 10/26/11 14:27, Alan Modra wrote:
> > Committed revision 180522. It turns out that shrink-wrapping isn't as
> > effective as it used to be with the 20110915 based sources I was using
> > originally. povray Ray_In_Bound no longer
> Thanks!
You're welcome. I have also installed the attached patch which makes minor
tweaks and fixes various issues in comments which have bugged me for years,
the most glaring one being:
Similar issue for (SUBREG:M1 (REG:M2 ...) ...) for a hard register R where
either M1 is not val
2011/10/26 Michael Matz :
> Hi,
>
> On Wed, 26 Oct 2011, Kai Tietz wrote:
>
>> >> > int f(char *i, int j)
>> >> > {
>> >> > if (*i && j!=2)
>> >> > return *i;
>> >> > else
>> >> > return j;
>> >> > }
>> >>
>>
>> the case can be produced quite easily.
>>
>
Rainer Orth writes:
> There's one problem left: with Solaris nawk, building libcalls.go fails
> (from Solaris 8 to 11 inclusive):
>
> nawk -f /vol/gcc/src/hg/trunk/local/libgo/go/syscall/mksyscall.awk ${files} >
> li
> bcalls.go.tmp
> nawk: syntax error at source line 47
> context is
>
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
> >> > int f(char *i, int j)
> >> > {
> >> > if (*i && j!=2)
> >> > return *i;
> >> > else
> >> > return j;
> >> > }
> >>
>
> the case can be produced quite easily.
>
> extern int global = 0;
>
>
> if
This completely rewrites LTO option merging. At compile (uselessly
now at WPA?) time we now stream a COLLECT_GCC_OPTIONS like string
as it comes from argv of the compiler binary. Those options are
read in by the LTO driver (lto-wrapper), merged into a single
set (very simple merge function right
On 10/26/2011 08:29 AM, Michael Matz wrote:
Hi,
On Tue, 25 Oct 2011, Andrew MacLeod wrote:
and new generic routines are provided as follows:
void __atomic_load (T* object, T* return_value, memory_order m)
void __atomic_store (T* object, T* new_value, memory_order m)
void __atomic_exchange (T*
On 10/26/11 14:27, Alan Modra wrote:
> Committed revision 180522. It turns out that shrink-wrapping isn't as
> effective as it used to be with the 20110915 based sources I was using
> originally. povray Ray_In_Bound no longer gets the benefit of shrink
> wrap, likely due to some cfg optimization.
I describe the sample more closely here
extern int global = 0;
extern int *a = NULL;
void catchSigSegV( int sig )
{
a = &global;
}
int foo (int j)
{
signal (SIGSEGV, catchSigSegV);
if (*a && global) return 2;
return 0;
}
I admit that in most cases such a scenario is not common. This samp
2011/10/26 Michael Matz :
> Hi,
>
> On Wed, 26 Oct 2011, Kai Tietz wrote:
>
>> > Yes, this part introduced different behavior for this small case,
>> >
>> > int f(char *i, int j)
>> > {
>> > if (*i && j!=2)
>> > return *i;
>> > else
>> > return j;
>> > }
Hi,
On Tue, 25 Oct 2011, Andrew MacLeod wrote:
> and new generic routines are provided as follows:
>
> void __atomic_load (T* object, T* return_value, memory_order m)
> void __atomic_store (T* object, T* new_value, memory_order m)
> void __atomic_exchange (T* object, T* new_value, T* return_valu
On Sun, Oct 16, 2011 at 02:51:01PM -0400, David Edelsohn wrote:
> The patch is okay, although I am not thrilled about the need to change
> the register allocation order.
Committed revision 180522. It turns out that shrink-wrapping isn't as
effective as it used to be with the 20110915 based source
Ian,
> I committed this patch to mainline to try to fix these problems. Thanks
> for testing. For this patch I bootstrapped and ran Go testsuite on
> x86_64-unknown-linux-gnu.
with this patch, go and libgo results on Solaris 10 and 11/x86 are back
to normal, and Solaris 10 and 11/SPARC bootstra
Hi,
On Wed, 26 Oct 2011, Kai Tietz wrote:
> > Yes, this part introduced different behavior for this small case,
> >
> > int f(char *i, int j)
> > {
> > if (*i && j!=2)
> > return *i;
> > else
> > return j;
> > }
>
> Well, as far as I understand C speci
Hi,
On Wed, 26 Oct 2011, Jiangning Liu wrote:
> > > >> -
> > > >> - if (LOGICAL_OP_NON_SHORT_CIRCUIT)
> > > >> - {
> > > >> - if (code != orig_code || lhs != orig_lhs || rhs !=
> > orig_rhs)
> > > >> - return build2_loc (loc, code, truth_type, lhs, rhs);
> > > >> - re
Seems only in some cases we fault freeing an uninitialized obstack.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-10-26 Richard Guenther
* lto-wrapper.c (run_gcc): Properly init/free obstack.
Index: gcc/lto-wrapper.c
===
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 Tue, Oct 25, 2011 at 2:22 PM, Tom de Vries wrote:
> On 09/24/2011 01:42 PM, Richard Guenther wrote:
>> On Sat, Sep 24, 2011 at 11:40 AM, Jakub Jelinek wrote:
>>> On Sat, Sep 24, 2011 at 11:31:25AM +0200, Richard Guenther wrote:
In the end I'd probably say the patch is ok without the optio
1 - 100 of 107 matches
Mail list logo
