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
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
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):
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
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
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.
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
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
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
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 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 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
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.
> 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
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/
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
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
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.
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 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
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: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 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 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, 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
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
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
"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.
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
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'
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.
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
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
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 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 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 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 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/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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
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 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
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 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
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
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, 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!
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
65 matches
Mail list logo
