Hi!
The following testcase ICEs in final_scan_insn_1. The problem is in the
@aarch64_compare_and_swaphi define_insn_and_split, since 9 it uses
aarch64_plushi_operand predicate for the "expected value" operand, which
allows either 0..0xfff constants or 0x1000..0xf000 constants (i.e. HImode
values
On Mon, 2020-03-30 at 12:09 -0400, David Malcolm via Gcc-patches wrote:
> On Sun, 2020-03-29 at 21:31 +0100, Andrea Corallo wrote:
> > David Malcolm writes:
> >
> > > On Wed, 2020-03-18 at 23:51 +0100, Andrea Corallo wrote:
> > > Please add the new test to the header in its alphabetical
> > > loc
Hi!
On Mon, Mar 30, 2020 at 12:50:43PM -0500, will schmidt wrote:
> On Fri, 2020-03-27 at 21:31 -0400, Michael Meissner via Gcc-patches
> > * config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): New macro.
> > (rs6000_option_override_internal): Set the -mprefixed and
> > -mpcrel
> > options
On 2020-03-30 12:06 p.m., David Malcolm wrote:
It's a double-free bug in lra.c, albeit one that requires being used
in a multithreaded way from libgccjit to be triggered.
libgccjit's test-threads.c repeatedly compiles and runs numerous tests,
each in a separate thread.
Attempting to add an em
On Mon, 30 Mar 2020, Jason Merrill wrote:
> On 3/30/20 3:58 PM, Patrick Palka wrote:
> > On Thu, 26 Mar 2020, Jason Merrill wrote:
> >
> > > On 3/22/20 9:21 PM, Patrick Palka wrote:
> > > > This patch relaxes an assertion in tsubst_default_argument that exposes
> > > > a
> > > > latent
> > > > bug
On Mon, Mar 30, 2020 at 4:53 PM Tobias Burnus wrote:
>
> Hi Fritz,
>
> On 3/30/20 10:20 PM, Fritz Reese via Fortran wrote:
>
> >>> * All included files need dependency; I do not quickly
> >>>see whether that' the case.
>
> If one looks at the build, the dependency is automatically
> obtained a
The resolution of CWG issue 1321 clarified that when deciding whether two
expressions involving template parameters are equivalent, two dependent
function calls where the function is named with an unqualified-id are
considered to be equivalent if the name is the same, even if unqualified
lookup fin
On Tue, 2020-03-24 at 10:50 +0100, Jakub Jelinek wrote:
> On Mon, Mar 23, 2020 at 06:00:06PM -0600, Jeff Law via Gcc-patches wrote:
> > +/* Return true if CODE is valid for comparisons of mode MODE, false
> > + otherwise.
> > +
> > + It is always safe to return false, even if the code was valid
Hi Fritz,
On 3/30/20 10:20 PM, Fritz Reese via Fortran wrote:
* All included files need dependency; I do not quickly
see whether that' the case.
If one looks at the build, the dependency is automatically
obtained and tracked in …/.deps/*.Po in the build directory.
Hence, no action needed.
On 3/29/20 6:42 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because the FE when processing the statement
expression changes the .VEC_CONVERT internal fn CALL_EXPR into .PHI call.
That is because the internal fn call is recorded in the base.u.ifn
field, which overlaps base.u.bits.la
On 3/30/20 3:58 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/22/20 9:21 PM, Patrick Palka wrote:
This patch relaxes an assertion in tsubst_default_argument that exposes a
latent
bug in how we substitute an array type into a cv-qualified wildcard function
parameter ty
Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:
/* ??? Here's to hoping the front end fills in all of the indices,
so we don't have to figure out what's missing ourselves. */
gcc_assert (purpose);
The indexes wer
On Sat, Mar 28, 2020 at 12:37 PM Steve Kargl
wrote:
>
> On Sat, Mar 28, 2020 at 08:10:38AM +0100, Tobias Burnus wrote:
> > Two remarks:
> >
> > * As the file trigd_lib.inc is shared between libgfortran
> > and gcc/fortran, I wonder whether it should be placed
> > under include/ (under the GCC
On Mon, 30 Mar 2020, Patrick Palka wrote:
> On Thu, 26 Mar 2020, Jason Merrill wrote:
>
> > On 3/22/20 9:21 PM, Patrick Palka wrote:
> > > This patch relaxes an assertion in tsubst_default_argument that exposes a
> > > latent
> > > bug in how we substitute an array type into a cv-qualified wildca
On Thu, 26 Mar 2020, Jason Merrill wrote:
> On 3/22/20 9:21 PM, Patrick Palka wrote:
> > This patch relaxes an assertion in tsubst_default_argument that exposes a
> > latent
> > bug in how we substitute an array type into a cv-qualified wildcard function
> > parameter type. Concretely, the latent
On Mar 26, 2020, at 3:00 PM, Maciej W. Rozycki wrote:
>
> I have actually considered extracting the bits already, but I hesitated
> putting that forward that as having looked at the part that we require I
> have thought it to be very messy:
Yeah, sometimes it's like that. I glanced at the wor
On Sun, Mar 29, 2020 at 3:03 PM Andreas Schwab wrote:
> * config/host-linux.c (TRY_EMPTY_VM_SPACE) [__riscv && __LP64__]:
> Define.
Looks like the same address already used by the aarch64 and ia64
ports, so it seems safe. OK.
Jim
On Fri, 2020-03-27 at 21:31 -0400, Michael Meissner via Gcc-patches
wrote:
Hi,
A few cosmetic nits and comments sprinkled in below. I defer to
Segher for his approvals and comments. thanks,
-Will
> This is a revised version of the patch I posted on March 23rd. The
> changes are
> to updat
On Mon, Mar 30, 2020 at 11:23:12AM -0500, Peter Bergner wrote:
> On 3/30/20 6:26 AM, Segher Boessenkool wrote:
> > On Mon, Mar 30, 2020 at 09:50:05AM +0100, Richard Sandiford wrote:
> >> Peter Bergner via Gcc-patches writes:
> >>> - if (HARD_REGISTER_NUM_P (rd) || HARD_REGISTER_NUM_P (rs))
> >>>
On 3/30/20 11:23 AM, Peter Bergner wrote:
> I kind of agree with Richard above on making it more applicable/symmetric,
> but why can't we just remove the HARD_REGISTER_NUM_P() tests altogether?
> It's not like lower-subreg is extending hard register lifetime usage than
> what is already there in th
On 3/30/20 6:26 AM, Segher Boessenkool wrote:
> On Mon, Mar 30, 2020 at 09:50:05AM +0100, Richard Sandiford wrote:
>> Peter Bergner via Gcc-patches writes:
>>> - if (HARD_REGISTER_NUM_P (rd) || HARD_REGISTER_NUM_P (rs))
>>> + if (HARD_REGISTER_NUM_P (rd))
>>> return false;
>>>
>>>b =
On Sun, 2020-03-29 at 21:31 +0100, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Wed, 2020-03-18 at 23:51 +0100, Andrea Corallo wrote:
> > Please add the new test to the header in its alphabetical location,
> > i.e. between:
> >
> > /* test-vector-types.cc: We don't use this, since it
Hi!
On Mon, Mar 30, 2020 at 09:50:05AM +0100, Richard Sandiford wrote:
> With this change, the only remaining function of -fsplit-wide-types-early
> is to act as a double lock on one pass. IMO it'd make more sense to remove
> that double lock and make -fsplit-wide-types-early and -fsplit-wide-typ
On Sun, 2020-03-29 at 21:31 +0100, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Wed, 2020-03-18 at 23:51 +0100, Andrea Corallo wrote:
> > Please add the new test to the header in its alphabetical location,
> > i.e. between:
> >
> > /* test-vector-types.cc: We don't use this, since it
On Mon, 30 Mar 2020, Dragan Mladjenovic wrote:
> Thanks. I forgot to mention. I would need someone to commit this for me.
I'll take care.
Gerald
On 3/30/20 5:49 PM, Dragan Mladjenovic wrote:
I won't be able to access to my sourceware account for some time.
Hi.
Done as 47f1af75a082fe6e4d2bd4b289d982abd749c824.
Martin
On Fri, 2020-03-27 at 00:46 +0100, Jakub Jelinek wrote:
> Hi!
>
> This define_insn has two issues.
> One is that with -mavx512f -mno-avx512vl it can emit an AVX512VL-only insn
> - 128-bit or 256-bit EVEX encoded vpternlog{d,q}.
> Another one is that because there is no vpternlog{b,w}, we emit vpte
On 3/30/2020 17:39, Jeff Law wrote:
On Sun, 2020-03-29 at 22:33 +0200, Dragan Mladjenovic wrote:
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index b5cbcebf..1e1eaf43 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -692,7 +692,17 @@ a work-in-
On Sun, 2020-03-29 at 22:33 +0200, Dragan Mladjenovic wrote:
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index b5cbcebf..1e1eaf43 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -692,7 +692,17 @@ a work-in-progress.
>
>
>
> -
> +
On Fri, 2020-03-27 at 00:26 +0100, Jakub Jelinek wrote:
> On Wed, Mar 25, 2020 at 05:59:36PM -0600, Jeff Law via Gcc-patches wrote:
> > Sorry. I know you asked me to look at this eons ago, but ever time I just
> > get
> > lost.
> >
> > I get the distinct impression that we could do something much
On Mon, 2020-03-30 at 16:06 +0200, Martin Liška wrote:
> Hi.
>
> I would like to relax scanned pattern, see the PR.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/testsuite/ChangeLog:
>
> 2020-03-30 Martin Liska
>
> PR testsuite/94402
> * gfortran.dg/vect/vect-8.f90: Allo
On Mon, 2020-03-30 at 14:10 +0200, Martin Liška wrote:
> Hi.
>
> I would like to XFAIL the mentioned test-case. It fails
> for quite some time and it has PR created.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/testsuite/ChangeLog:
>
> 2020-03-30 Martin Liska
>
> PR rtl-optim
Hi.
I would like to relax scanned pattern, see the PR.
Ready to be installed?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2020-03-30 Martin Liska
PR testsuite/94402
* gfortran.dg/vect/vect-8.f90: Allow 22 or 23 loops
to be vectorized (based on libmvec presence).
---
gc
Hello,
On Thu, 26 Mar 2020, Jan Hubicka wrote:
> > I think we should continue to try to model ELF semantics re weak and
> > aliases. If so, then yes, LTO gets it wrong and the above testcase should
> > not abort. Weak doesn't enter the picture for creating aliases (the
> > aliases is created
Hi Jakub:
Thanks for your correction, I read the doc for the aligned attribute
again[1], it's minimum alignment not restricted alignment, I thought
it should honor to the alignment attribute, Richard Biener
suggested[2] should put an assertion here to make sure never decrease
alignment here, so I'
Hi.
I would like to XFAIL the mentioned test-case. It fails
for quite some time and it has PR created.
Ready to be installed?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2020-03-30 Martin Liska
PR rtl-optimization/87716
* gcc.target/i386/pr57193.c: XFAIL a test-case.
---
gcc/t
"Yangfei (Felix)" writes:
> Hi!
>> -Original Message-
>> From: Yangfei (Felix)
>> Sent: Monday, March 30, 2020 5:28 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: 'rguent...@suse.de'
>> Subject: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
>>
>> Hi,
>>
>> New bug: https://gcc.
Hi!
> -Original Message-
> From: Yangfei (Felix)
> Sent: Monday, March 30, 2020 5:28 PM
> To: gcc-patches@gcc.gnu.org
> Cc: 'rguent...@suse.de'
> Subject: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
>
> Hi,
>
> New bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
Hi!
On Mon, Mar 30, 2020 at 09:50:05AM +0100, Richard Sandiford wrote:
> Peter Bergner via Gcc-patches writes:
> > - if (HARD_REGISTER_NUM_P (rd) || HARD_REGISTER_NUM_P (rs))
> > + if (HARD_REGISTER_NUM_P (rd))
> > return false;
> >
> >b = reg_copy_graph[rs];
>
> I guess this would
On Mon, Mar 30, 2020 at 06:31:27PM +0800, Kito Cheng wrote:
> gcc/ChangeLog
>
> * cfgexpand.c (align_local_variable): Check DECL_USER_ALIGN.
Why? LOCAL_DECL_ALIGNMENT surely shouldn't decrease alignment of decls
with DECL_USER_ALIGN vars (but do you have evidence that it does),
but it is j
On Mon, Mar 30, 2020 at 01:09:41PM +0200, Richard Biener wrote:
> Btw, does the above fallout already happen if you add -g? Because
> all the affected stmt-lists should end up with some DEBUG_BEGIN_STMTs
> in them and thus preserved?
Such STATEMENT_LISTs were marked !TREE_SIDE_EFFECTS, which mean
On Mon, 30 Mar 2020, Jakub Jelinek wrote:
> On Mon, Mar 30, 2020 at 12:44:40PM +0200, Richard Biener wrote:
> > >type = TREE_TYPE (stmt_expr);
> > > + /* For statement-expressions, force the STATEMENT_LIST
> > > + to be preserved with side-effects, even if it contains
> > > + just one
On Mon, Mar 30, 2020 at 12:44:40PM +0200, Richard Biener wrote:
> >type = TREE_TYPE (stmt_expr);
> > + /* For statement-expressions, force the STATEMENT_LIST
> > + to be preserved with side-effects, even if it contains
> > + just one statement or no statements. See PR93786. */
> > +
On Mon, 30 Mar 2020, Jakub Jelinek wrote:
> On Fri, Mar 27, 2020 at 09:09:42PM +0100, Richard Biener wrote:
> > Sounds worth a try.
>
> Unfortunately that FAILed miserably:
> +FAIL: g++.dg/cpp0x/constexpr-object1.C -std=c++11 (test for excess errors)
> +FAIL: g++.dg/cpp0x/constexpr-object1.C -
On Mon, Mar 30, 2020 at 12:24 PM Kewen.Lin wrote:
>
> Hi,
>
> As PR94043 shows, my commit r10-4524 exposed one issue in
> vectorizable_live_operation, which inserts one extra BB
> before the single exit, leading unexpected operand expansion
> and unexpected loop depth assertion. As Richi suggeste
gcc/ChangeLog
* cfgexpand.c (align_local_variable): Check DECL_USER_ALIGN.
---
gcc/cfgexpand.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index a7ec77d5c85..19a020b4b97 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/
On Mon, Mar 30, 2020 at 06:24:32PM +0800, Kito Cheng wrote:
> Hi Jakub:
>
> I saw the omp and oacc related passes are in the head of all_passes,
> so I plan added after pass_omp_target_link, does it late enough?
Yes, that is ok.
> diff --git a/gcc/passes.def b/gcc/passes.def
> index 2bf2cb78fc5.
Hi Andrew:
> > + FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
> > +{
> > + function *fun = node->get_fun ();
> > + FOR_EACH_LOCAL_DECL (fun, i, var)
> > + {
> > + align = LOCAL_DECL_ALIGNMENT (var);
> > +
> > + SET_DECL_ALIGN (var, align);
>
>
> I think this is wr
Hi Jakub:
I saw the omp and oacc related passes are in the head of all_passes,
so I plan added after pass_omp_target_link, does it late enough?
diff --git a/gcc/passes.def b/gcc/passes.def
index 2bf2cb78fc5..92cbe587a8a 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -183,6 +183,7 @@ along wi
Hi,
As PR94043 shows, my commit r10-4524 exposed one issue in
vectorizable_live_operation, which inserts one extra BB
before the single exit, leading unexpected operand expansion
and unexpected loop depth assertion. As Richi suggested,
this patch is to teach vectorizable_live_operation to
generat
On Fri, Mar 27, 2020 at 09:09:42PM +0100, Richard Biener wrote:
> Sounds worth a try.
Unfortunately that FAILed miserably:
+FAIL: g++.dg/cpp0x/constexpr-object1.C -std=c++11 (test for excess errors)
+FAIL: g++.dg/cpp0x/constexpr-object1.C -std=c++14 (test for excess errors)
+FAIL: g++.dg/cpp0x/
> But I wonder if we can instead fix the memcpy inlining issue by
> making the predicates involved honor LOCAL_ALIGNMENT
> instead of relying on DECL_ALIGN?
The memcpy inlining issue is not the only one affected by alignment
issue, I guess?
So I think it would be better to fix DECL_ALIGN?
On Mon
Hi,
New bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94398
With -mstrict-align, aarch64_builtin_support_vector_misalignment will returns
false when misalignment factor is unknown at compile time.
Then vect_supportable_dr_alignment returns dr_unaligned_unsupported, which
triggers the ICE.
On Mon, 30 Mar 2020, Martin Liška wrote:
The patch ensures that a deleted new/delete pair has a same context.
That will fix the issue presented in the PR.
DECL_CONTEXT seems good for that example (assuming it is still available
in the middle-end), but shouldn't we also check if both are array
On Mon, Mar 30, 2020 at 11:09:40AM +0200, Richard Biener wrote:
> On Fri, Mar 27, 2020 at 7:27 PM Jakub Jelinek wrote:
> >
> > On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote:
> > > PR target/90811
> > > * ipa-increase-alignment.cc (increase_alignment_local_var): New.
> > >
On Fri, Mar 27, 2020 at 7:27 PM Jakub Jelinek wrote:
>
> On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote:
> > PR target/90811
> > * ipa-increase-alignment.cc (increase_alignment_local_var): New.
> > (increase_alignment_global_var): New.
> > (pass_ipa_increase_ali
On Mon, Mar 30, 2020 at 10:41 AM Martin Liška wrote:
>
> Hi.
>
> The patch ensures that a deleted new/delete pair has a same context.
> That will fix the issue presented in the PR.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I think this will break the DCE with LTO
Peter Bergner via Gcc-patches writes:
> The pr87507.c test case regressed due to Segher's commit that added
> -fsplit-wide-types-early. The issue is that the lower-subreg pass only
> decomposes the TImode code in the example if there is a pseudo reg to pseudo
> reg copy. When the lower-subreg pa
Hi.
The patch ensures that a deleted new/delete pair has a same context.
That will fix the issue presented in the PR.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-03-30 Martin Liska
PR c++/94314
Early *ping*.
Tobias
On 3/27/20 11:06 AM, Tobias Burnus wrote:
Hi all,
here, the reject_statement cleanup and the freeing of the
namespace both remove the symbol. Solution: Remove it first,
then clean the namespace – then the reject_statement has no
(deleted) statement to cleanup.
As select
Hi Mark,
the error message does not make sense – and I also currently
do not see why that example should be invalid.
Regarding the error message:
"uses the same global identifier"
In the test program (attached or PR) I do see one function "f"
and one entry "g" – and both "f" and "g" is only u
OK.
Thanks,
Tobias
On 3/30/20 9:30 AM, Mark Eggleston wrote:
Please find attached patch for PR94030.
OK to commit?
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/94030
* resolve.c (resolve_equivalence): Correct formatting
around the label "identical_types". Instead o
OK (both GCC 9 + 10). Thanks for the packaging the patch
and to Steven for the patch.
Tobias
On 3/30/20 9:00 AM, Mark Eggleston wrote:
Please find attached patch for PR93498.
OK to commit?
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/93498
* check.c (gfc_check_findloc):
Please find attached patch for PR94030.
OK to commit?
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/94030
* resolve.c (resolve_equivalence): Correct formatting
around the label "identical_types". Instead of using
gfc_resolve_array_spec use is_non_constants_shape_arra
Please find attached patch for PR93498.
OK to commit?
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/93498
* check.c (gfc_check_findloc): If the kinds of the arguments
differ goto label "incompat".
gcc/testsuite/ChangeLog:
Mark Eggleston
PR fortran/93498
65 matches
Mail list logo
