gcc/ChangeLog:
2017-03-09 Andreas Krebbel
* config/s390/vx-builtins.md ("vfee", "vfeez")
("vfenez"): Add missing constraints.
---
gcc/config/s390/vx-builtins.md | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/gcc/config/s390/vx-builtins.m
Hi James,
Thanks for the review and your comments.
>> I'd need more detail on what types of instruction pairs you
>> are trying to fuse.
The documentation mentions it as follows:-
Single uop ALU instruction may fuse with adjacent branch instruction in the
same bundle
>> This comment looks inc
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-7.1-b20170226.de.po', h
In this testcase, ctx->object was the array subobject and 'this'
refers to the containing object, so we failed. Fixed by generalizing
PLACEHOLDER_EXPR handling more (in a way that replace_placeholders_r
already handles).
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a383ab56e2ea367509255f
OK.
On Wed, Mar 8, 2017 at 6:00 PM, Marek Polacek wrote:
> We crash on an assert in strip_typedefs, because we find ourselves in a
> scenario where RESULT, the main variant of a struct, was modified in
> finalize_record_size (its TYPE_ALIGN changed), but its variants (T in
> strip_typedefs) weren
On Thu, Mar 09, 2017 at 12:02:17AM +0100, Marek Polacek wrote:
> Ping.
>
> On Wed, Mar 01, 2017 at 08:09:05PM +0100, Marek Polacek wrote:
> > The following testcase ICEd with -Wduplicated-branches and -fopenmp
> > because we tried to has omp_parallel expression that contained some
> > TREE_VECs, b
Ping.
On Wed, Mar 01, 2017 at 08:09:05PM +0100, Marek Polacek wrote:
> The following testcase ICEd with -Wduplicated-branches and -fopenmp
> because we tried to has omp_parallel expression that contained some
> TREE_VECs, but those aren't handled in inchash::add_expr. Handling
> that is easy and
We crash on an assert in strip_typedefs, because we find ourselves in a
scenario where RESULT, the main variant of a struct, was modified in
finalize_record_size (its TYPE_ALIGN changed), but its variants (T in
strip_typedefs) weren't fixed-up yet; that will happen slightly later in
finalize_type_s
Hi,
On 5 March 2017 at 12:41, Andre Vehreschild wrote:
> Hi Jerry,
>
> thanks for seconding my read of the standard and reviewing so quickly.
> Committed as r245900.
>
I've noticed that the new test:
gfortran.dg/coarray/fail_image_2.f08 -fcoarray=single -O2 -latomic
execution test
fails on arm
The following patch fixes an "insn does not match its constraints" ICE
that occurred when copying a VR reg to a GPR when -mno-upper-regs-df is
in effect. The regclass used for the wi/wj constraints was being
incorrectly based on TARGET_UPPER_REGS_DF instead of
TARGET_UPPER_REGS_DI. This patch fixes
On Mon, Mar 06, 2017 at 05:09:44AM +, Hurugalawadi, Naveen wrote:
> Hi,
>
> Please find attached the patch that adds "neon_pairwise_add" &
> "neon_pairwise_add_qcrypto_pmull" for AArch64.
>
> The patch doesn't change spec but improve other benchmarks.
>
> Bootstrapped and Regression tested
On Mon, Mar 06, 2017 at 05:10:10AM +, Hurugalawadi, Naveen wrote:
> Hi,
>
> Please find attached the patch that implements alu_branch fusion
> for AArch64.
> The patch doesn't change spec but improve other benchmarks.
>
> Bootstrapped and Regression tested on aarch64-thunder-linux.
> Please r
On Mon, Mar 06, 2017 at 05:10:04AM +, Hurugalawadi, Naveen wrote:
> Hi,
>
> Please find attached the patch that adds crc reservations for Thunderx2t99.
>
> Bootstrapped and Regression tested on aarch64-thunder-linux.
> Please review the patch and let us know if its okay for Stage-1?
OK for S
On Mon, Mar 06, 2017 at 05:09:58AM +, Hurugalawadi, Naveen wrote:
> Hi,
>
> Please find attached the patch that adds aes and sha reservations for
> Thunderx2t99.
>
> Bootstrapped and Regression tested on aarch64-thunder-linux.
> Please review the patch and let us know if its okay for Stage-1?
On Mon, Mar 06, 2017 at 05:09:51AM +, Hurugalawadi, Naveen wrote:
> Hi,
>
> Please find attached the patch that fixes type for 1-element load in AArch64.
>
> Bootstrapped and Regression tested on aarch64-thunder-linux.
> Please review the patch and let us know if its okay for Stage-1?
>
> Th
Hi!
As reported, we were using often completely bogus access sizes for
atomic builtins, where the access size should be determined purely by their
_{1,2,4,8,16} suffix, not by whatever type the passed pointer points to,
pointer conversions are useless.
Bootstrapped/regtested on x86_64-linux and i
Hi!
We split OMP_TASKLOOP into 3 constructs, two GIMPLE_OMP_FOR
with GIMPLE_OMP_PARALLEL sandwiched in between them, so that
it is possible to compute number of iterations etc. before calling
GOMP_taskloop*. Using the original iterator in the outer gfor
doesn't play very well if the taskloop regi
Hi all,
For the testcase in this patch where the value of x is zero we currently
generate:
foo:
mov w1, 4
.L2:
ldaxr w2, [x0]
cmp w2, 0
bne .L3
stxrw3, w1, [x0]
cbnzw3, .L2
.L3:
csetw0, eq
ret
We currently
On 08/03/17 15:51, Bill Schmidt wrote:
On Mar 6, 2017, at 6:55 AM, Jakub Jelinek wrote:
Nice. So just arm, aarch64 and rs6000 to go.
Proposed patch for rs6000 is here:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00372.html.
arm patch is here https://gcc.gnu.org/ml/gcc-patches/2017-03/m
On 03/08/2017 03:12 AM, Richard Biener wrote:
The following avoids warning about completely out-of-bound accesses
as uninitialized.
For GCC8 we likely want to enhance path isolation to catch those
cases (and eventually issue a diagnostic about them). And we
finally want to fix complete peeling
> On Mar 6, 2017, at 6:55 AM, Jakub Jelinek wrote:
>
> Nice. So just arm, aarch64 and rs6000 to go.
Proposed patch for rs6000 is here:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00372.html.
Thanks,
Bill
Hi,
As noted by Jakub in https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00183.html,
the PowerPC back end incorrectly uses vec_select with 2 elements for a mode
that has only one. This is due to faulty mode iterator use: V1TImode was
wrongly included in the VSX_LE mode iterator, but should instead
Hi Toma,
> g++.dg/lto/pr69589_0.C is currently failing for mips-mti-elf with the
> following error:
>
> xg++: error: unrecognized command line option '-rdynamic'
>
> However, it passes just fine for mips-mti-linux-gnu.
> I think that we should skip this test for mips-mti-elf.
could it be that mi
On Wed, Mar 8, 2017 at 4:55 AM, Sam Thursfield
wrote:
>
> Thanks a lot for reviewing the patch. I've attached a new version with some
> comments below.
>
> On 08/03/17 04:03, Ian Lance Taylor via gcc-patches wrote:
>>
>> Thanks. The patch submission is fine but 1) you didn't see which
>> version
On 03/08/2017 08:29 AM, Mark Wielaard wrote:
On Wed, 2017-03-08 at 08:22 -0500, Nathan Sidwell wrote:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00089.html?
Patch looks good to me (not a libiberty maintainer)
One question:
+ if (dc == NULL || dc->d_printing > 1)
Can dc ever be null here,
On Wed, 2017-03-08 at 08:22 -0500, Nathan Sidwell wrote:
> https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00089.html?
>
> Patch looks good to me (not a libiberty maintainer)
>
> One question:
> + if (dc == NULL || dc->d_printing > 1)
>
> Can dc ever be null here, or is this just extra defensiven
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00089.html?
Patch looks good to me (not a libiberty maintainer)
One question:
+ if (dc == NULL || dc->d_printing > 1)
Can dc ever be null here, or is this just extra defensiveness?
nathan
--
Nathan Sidwell
b = static_cast(__builtin_alloca (a)); // { dg-warning
> > "argument to .alloca. may be too large" }
>
> FAIL: g++.dg/Walloca1.C -std=gnu++11 (test for warnings, line 6)
> FAIL: g++.dg/Walloca1.C -std=gnu++11 (test for excess errors)
> Excess errors:
> /daten/ar
Hi Ian
Thanks a lot for reviewing the patch. I've attached a new version with
some comments below.
On 08/03/17 04:03, Ian Lance Taylor via gcc-patches wrote:
Thanks. The patch submission is fine but 1) you didn't see which
version of GCC you are using; 2) I don't understand why it works. If
1.C -std=gnu++11 (test for warnings, line 6)
FAIL: g++.dg/Walloca1.C -std=gnu++11 (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20170308/gcc/testsuite/g++.dg/Walloca1.C:6:48: warning:
unbounded use of 'alloca' [-Walloca-larger-than=]
Andreas.
--
Andreas Schwab, sch..
On Wed, Mar 8, 2017 at 11:53 AM, Andrew Haley wrote:
> Loop splitting is fine when the control variable is of integer type,
> but when it is a pointer type the upper bound of the new loop is
> calculated incorrectly.
> The calculation should be guard_init + (end-beg), but instead we do
> guard_ini
On Tue, Mar 7, 2017 at 5:07 PM, Martin Liška wrote:
> On 03/07/2017 03:57 PM, Richard Biener wrote:
>> On Thu, Mar 2, 2017 at 6:06 PM, marxin wrote:
>>> gcc/ChangeLog:
>>>
>>> 2017-03-06 Martin Liska
>>>
>>> PR ipa/79761
>>> * tree-chkp.c (chkp_get_bound_for_parm): Get bounds f
On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška wrote:
> On 03/07/2017 03:53 PM, Richard Biener wrote:
>> On Tue, Mar 7, 2017 at 3:48 PM, Martin Liška wrote:
>>> On 03/07/2017 11:17 AM, Rainer Orth wrote:
marxin writes:
> diff --git a/gcc/testsuite/g++.dg/pr79769.C
> b/gcc/testsu
Loop splitting is fine when the control variable is of integer type,
but when it is a pointer type the upper bound of the new loop is
calculated incorrectly.
The calculation should be guard_init + (end-beg), but instead we do
guard_init - (end-beg).
Fixed thusly. Bootstrapped, regtested.
OK?
An
On Wed, Mar 8, 2017 at 12:58 AM, Alexandre Oliva wrote:
> Don't let pointer randomization change the order in which we process
> store chains. This may cause SSA_NAMEs to be released in different
> order, and if they're reused later, they may cause differences in SSA
> partitioning, leading to di
Hi all,
This patch fixes the NEON patterns with Jakub's genrecog verification
improvements:
../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select
HImode and its operand QImode
../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select
SImode and its o
On Wed, Mar 08, 2017 at 11:12:47AM +0100, Richard Biener wrote:
>
> The following avoids warning about completely out-of-bound accesses
> as uninitialized.
>
> For GCC8 we likely want to enhance path isolation to catch those
> cases (and eventually issue a diagnostic about them). And we
> finall
The following avoids warning about completely out-of-bound accesses
as uninitialized.
For GCC8 we likely want to enhance path isolation to catch those
cases (and eventually issue a diagnostic about them). And we
finally want to fix complete peeling to not introduce those
accesses.
Bootstrap and
On Wed, Mar 08, 2017 at 11:06:38AM +0100, Jakub Jelinek wrote:
> On Wed, Mar 08, 2017 at 11:03:53AM +0100, Richard Biener wrote:
> > On Wed, 8 Mar 2017, Jakub Jelinek wrote:
> >
> > > On Wed, Mar 08, 2017 at 09:15:05AM +0100, Richard Biener wrote:
> > > > Ok. Note that another option for the loop
On Wed, Mar 08, 2017 at 11:03:53AM +0100, Richard Biener wrote:
> On Wed, 8 Mar 2017, Jakub Jelinek wrote:
>
> > On Wed, Mar 08, 2017 at 09:15:05AM +0100, Richard Biener wrote:
> > > Ok. Note that another option for the loopy case is to do
> > >
> > > for (;;)
> > > {
> > > vec >> by
On Wed, 8 Mar 2017, Jakub Jelinek wrote:
> On Wed, Mar 08, 2017 at 09:15:05AM +0100, Richard Biener wrote:
> > Ok. Note that another option for the loopy case is to do
> >
> > for (;;)
> > {
> > vec >> by-one-elt;
> > elt = BIT_FIELD_REF ;
> > }
>
> Indeed, that is a possi
Hi,
I got some review comment from Bernhard Reutner-Fischer, and I have
updated the patch accordingly.
This patch is for bug opened
here:https://sourceware.org/bugzilla/show_bug.cgi?id=21187
Please find the attachment below.
Thanks and Regards,
Nitish K Mishra.
diff --git a/configure.ac b/config
This (apparently) fixes the build of the runtime on RTEMS.
Tested on x86-64/Linux, applied on mainline and 6 branch.
2017-03-08 Thanassis Tsiodras
PR ada/79903
* socket.c (__gnat_gethostbyaddr): Add missing test for __rtems__.
--
Eric BotcazouIndex: socket.c
===
On Wed, Mar 08, 2017 at 09:15:05AM +0100, Richard Biener wrote:
> Ok. Note that another option for the loopy case is to do
>
> for (;;)
> {
> vec >> by-one-elt;
> elt = BIT_FIELD_REF ;
> }
Indeed, that is a possibility, but I guess I'd need to construct
the result similarly
This adjusts the declaration of Default_Bit_Order for PowerPC/Linux to handle
the new little-endian variant. And, on mainline only, this merges system.ads
files for the big-endian & little-endian variants of ARM/Linux and MIPS/Linux,
since their only difference is precisely the Default_Bit_Orde
Hi!
Richard reported that after my PR79345 r245833 fix avr no longer builds:
../../gcc/config/avr/avr.md:1060:1: define_expand for setmemhi needs to have
match_scratch numbers above all other operands
The following patch ought to fix that, committed as obvious to trunk.
2017-03-08 Jakub Jelinek
The following fixes a bug in vect_transform_slp_perm_load which tries
to be clever in computing sth like "ncopies" but fails to do that
correctly (and in fact it can't be done). Instead just compute all
loads/permutations manually.
The fix is as simple as
Index: tree-vect-slp.c
On Tue, 7 Mar 2017, Jakub Jelinek wrote:
> Hi!
>
> If any of the operands of the UBSAN_{ADD,SUB,MUL}_OVERFLOW ifn with
> vector operand is a uniform vector, expanding it as VCE on the VECTOR_CST
> followed by ARRAY_REF with variable index in the loop is unnecessarily
> expensive and nothing fixes
> I prepared quite obvious fix for that and tested make check -k
> RUNTESTFLAGS="dg.exp=dump-ada-spec-*" on x86_64-linux-gnu.
Thanks for spotting and fixing it. Please put the fix on the 6 branch too.
--
Eric Botcazou
49 matches
Mail list logo
