Which requires int mult for vectorization.
Committed.
Richard.
2015-05-06 Richard Biener
PR tree-optimization/62283
* gcc.dg/vect/bb-slp-14.c: Adjust.
Index: gcc/testsuite/gcc.dg/vect/bb-slp-14.c
===
--- gcc/te
On Tue, May 05, 2015 at 06:12:50PM -0700, Mike Stump wrote:
> On Apr 26, 2015, at 10:55 PM, tbsaunde+...@tbsaunde.org wrote:
> > From: Trevor Saunders
> >
> > gcc/ChangeLog:
> >
> > 2015-04-27 Trevor Saunders
> >
> > * bb-reorder.c (HAVE_return): Don't check if its undefined.
> > * d
On Mon, May 04, 2015 at 11:42:20AM -0600, Jeff Law wrote:
> On 05/04/2015 11:39 AM, Jakub Jelinek wrote:
> >On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote:
> >>On 05/04/2015 10:37 AM, Alexander Monakov wrote:
> >>>This patch introduces option -fno-plt that allows to expand calls that
> >
C++11 changed destructors to be noexcept by default; as a result, code
with throwing destructors that works in C++98 immediately calls
terminate in C++11. When testing changing the default for cxx_dialect
to C++11 I noticed that this was causing one of the tests to fail, and
decided to add a w
These patches fix several issues I found by switching the C++ dialect
default to C++11.
The first patch fixes obj-c++.dg/encode-10.mm: When
build_non_dependent_expr tries to get a constant value for a
non-dependent expression, we need to know that AT_ENCODE_EXPR can't be a
constant expression
On 05/05/15 16:17, James Greenhalgh wrote:
> On Sat, Apr 25, 2015 at 12:26:16AM +0100, Kugan wrote:
>>
>> Thanks for the review. I have updated the patch based on the comments
>> with some other minor changes. Bootstrapped and regression tested on
>> aarch64-none-linux-gnu with no-new regressions
A variable template or partial specialization trying to refer to the
template in its initializer got confused because name lookup found the
VAR_DECL rather than the template. Fixed by avoiding pushing the VAR_DECL.
Tested x86_64-pc-linux-gnu, applying to trunk and 5.
commit fb2e3bd25d2b8ce5cde
I went to draft standardese for DR 1518 this week and realized that it
had already been resolved by DR 1630, which clarified that
default-initialization can call explicit default constructors even in
the context of copy-list-initialization. So this patch adjusts my
earlier approximation to ref
On Apr 26, 2015, at 10:55 PM, tbsaunde+...@tbsaunde.org wrote:
> From: Trevor Saunders
>
> gcc/ChangeLog:
>
> 2015-04-27 Trevor Saunders
>
> * bb-reorder.c (HAVE_return): Don't check if its undefined.
> * defaults.h (gen_simple_return): New function.
> (gen_simple_return):
On Apr 12, 2015, at 11:11 AM, Jack Howarth wrote:
> The attached patch is a back port of the change from
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=211067 for
> gcc-4_9-branch. Bootstrap and regression tested on
> x86_64-apple-darwin14 with Xcode 6.3. Okay for gcc-4_9-branch?
>
This patch contains the machine independent changes that I will need to add
IEEE 128-bit floating point to the GCC compiler for PowerPC.
It adds a new mode defintion macro: SPECIAL_FLOAT_MODE that is similar to
FLOAT_MODE. The difference is the conversion system will skip
SPECIAL_FLOAT_MODE types
Hi Nick,
On Tue, 5 May 2015, Nick Clifton wrote:
> I recently contributes a patch to enhance the MSP430 backend with the
> ability to automatically distribute code and data between high and low
> memory regions. Below is a patch to update the html documentation
> with a description of thi
I started working on this over the weekend, and then Jason
wondered about it yesterday, so I completed and committed the
following skeleton for the GCC 6 release notes yesterday.
Gerald
Index: gcc-6/changes.html
===
RCS file: gcc-6
On 05/05/2015 02:08 PM, Jason Merrill wrote:
On 05/04/2015 09:29 PM, Aldy Hernandez wrote:
The code handling parameter DIEs needed a little tweaking for variable
length template arguments. I've relaxed the original assert, but this
may require tweaking at branch review time-- hopefully later th
Hi,
per the audit trail, this issue appears to boil down to two separate issues:
- The warning doesn't appear universally useful, thus it would be nice
to give it a name in order to enable disabling it.
- As shown by the testcase, sometimes the wording is misleading: it
talks about 'anonymous n
On 05/04/2015 09:29 PM, Aldy Hernandez wrote:
The code handling parameter DIEs needed a little tweaking for variable
length template arguments. I've relaxed the original assert, but this
may require tweaking at branch review time-- hopefully later this week.
What testcase motivated this? We'r
This patch from Chris Manghane changes the Go frontend to not use
temporaries for constants when doing string concatenation. This fixes
http://golang.org/issue/10642. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and GCC 5 branch.
Ian
diff -r b2bef4b0764a
On Tue, May 5, 2015 at 8:10 PM, Richard Biener
wrote:
>>> I've checked spec2000 performance.
>>> Only few spec binaries differ. Anyway performance is unchanged.
>>
>>Thanks, that confirms expectations.
>
> Are changes in generated code expected at all?
The change by itself should have no effect
On Wed, 2015-04-29 at 14:10 +0200, Mikael Morin wrote:
> Hello,
>
> Le 29/04/2015 02:02, David Malcolm a écrit :
> > diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> > index 2c7c554..30e4eab 100644
> > --- a/gcc/fortran/parse.c
> > +++ b/gcc/fortran/parse.c
> > @@ -4283,7 +4283,7 @@ parse_
> OK to apply ?
Ok, but...
> - if (regno == FRAME_POINTER_REGNUM && frame_pointer_needed)
> + if (regno == FRAME_POINTER_REGNUM
> + && (frame_pointer_needed || df_regs_ever_live_p (regno)))
Do we want regs_ever_live or regs_ever_written_to ? I seem to recall
changing a port... mep per
On 05/05/2015 08:52 PM, Jakub Jelinek wrote:
> Hi!
>
> http://gcc.gnu.org/ml/gcc-patches/2015-04/msg01432.html
> - this got approved for arm and aarch64, but not for s390{,x}
> Ok for trunk?
Yes. Thanks!
-Andreas-
Hi!
http://gcc.gnu.org/ml/gcc-patches/2015-04/msg01432.html
- this got approved for arm and aarch64, but not for s390{,x}
Ok for trunk?
Jakub
On May 5, 2015 6:16:14 PM GMT+02:00, Uros Bizjak wrote:
>On Tue, May 5, 2015 at 2:23 PM, Evgeny Stupachenko
>wrote:
>
>> I've checked spec2000 performance.
>> Only few spec binaries differ. Anyway performance is unchanged.
>
>Thanks, that confirms expectations.
Are changes in generated code expe
gcc/java/ChangeLog:
* jcf-parse.c (set_source_filename): Replace write through
ORDINARY_MAP_FILE_NAME with direct access to "to_file".
libcpp/ChangeLog:
* include/line-map.h (MAP_START_LOCATION): Eliminate the non-const
variant, and tweak comment for the const varia
libcpp/ChangeLog:
* include/line-map.h (MAX_SOURCE_LOCATION): Convert from a macro
to a const source_location.
(RESERVED_LOCATION_COUNT): Likewise.
(linemap_check_ordinary): Convert from a macro to a pair of inline
functions, for const/non-const arguments.
---
libcpp/include/line-map.h | 71 ---
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h
index e1681ea..7001552 100644
--- a/libcpp/include/line-map.h
+++ b/libcpp/include/line-map.h
@@
On Mon, 2015-05-04 at 13:15 -0600, Jeff Law wrote:
On 05/01/2015 06:56 PM, David Malcolm wrote:
> > libcpp makes extensive use of the C preprocessor. Whilst this has a
> > pleasingly self-referential quality, I find the code hard-to-read;
> > implementing source location support in my JIT branch w
On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw
wrote:
>On 05/05/15 15:33, Richard Earnshaw wrote:
>> On 05/05/15 15:29, Jakub Jelinek wrote:
>>> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
On 05/05/15 14:06, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 02:0
This patch I posted last fall:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00711.html
still has not been reviewed, in spite of me pinging it several times
before GCC 5 went into stage 4. Now that we're back in stage 1 again,
can somebody please take a look at it? I've just re-tested it on
On Tue, May 5, 2015 at 10:35 AM, Andreas Schwab wrote:
> Ian Lance Taylor writes:
>
>> Committed to mainline and 4.9 branch.
>
> What about the 5 branch?
Oh yeah. Thanks. Committing to GCC 5 branch shortly, after tests complete.
Ian
Hello!
> 2015-05-03 Sandra Loosemore
>
>gcc/
>* doc/extend.texi (Variable Attributes, Type Attributes): Move
>sections up in file, to immediately after the Function Attributes
>section.
You also need to update relevant @menu entry, otherwise you get
several warning like:
/hom
Ian Lance Taylor writes:
> Committed to mainline and 4.9 branch.
What about the 5 branch?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Running /usr/local/gcc/gcc-20150505/gcc/testsuite/gcc.dg/ipa/ipa.exp ...
PASS: gcc.dg/ipa/iinline-attr.c (test for excess errors)
PASS: gcc.dg/ipa/iinline-attr.c scan-ipa-dump inline "hooray[^\\n]*inline copy \
in test"
Running /usr/local/gcc/gcc-20150505/gcc/testsuite/gcc.target/ia6
On Tue, May 05, 2015 at 04:14:03PM +, Kumar, Venkataramanan wrote:
> Hi Segher,
>
> Thank you for testing the patch and approving it.
>
> Before I commit it, I wanted to check with you on the changelog entry.
>
> Please find the updated patch with the changelog entry.
> I have just removed
On Tue, May 05, 2015 at 06:58:08PM +0200, Uros Bizjak wrote:
> RMs, should this patch be backported to release branches?
I think so (4.9+, I think 4.8 doesn't have -mmemcpy-strategy=).
Jakub
Hello!
Attached patch fixes PR65990. rep_8byte is not a valid stringop
strategy for 32bit targets.
2015-05-05 Uros Bizjak
PR target/65990
* config/i386/i386.c (ix86_parse_stringop_strategy_string): Error out
if rep_8byte stringop strategy was specified for 32-bit target.
testsuit
The gc toolchain permits Func to be nil when calling the
runtime.Func.Name method, returning an empty string. This patch
changes libgo to do the same, rather than crashing. This is GCC PR
66016. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.9 branch.
On Tue, May 5, 2015 at 2:23 PM, Evgeny Stupachenko wrote:
> I've checked spec2000 performance.
> Only few spec binaries differ. Anyway performance is unchanged.
Thanks, that confirms expectations.
Patch committed.
Uros.
Hi Segher,
Thank you for testing the patch and approving it.
Before I commit it, I wanted to check with you on the changelog entry.
Please find the updated patch with the changelog entry.
I have just removed the comments that says checks for PLUS/MINUS RTX is a hack.
Let me know if it ok.
Hello build machinery maintainers,
following up
http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462
http://thread.gmane.org/gmane.comp.gcc.patches/332160
On 01/25/2015 08:42 PM, Jan-Benedict Glaw wrote:
> On Sun, 2015-01-04 20:20:40 +0100, Michael Haubenwallner
> wrote:
>> Updat
On Tue, 2015-05-05 at 14:19 +0200, Christian Bruel wrote:
> I don't the environment to run the testsuite for ia64. would you mind
> giving it a try and verify that it fixes the issue ?
I don't have ia64 hardware anymore.
The GCC compile farm advertises ia64 hardware
https://gcc.gnu.org/wiki/C
On 05/05/2015 07:18 AM, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 10:57:28AM +0200, Thomas Schwinge wrote:
>> --- gcc/c-family/c-common.c
>> +++ gcc/c-family/c-common.c
>> @@ -809,7 +809,7 @@ const struct attribute_spec c_common_attribute_table[] =
>>handle_omp_decl
Hi Gerald, Hi Joesph, Hi Sandra,
I recently contributes a patch to enhance the MSP430 backend with the
ability to automatically distribute code and data between high and low
memory regions. Below is a patch to update the html documentation
with a description of this new feature. Is it OK
On Wed, Apr 22, 2015 at 9:34 AM, H.J. Lu wrote:
> Normally, with PIE, GCC accesses globals that are extern to the module
> using GOT. This is two instructions, one to get the address of the global
> from GOT and the other to get the value. Examples:
>
> ---
> extern int a_glob;
> int
> main ()
>
Hi Guys,
I am applying the attached patch to add two new command line options
to the MSP430 backend. The -mcode-region= and -mdata-region= options
allow the user to specify whether functions and data should be placed
into low memory (below 64K) or high memory. This only applies to the
Hi DJ,
Below is a small patch to fix a small problem with the need_to_save()
function in the RL78 backend. It was only marking the frame pointer
register as needing a save if the frame pointer was in use. But since
the frame pointer is call-saved it needs to be saved any time it is
use
On 05/05/15 15:33, Richard Earnshaw wrote:
> On 05/05/15 15:29, Jakub Jelinek wrote:
>> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
>>> On 05/05/15 14:06, Jakub Jelinek wrote:
On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
> In a literal sense, yes.
On 05/05/15 15:29, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
>> On 05/05/15 14:06, Jakub Jelinek wrote:
>>> On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
In a literal sense, yes. However, even K&R & stdarg have standard
p
On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
> On 05/05/15 14:06, Jakub Jelinek wrote:
> > On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
> >> In a literal sense, yes. However, even K&R & stdarg have standard
> >> promotion and conversion rules (size < int =
On Tue, May 05, 2015 at 09:32:28AM +0200, Jakub Jelinek wrote:
> 2015-05-05 Jakub Jelinek
>
> PR target/65956
> * config/arm/arm.c (arm_needs_doubleword_align): For non-aggregate
> types check TYPE_ALIGN of TYPE_MAIN_VARIANT rather than type itself.
>
> * gcc.c-torture/
On 05/05/15 15:06, Richard Biener wrote:
> On May 5, 2015 2:49:55 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 13:46, Richard Earnshaw wrote:
>>> On 05/05/15 13:37, Richard Biener wrote:
On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
>> wrote:
> On 05/05/15 11:54, Richa
On Tue, May 05, 2015 at 10:57:28AM +0200, Thomas Schwinge wrote:
> --- gcc/c-family/c-common.c
> +++ gcc/c-family/c-common.c
> @@ -809,7 +809,7 @@ const struct attribute_spec c_common_attribute_table[] =
> handle_omp_declare_simd_attribute, false },
>{ "cilk simd fun
Hi!
On Tue, 5 May 2015 08:43:48 -0400, John David Anglin
wrote:
> On 2015-05-05 5:43 AM, Thomas Schwinge wrote:
> >> FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-62.c
> >> >-DACC_DEVICE_TYPE_hos
> >> >t=1 -DACC_MEM_SHARED=1 output pattern test, is , should match invalid size
> > With th
On May 5, 2015 2:49:55 PM GMT+02:00, Richard Earnshaw
wrote:
>On 05/05/15 13:46, Richard Earnshaw wrote:
>> On 05/05/15 13:37, Richard Biener wrote:
>>> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
> wrote:
On 05/05/15 11:54, Richard Earnshaw wrote:
> On 05/05/15 08:32, Jakub Je
On 05/05/15 14:06, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
>> In a literal sense, yes. However, even K&R & stdarg have standard
>> promotion and conversion rules (size < int => int, floats promoted to
>> double, etc). What are those rules for GCC's
Hi James，
Thanks for your comment.
Seems we need a 'dup' before 'fmul' if we use the GCC vector extension syntax
way.
Example:
dup v1.2s, v1.s[0]
fmulv0.2s, v1.2s, v0.2s
And we need another pattern to combine this two insns into 'fmul
%0.2s,%1.2s,%2.s[0]', which is kin
On Tue, May 5, 2015 at 3:03 PM, Ilya Tocar wrote:
>> >> +++ b/gcc/testsuite/gcc.target/i386/pr65915.c
>> >> @@ -0,0 +1,6 @@
>> >> +/* { dg-do run } */
>> >> +/* { dg-options "-O2 -mavx512f -fpic -mcmodel=medium" } */
>> >> +/* { dg-require-effective-target avx512f } */
>> >> +/* { dg-require-effec
On 2015-05-05 8:43 AM, John David Anglin wrote:
It would seem resolve_device returned 0.
dispatchers[acc_device_nvidia] is zero when resolve_device is called.
Dave
--
John David Anglin dave.ang...@bell.net
On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote:
> In a literal sense, yes. However, even K&R & stdarg have standard
> promotion and conversion rules (size < int => int, floats promoted to
> double, etc). What are those rules for GCC's overaligned types (ie
> where in the docs do
> >> +++ b/gcc/testsuite/gcc.target/i386/pr65915.c
> >> @@ -0,0 +1,6 @@
> >> +/* { dg-do run } */
> >> +/* { dg-options "-O2 -mavx512f -fpic -mcmodel=medium" } */
> >> +/* { dg-require-effective-target avx512f } */
> >> +/* { dg-require-effective-target lp64 } */
> >> +
> >> +#include "avx512f-vrnd
On 05/05/15 13:54, Jakub Jelinek wrote:
> On Tue, May 05, 2015 at 01:49:55PM +0100, Richard Earnshaw wrote:
>> The real question here is why is TYPE the type of the value, rather than
>> the type of the formal as expressed by the prototype (or implicit
>> prototype in the case of variadics or K&R)?
Le 05/05/2015 08:25, Thomas Koenig a écrit :
> Hello world,
>
> this is an update of the matmul inline patch. The only difference to
> the last version is that it has the ubound simplification taken out.
Sorry, I delayed this, but it wasn't (yet) forgotten.
Below a few answers to
https://gcc.gn
On Tue, May 05, 2015 at 01:49:55PM +0100, Richard Earnshaw wrote:
> The real question here is why is TYPE the type of the value, rather than
> the type of the formal as expressed by the prototype (or implicit
> prototype in the case of variadics or K&R)? Surely this is the mid-end
> passing the wr
On 05/05/15 13:46, Richard Earnshaw wrote:
> On 05/05/15 13:37, Richard Biener wrote:
>> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
>> wrote:
>>> On 05/05/15 11:54, Richard Earnshaw wrote:
On 05/05/15 08:32, Jakub Jelinek wrote:
> On Mon, May 04, 2015 at 05:00:11PM +0200, Jaku
Today I have received the news that the Copyright Assignment was
completed with the FSF.
On Thu, Apr 30, 2015 at 8:10 AM, Nuno Diegues wrote:
>
> > Patch looks good to me now. It would be perhaps nice to have an
> > environment variable to turn the adaptive algorithm off for tests,
> > but that'
On 05/05/15 13:37, Richard Biener wrote:
> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 11:54, Richard Earnshaw wrote:
>>> On 05/05/15 08:32, Jakub Jelinek wrote:
On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
> So at least changing arm_ne
On 05/05/15 13:37, Richard Biener wrote:
> On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
> wrote:
>> On 05/05/15 11:54, Richard Earnshaw wrote:
>>> On 05/05/15 08:32, Jakub Jelinek wrote:
On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
> So at least changing arm_ne
On 2015-05-05 5:43 AM, Thomas Schwinge wrote:
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-62.c
>-DACC_DEVICE_TYPE_hos
>t=1 -DACC_MEM_SHARED=1 output pattern test, is , should match invalid size
With this one I'll need your help: please cite from libgomp.log (or, from
a manual run) the
On 5 May 2015 at 12:07, Christian Bruel wrote:
> This fixes PR target/66015 and a latent issue revealed by
> gcc.dg/ipa/iinline-attr.c since
> https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01609.html
>
> Regtested on aarch64-linux-gnu by Linaro.
>
> OK for trunk ?
OK. Is this issue present in gc
On May 5, 2015 1:01:59 PM GMT+02:00, Richard Earnshaw
wrote:
>On 05/05/15 11:54, Richard Earnshaw wrote:
>> On 05/05/15 08:32, Jakub Jelinek wrote:
>>> On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
So at least changing arm_needs_doubleword_align for non-aggregates
>would
>>>
On Tue, May 05, 2015 at 12:01:59PM +0100, Richard Earnshaw wrote:
> > Either way, this would need careful cross-testing against an existing
> > compiler.
> >
>
> It looks as though either patch would cause ABI incompatibility for
>
> typedef int alignedint __attribute__((aligned((8;
>
> int
Hi HJ,
I've checked spec2000 performance.
Only few spec binaries differ. Anyway performance is unchanged.
Thanks,
Evgeny
On Thu, Apr 30, 2015 at 10:08 PM, H.J. Lu wrote:
> On Thu, Apr 30, 2015 at 12:01 PM, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch switches x86 to TARGET_SUPPORTS_WIDE_INT
Hi Jim, Steve, Andreas
Please find here a fix for the issue reported by Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835 for ia64.
same than x86 and aarch64.
I don't the environment to run the testsuite for ia64. would you mind
giving it a try and verify that it fixes the issue ?
many
Patch ping ...
>
> > On 04/02/2015 11:59 PM, Yangfei (Felix) wrote:
> > > Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01148.html
> >
> > This patch needs documentation for the new attributes and pragmas
> > before it can be committed. (Since this is a new feature I think it
> > ha
On 17 April 2015 at 16:41, Alan Lawrence wrote:
> This also makes the existing intrinsics tests apply to the new patterns.
>
> Tested on aarch64-none-elf.
>
> gcc/ChangeLog:
>
> * config/aarch64/arm_neon.h (vceq_s64, vceq_u64, vceqz_s64,
> vceqz_u64,
> vcge_s64, vcge_u64, vcgez_s64
On 17 April 2015 at 16:40, Alan Lawrence wrote:
> This just adds the necessary patterns used for comparisons of DImode
> vectors. Used as part of arm_neon.h, in next/final patch.
>
> Tested on aarch64-none-elf.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md
> (aarch64_vcond_intern
This fixes PR target/66015 and a latent issue revealed by
gcc.dg/ipa/iinline-attr.c since
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01609.html
Regtested on aarch64-linux-gnu by Linaro.
OK for trunk ?
Many thanks
Christian
2015-05-05 Christian Bruel
PR target/66015
* config/aarch64/aar
2015-04-21 8:52 GMT+03:00 Jeff Law :
> On 04/17/2015 02:34 AM, Ilya Enkovich wrote:
>>
>> On 15 Apr 14:07, Ilya Enkovich wrote:
>>>
>>> 2015-04-14 8:22 GMT+03:00 Jeff Law :
On 03/15/2015 02:30 PM, Richard Sandiford wrote:
>
>
> Ilya Enkovich writes:
>>
>>
>> This
Hello!
No functional changes.
2015-05-05 Uros Bizjak
* config/i386/i386.c: Use HOST_WIDE_INT_1 instead of (HOST_WIDE_INT) 1
and HOST_WIDE_INT_1U instead of (unsigned HOST_WIDE_INT) 1.
* config/i386/i386.md: Ditto.
* config/i386/winnt.c: Ditto.
Tested on x86_64-linux-gnu {,-m3
On 05/05/15 11:54, Richard Earnshaw wrote:
> On 05/05/15 08:32, Jakub Jelinek wrote:
>> On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
>>> So at least changing arm_needs_doubleword_align for non-aggregates would
>>> likely not break anything that hasn't been broken already and would
On 5 May 2015 at 11:00, Matthew Wahab wrote:
> 2015-05-05 Matthew Wahab
>
>
> * gcc/config/aarch64-protos.h (struct cpu_branch_cost): New.
> (tune_params): Add field branch_costs.
> (aarch64_branch_cost): Declare.
> * gcc/config/aarch64.c (generic_branch_cost):
On 05/05/15 08:32, Jakub Jelinek wrote:
> On Mon, May 04, 2015 at 05:00:11PM +0200, Jakub Jelinek wrote:
>> So at least changing arm_needs_doubleword_align for non-aggregates would
>> likely not break anything that hasn't been broken already and would unbreak
>> the majority of cases.
>
> Attached
On 05/05/15 09:22, Kyrill Tkachov wrote:
Hi all,
As the PR says, the movcond_addsi pattern takes the REGNO of an operand that
may be a CONST_INT.
The fix for that is rather simple (perhaps even obvious?).
Unfortunately the testcase is in ada, and I'm not sure how to integrate this
into the t
On 5 May 2015 at 10:58, Thomas Schwinge wrote:
> Hi!
+/* Node in the linked list used for storing !$oacc declare constructs. */
The clause is called $ACC declare, isn't it?
> + for (oc = new_oc; oc; oc = oc->next)
> +{
> + c = oc->clauses;
> + for (n = c->lists[OMP_LIST_MAP];
Thomas Schwinge wrote:
> In follow-up messages, I'll be posting the separated parts (for easier
> review) of a next set of OpenACC changes that we'd like to commit.
> ChangeLog updates not yet written; will do that before commit, obviously.
Still, it would have been nice if you had given an overvi
On 01/05/15 10:18, Marcus Shawcroft wrote:
On 21 April 2015 at 15:00, Matthew Wahab wrote:
+int aarch64_branch_cost (bool, bool);
+
You would never guess looking at this .h today, but long ago there was
something close to alphabetical order by function name in place.
Please lift this definitio
On May 5, 2015 11:15:11 AM GMT+02:00, Tom de Vries
wrote:
>Hi,
>
>after checking in the 'postpone expanding va_arg till pass_stdarg'
>patch series,
>some scans related to function f15 in gcc.dg/tree-ssa/stdarg-2.c have
>started
>failing.
>
>[ The committed patch series contained a modification
thanks for the validation and the confirmation that iinline-attr.c is
now fixed on aarch64. I can now send the patch for submission request
(this one was just illustrative).
thanks
Christian
On 05/05/2015 11:10 AM, Yvan Roux wrote:
> Hi Christian,
>
> On 4 May 2015 at 11:29, Christian Bruel wr
Hi!
On Mon, 4 May 2015 10:20:14 -0400, John David Anglin
wrote:
> On 2015-05-04 4:32 AM, Thomas Schwinge wrote:
> > Dave, would you please test the following patch, and report the
> > regression status compared to before r222620? (Compared to your existing
> > r222021 results, as posted in the
Alan Lawrence wrote:
Hi,
Comparing 64x1 vector types (defined by hand or from arm_neon.h) using GCC
vector extensions currently generates very poor assembly code, for example
"uint64x1_t foo (uint64x1_t a, uint64x1_t b) { return a >= b; }" generates (at -O3):
fmov x0, d0 // 22 movdi_aarch64/
Hi,
after checking in the 'postpone expanding va_arg till pass_stdarg' patch series,
some scans related to function f15 in gcc.dg/tree-ssa/stdarg-2.c have started
failing.
[ The committed patch series contained a modification of stdarg-2.c, but that
seems to be not complete and not correct.
Hi Christian,
On 4 May 2015 at 11:29, Christian Bruel wrote:
>
>> Hi Christian,
>> I noticed case gcc.dg/ipa/iinline-attr.c failed on aarch64. The
>> original patch is x86 specific, while the case is added as general
>> one. Could you please have a look at this?
>>
>> FAIL: gcc.dg/ipa/iinline-a
Hi Mikael, hi all,
Mikael, thanks for the review so far. I have inserted the changes requested and
updated this patch to trunk. For the e->expr_type == EXPR_FUNCTION I have
choose !DECL_P(parmse.expr) to not only prevent VAR_DECLs aliasing, but also
prevent aliasing for PARM_DECLs and similar.
Bo
Hi!
On Tue, 05 May 2015 10:54:02 +0200, I wrote:
> In follow-up messages, I'll be posting the separated parts (for easier
> review) of a next set of OpenACC changes that we'd like to commit.
> ChangeLog updates not yet written; will do that before commit, obviously.
gcc/fortran/dump-parse-tree.c
Hi!
On Tue, 05 May 2015 10:54:02 +0200, I wrote:
> In follow-up messages, I'll be posting the separated parts (for easier
> review) of a next set of OpenACC changes that we'd like to commit.
> ChangeLog updates not yet written; will do that before commit, obviously.
gcc/gimplify.c
Hi!
In follow-up messages, I'll be posting the separated parts (for easier
review) of a next set of OpenACC changes that we'd like to commit.
ChangeLog updates not yet written; will do that before commit, obviously.
Overall diffstat:
gcc/c-family/c-common.c|3 +-
On 4 May 2015 at 10:03, Chen Shanyao wrote:
> According to your opinion, I split the backports of pr64304 into 2 emails,
> and this one is for 4.8 branch.
> This patch backport the fix of PR target/64304 , miscompilation with
> -mgeneral-regs-only, to the 4.8 branch from trunk r219844. Tested on x
On 4 May 2015 at 10:13, Chen Shanyao wrote:
> According to your opinion, I split the backports of pr64304 into 2 emails,
> and this one is for 4.9 branch.
> This patch backport the fix of PR target/64304 , miscompilation with
> -mgeneral-regs-only, to the 4.9 branch from trunk r219844. Tested on x
Hi all,
As the PR says, the movcond_addsi pattern takes the REGNO of an operand that
may be a CONST_INT.
The fix for that is rather simple (perhaps even obvious?).
Unfortunately the testcase is in ada, and I'm not sure how to integrate this
into the testsuite.
Does anyone know how to add an ad
On 04/05/15 10:14, Yvan Roux wrote:
Hi,
This patch fixes two ARM testcases that require target to be Thumb2
effective. One is built for Cortex-m3, the purpose of the second one
is to generate thumb2_addsi3_compare0_scratch insn and both are
failing when compiled for armv5t for instance.
Built
1 - 100 of 105 matches
Mail list logo
