Hi!
On the following testcase, we emit "did you mean '__dt '?" in the error
message. "__dt " shows there because it is dtor_identifier, but we
shouldn't suggest those to the user, they are purely internal and can't
be really typed by the user because of the final space in it.
Bootstrapped/regtes
On Mon, Mar 7, 2022 at 5:37 PM Richard Biener via Gcc-patches
wrote:
>
> On Fri, Mar 4, 2022 at 8:27 AM liuhongt wrote:
> >
> > For parameter passing through stack, vectorized load from parm_decl
> > in callee may trigger serious STF issue. This is why GCC12 regresses
> > 50% for cray at -O2 comp
From: LiaoShihua
The crypto extension have several shorthand extensions that don't consist of
any extra instructions.
Take zk for example, while the extension would imply zkn, zkr, zkt.
The 3 extensions should also combine back into zk to maintain the canonical
order in isa strings.
This patch
Currently, libatomic's _sync_fetch_and_#op# and
__sync_val_compare_and_swap methods are not sufficiently strong for the
ATOMIC_SEQ_CST memory model.
This can be shown using the following Herd litmus test:
RISCV LRSC-LIB-CALL
{
0:x6=a; 0:x8=b; 0:x10=c;
1:x6=a; 1:x8=b; 1:x10=c;
}
P0
ping^1
On Fri, Feb 25, 2022 at 1:51 PM Hongtao Liu wrote:
>
> On Fri, Feb 25, 2022 at 1:50 PM liuhongt wrote:
> >
> > The patch fixes ICE in ix86_gimple_fold_builtin.
> >
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> Ok for main trunk?
>
> > gcc/ChangeLog:
> >
> > PR target/
On Mon, Mar 07, 2022 at 07:03:17PM -0500, Marek Polacek via Gcc-patches wrote:
> In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can
> jump to a label, the insn should be a JUMP_INSN.
>
> However, as the following testcase shows, non-null ASM_OPERANDS_LABEL_VEC
> doesn't guara
In r270550, Jakub fixed classify_insn to handle asm goto: if the asm can
jump to a label, the insn should be a JUMP_INSN.
However, as the following testcase shows, non-null ASM_OPERANDS_LABEL_VEC
doesn't guarantee that the rtx has any actual labels it can branch to.
Here, the rtvec has 0 elements
On 3/7/22 08:55, Roger Sayle wrote:
This patch fixes PR c++/96440 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03
On 3/7/22 08:04, Roger Sayle wrote:
This patch fixes PR c++/96329 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03
On 3/7/22 08:33, Roger Sayle wrote:
This patch fixes PR c++/96437 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03
Currently, libatomic's _sync_fetch_and_#op# and
__sync_val_compare_and_swap methods are not sufficiently strong for the
ATOMIC_SEQ_CST memory model.
This can be shown using the following Herd litmus test:
RISCV LRSC-LIB-CALL
{
0:x6=a; 0:x8=b; 0:x10=c;
1:x6=a; 1:x8=b; 1:x10=c;
}
P0
On 2/27/22 18:52, Jason Merrill wrote:
The patch for PR90451 deferred marking to the point of actual use; we missed
this one because of the parens.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104618
gcc/cp/ChangeLog:
* typeck.cc (cp_build_addr_expr_1): Also
m
On Sun, Mar 6, 2022 at 11:11 PM wrote:
>
> +#ifdef __PPC64__
> + ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gp_regs[32];
> +#else
> + ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[32];
> +#endif
Have you tested this in 32-bit mode? It does not look correct based
on t
On Mon, Mar 07, 2022 at 08:53:42PM +, Joseph Myers wrote:
> This breaks the build of libgcc for powerpc-linux-gnu (32-bit, default
> CPU; configured --disable-multilib --enable-secureplt).
>
> cc1: warning: The '-mfloat128' option may not be fully supported
> /tmp/ccHCPzSh.s: Assembler messag
Hi!
On Sat, Mar 05, 2022 at 09:21:51AM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, right now on powerpc* __SIZEOF_{FLOAT,IBM}128__
> macros are predefined unconditionally, because {ieee,ibm}128_float_type_node
> is always non-NULL, doesn't reflect whether __ieee128 or __ibm128 are
> actu
This breaks the build of libgcc for powerpc-linux-gnu (32-bit, default
CPU; configured --disable-multilib --enable-secureplt).
cc1: warning: The '-mfloat128' option may not be fully supported
/tmp/ccHCPzSh.s: Assembler messages:
/tmp/ccHCPzSh.s:163: Error: unrecognized opcode: `lfiwzx'
/scratch/j
Bootstrapped and regtested on mips64el-linux-gnuabi64.
I'm not sure if it's "correct" to clobber other registers during the
zeroing of scratch registers. But I can't really come up with a better
idea: on MIPS there is no simple way to clear one bit in FCSR (i. e.
FCC[x]). We can't just use "c.f.
On Fri, 2022-03-04 at 15:18 +0800, xucheng...@loongson.cn wrote:
> * config/loongarch/loongarch.md: New file.
An ICE happens building OpenSSH-8.9p1. Investigation shows it's caused
by the flag "-fzero-call-used-regs=". It's because the compiler
attempts to clear FCCx registers but can't
Hi Tobias,
Am 07.03.22 um 15:01 schrieb Tobias Burnus:
The problem is that inside the main program,
y = f(z)
where the the result of z is
type(t) :: z(size(x%a))
and 'x' is a dummy argument.
'x' looses the attr.dummy in gfc_add_interface_mapping
and this leads to an additional indirect re
PR analyzer/101983 reports what I thought were false positives
from -Wanalyzer-malloc-leak, but on closer inspection, the
analyzer is correctly reporting heap-allocated buffers that are
no longer reachable.
However, these "leaks" occur at the end of "main". The analyzer already
has some logic to
On 3/7/22 10:47, Patrick Palka wrote:
On Fri, 4 Mar 2022, Jason Merrill wrote:
On 3/4/22 14:24, Patrick Palka wrote:
Here we're failing to communicate to cp_finish_decl from tsubst_expr
that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING
flag), which causes do_class_dedu
On 3/7/22 14:41, Patrick Palka wrote:
instantiate_non_dependent_expr_sfinae instantiates only potentially
constant expressions
Hmm, that now strikes me as a problematic interface, as we don't know
whether what we get back is template or non-template trees.
Maybe we want to change instantiate
instantiate_non_dependent_expr_sfinae instantiates only potentially
constant expressions, but when processing a non-dependent decltype
operand we want to instantiate it even if it's non-constant since
such non-dependent decltype is always resolved ahead of time.
Currently finish_decltype_type uses
Hi,
Some comments below, but otherwise it looks good to me.
A few of the comments are about removing hook or macro definitions
that are the same as the default. Doing that helps people who want
to update a hook interface in future, since there are then fewer
places to adjust.
xucheng...@loongso
I saw that Jakub fixed some typos/duplicated words, I thought
I could do likewise – and I found some more in gcc/fortran.
Committed as r12-7524.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung;
Ok, please include PR 104790 in the ChangeLog.
Thanks,
Kyrill
From: Andre Vieira (lists)
Sent: Monday, March 7, 2022 2:17 PM
To: Kyrylo Tkachov
Cc: GCC Patches
Subject: Re: [arm] MVE: Relax addressing modes for full loads and stores
On 17/01/2022 07:48, Christophe Lyon wrote:
Hi André,
On Fri
Discussed with Jason and then committed as obvious.
-- >8 --
As C++20 has already been published, we don't need to link to the draft
(which is now the C++23 draft anyway). And there's no need to say it's
part of the C++20 spec, or that there might be defect reports. That's
true for everything in
On Sat, 5 Mar 2022 at 20:34, Jonathan Wakely via Libstdc++
wrote:
>
> Tested powerpc64le-linux, pushed to trunk.
>
> -- >8 --
>
> This ensures there's no linker error if libstdc++ headers are included
> following a pragma that sets hidden visibility.
>
> Similarly for std::__terminate, which is al
On Mon, Mar 7, 2022 at 6:23 AM Jakub Jelinek wrote:
>
> On Mon, Mar 07, 2022 at 05:57:40AM -0800, H.J. Lu via Gcc-patches wrote:
> > --- a/gcc/config/i386/i386.cc
> > +++ b/gcc/config/i386/i386.cc
> > @@ -9444,9 +9444,8 @@ ix86_expand_epilogue (int style)
> > rtx sa = EH_RETURN_STACKADJ_RT
Since eh_return doesn't work with stack realignment, disable SSE on
unwind-c.c and unwind-dw2.c to avoid stack realignment with the 4-byte
incoming stack to avoid SSE usage which is caused by
commit 609e8c492d62d92465460eae3d43dfc4b2c68288
Author: H.J. Lu
Date: Sat Feb 26 14:17:23 2022 -0800
On Fri, 4 Mar 2022, Jason Merrill wrote:
> On 3/4/22 14:24, Patrick Palka wrote:
> > Here we're failing to communicate to cp_finish_decl from tsubst_expr
> > that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING
> > flag), which causes do_class_deduction to always consider exp
Hi!
After more than 2 years I've run my
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00844.html
script again. While it has lots of false positives, it discovered
two bugs.
Committed to trunk as obvious.
2022-03-07 Jakub Jelinek
gcc/c/
* c-parser.cc (c_parser_omp_clause_map): Add mi
On Mon, Mar 07, 2022 at 05:57:40AM -0800, H.J. Lu via Gcc-patches wrote:
> --- a/gcc/config/i386/i386.cc
> +++ b/gcc/config/i386/i386.cc
> @@ -9444,9 +9444,8 @@ ix86_expand_epilogue (int style)
> rtx sa = EH_RETURN_STACKADJ_RTX;
> rtx_insn *insn;
>
> - /* %ecx can't be used
On 17/01/2022 07:48, Christophe Lyon wrote:
Hi André,
On Fri, Jan 14, 2022 at 6:03 PM Andre Vieira (lists) via Gcc-patches
wrote:
Hi Christophe,
This patch relaxes the addressing modes for the mve full load and
stores
(by full loads and stores I mean non-widening or narrowin
Pre-remark: Related NULL, there some accepts-invalid issues, not addressed in
this
patch. See https://gcc.gnu.org/PR104819
This patch fixes an ICE (12 regression) with NULL() that has no MOLD argument.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschri
Hi!
Like in r10-7215-g700d4cb08c88aec37c13e21e63dd61fd698baabc 2 years ago,
I've run
grep -v 'long long\|optab optab\|template template\|double double' *.{[chS],cc}
*/*.{[chS],cc} *.def config/*/* 2>/dev/null | grep ' \([a-zA-Z]\+\) \1 '
and for the cases that looked clearly wrong changed them, m
The problem is that inside the main program,
y = f(z)
where the the result of z is
type(t) :: z(size(x%a))
and 'x' is a dummy argument.
'x' looses the attr.dummy in gfc_add_interface_mapping
and this leads to an additional indirect ref in
gfc_maybe_dereference_var - but after the first indire
On Sun, Mar 6, 2022 at 10:07 AM Eric Botcazou wrote:
>
> > PR target/104781
> > * config.host (tmake_file): Add i386/32/t-eh-return-no-sse for
> > 32-bit x86 Cygwin and Solaris.
> > * config/i386/32/t-eh-return-no-sse: New file.
>
> What about MinGW here?
It should be incl
Since eh_return doesn't work with stack realignment, disable SSE on
unwind-c.c and unwind-dw2.c to avoid stack realignment with the 4-byte
incoming stack to avoid SSE usage which is caused by
commit 609e8c492d62d92465460eae3d43dfc4b2c68288
Author: H.J. Lu
Date: Sat Feb 26 14:17:23 2022 -0800
On Fri, Mar 4, 2022 at 2:12 PM Martin Liška wrote:
>
> On 3/1/22 09:48, Richard Biener wrote:
> > I think moving flag_gtoggle handling before the flag_syntax_only handling
> > is a good thing. But I don't quite understand the flag_var_tracking
> > disabling
> > or how it worked before.
>
> Well,
On Wed, Mar 2, 2022 at 10:18 PM H.J. Lu wrote:
>
> On Wed, Mar 02, 2022 at 09:51:26AM +0100, Richard Biener wrote:
> > On Tue, Mar 1, 2022 at 11:41 PM H.J. Lu via Gcc-patches
> > wrote:
> > >
> > > Add TARGET_FOLD_MEMCPY_MAX for the maximum number of bytes to fold memcpy.
> > > The default is
> >
On 3/7/22 14:14, Richard Earnshaw wrote:
Wasn't the complaint also that there should be a space in the text between the 'and"'
and the '"%<' on the subsequent line?
Yeah, I overlooked that.
I'm going to push the following patch.
Cheers,
MartinFrom b1d8198e7df616ea80cb648a2c831e2c21f4319f Mon
On 07/03/2022 10:27, Martin Liška wrote:
This fixes option quoting in error messages.
Ready to be installed?
Thanks,
Martin
PR target/104794
gcc/ChangeLog:
* config/arm/arm.cc (arm_option_override_internal): Fix quoting
of options in error messages.
(arm_option_reconfig
This patch fixes PR c++/96440 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03-07 Roger Sayle
gcc/cp/ChangeLog
This patch fixes PR c++/96437 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03-07 Roger Sayle
gcc/cp/ChangeLog
This patch fixes PR c++/96329 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03-07 Roger Sayle
gcc/cp/ChangeLog
On Mon, Mar 07, 2022 at 11:51:50AM -, Roger Sayle wrote:
> I agree that for completeness similar peepholes handling inserts into
> SImode would be a good thing, but these wouldn't be restricted by
> TARGET_64BIT and would therefore require additional -m32 testing.
> The DImode peepholes I can
Hi Uros,
> Is there a reason that only inserts to DImode registers are implemented?
> IMO, these peepholes should also handle inserts to SImode.
I wasn't able to construct a test case that produced a byte or word insert
into an SImode register. The front-ends and middle-end end up producing
di
This reverts the reversion of r10-5979 amending the CTOR case
with a comment as to why the conversion is not necessary there.
It also adds a testcase (but not for the CTOR case).
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-03-07 Richard Biener
PR tree-optimizatio
On Mon, Mar 7, 2022 at 6:11 AM liuhongt wrote:
>
> >What happens if you set preferred_for_speed to false for alternative 1?
> It works, and I've removed the newly added splitter in this patch.
> Also i tried to do similar things to *vec_dup with mode iterator
> AVX2_VEC_DUP_MODE, but it hit ICE d
On Mon, Mar 7, 2022 at 11:55 AM Roger Sayle wrote:
>
>
> This patch is the backend piece of my proposed fix to PR tree-opt/98335,
> to allow C++ partial struct initialization to be as efficient/optimized
> as full struct initialization.
>
> With the middle-end patch just posted to gcc-patches, the
This patch is the backend piece of my proposed fix to PR tree-opt/98335,
to allow C++ partial struct initialization to be as efficient/optimized
as full struct initialization.
With the middle-end patch just posted to gcc-patches, the test case
in the PR compiles on x86_64-pc-linux-gnu with -O2 to
PR target/104797
gcc/ChangeLog:
* config/msp430/msp430.cc (msp430_expand_delay_cycles): Remove
parenthesis from built-in name.
---
gcc/config/msp430/msp430.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/msp430/msp430.cc b/gcc/config/msp
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Martin Liška
> Sent: Monday, March 7, 2022 10:28 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Christophe Lyon
> Subject: [PATCH] arm: fix option quoting in error messages.
>
> This fixes option
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Martin Liška
> Sent: Monday, March 7, 2022 10:22 AM
> To: Christophe Lyon ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH][ARM] translation: reuse string and use switch for codes
>
> On 3/7
This fixes option quoting in error messages.
Ready to be installed?
Thanks,
Martin
PR target/104794
gcc/ChangeLog:
* config/arm/arm.cc (arm_option_override_internal): Fix quoting
of options in error messages.
(arm_option_reconfigure_globals): Likewise.
---
gcc/
On 3/7/22 11:18, Christophe Lyon via Gcc-patches wrote:
Hi!
On 3/7/22 11:09, Martin Liška wrote:
Hi.
The patch simplifies translation strings.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
This is an arm-only patch, it's not clear if you built a cross-compiler for
a
Hi!
On 3/7/22 11:09, Martin Liška wrote:
Hi.
The patch simplifies translation strings.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
This is an arm-only patch, it's not clear if you built a cross-compiler
for arm, and that these regression tests passed?
Ready to b
On 3/7/22 11:12, Jakub Jelinek wrote:
Will defer review to ARM maintainers, just wanted to mention some of the
lines are way too long (before or after).
Sure, fixed in V3.
MartinFrom 34a195d905bb1719e13c2021ee475a0581b62a5b Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 7 Mar 2022 10:
Hello.
There's V2 where I fixed fact that:
ARM_BUILTIN_WRORHI || fcode == ARM_BUILTIN_WRORH can have valid range on [1,
16].
Ready to be installed?
Thanks,
MartinFrom 879262c3a7aefd3ab9552cec881248b240f53818 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 7 Mar 2022 10:56:43 +0100
Subj
On Mon, Mar 07, 2022 at 11:09:26AM +0100, Martin Liška wrote:
> gcc/ChangeLog:
>
> * config/arm/arm-builtins.cc (arm_expand_builtin): Reuse error
> message.
Will defer review to ARM maintainers, just wanted to mention some of the
lines are way too long (before or after).
> --- a/gcc/
On 3/5/22 09:33, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
> insn not being accepted by assembler.
> My rough understanding is that in the RSY-b insn format the spot
> in other formats used for index registers is used instead for M3 what
>
Hi.
The patch simplifies translation strings.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* config/arm/arm-builtins.cc (arm_expand_builtin): Reuse error
message.
---
gcc/config/arm/arm-builtins.cc
This patch is the main middle-end piece of a fix for PR tree-opt/98335,
which is a code-quality regression affecting mainline. The issue occurs
in DSE's (dead store elimination's) compute_trims function that determines
where a store to memory can be trimmed. In the testcase given in the
PR, this
On Fri, Mar 4, 2022 at 8:27 AM liuhongt wrote:
>
> For parameter passing through stack, vectorized load from parm_decl
> in callee may trigger serious STF issue. This is why GCC12 regresses
> 50% for cray at -O2 compared to GCC11.
>
> The patch add an extremely large number to stmt_cost to prevent
On Mon, Mar 07, 2022 at 10:15:48AM +0800, Hongtao Liu wrote:
> > Note, the predicates on cond_fma* and other FMA variants look all wrong to
> > me, usually the fma instructions require nonimmediate_operand operands,
> > but the cond_* patterns use vector_operand. Besides what this patch
>
On Fri, Mar 4, 2022 at 3:28 PM liuhongt via Gcc-patches
wrote:
>
> For parameter passing through stack, vectorized load from parm_decl
> in callee may trigger serious STF issue. This is why GCC12 regresses
> 50% for cray at -O2 compared to GCC11.
>
> The patch add an extremely large number to stmt
67 matches
Mail list logo
