On Tue, 25 Oct 2011, Joseph S. Myers wrote:
> On Tue, 25 Oct 2011, Richard Guenther wrote:
>
> > Joseph, does this look like a sensible use of the common
> > machinery? Do we want the init from COLLECT_GCC_OPTIONS
> > in opts-common.c instead?
>
> Certainly there should be a single function to
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 6:27 PM, Xinliang David Li
>> wrote:
>> >> Well, you seem to keep not reading what I write. I am not opposed
>> >> to adding -fopt-info/report
On Tue, Oct 25, 2011 at 2:15 PM, Tom de Vries wrote:
> Richard,
>
> I have a patch for the i686 bootstrap problem reported in PR50763 comment 10.
>
> pr50763-2.c looks like this before tail_merge_optimize:
> ...
> std_canonical_va_list_type (union tree_node * typeD.1608)
> {
> _BoolD.1576 pretmp.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Michael Matz
> Sent: Tuesday, October 11, 2011 10:45 PM
> To: Kai Tietz
> Cc: Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org; Richard
> Henderson
> Subject: Re: [patch t
On Oct 21, 2011, Steve Ellcey wrote:
> On Fri, 2011-10-21 at 21:25 +0200, Jakub Jelinek wrote:
>> My guess would be
>> http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180194
>> DEBUG_EXPR certainly shouldn't make it through into mem_loc_descriptor,
>> var-tracking is supposed to resolve that.
>>
On Wed, Oct 26, 2011 at 07:15:20AM -0200, Alexandre Oliva wrote:
> Ok to install?
>
> for gcc/ChangeLog
> from Alexandre Oliva
>
> PR debug/50826
> * var-tracking.c (rtx_debug_expr_p): New.
> (use_type): Don't use debug exprs to track non-VTA variables.
Yes, thanks.
2011/10/26 Jiangning Liu :
>
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Michael Matz
>> Sent: Tuesday, October 11, 2011 10:45 PM
>> To: Kai Tietz
>> Cc: Richard Guenther; Kai Tietz; gcc-patches@gcc.gnu.org; Richard
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
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
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,
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
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
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
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
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
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;
>> > }
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
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.
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*
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
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
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
>
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.
>>
>
> 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
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
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 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 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
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
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,
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
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
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
>
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.
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
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
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])'
> [...]
>
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
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
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
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
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
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
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
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
(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 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
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/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/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
OK.
Jason
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
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
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 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,
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
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,
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
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
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
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
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.
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
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
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
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
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.
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
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 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 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. :-)
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
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
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
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
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
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.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
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.
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.
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 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
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
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
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
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
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 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 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
... 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 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
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/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
.. 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,
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
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
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
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 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
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
1 - 100 of 107 matches
Mail list logo
