> 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
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
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
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
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
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 (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
===
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
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
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, 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
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: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
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 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
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 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
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 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
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..
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
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
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
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
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, 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
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
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
> 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
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 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
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
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!
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
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
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: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: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: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
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
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
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
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
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
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
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
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
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
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
49 matches
Mail list logo
