Hi Paul, hi all fortran@/gcc-patch@ reader,
it looks as if you replied with your patch submission to the wrong email
address – and your re-submission ended up at https://gcc.gnu.org/PR99602#c17
On 16.03.21 18:08, Tobias Burnus wrote:
On 16.03.21 17:42, Paul Richard Thomas via Gcc-patches wrote:
*PING* of my 11.03.21 18:15 CET patch.
The issue is that the TREE_TYPE of the fndecl does not match its arglist.
In some cases, the middle end looks at the function type – and then it
goes wrong.
The issue only occurs for -fcoarray=lib as other hidden arguments are
properly handled.
Soluti
> -Original Message-
> From: qia...@fujitsu.com
> Sent: 18 March 2021 01:52
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford
> Subject: RE: [PATCH] aarch64: Improve generic SVE tuning defaults
>
> Hello Kyrill,
>
> Sorry for the slow response.
> The performance o
The installation of the jit headers can fail, because the directory might not be
created yet, a missing dependency on the installdirs target.
Also the Makefile hardcodes mkdir -p, instead of using $(mkinstalldirs).
Ok for the trunk and the branches?
Matthias
diff --git a/gcc/jit/Make-lang.in b/g
Hello.
The patch is about a missing struct initialization. It's pre-approved by Iain.
Thanks,
Martin
gcc/cp/ChangeLog:
PR c++/99617
* coroutines.cc (struct var_nest_node): Init then_cl and else_cl
to NULL.
---
gcc/cp/coroutines.cc | 2 +-
1 file changed, 1 insertion(+)
As discussed in PR 97680, -fzero-call-used-regs is not supported on
arm.
Skip this test to avoid failure reports.
2021-03-18 Christophe Lyon
gcc/tesuite/
* c-c++-common/zero-scratch-regs-10.c: Skip on arm
---
gcc/testsuite/c-c++-common/zero-scratch-regs-10.c | 1 +
1 file cha
From: Mihailo Stojanovic
Hi all,
Currently, SF->SI and DF->DI conversions on Aarch64 with the "nosimd"
flag provided sometimes cause the emitting of a vector variant of the
fcvtz[su] instruction (e.g. fcvtzu s0, s0).
This modifies the corresponding pattern to only select the vector
variant of t
> -Original Message-
> From: Kyrylo Tkachov
> Sent: 18 March 2021 09:37
> To: 'qia...@fujitsu.com' ; gcc-patches@gcc.gnu.org
> Cc: Richard Sandiford
> Subject: RE: [PATCH] aarch64: Improve generic SVE tuning defaults
>
>
>
> > -Original Message-
> > From: qia...@fujitsu.com
>
Hey.
Recently, I noticed a cumbersome construct we use for string startswith function
(most notably in a situation when the prefix is a string literal).
Commonly used patterns are:
1) strncmp (arg, "--sysroot=", 10) == 0
2) strncmp (name, "not found", sizeof ("not found") - 1) == 0
3) strncmp (v
Hi,
this is the failure of a couple of tests in the gnat.dg testsuite on 32-bit
platforms (but on some hosts only):
FAIL: gnat.dg/loop_optimization3.adb (test for excess errors)
FAIL: gnat.dg/opt30.adb (test for excess errors)
FAIL: gnat.dg/opt49.adb (test for excess errors)
caused by a segfaul
Fortran itself: suggestion is to add a new entry to the vtable
(breaking change) — thus, please also comment if you are not
interested in OpenMP (or coarrays).
For OpenMP: When mapping a derived-type to a non-shared-memory
(accelerator/GPU) device, it gets complicated with (polymorphic)
allocatab
On Wed, Mar 17, 2021 at 10:46 PM Jan Hubicka wrote:
>
> Hi,
> this patch enables gather on zen3 hardware. For TSVC it get used by 6
> benchmarks with following runtime improvements:
>
> s4114: 1.424 -> 1.209 (84.9017%)
> s4115: 2.021 -> 1.065 (52.6967%)
> s4116: 1.549 -> 0.854 (55.1323%)
> s41
On Thu, Mar 18, 2021 at 1:04 PM Eric Botcazou wrote:
>
> Hi,
>
> this is the failure of a couple of tests in the gnat.dg testsuite on 32-bit
> platforms (but on some hosts only):
>
> FAIL: gnat.dg/loop_optimization3.adb (test for excess errors)
> FAIL: gnat.dg/opt30.adb (test for excess errors)
>
Hi!
On 2021-03-17T08:54:15+0100, Richard Biener wrote:
> On Wed, Mar 17, 2021 at 12:35 AM Thomas Schwinge
> wrote:
>> On 2021-03-17T00:24:55+0100, I wrote:
>> > Now, walking each function backwards (!), [...]
>>
>> > I've now got a simple 'callback_op', which for '!is_lhs' looks at
>> > 'get_bas
Hi JBG,
These three let it build. One done. Thanks for your support!
No worries. Patch pushed.
Cheers
Nick
Hi Tobias,
Thanks for the review. I am resisting dg-run for this patch simply because
the testsuite already takes an oppressive amount of time to run. That the
runtime error is present in the code should be sufficient IMHO.
Regards
Paul
On Thu, 18 Mar 2021 at 08:46, Tobias Burnus wrote:
> Hi
On 3/18/2021 4:02 AM, Christophe Lyon via Gcc-patches wrote:
As discussed in PR 97680, -fzero-call-used-regs is not supported on
arm.
Skip this test to avoid failure reports.
2021-03-18 Christophe Lyon
gcc/tesuite/
* c-c++-common/zero-scratch-regs-10.c: Skip on arm
OK
J
On 3/18/2021 3:40 AM, Matthias Klose wrote:
The installation of the jit headers can fail, because the directory might not be
created yet, a missing dependency on the installdirs target.
Also the Makefile hardcodes mkdir -p, instead of using $(mkinstalldirs).
Ok for the trunk and the branches?
This patch introduces a dwarf_debuginfo_p predicate that abstracts and
replaces complex checks on write_symbols.
2021-03-18 Indu Bhagat
gcc/ChangeLog
* flags.h (dwarf_debuginfo_p): New function declaration.
* opts.c (dwarf_debuginfo_p): New function definition.
* confi
[Changes from V4:
- Rebased to latest master.
- Support for DATASEC in BTF.
- Bug fixes in the CTF support.
- Be more silent: do not inform() the user anymore if -gctf is used
along with a frontend for which there is no CTF support. Ignore
the request instead.
- Got rid of lang_GNU_GIMPLE, whi
This patch introduces a dwarf2int.h header, to be used by code that
needs access to the internal DIE structures and their attributes.
The following functions which were previously defined as static in
dwarf2out.c are now non-static, and extern prototypes for them have
been added to dwarf2int.h:
-
This commit documents the new command line options introduced by the
CTF and BTF debug formats.
2021-02-18 Indu Bhagat
* doc/invoke.texi: Document the CTF and BTF debug info options.
---
gcc/doc/invoke.texi | 20
1 file changed, 20 insertions(+)
diff --git a/gcc/
This patch changes the BPF GCC backend in order to use the DWARF debug
hooks and therefore enables the user to generate BTF debugging
information with -gbtf. Generating BTF is crucial when compiling BPF
programs, since the CO-RE (compile-once, run-everwhere) mechanism
used by the kernel BPF loader
This commit adds a new testsuite for the CTF debug format.
2021-03-18 Indu Bhagat
David Faust
gcc/testsuite/
* gcc.dg/debug/btf/btf-1.c: New test.
* gcc.dg/debug/btf/btf-2.c: Likewise.
* gcc.dg/debug/btf/btf-anonymous-struct-1.c: Likewise.
* gcc.d
Hi!
As mentioned in the testcase as well as in the PR, this testcase relies on
MOVE_MAX being sufficiently large that the memcpy call is folded early into
load + store. Some popular targets define MOVE_MAX to 8 or even 16 (e.g.
x86_64 or some options on s390x), but many other targets define it to
Hi!
Similar issue as in strlenopt-73.c, various spots in this test rely
on MOVE_MAX >= 8, this time it uses a target selector to pick up a couple
of targets, and all of them but powerpc 32-bit satisfy it, but powerpc
32-bit have MOVE_MAX just 4.
Tested on x86_64-linux and powerpc64-linux -m32/-m6
On 3/18/2021 8:37 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Similar issue as in strlenopt-73.c, various spots in this test rely
on MOVE_MAX >= 8, this time it uses a target selector to pick up a couple
of targets, and all of them but powerpc 32-bit satisfy it, but powerpc
32-bit have MOVE_M
On 3/18/2021 8:35 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
As mentioned in the testcase as well as in the PR, this testcase relies on
MOVE_MAX being sufficiently large that the memcpy call is folded early into
load + store. Some popular targets define MOVE_MAX to 8 or even 16 (e.g.
x86_64
On Thu, Mar 18, 2021 at 08:58:20AM -0600, Jeff Law via Gcc-patches wrote:
>
> On 3/18/2021 8:37 AM, Jakub Jelinek via Gcc-patches wrote:
> > Hi!
> >
> > Similar issue as in strlenopt-73.c, various spots in this test rely
> > on MOVE_MAX >= 8, this time it uses a target selector to pick up a coupl
On Thu, Mar 18, 2021 at 4:09 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Mar 18, 2021 at 08:58:20AM -0600, Jeff Law via Gcc-patches wrote:
> >
> > On 3/18/2021 8:37 AM, Jakub Jelinek via Gcc-patches wrote:
> > > Hi!
> > >
> > > Similar issue as in strlenopt-73.c, various spots in this test
Hao,
Segher and I do not doubt that the patch can improve the examples and
testcases. The question is if those examples are representative of
common situations and if the patch truly improves performance overall
-- for real workloads. Can you test the performance impact of your
patch, not only d
On 3/18/21 4:46 AM, Martin Liška wrote:
Hey.
Recently, I noticed a cumbersome construct we use for string startswith
function
(most notably in a situation when the prefix is a string literal).
Commonly used patterns are:
1) strncmp (arg, "--sysroot=", 10) == 0
2) strncmp (name, "not found", s
On 3/18/2021 9:08 AM, Jakub Jelinek wrote:
On Thu, Mar 18, 2021 at 08:58:20AM -0600, Jeff Law via Gcc-patches wrote:
On 3/18/2021 8:37 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Similar issue as in strlenopt-73.c, various spots in this test rely
on MOVE_MAX >= 8, this time it uses a target
The backend pattern for storing a pair of identical values in 32 and 64-bit
modes with the machine instruction STP was missing, and multiple instructions
were needed to reproduce this behavior as a result of failed RTL pattern match
in combine pass.
For the test case :
typedef long long v2di _
On Thu, Mar 18, 2021 at 09:31:03AM -0600, Jeff Law wrote:
> > > OK. But it'd sure be nice to be able to do something like force a value
> > > of
> > > MOVE_MAX using a --param to make this kind of hack unnecessary.
> > I fear such a param would be quite dangerous, dunno what would happen if
> > s
On 3/18/21 8:58 AM, Jeff Law via Gcc-patches wrote:
On 3/18/2021 8:37 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Similar issue as in strlenopt-73.c, various spots in this test rely
on MOVE_MAX >= 8, this time it uses a target selector to pick up a couple
of targets, and all of them but power
On 3/14/2021 9:16 PM, HAO CHEN GUI via Gcc-patches wrote:
Hi,
This patch fixes an ICE found by enabling const_anchor for rs6000.
The BLKmode constant rtx is sent to try_const_anchors which causes
assertion failure in try_const_anchors.
The attachment are the patch diff and change l
On Thu, Mar 18, 2021 at 09:27:17AM +0800, Xionghu Luo via Gcc-patches wrote:
> gcc/ChangeLog:
>
> 2021-03-18 Xionghu Luo
>
> PR target/98914
> * config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9):
> Convert idx to DImode.
> (rs6000_expand_vector_set_var_p8): Likew
Hi,
this patch updates costs of integer divides to match actual latencies (the
scheduler model already does the right thing). It is essentially no-op, since
we end up expanding idiv for all sensible constants, so this only may end
up disabling vectorization in some cases, but I did not find any su
On Wed, 2021-03-17 at 15:49 -0500, Pat Haugen via Gcc-patches wrote:
> Update prefixed attribute for Power10.
>
> This patch creates a new attribute, prepend_prefixed_insn, which is
> used to mark
> those instructions that are prefixed and need to have a 'p' prepended
> to their
> mnemonic at asm
No feedback for 2 weeks, and we already verified this with our
internal CI system for a while, so I go ahead committed to trunk now.
On Fri, Mar 5, 2021 at 12:48 PM Kito Cheng wrote:
>
> From: Sinan Lin
>
> Third operand of cpymem pattern is unsigned HOST_WIDE_INT, however we
> are interpret tha
On Thu, 2021-03-18 at 09:21 +0800, HAO CHEN GUI wrote:
> David & Segher,
>
> Thanks so much for your explanation. My patch wants to enables the
> constant anchor on rs6000 as TARGET_ANCHOR_CONST or targetm.anchor_const
> is undefined. I realized that we have addi and addis instructions. So
> Can you use wide_ints instead of building trees here please?
Note that this will reject array types whose lower bound is not fixed, but the
wide_int version is attached.
PR middle-end/99641
* fold-const.c (native_encode_initializer) : For an
array type, do the computat
This patch has no functional changes; it merely cleans up some warning
messages.
Thanks to Jan-Benedict for pointing them out, off-list.
Andrew
amdgcn: Silence warnings in gcn.c
This fixes a few cases of "unquoted identifier or keyword", one "spurious
trailing punctuation sequence", and a "m
Please disregard this patch: I'll resubmit it as part of a larger
series, based on similar patches I sent ~1 year ago.
On Wed, 17 Mar 2021 at 19:25, Christophe Lyon
wrote:
>
> Function stacktest1 in bfloat16_scalar_1_1.c test requires
> -mfloat-abi=hard for the associated check-function-bodies to
This patch adds proper lambda capturing of pointer and reference variables
as specified in OpenMP 5.0. We map the entire closure object as a to-map,
attach pointers to zero-length array sections, and perform mapping of
references.
The main way of implementation is by tree-walk when finishing proc
As discussed in the r11-7709 patch, we can now make sure that tsubst
never sees a FLOAT_EXPR, much like its counterpart FIX_TRUNC_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* pt.c (tsubst_copy_and_build): Add assert.
---
gcc/cp/pt.c | 2 ++
1 file changed, 2
On 3/18/21 11:33 AM, will schmidt wrote:
> Per this change:
>
> +;; Whether an insn is a prefixed insn. A prefixed instruction has a prefix
> +;; instruction word that conveys additional information such as a larger
> +;; immediate, additional operands, etc., in addition to the normal
> instruct
This is an additional patch for PR99422:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit a4670f58ebff805e35268542aac35f9791980954
Author: Vladimir N. Makarov
Date: Thu Mar 18 15:58:26 2021 -0400
Hi Andrew,
On Thu, 2021-03-18 17:41:59 +, Andrew Stubbs wrote:
> gcc/ChangeLog:
>
> (gcn_vectorize_vec_perm_const): Ensure perm is fully uninitialized.
I guess "initialized" is ment here?
MfG, JBG
--
signature.asc
Description: PGP signature
On Thu, Mar 18, 2021 at 11:35 AM Marek Polacek via Gcc-patches
wrote:
>
> As discussed in the r11-7709 patch, we can now make sure that tsubst
> never sees a FLOAT_EXPR, much like its counterpart FIX_TRUNC_EXPR.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> gcc/cp/ChangeLog:
>
> *
On 3/10/21 4:14 PM, Anthony Sharp wrote:
Hiya
That's because none of the names are overloaded within a single base
class.
Ah, thanks. Thought there must be something I wasn't thinking of.
Also, you can use == instead of cp_tree_equal for comparing FUNCTION_DECLs.
Changed it.
Latest patch
On Thu, Mar 18, 2021 at 02:04:59PM -0700, H.J. Lu wrote:
> On Thu, Mar 18, 2021 at 11:35 AM Marek Polacek via Gcc-patches
> wrote:
> >
> > As discussed in the r11-7709 patch, we can now make sure that tsubst
> > never sees a FLOAT_EXPR, much like its counterpart FIX_TRUNC_EXPR.
> >
> > Tested x86_
On 3/9/21 10:31 AM, Jakub Jelinek wrote:
Hi!
My PR82304/PR95307 fix moved reinterpret cast from pointer to integer
diagnostics from cxx_eval_outermost_constant_expr where it caught
invalid code only at the outermost level down into
cxx_eval_constant_expression.
Unfortunately, it regressed follow
On Linux/x86_64,
c5e55673b486533c4d6d19ac903460f70b48f11a is the first bad commit
commit c5e55673b486533c4d6d19ac903460f70b48f11a
Author: Marek Polacek
Date: Wed Mar 17 19:39:10 2021 -0400
c++: Add assert to tsubst.
caused
FAIL: g++.dg/torture/pr85013.C -O0 (internal compiler error)
F
Fixed now.
On Thu, Mar 18, 2021 at 02:40:19PM -0700, sunil.k.pandey via Gcc-patches wrote:
> On Linux/x86_64,
>
> c5e55673b486533c4d6d19ac903460f70b48f11a is the first bad commit
> commit c5e55673b486533c4d6d19ac903460f70b48f11a
> Author: Marek Polacek
> Date: Wed Mar 17 19:39:10 2021 -0400
>
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564483.html
The review of this patch digressed into a design discussion of a new,
more capable implementation of -Wstrict-aliasing, but the proposed
patch turning just this one instance of -Warray-bounds into
-Wstrict-aliasing and makin
On 3/14/2021 8:03 AM, Iain Buclaw via Gcc-patches wrote:
Excerpts from Iain Sandoe's message of March 13, 2021 6:09 pm:
Hi Iain,
Iain Buclaw via Gcc-patches wrote:
This patch fixes an ICE caused by emutls routines generating a weak,
non-public symbol for storing the initializer of a weak T
If we never generate function body, we shouldn't issue errors for return
nor argument. Add init_cumulative_args_called to i386 machine_function
to avoid issuing errors for return and argument without function body.
gcc/
PR target/99652
* config/i386/i386.c (init_cumulative_args):
On 3/9/21 10:22 PM, Marek Polacek wrote:
This fixes an ICE on invalid code where one of the parameters was
error_mark_node and thus resetting its DECL_CONTEXT crashed.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
Jason
gcc/cp/ChangeLog:
PR c++/99500
* pa
Hi,
As Segher and Mike pointed out, the define_insn_and_split should avoid
to use empty split condition if the condition for define_insn isn't empty,
otherwise it can sometimes leads to unexpected consequence.
This patch is to fix some places like this.
Bootstrapped/regtested on powerpc64le-linu
On 3/10/2021 5:21 AM, Matthias Klose wrote:
The gcc man page currently has untranslated @tie{} patterns in the man page.
Just replace these with a white space. Ok for the trunk and branches?
Matthias
--- a/contrib/texi2pod.pl
+++ b/contrib/texi2pod.pl
@@ -210,6 +210,7 @@ while(<$inf>) {
The split in ssse3_pshufbv8qi3 forces a const vector into the constant
pool, and loads from it. That runs after reload, so if the load
requires any reloading, we're out of luck. Indeed, if the load
address is not legitimate, e.g. -mcmodel=large, the insn is no longer
recognized.
This patch tur
63 matches
Mail list logo
