On 02/11/2014 10:27 PM, Jan Hubicka wrote:
On 02/11/2014 07:54 PM, Jan Hubicka wrote:
+ /* Allow combining RTTI and non-RTTI is OK. */
You mean combining -frtti and -fno-rtti compiles? Yes, that's fine,
though you need to prefer the -frtti version in case code from that
translation u
On 02/06/2014 02:59 AM, Paolo Carlini wrote:
- if (vec_safe_is_empty (vbases))
+ if (vbases == NULL)
vec_safe_is_empty is still more correct here.
The rest of the patch is OK.
Jason
The below patch fixes the build for AVR and SPU targets, which got broken
when the signature of build_function_call_vec changed. The patch passes
vNULL for the extra parameter added (arg_loc), which I hope is ok for
builtins?
If ok, could someone commit please? I don't have commit access.
Regards
On Tue, Feb 11, 2014 at 9:41 PM, H.J. Lu wrote:
> HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
> pass --32 to assembler. Otherwise, we get the wrong result on x86-64.
> We already pass --32 to assembler on x86. It should be OK to do it
> in configure. OK
d 4.8 branch.
2014-02-12 Eric Botcazou
PR rtl-optimization/60116
* combine.c (try_combine): Also remove dangling REG_DEAD notes on the
other_insn once the combination has been validated.
2014-02-12 Eric Botcazou
* gcc.c-torture/execute/20140212-1.c: New
The following patch avoids the cubic search for equal types by
collecting candidates and sorting them. The length() == 2
qsort optimization probably belongs to vec.h and additionally
we can avoid sorting the other vector if one has length() == 1.
Bootstrapped and tested on x86_64-unknown-linux-g
On 07/02/14 10:33, Richard Biener wrote:
> + static void
> + lower_builtin_posix_memalign (gimple_stmt_iterator *gsi)
> + {
> + gimple stmt = gsi_stmt (*gsi);
> + tree pptr = gimple_call_arg (stmt, 0);
> + tree align = gimple_call_arg (stmt, 1);
> + tree ptr = create_tmp_reg (ptr_type_node,
On Wed, Feb 12, 2014 at 09:51:44AM +0100, Eric Botcazou wrote:
> --- combine.c (revision 207685)
> +++ combine.c (working copy)
> @@ -3894,14 +3894,15 @@ try_combine (rtx i3, rtx i2, rtx i1, rtx
>
>PATTERN (undobuf.other_insn) = other_pat;
>
> - /* If any of the notes in OTHER_INSN
On Wed, Feb 12, 2014 at 01:43:39PM +0530, Senthil Kumar Selvaraj wrote:
> The below patch fixes the build for AVR and SPU targets, which got broken
> when the signature of build_function_call_vec changed. The patch passes
> vNULL for the extra parameter added (arg_loc), which I hope is ok for
> bui
On Wed, Feb 12, 2014 at 10:16:37AM +0100, Marek Polacek wrote:
> On Wed, Feb 12, 2014 at 01:43:39PM +0530, Senthil Kumar Selvaraj wrote:
> > The below patch fixes the build for AVR and SPU targets, which got broken
> > when the signature of build_function_call_vec changed. The patch passes
> > vNUL
> Thanks, just wonder if reg_set_p is the right predicate for the REG_DEAD
> notes, don't we want to check if the register in REG_DEAD note isn't used
> in undobuf.other_insn rather than set?
You're right, the correct predicate is reg_referenced_p, I'll adjust.
--
Eric Botcazou
On Wed, 12 Feb 2014, Andreas Krebbel wrote:
> On 07/02/14 10:33, Richard Biener wrote:
> > + static void
> > + lower_builtin_posix_memalign (gimple_stmt_iterator *gsi)
> > + {
> > + gimple stmt = gsi_stmt (*gsi);
> > + tree pptr = gimple_call_arg (stmt, 0);
> > + tree align = gimple_call_arg
On Wed, Feb 12, 2014 at 10:30:01AM +0100, Richard Biener wrote:
> Bah. I am testing the following.
But then there is no guarantee that ptr is aligned after the call.
char buf[32] __attribute__((aligned (32)));
int
foo (void)
{
void *ptr = buf + 1;
posix_memalign (&ptr, 32, -1);
/* Assume po
I figured it might be a good idea to warn about variadic main decl
(well, not in freestanding environment where it's
implementation-defined).
Regtested/bootstrapped on x86_64-linux, ok for 5.0?
2014-02-12 Marek Polacek
PR c/60156
c-family/
* c-common.c (check_main_parameter_ty
On 12 February 2014 00:52, David Malcolm wrote:
> On Tue, 2014-02-11 at 16:51 +, Philip Herron wrote:
> [adding the j...@gcc.gnu.org ML to the CC]
>
>> Added install hook:
>
> Thanks!
>
> I don't know that this is needed for a 3-line patch, but have you done
> the copyright assignment paperwor
On Wed, 12 Feb 2014, Jakub Jelinek wrote:
> On Wed, Feb 12, 2014 at 10:30:01AM +0100, Richard Biener wrote:
> > Bah. I am testing the following.
>
> But then there is no guarantee that ptr is aligned after the call.
> char buf[32] __attribute__((aligned (32)));
> int
> foo (void)
> {
> void *p
The attached patch fixes a crash if gfortran encounters a nested
function when -mhotpatch is enabled. (It slightly improves the
warning message too.)
This patch affects s390 only. Andreas Krebbel will commit the
patch soon, if there are no objections.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
I
On Wed, Feb 12, 2014 at 11:28:38AM +0100, Dominik Vogt wrote:
> The attached patch fixes a crash if gfortran encounters a nested
> function when -mhotpatch is enabled. (It slightly improves the
> warning message too.)
>
> This patch affects s390 only. Andreas Krebbel will commit the
> patch soon
On Wed, 12 Feb 2014, Richard Biener wrote:
> On Wed, 12 Feb 2014, Jakub Jelinek wrote:
>
> > On Wed, Feb 12, 2014 at 10:30:01AM +0100, Richard Biener wrote:
> > > Bah. I am testing the following.
> >
> > But then there is no guarantee that ptr is aligned after the call.
> > char buf[32] __attri
On Wed, Feb 12, 2014 at 11:42:09AM +0100, Richard Biener wrote:
> But as the testcase was supposed to test field-sensitive points-to
> I chose to disable SRA for the testcase (and queue pass interchange
> for 4.10 - unless you think it's ok now - I think it's harmless
> and should only improve earl
On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek wrote:
> On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
>> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
>> >> I've just seen that an explicit --enable-multilib is a way to do that.
>> >
>> > Yes, I was writing that as a reply when I re
Hi,
This patch implements vqneg_s64, vqnegd_s64, vqabs_s64 and
vqabsd_s64 AArch64 intrinsics. Regression tests added.
Run full regression with no regressions.
Is patch OK?
Thanks,
Alex
gcc/
2014-02-12 Alex Velenko
* gcc/config/aarch64/aarch64-simd.md (aarch64_s):
Pattern e
On Tue, Feb 11, 2014 at 6:15 PM, Eric Botcazou wrote:
>> Hmm. The intent was of course to only allow truly no-op converts via
>> VIEW_CONVERT_EXPR - that is, the size of the operand type and the
>> result type should be the same. So, isn't SRA doing it wrong when
>> creating the VIEW_CONVERT_EXP
On Wed, Feb 12, 2014 at 11:52:47AM +0100, Richard Biener wrote:
> On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek wrote:
> > On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
> >> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
> >> >> I've just seen that an explicit --enable-multilib is
Hi!
On Tue, 14 Jan 2014 16:10:07 +0100, I wrote:
> gcc/c-family/
> * c-pragma.h (pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_COPY,
> PRAGMA_OMP_CLAUSE_COPYOUT, PRAGMA_OMP_CLAUSE_CREATE,
> PRAGMA_OMP_CLAUSE_DELETE, PRAGMA_OMP_CLAUSE_DEVICEPTR,
> PRAGMA_OMP_CLAUSE_PRESENT
On Wed, Feb 12, 2014 at 7:27 AM, Jan Hubicka wrote:
>> On 02/11/2014 07:54 PM, Jan Hubicka wrote:
>> >+ /* Allow combining RTTI and non-RTTI is OK. */
>>
>> You mean combining -frtti and -fno-rtti compiles? Yes, that's fine,
>> though you need to prefer the -frtti version in case code from
On Wed, Feb 12, 2014 at 11:57 AM, Jakub Jelinek wrote:
> On Wed, Feb 12, 2014 at 11:52:47AM +0100, Richard Biener wrote:
>> On Tue, Feb 11, 2014 at 5:17 PM, Jakub Jelinek wrote:
>> > On Fri, Jan 31, 2014 at 03:49:40PM +0100, Richard Biener wrote:
>> >> On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
Dominik Vogt writes:
> diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
> index 32a25a4..9ae8ffd 100644
> --- a/gcc/config/s390/s390.c
> +++ b/gcc/config/s390/s390.c
> @@ -5510,9 +5510,8 @@ s390_asm_output_function_label (FILE *asm_out_file,
> const char *fname,
>if (hotpatch_
> That's true. What I wonder is why the stmt checker doesn't trip. Probably
> because while SRA scalarizes the thing the result isn't rewritten into
> SSA form?
We have a slice of an array on the RHS so there is no SSA form, it's the VCE
of an ARRAY_RANGE_REF to a 24-bit precision integer type.
Hi,
In aarch-common-protos.h we define a field in alu_cost_table:
"extnd"
On its own this is an upsetting optimization of the
English language, but this trouble is compounded by the
comment attached to this field throughout the cost tables
themselves:
/* Extend. */
This patch fixes the s
Hi,
This patch fixes a nuisance with the comments in the cost tables.
Presently they are in sentence case, which to any casual observer
(i.e. me) would suggest that the field name should begin with
an upper-case character, .Fma for example. Also irritating is trying
to find the cost of the real .
On 02/12/14 12:19, James Greenhalgh wrote:
Hi,
In aarch-common-protos.h we define a field in alu_cost_table:
"extnd"
On its own this is an upsetting optimization of the
English language, but this trouble is compounded by the
comment attached to this field throughout the cost tables
themsel
On 02/12/14 12:34, James Greenhalgh wrote:
Hi,
This patch fixes a nuisance with the comments in the cost tables.
Presently they are in sentence case, which to any casual observer
(i.e. me) would suggest that the field name should begin with
an upper-case character, .Fma for example. Also irrita
On Wed, Feb 12, 2014 at 12:46:04PM +, Ramana Radhakrishnan wrote:
> Ok by me but I'd like the RM ack.
Ok.
> >2014-02-12 James Greenhalgh
> >
> > * config/arm/aarch-cost-tables
The filename is config/arm/aarch-cost-tables.h, and
the (...) if it fits should just be on the same line as t
The following aims to improve code generation for loops like
those in tree-ssa-alias.c:
auto_vec component_refs1;
auto_vec component_refs2;
/* Create the stack of handled components for REF1. */
while (handled_component_p (ref1))
{
component_refs1.safe_push (ref1);
ref1
On Wed, Feb 12, 2014 at 03:09:17PM +0100, Richard Biener wrote:
> 2014-02-12 Richard Biener
>
> * vec.c (vec_prefix::calculate_allocation): Move as
> inline variant to vec.h.
> (vec_prefix::calculate_allocation_1): New out-of-line version.
> * vec.h (vec_prefix::calculat
Hi Jakub,
Did you get a chance to look at this patch?
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Monday, February 10, 2014 5:07 PM
> To: Jakub Jelinek
> Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.c
No magic bullet for the insn-recog.c testcase I'm looking at but
quite obvious and should save half of the canon_true_dependence calls
for blocks that end up non-transparent.
Now one of the main weakness of compute_transp is that we call it
for all expressions but for the MEM case it's certainly
On Tue, Feb 11, 2014 at 6:13 PM, Xinliang David Li wrote:
> On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson wrote:
>> On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li
>> wrote:
>>> Why is call graph needed to determine whether to drop the profile?
>>
>> Because we detect this situation by loo
From: tschwinge
gcc/testsuite/
* c-c++-common/raw-string-3.c: Fix typo in dg-error invocation.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207725
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsuite/ChangeLog | 2 ++
gcc/testsuite/c-c++-common/raw-string
On Mon, Feb 10, 2014 at 10:07:18PM +, Iyer, Balaji V wrote:
> I looked at both but forgot to test them with my implementation. Sorry
> about this. I have fixed the ICE issue. To make sure this does not
> happen further, I have added your test cf3.C into test suite (renamed to
> cf3.cc). I ho
As said in the other mail esra corrupts ealias info by eventually
adding new PHI nodes but at the same time doesn't benefit from
points-to info. Also esra may improve PTA precision by exposing
more SSA names.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progres.
Queued for stage1.
Rich
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, February 12, 2014 9:59 AM
> To: Iyer, Balaji V
> Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: Re: [PING] [PATCH] _Cilk_for for C and C++
On 3 February 2014 10:02, Renlin Li wrote:
> 2014-02-03 Renlin Li
>
> * gcc.target/aarch64/aapcs64/validate_memory.h: move f32in64 and
> i32in128 cases
> outside special big-endian processing block.
This is a test case fix. This is ok with me but needs a release manager ack.
/Marcus
On Wed, Feb 12, 2014 at 4:21 PM, Trevor Saunders wrote:
> On Wed, Feb 12, 2014 at 03:09:17PM +0100, Richard Biener wrote:
>>
>> The following aims to improve code generation for loops like
>> those in tree-ssa-alias.c:
>>
>> auto_vec component_refs1;
>> auto_vec component_refs2;
>>
>> /* Cre
On Wed, Feb 12, 2014 at 03:14:23PM +, Iyer, Balaji V wrote:
> > The testcase is GPL as the original libgomp.c++/for-1.C testcase, so sure.
> > Perhaps it would be much better though if instead of having a compile time
> > testcase you'd just do what libgomp.c++/for-1.C does, just replace all th
On Wed, Feb 12, 2014 at 03:09:17PM +0100, Richard Biener wrote:
>
> The following aims to improve code generation for loops like
> those in tree-ssa-alias.c:
>
> auto_vec component_refs1;
> auto_vec component_refs2;
>
> /* Create the stack of handled components for REF1. */
> while (han
On Wed, Feb 12, 2014 at 04:28:14PM +0100, Richard Biener wrote:
> On Wed, Feb 12, 2014 at 4:21 PM, Trevor Saunders
> wrote:
> > On Wed, Feb 12, 2014 at 03:09:17PM +0100, Richard Biener wrote:
> >>
> >> The following aims to improve code generation for loops like
> >> those in tree-ssa-alias.c:
>
On Tue, Feb 4, 2014 at 8:44 AM, H.J. Lu wrote:
> Hi,
>
> Revision 206943 caused a regression on g++.dg/opt/pr52727.C, which wasn't
> caught by my automated tester since SSE2 and SSE math are enabled by
> default. This patch adds -march=i686 for ia32 when compiling
> g++.dg/opt/pr52727.C, which is
On Wed, Feb 12, 2014 at 6:45 AM, Teresa Johnson wrote:
> On Tue, Feb 11, 2014 at 6:13 PM, Xinliang David Li wrote:
>> On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson wrote:
>>> On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David Li
>>> wrote:
Why is call graph needed to determine whether to d
Hi all,
This is a simple patch which adds a space between base register and
offset during the address asm translation, making the output assembler
code format consistent for aarch64 target.
Is it Okay for stage-1?
Kind regards,
Renlin Li
gcc/ChangeLog:
2014-02-12 Renlin Li
* confi
On Wed, Feb 12, 2014 at 12:20 AM, Uros Bizjak wrote:
> On Tue, Feb 11, 2014 at 9:41 PM, H.J. Lu wrote:
>
>> HAVE_AS_GOTOFF_IN_DATA defines a 32-bit assembler feature, we need to
>> pass --32 to assembler. Otherwise, we get the wrong result on x86-64.
>> We already pass --32 to assembl
On Thu, Aug 22, 2013 at 05:27:54AM -0500, Gabriel Dos Reis wrote:
> * error.c (init_error): Remove calls to pp_construct and
> pp_cxx_pretty_printer_init. Initialize cxx_pp with placement-new.
> * cxx-pretty-print.h (cxx_pretty_printer::cxx_pretty_printer): Declare.
> (cxx_
On 12/02/14 15:18, Marcus Shawcroft wrote:
On 3 February 2014 10:02, Renlin Li wrote:
2014-02-03 Renlin Li
* gcc.target/aarch64/aapcs64/validate_memory.h: move f32in64 and
i32in128 cases
outside special big-endian processing block.
This is a test case fix. This is ok with me b
On Mon, Feb 10, 2014 at 8:33 PM, Alan Modra wrote:
> On Mon, Feb 10, 2014 at 07:01:03PM -0500, David Edelsohn wrote:
>> On Mon, Feb 10, 2014 at 5:18 PM, Alan Modra wrote:
>>
>> Shouldn't addr_op2 also be set from find_replacement?
>
> Sorry, I thought after I sent the email that I should have add
Hi!
On Tue, Feb 11, 2014 at 09:43:52PM +0100, Jan Hubicka wrote:
> *** record_targets_from_bases (tree otr_type
> *** 1286,1292
> HOST_WIDE_INT otr_token,
> tree outer_type,
> HOST_WIDE_INT offset,
> !
> > > More importantly, what is retval.1? I'd expect you should be using
> > > retval.0 there and have it also as firstprivate(retval.0) on the parallel.
> > > In *.omplower dump I actually see:
> > > retval.0 = operator- (D.2885, &i); ...
> > > retval.1 = opera
On Wed, Feb 12, 2014 at 05:04:38PM +, Iyer, Balaji V wrote:
> I looked at the test code you send me (cf3.cc) at -O1 and it is removing
> all the lines you have shown above. Yes, I would imagine -O0 to have code
> that can be redundant or unnecessary. Some of it could be the artifact of
> inte
Hi,
On Tue, Feb 11, 2014 at 02:17:04PM +0100, Richard Biener wrote:
> Hmm. The intent was of course to only allow truly no-op converts via
> VIEW_CONVERT_EXPR - that is, the size of the operand type and the
> result type should be the same. So, isn't SRA doing it wrong when
> creating the VIEW_C
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, February 12, 2014 12:10 PM
> To: Iyer, Balaji V
> Cc: 'Jason Merrill'; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
> 'r...@redhat.com'
> Subject: Re: [PING] [PATCH] _Cilk_for for C and C++
David Edelsohn wrote:
> On Mon, Feb 10, 2014 at 8:33 PM, Alan Modra wrote:
> > On Mon, Feb 10, 2014 at 07:01:03PM -0500, David Edelsohn wrote:
> >> On Mon, Feb 10, 2014 at 5:18 PM, Alan Modra wrote:
> >>
> >> Shouldn't addr_op2 also be set from find_replacement?
> >
> > Sorry, I thought after I s
> I am not sure how to deal with this, given that we have mismatched
> V_C_Es anyway, I'm inclined not to care and let the expander deal with
> it. But at the same I understand that it is ugly and will certainly
> cause somebody more headache in the future. I suppose that not
> scalarizing here m
On 12 February 2014 07:27:59 Jan Hubicka wrote:
> On 02/11/2014 07:54 PM, Jan Hubicka wrote:
> >+/* Allow combining RTTI and non-RTTI is OK. */
> You mean combining -frtti and -fno-rtti compiles? Yes, that's fine,
> though you need to prefer the -frtti version in case code from that
>
In resolving a recent x86_64 libitm build problem found while trunk merging, I
discovered that fold_builtin_memory_op grabs an int whose size is based upon
the size of a complex long double, which is 256 bits, and then during type
hashing (where it calls type_hash_canon), it wants to check to s
On Wed, Feb 12, 2014 at 8:02 AM, Teresa Johnson wrote:
> On Wed, Feb 12, 2014 at 6:45 AM, Teresa Johnson wrote:
>> On Tue, Feb 11, 2014 at 6:13 PM, Xinliang David Li
>> wrote:
>>> On Tue, Feb 11, 2014 at 5:36 PM, Teresa Johnson
>>> wrote:
On Tue, Feb 11, 2014 at 5:16 PM, Xinliang David L
Hi!
With -O1 -m32 -mpreferred-stack-boundary=2 -msseregparm -msse
the following testcase ICEs, because the stack realignment code isn't aware
of the DFmode value that possibly needs spilling (on i?86/x86_64 the cost
code is saying that extending load from SFmode memory into DFmode constant
is for
Hi!
gen_subprogram_die is often called more than once for the same decl
(e.g. the first time through force_decl_die etc.), but it always
unconditionally calls add_calling_convention_attribute which thus
may add the attributes several times.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
Problem: A common use care for OMP is to accelerate the internal
workings of an otherwise serial interface. For example, OpenBLAS in
some settings will internally use OMP to accelerate the implementation
of matrix-matrix multiply (DGEMM). When DGEMM is called, then an OMP
section is started, the wo
> gen_subprogram_die is often called more than once for the same decl
> (e.g. the first time through force_decl_die etc.), but it always
> unconditionally calls add_calling_convention_attribute which thus
> may add the attributes several times.
>
> Fixed thusly, bootstrapped/regtested on x86_64-lin
This hunk of code disabling auto increment instructions can be removed
on
the trunk now that PR middle-end/56791 is fixed there.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2014-02-12 John David Anglin
On Wed, Feb 12, 2014 at 11:34:16AM +, Richard Sandiford wrote:
> Dominik Vogt writes:
> > diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
> > index 32a25a4..9ae8ffd 100644
> > --- a/gcc/config/s390/s390.c
> > +++ b/gcc/config/s390/s390.c
> > @@ -5510,9 +5510,8 @@ s390_asm_output_f
On Wed, Feb 12, 2014 at 11:30:30AM +0100, Dominik Vogt wrote:
> On Wed, Feb 12, 2014 at 11:28:38AM +0100, Dominik Vogt wrote:
> > The attached patch fixes a crash if gfortran encounters a nested
> > function when -mhotpatch is enabled. (It slightly improves the
> > warning message too.)
> >
> > T
This patch adds a s390 specific test that verifies that
hotpatching of nested functions is not supported and generates a
warning.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
>From ae383db14eb5a9035603e7c80126470389ea8029 Mon Sep 17 00:00:00 2001
From: Dominik Vogt
Date: Thu, 13 Feb 2014
73 matches
Mail list logo
