Please find attached a patch to fix PR95981. Original patch by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_find_array_ref(): No ref found PR95981
When looking for an array reference allow NULL references. If
no array reference is found dim_rank_check should
Hi,
the GIMPLE store merging pass doesn't merge STRING_CSTs in the general case,
although they are accepted by native_encode_expr; the reason is that the pass
only works with integral modes, i.e. with chunks whose size is a power of two.
There are two possible ways of extending it to handle STR
Please find attached a patch which is a fix for PR95612. The original
patch is by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_check_pointer_assign PR95612
Output an error if the right hand value is a zero sized array or
does not have a symbol tree otherwise
The change to C++-17 broke PA bootstrap as pa.c uses the "register" keyword.
This patch drops the keyword and should hopefully restore bootstrapping. It'll
take a day or so to verify.
Committed to the trunk,
Jeff
commit a580aca1b6dad32e621d4c8c8ceaab6d0c52f6c1
Author: Jeff Law
Date: Tue Jun
> On Tue, Jun 30, 2020 at 1:31 PM yangyang (ET)
> wrote:
> >
> > > On Tue, Jun 30, 2020 at 4:29 AM yangyang (ET)
> > >
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > > Hi,
> > > > > >
> > > > > > This is a simple fix for pr95855.
> > > > > >
> > > > > > With this fix, pass_split_paths
Committed with coding style fixing.
On Wed, Jul 1, 2020 at 11:16 AM Kito Cheng wrote:
>
> Hi Jim:
>
> > This isn't a criticism of your patch, but I noticed while looking at
> > this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd
> > are all numbered independently. It doesn't m
Hi Jim:
> This isn't a criticism of your patch, but I noticed while looking at
> this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd
> are all numbered independently. It doesn't make much sense to specify
> a version with g and assume it is correct for all of imafd. Similarly
Hi!
On Tue, Jun 30, 2020 at 01:58:50AM -0400, Michael Meissner wrote:
> On Mon, Jun 29, 2020 at 01:42:56PM -0500, Segher Boessenkool wrote:
> > On Mon, Jun 29, 2020 at 02:23:22PM -0400, Michael Meissner wrote:
> > > +/* { dg-options "-O2 -mdejagnu-cpu=power10" } */
> > > +
> > > +/* Test that PLI
An enhancement to GCC 10 to improve the expansion of strncmp
calls with strings with embedded nuls introduced a regression
in similar calls to memcmp. A review of the changes that led
up to the regression exposed a number of questionable choices
that likely conspired to cause the bug.
For exampl
On 30/06/20 17:25 -0600, Martin Sebor via Libstdc++ wrote:
In testing a recent change to -Wnonnull, including the wording
of the warning, I overlooked failures in a number of tests,
including a few in libstdc++. Attached is a patch that makes
adjustments to let them pass again.
OK for master,
Hi!
On Tue, Jun 30, 2020 at 12:57:45PM -0500, will schmidt wrote:
> Add support for the vmsumudm instruction and tie it into the vec_msum
> built-in to support the variants of that built-in using vector
> _int128 parameters.
> 2020-06-18 Will Schmidt
>
> * config/rs6000/altivec.h
Hi!
On Tue, Jun 30, 2020 at 04:39:03PM -0500, will schmidt wrote:
> On Tue, 2020-06-30 at 12:57 -0500, will schmidt via Gcc-patches wrote:
> > vector _uint128_t vec_msum (vector unsigned long long,
> > vector unsigned long long,
> > vec
On Mon, Jun 29, 2020 at 7:00 PM Kito Cheng wrote:
> - Arch version should preserved if user explicitly specified the version.
> e.g.
> After normalize, -march=rv32if3d should be -march=rv32i_f3p0d
> instead of-march=rv32ifd.
This looks good to me.
> +explicit_version_p(false)
I'd
On Mon, Jun 29, 2020 at 7:35 PM Kito Cheng wrote:
> * config/riscv/multilib-generator (arch_canonicalize): Handle
> multi-letter extension.
> Using underline as separator between different extensions.
This looks good to me.
> + # Multi-letter extension must in lexicograp
This patch adds execution tests that use the MMA builtins,
checks for the right answer, and checks that __builtin_cpu_supports
and __builtin_cpu_is return sane answers given that the code
executed correctly.
Tested against P10 sim, should not execute anywhere else due to
requiring power10_hw. Act
Committed as obvious to master.
Will backport as seems fit.
Thanks,
Harald
PR fortran/88379 - ICE with allocatable coarray, class and associate
Catch NULL pointer dereference for ASSOCIATE on allocatable coarray variable.
gcc/fortran/
PR fortran/88379
* resolve.c (resolve_asso
OK,
so here is an updated version, which includes the updated test cases.
Anything else? OK for trunk?
(And will I "see" anybody at the Fortran Conference ? )
Best regards
Thomas
Test global identifiers against what is specified interfaces.
Apart from calling gfc_compare_interfaces
On Tue, 2020-06-30 at 12:57 -0500, will schmidt via Gcc-patches wrote:
> Hi,
>
> Add support for the vmsumudm instruction and tie it into the
> vec_msum
> built-in to support the variants of that built-in using vector
> _int128 parameters.
>
> vector _uint128_t vec_msum (vector unsigned lo
Hi
Any feedback regarding this patch ?
François
On 17/01/20 6:27 pm, François Dumont wrote:
On 1/17/20 11:01 AM, Jonathan Wakely wrote:
On 20/05/19 07:39 +0200, François Dumont wrote:
Hi
std::deque is supposed to be like a double-queue that you can
attack from front and back. But currre
Hi,
Thanks for the patch.
Omar Tahir writes:
> Hi,
>
> The variables first_moveable_pseudo and last_moveable_pseudo aren't reset
> after compiling a function, which means they leak into the first scheduler
> pass of the following function. In some cases, this can cause an extra spill
> during re
"Kewen.Lin" writes:
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 06a04e3d7dd..284c15705ea 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -13389,6 +13389,13 @@ by the copy loop headers pass.
> @item vect-epilogues-nomask
> Enable loop epilogue vectorizatio
Hi Alexandre!
On 2020-06-22T11:32:46-0300, Alexandre Oliva wrote:
> Here's a consolidated patch, [...]
Another small issue here:
> --- /dev/null
> +++ b/gcc/testsuite/lib/scanoffload.exp
> +# Utility for scanning offloading dump output, used by libgomp.exp.
> +
> +# Format an offload dump suff
v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
This is the implementation of Jakub's suggestion: allow
__builtin_constant_p () after IPA, but fold it into 0. Smoke test
passed on s390x-redhat-linux, full regtest and bootstrap are running on
x86_64-redhat-linux.
---
Linux Ke
On 6/30/20 11:59 AM, David Edelsohn wrote:
Why did you mark PR96008 as a duplicate? The ICE is a duplicate, but
the wrong IL is a C++ FE bug.
They're both caused by the same problem: the -Wnonnull warning
is triggered by the C++ FE bug (assuming it is one) and the ICE
by the C++ pretty printer
Why did you mark PR96008 as a duplicate? The ICE is a duplicate, but
the wrong IL is a C++ FE bug.
Thanks, David
On Tue, Jun 30, 2020 at 1:45 PM Martin Sebor wrote:
>
> On 6/30/20 10:47 AM, David Edelsohn wrote:
> > Also, cpp1y/lambda-generic-69078-1.C elicits a similar, new warning:
> >
> > FA
Hi,
Add support for the vmsumudm instruction and tie it into the vec_msum
built-in to support the variants of that built-in using vector
_int128 parameters.
vector _uint128_t vec_msum (vector unsigned long long,
vector unsigned long long,
On the modules branch I need to expose an intermediate step of the
function cloning, but before that it'd be nice to rationalize the names
somewhat, now that we also use that API for copying the equality
operator. Jason's recent patch caused me some pain by altering the same
code. I can only
On 6/30/20 10:47 AM, David Edelsohn wrote:
Also, cpp1y/lambda-generic-69078-1.C elicits a similar, new warning:
FAIL: g++.dg/cpp1y/lambda-generic-69078-1.C -std=gnu++14 (test for
excess errors)
Excess errors:
g++.dg/cpp1y/lambda-generic-69078-1.C:23:13: warning: 'this' pointer
null [-Wnonnull]
On 6/30/20 10:22 AM, David Malcolm wrote:
On Tue, 2020-06-30 at 10:12 -0600, Martin Sebor wrote:
On 6/30/20 8:47 AM, David Edelsohn via Gcc-patches wrote:
The unexpected warning is
gcc/testsuite/g++.dg/analyzer/pr94028.C:28:21: warning: use of
possibly-NULL '' where non-null expected [CWE-690]
Hi,
The variables first_moveable_pseudo and last_moveable_pseudo aren't reset
after compiling a function, which means they leak into the first scheduler
pass of the following function. In some cases, this can cause an extra spill
during register allocation of the second function.
This patch fixes
Also, cpp1y/lambda-generic-69078-1.C elicits a similar, new warning:
FAIL: g++.dg/cpp1y/lambda-generic-69078-1.C -std=gnu++14 (test for
excess errors)
Excess errors:
g++.dg/cpp1y/lambda-generic-69078-1.C:23:13: warning: 'this' pointer
null [-Wnonnull]
Thanks, David
On Tue, Jun 30, 2020 at 12:23
gcc/testsuite/ChangeLog:
* g++.dg/analyzer/pr94028.C: Make operator new non-throwing so
that the compiler doesn't implicitly mark it as returning
non-null.
Fixes these:
FAIL: g++.dg/analyzer/pr94028.C -std=c++98 (test for excess errors)
FAIL: g++.dg/analyzer/pr94028.C -
Hi!
On 2020-06-22T11:32:46-0300, Alexandre Oliva wrote:
> Here's a consolidated patch, [...]
Again, many thanks for working through this, with Tobias' help.
> --- /dev/null
> +++ b/gcc/testsuite/lib/scanoffload.exp
> +# Utility for scanning offloading dump output, used by libgomp.exp.
;-) Yea
On 23/06/2020 5:51 pm, Jakub Jelinek wrote:
On Tue, Jun 23, 2020 at 06:44:26PM +0200, Thomas Schwinge wrote:
On 2020-06-15T21:28:12+0100, Kwok Cheung Yeung wrote:
This patch adds support on nvptx for __sync_val_compare_and_swap operations on
1- and 2-byte values.
Is this a thorough review th
On Tue, 2020-06-30 at 10:12 -0600, Martin Sebor wrote:
> On 6/30/20 8:47 AM, David Edelsohn via Gcc-patches wrote:
> > The unexpected warning is
> >
> > gcc/testsuite/g++.dg/analyzer/pr94028.C:28:21: warning: use of
> > possibly-NULL '' where non-null expected [CWE-690]
> > [-Wanalyzer-possible-nu
Hi!
On 2020-06-18T14:06:10+0200, Tobias Burnus wrote:
> On 6/18/20 12:39 PM, Alexandre Oliva wrote:
>>> and intelmic.
>> How does intelmic get into the picture?
>
> No idea – I just know that it counts as offloading platform,
> ENABLE_OFFLOAD is set for it (but not for has).
> I just wanted to me
On 6/30/20 8:47 AM, David Edelsohn via Gcc-patches wrote:
The unexpected warning is
gcc/testsuite/g++.dg/analyzer/pr94028.C:28:21: warning: use of
possibly-NULL '' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]
This is the same location as one of the existing "leak" warni
On 6/30/20 8:47 AM, David Edelsohn via Gcc-patches wrote:
The unexpected warning is
gcc/testsuite/g++.dg/analyzer/pr94028.C:28:21: warning: use of
possibly-NULL '' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]
This is the same location as one of the existing "leak" warni
Hi!
Many thanks, Alexandra and Tobias for working this out together!
On 2020-06-23T06:50:26-0300, Alexandre Oliva wrote:
> On Jun 9, 2020, Thomas Schwinge wrote:
>
>> Previously, for '-foffload=nvptx-none -foffload=-fdump-rtl-mach
>> -save-temps -o ./nvptx-merged-loop.exe', GCC produced the e
Hi Julian!
On 2019-12-17T22:03:47-0800, Julian Brown wrote:
> This part contains the libgomp runtime support for the GOMP_MAP_ATTACH and
> GOMP_MAP_DETACH mapping kinds (etc.), as introduced by the front-end
> patches following in this series.
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
>
Installed to master.
contrib/ChangeLog:
* gcc-changelog/git_repository.py: Support older releases of
GitPython when renamed_file was named renamed.
---
contrib/gcc-changelog/git_repository.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/gcc-ch
Hi
A recently add diagnostic has a trailing space which triggers a warning.
Fixed thus.
tested on x86_64-darwin, applied to master, will also apply to 10.2
thanks
Iain
gcc/cp/ChangeLog:
* coroutines.cc (morph_fn_to_coro): Remove trailing
space in a diagnostic.
---
gcc/cp/corout
There is some concern about clang's -fuse-ld=path
http://lists.llvm.org/pipermail/cfe-dev/2020-June/065710.html and use
of COMPILER_PATH vs PATH.
Shall we introduce another option like -fld-path=path (PATH is used,
COMPILER_PATH is not used)?
On Tue, Jun 30, 2020 at 6:04 AM Martin Liška wrote:
>
"Kewen.Lin" writes:
> Hi Richard,
>
> Thanks for the comments!
>
> on 2020/6/29 下午6:07, Richard Sandiford wrote:
>> Thanks for the update. I agree with the summary of the IRC discussion
>> except for…
>>
>> "Kewen.Lin" writes:
>>> Hi Richard S./Richi/Jim/Segher,
>>>
>>> Thanks a lot for your co
Hu Jiangping writes:
> Hi,
>
> this patch fix a typo in contribute.html.
>
> Best Regards.
> Hujp
Thanks for the patch, pushed to gcc-wwwdocs.
Richard
>
> ---
> htdocs/contribute.html | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/htdocs/contribute.html b/htdocs/contr
Richard Biener writes:
>> Another thing we'd like for SVE in general is to allow vectors *with*
>> gaps throughout the SLP graph, since with predication it's simple to
>> ignore any inactive element where necessary. This is often much cheaper
>> than packing the active elements together to remove
On June 30, 2020 4:23:03 PM GMT+02:00, Richard Sandiford
wrote:
>Richard Biener writes:
>> On Tue, 30 Jun 2020, Richard Sandiford wrote:
>>
>>> Richard Biener writes:
>>> > On Tue, Jun 30, 2020 at 2:18 PM Richard Sandiford
>>> > wrote:
>>> >>
>>> >> "Yangfei (Felix)" writes:
>>> >> > diff --g
The unexpected warning is
gcc/testsuite/g++.dg/analyzer/pr94028.C:28:21: warning: use of
possibly-NULL '' where non-null expected [CWE-690]
[-Wanalyzer-possible-null-argument]
This is the same location as one of the existing "leak" warnings.
How would you like pr94028.C to be adjusted in the tes
On 6/23/20 6:44 PM, Thomas Schwinge wrote:
> Per the PTX 3.1 manual that I looked into, I see for CAS it supports:
> '.b32', '.b64'. We've got:
>
> $ build-gcc-offload-nvptx-none/gcc/xgcc
> -Bbuild-gcc-offload-nvptx-none/gcc -dM -E -x c /dev/null | grep -i
> compare.and.swap
> #define _
Ilya Leoshkevich writes:
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548822.html
>
> This is the implementation of Richard's suggestion. I've decided not
> to remove the initial #define NULL 0, since system.h mixes inclusion of
> system and helper headers (e.g. libiberty), which mig
Richard Biener writes:
> On Tue, 30 Jun 2020, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Tue, Jun 30, 2020 at 2:18 PM Richard Sandiford
>> > wrote:
>> >>
>> >> "Yangfei (Felix)" writes:
>> >> > diff --git a/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
>> >> > b/gcc/testsuite/gcc.d
On Tue, 2020-06-30 at 09:51 -0400, David Edelsohn wrote:
> The changes to the non-null warning now produce an additional warning
> for analyzer/pr94028.C on one of the "leak" lines. This causes new
> failures on trunk.
Hi David
Do you have the output to hand? What is the full text of the new
di
Am 30.06.20 um 13:11 schrieb Thomas Koenig:
PR fortran/95355
That should have been PR 955366.
Regards
Thomas
On Tue, Jun 30, 2020 at 1:31 PM yangyang (ET) wrote:
>
> > On Tue, Jun 30, 2020 at 4:29 AM yangyang (ET)
> > wrote:
> > >
> > > Hi,
> > >
> > > > > Hi,
> > > > >
> > > > > This is a simple fix for pr95855.
> > > > >
> > > > > With this fix, pass_split_paths can recognize the
> > > > > if-
Hi Julian!
On 2020-06-16T15:38:33-0700, Julian Brown wrote:
> This is a new version of the patch last sent here:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546332.html
>
> Minus the bits that Thomas has committed already (thanks!), and with
> adjustments to allow for GOMP_MAP_ATTACH b
The changes to the non-null warning now produce an additional warning
for analyzer/pr94028.C on one of the "leak" lines. This causes new
failures on trunk.
Because non-null is not the purpose of the analyzer test, I propose
pruning the output to resolve the new failures. Alternatively, I
could e
On 29/06/2020 11:15, Christophe Lyon wrote:
On Mon, 29 Jun 2020 at 10:56, Andre Vieira (lists)
wrote:
On 23/06/2020 21:52, Christophe Lyon wrote:
On Tue, 23 Jun 2020 at 15:28, Andre Vieira (lists)
wrote:
On 23/06/2020 13:10, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vi
Hi Mark,
Fixed the test case, the new patch is attached.
OK for commit to master and backports?
OK.
Thanks a lot!
Regards
Thomas
> -Original Message-
> From: Christophe Lyon
> Sent: 30 June 2020 14:32
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] arm: Warn if IRQ handler is not compiled with -
> mgeneral-regs-only [PR target/94743]
>
> On Tue, 30 Jun 2020 at 15:16, Kyrylo Tkachov
> w
On Tue, 30 Jun 2020 at 15:16, Kyrylo Tkachov wrote:
>
> Hi Christophe,
>
> Sorry for the delay.
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 29 April 2020 16:19
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] arm: Warn if I
Hi Mark,
OK to commit and backport?
OK, fixing such a NULL dererefence could also count as obvious
and simple (if it does the right thing :-)
Regarding backport: I probably would not do it myself; it's
not a regression, and ICE does not have such a large impact.
However, if you want to do i
On 6/30/20 8:53 AM, Martin Liška wrote:
Hey.
The bug reported confirmed that using the direct merging provides a solid
speed and so I don't insist on this patch. Using a generic compression
algorithm
would be a better solution anyway.
Thanks for the reminder. I won't insist on the generic c
v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548822.html
This is the implementation of Richard's suggestion. I've decided not
to remove the initial #define NULL 0, since system.h mixes inclusion of
system and helper headers (e.g. libiberty), which might use NULL - if
not today, then in
Hi Christophe,
Sorry for the delay.
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 29 April 2020 16:19
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Warn if IRQ handler is not compiled with -mgeneral-
> regs-only [PR target/94743]
Hey.
The bug reported confirmed that using the direct merging provides a solid
speed and so I don't insist on this patch. Using a generic compression algorithm
would be a better solution anyway.
Martin
Hi Mark,
that one is OK for master. Thanks!
Regards
Thomas
Hi Mark,
this is OK.
Regarding backport: This is not a regression, and the patch itself
is a bit large to bee entirely trivial. So, I'd prefer it you left
that for master.
Thanks for taking this up!
Regards
Thomas
Hi Alex,
> -Original Message-
> From: Alex Coplan
> Sent: 26 June 2020 10:38
> To: Alex Coplan ; Kyrylo Tkachov
> ; gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; nd ;
> Ramana Radhakrishnan
> Subject: RE: [PATCH] [arm] Don't generate invalid LDRD insns
>
> > -Original Message
PING^1
On 5/29/20 3:10 AM, Fangrui Song wrote:
On 2020-05-25, Martin Liška wrote:
On 5/22/20 6:42 AM, Fangrui Song wrote:
but I can't fix this one because joining two lines will break the 80-column
rule.
What about this:
diff --git a/gcc/collect2.c b/gcc/collect2.c
index cc57a20e08b..e5b54
On Tue, 30 Jun 2020, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, Jun 30, 2020 at 2:18 PM Richard Sandiford
> > wrote:
> >>
> >> "Yangfei (Felix)" writes:
> >> > diff --git a/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> >> > b/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> >> > index
On Tue, Jun 30, 2020 at 2:16 PM Martin Liška wrote:
>
> On 6/30/20 12:38 PM, Richard Biener wrote:
> > On Tue, Jun 30, 2020 at 11:44 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is about blocking of vector expansion of comparisons
> >> that are only feeding a VEC_COND_EXPR statements.
I forgot to use [PATCH] in the subject line. ping!
On 25/06/2020 07:33, Mark Eggleston wrote:
Please find attached fix for PR95584. Original patch by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in generic_correspondence PR95584
Output an error for ambiguous interf
ping!
On 25/06/2020 07:28, Mark Eggleston wrote:
Patch to fix PR52279. Marked strings that are indirectly used in
error and warning messages so that they are marked for translation.
OK to commit?
Commit message:
Fortran : Fortran translation issues PR52279
Mark strings for translation by
ping!
On 24/06/2020 09:00, Mark Eggleston wrote:
Please find attached a fix for PR95446. Patch originally posted to
the PR by Steve Kargl.
OK to commit to master and backport?
Commit message:
Fortran : False positive for optional arguments PR95446
Check that there is non-optional argument
On 24/06/2020 10:13, Manfred Schwarb wrote:
Am 24.06.20 um 10:12 schrieb Mark Eggleston:
Please find a fix for PR95829. Original patch by Steve Kargl posted to PR.
Commit to master and backport?
Commit message:
Fortran : Bogus error with additional blanks in type(*) PR95829
Checking for "*
Richard Biener writes:
> On Tue, Jun 30, 2020 at 2:18 PM Richard Sandiford
> wrote:
>>
>> "Yangfei (Felix)" writes:
>> > diff --git a/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
>> > b/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
>> > index e050db1a2e4..ea39fcac0e0 100644
>> > --- a/gcc/testsuite/gcc.dg
Hi Julian!
On 2020-06-16T15:38:32-0700, Julian Brown wrote:
> Later patches in this series assume that GOMP_MAP_ATTACH will be grouped
> together with a preceding GOMP_MAP_TO_PSET or other "to" data movement
> clause, except in cases where an explicit "attach" clause is used.
> This patch arrange
On Tue, Jun 30, 2020 at 2:18 PM Richard Sandiford
wrote:
>
> "Yangfei (Felix)" writes:
> > diff --git a/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> > b/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> > index e050db1a2e4..ea39fcac0e0 100644
> > --- a/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> > +++ b/gcc/
"Yangfei (Felix)" writes:
> diff --git a/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> b/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> index e050db1a2e4..ea39fcac0e0 100644
> --- a/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-ctor-1.c
> @@ -1,6 +1,7 @@
> /* { dg-do comp
On 6/30/20 12:38 PM, Richard Biener wrote:
On Tue, Jun 30, 2020 at 11:44 AM Martin Liška wrote:
Hi.
The patch is about blocking of vector expansion of comparisons
that are only feeding a VEC_COND_EXPR statements.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
The prob
On Tue, 30 Jun 2020, Richard Sandiford wrote:
> Sorry for the slow reponse…
No problem.
> Richard Biener writes:
> > This splits SLP load nodes with load permutation into a SLP
> > load node (with load "permutation" removing gaps) and a
> > lane permutation node. The first and foremost goal of
> On Tue, Jun 30, 2020 at 4:29 AM yangyang (ET)
> wrote:
> >
> > Hi,
> >
> > > > Hi,
> > > >
> > > > This is a simple fix for pr95855.
> > > >
> > > > With this fix, pass_split_paths can recognize the
> > > > if-conversion
> > > opportunity of the testcase and doesn't duplicate the corresp
Hello world,
fortunately, upon inspection the fix for this PR turned out to be
obvious (and simple). I have committed it as such. Unless there
is unexpected fallout, I intend to backport it to gcc-10 over
the weekend so it can still be included into 10.2.
Regression-tested on x86_64 and on a b
On Tue, Jun 30, 2020 at 4:29 AM yangyang (ET) wrote:
>
> Hi,
>
> > > Hi,
> > >
> > > This is a simple fix for pr95855.
> > >
> > > With this fix, pass_split_paths can recognize the if-conversion
> > opportunity of the testcase and doesn't duplicate the corresponding block.
> > >
> > >
On Mon, Jun 29, 2020 at 4:58 PM Ilya Leoshkevich wrote:
>
> On Thu, 2020-06-25 at 14:34 +0200, Richard Biener wrote:
> > On Wed, Jun 24, 2020 at 1:31 AM Ilya Leoshkevich via Gcc-patches
> > wrote:
> > > Bootstrapped and regtested x86_64-redhat-linux, ppc64le-redhat-
> > > linux and
> > > s390x-re
Sorry for the slow reponse…
Richard Biener writes:
> This splits SLP load nodes with load permutation into a SLP
> load node (with load "permutation" removing gaps) and a
> lane permutation node. The first and foremost goal of this
> is to be able to have a single SLP node for each load group
>
On Tue, Jun 30, 2020 at 11:44 AM Martin Liška wrote:
>
> Hi.
>
> The patch is about blocking of vector expansion of comparisons
> that are only feeding a VEC_COND_EXPR statements.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> The problematic mips64 test-case looks go
PING^3
On 6/12/20 10:31 AM, Martin Liška wrote:
PING^2
On 6/3/20 11:14 AM, Martin Liška wrote:
On 6/1/20 1:40 PM, Martin Liška wrote:
Adding Honza as Uros recommended him for a review.
@Honza asked me personally to remind him this patch ;)
Martin
PING^2
On 6/17/20 8:38 AM, Martin Liška wrote:
PING^1
On 6/3/20 8:28 AM, Martin Liška wrote:
On 6/2/20 3:19 PM, Martin Liška wrote:
I'm suggesting to pre-allocate 16 gcov_kvp in the gcov run-time library.
Please take a look at the attached patch. I also added a test-case that
stresses that. I
Hi.
The patch is about blocking of vector expansion of comparisons
that are only feeding a VEC_COND_EXPR statements.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
The problematic mips64 test-case looks good now.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
On Tue, 30 Jun 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs since recent Martin's -Wnonnull changes,
> we see a CALL_EXPR and ICE because CALL_EXPR_FN is NULL, which is
> valid for internal function calls. Internal function calls don't have a
> function type, and will never h
> >>
> >
> > Just a small note that 510.parest_r SPEC 2017 benchmark can't be built
> > now with default changed to -std=c++17. The spec config needs to be
> adjusted.
> >
> > Martin
>
> And there one another failure in 520.omnetpp_r caused by run-time error:
> Error during startup: Register_Func
This breaks a lot of tests due to the different error messages.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi!
The following testcase ICEs since recent Martin's -Wnonnull changes,
we see a CALL_EXPR and ICE because CALL_EXPR_FN is NULL, which is
valid for internal function calls. Internal function calls don't have a
function type, and will never have format_arg attribute on them nor will
serve as the
94 matches
Mail list logo
