On 3/8/22 22:51, Martin Jambor wrote:
Hi,
when writing the patch that downgrades address-taken references to
load references when IPA-CP can prove that all uses of the taken
address ends up in loads, I unfortunately did not take into account
that find_more_scalar_values_for_callers_subset now
On Wed, Mar 9, 2022 at 7:10 PM Roger Sayle wrote:
>
>
> Hi Uros,
> Firstly many thanks for already (pre)approving half of this patch. Jakub
> Jelinek's
> suggestion for creating a testcase that exposes the SImode issue was extremely
> helpful, but interestingly exposed another missed
On Thu, 10 Mar 2022, Jiufu Guo wrote:
>
> Hi!
>
> Richard Biener writes:
>
> > On Wed, 9 Mar 2022, Jiufu Guo wrote:
> >
> >>
> >> Hi!
> >>
> >> Richard Biener writes:
> >>
> >> > On Tue, 8 Mar 2022, Jiufu Guo wrote:
> >> >
> >> >> Jiufu Guo writes:
> >> >>
> >> >> Hi!
> >> >>
> >> >> >
Hi Richard,
> 2022-03-09 Roger Sayle
> Richard Biener
>
> gcc/ChangeLog
> PR tree-optimization/98335
> * builtins.cc (get_object_alignment_2): Export.
> * builtins.h (get_object_alignment_2): Likewise.
> * tree-ssa-alias.cc (ao_ref_alignment): New.
>
Hi,
This patch adds V1TI mode into mode iterator used in vector comparison
expands.With the patch, both built-ins and direct comparison could generate
P10 new V1TI comparison instructions.
Bootstrapped and tested on ppc64 Linux BE and LE with no regressions. Is
this okay for trunk? Any
Hi,
We are modifying the code, this support will be
added in the next commit.
Thanks.
在 2022/3/8 上午4:15, Xi Ruoyao 写道:
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.
On 2/21/22 08:17, Roger Sayle wrote:
This patch resolves PR c++/95999 which is an ICE-after-error regression
in the g++ front-end. When parsing an enumerator list, the C++ parser
assumes that cp_parser_constant_expression always returns either an
INTEGER_CST or error_mark_node, but in testcase
On 2/22/22 08:02, Roger Sayle wrote:
This patch resolves PR c++/96442, another ICE-after-error regression.
In this case, invalid code attempts to use a non-integral type as the
underlying type for an enumeration (a record_type in the example given
in the bugzilla PR), for which the parser emits
On 2/26/22 19:55, Roger Sayle wrote:
This is a fix for PR c++/39751 which is an ICE-on-invalid regression in
the C++ parser after encountering the end of file. The one line change
is to check that the tokens cached in DECL_PENDING_INLINE_INFO haven't
been purged before processing them in
On 3/9/22 10:39, Patrick Palka wrote:
On Tue, 8 Mar 2022, Jason Merrill wrote:
On 3/2/22 14:32, Patrick Palka wrote:
In order to be able to perform CTAD for a dependently-scoped template
such as A::B in the testcase below, we need to permit a
typename-specifier to resolve to a template as per
On 3/9/22 11:22, Marek Polacek wrote:
On Tue, Mar 08, 2022 at 02:47:42PM -0500, Jason Merrill wrote:
On 3/2/22 14:31, Marek Polacek wrote:
104752 points out that
template
concept C = true;
auto y = C auto(1);
is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type
On 3/9/22 14:09, Marek Polacek wrote:
This is an ICE-on-invalid with "auto operator delete[] (void *)" whose
return type must be void. The return type is checked in coerce_delete_type
but we never got there in this test, because we took the wrong path in
grokdeclarator, set type to
On 3/9/22 14:35, Roger Sayle wrote:
Hi Jason,
Very many thanks for your reviews/approvals of these ICE-on-invalid-code fixes.
+ if (TREE_VALUE (new_parm) != error_mark_node)
+DECL_VIRTUAL_P (TREE_VALUE (new_parm)) = true;
Hmm, I wonder about returning early if there was an error, but
On 3/1/22 17:12, Marek Polacek wrote:
On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote:
On 2/22/22 17:46, Marek Polacek wrote:
Here we have a forward declaration of Parameter for which we create
an implicit typedef, which is a TYPE_DECL. Then, when looking it up
at template
On 3/1/22 18:08, Patrick Palka wrote:
A well-formed call to std::move/forward is equivalent to a cast, but the
former being a function call means it comes with bloated debug info, which
persists even after the call has been inlined away, for an operation that
is never interesting to debug.
This
Eliminate power8 fusion options, use power8 tuning, PR target/102059
The power8 fusion support used to be set automatically when -mcpu=power8 or
-mtune=power8 was used, and it was cleared for other cpu's. However, if you
used the target attribute or target #pragma to change the default cpu type
Hi!
Richard Biener writes:
> On Wed, 9 Mar 2022, Jiufu Guo wrote:
>
>>
>> Hi!
>>
>> Richard Biener writes:
>>
>> > On Tue, 8 Mar 2022, Jiufu Guo wrote:
>> >
>> >> Jiufu Guo writes:
>> >>
>> >> Hi!
>> >>
>> >> > Hi Sehger,
>> >> >
>> >> > Segher Boessenkool writes:
>> >> >
>> >> >> On
The size argument larger than size of SRC for strnlen and strndup is
problematic only if SRC is not NULL terminated, which invokes undefined
behaviour. In all other cases, as long as SRC is large enough to have a
NULL char (i.e. size 1 or more), a larger N should not invoke a warning
during
We need to be explicit about narrowing conversions from uint128_t since,
on targets that lack __int128, this type is defined as an integer-class
type that is only _explicitly_ convertible to the builtin integer types.
This issue was latent until r12-7563-ge32869a17b788b made the frontend
correctly
On Wed, Mar 09, 2022 at 10:10:07PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 09, 2022 at 02:57:20PM -0600, Segher Boessenkool wrote:
> > But __ibm128 should *always* be supported, so this is a hypothetical
> > problem.
>
> I bet that will require much more work. I think for the barely supported
In commit cc806126215c3f4dc187eff3bf923458d8cc6b4f, I implemented
changes that C2x had made to compatibility of unprototyped and
prototyped function types.
C2x has since completely removed unprototyped function types, making
() in a function declaration mean (void) as in C++. While that change
On Wed, Mar 09, 2022 at 02:57:20PM -0600, Segher Boessenkool wrote:
> But __ibm128 should *always* be supported, so this is a hypothetical
> problem.
I bet that will require much more work. I think for the barely supported
(or really unsupported?) case of old sysv IEEE quad or for when long
Dear all,
referencing an invalid array section could lead to a NULL pointer
dereference. Testcase by Gerhard.
Committed to mainline as obvious after regtesting as
https://gcc.gnu.org/g:22015e77d3e45306077396b9de8a8a28bb67fb20
Thanks,
Harald
From 22015e77d3e45306077396b9de8a8a28bb67fb20 Mon
On Wed, Mar 09, 2022 at 08:24:24PM +0100, Jakub Jelinek wrote:
> On Wed, Mar 09, 2022 at 12:34:06PM -0600, Segher Boessenkool wrote:
> > > rs6000_expand_builtin has (but at an incorrect spot) code to remap
> > > __builtin_{,un}pack_ibm128 to __builtin_{,un}pack_longdouble under the
> > > hood,
>
On Wed, Mar 09, 2022 at 12:34:06PM -0600, Segher Boessenkool wrote:
> It is a common idiom anyway, much clearer than any macro :-) (But no
> parens please? sizeof is an operator, not a function).
Ok, changed in my copy.
> > > > +{ "if","ibm128_float_type_node "
> > > > +
Hi Jason,
Very many thanks for your reviews/approvals of these ICE-on-invalid-code fixes.
> > + if (TREE_VALUE (new_parm) != error_mark_node)
> > +DECL_VIRTUAL_P (TREE_VALUE (new_parm)) = true;
>
> Hmm, I wonder about returning early if there was an error, but this is fine
> as is.
The
Hi!
On Wed, Mar 09, 2022 at 02:27:19PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 07, 2022 at 03:37:18PM -0600, Segher Boessenkool wrote:
> > > 2) adjusts the builtins code to use
> > >ibm128_float_type_node ? ibm128_float_type_node : long_double_type_node
> > >for the 2 builtins, so that
Xi Ruoyao writes:
> 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.
>
Hi Uros,
Firstly many thanks for already (pre)approving half of this patch. Jakub
Jelinek's
suggestion for creating a testcase that exposes the SImode issue was extremely
helpful, but interestingly exposed another missed optimization opportunity
that's
also addressed with this revision of my
This is an ICE-on-invalid with "auto operator delete[] (void *)" whose
return type must be void. The return type is checked in coerce_delete_type
but we never got there in this test, because we took the wrong path in
grokdeclarator, set type to error_mark_node, ended up creating a FIELD_DECL
with
On Wed, 9 Mar 2022 at 17:40, Patrick Palka wrote:
>
> On Wed, Mar 9, 2022 at 8:54 AM Mikael Morin wrote:
> >
> > Hello,
> >
> > Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
> > > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in
> > > release branch
On Wed, Mar 9, 2022 at 12:25 AM Richard Biener
wrote:
>
> On Tue, Mar 8, 2022 at 4:44 PM H.J. Lu wrote:
> >
> > On Mon, Mar 7, 2022 at 5:45 AM Richard Biener
> > wrote:
> > >
> > > On Wed, Mar 2, 2022 at 10:18 PM H.J. Lu wrote:
> > > >
> > > > On Wed, Mar 02, 2022 at 09:51:26AM +0100, Richard
Richard Biener via Gcc-patches writes:
> 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
On Wed, Mar 09, 2022 at 12:40:24PM -0500, Patrick Palka via Gcc-patches wrote:
> On Wed, Mar 9, 2022 at 8:54 AM Mikael Morin wrote:
> > Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
> > > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in
> > > release branch
Hi Richard,
Many thanks. Yes, your proposed ao_ref_alignment is exactly what I was looking
for.
Here's the second revision of my patch for PR tree-optimization/98335 that both
uses/
introduces ao_ref_alignment and more intelligently aligns/trims both head and
tail,
for example handling the
On Wed, Mar 9, 2022 at 8:54 AM Mikael Morin wrote:
>
> Hello,
>
> Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
> > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in release
> > branch numbers, where
> > a leading zero does not occur.
> >
> Note that you also
> Am 09.03.2022 um 17:54 schrieb Hans-Peter Nilsson via Gcc-patches
> :
>
> Tom Tromey ok'd this for the sourceware side, but thinks I
> need explicit approval on the gcc side. Ok to commit?
>
> --- Start of forwarded message ---
> From: Hans-Peter Nilsson
> To:
On Wed, 9 Mar 2022 at 14:01, Mikael Morin wrote:
>
> Hello,
>
> Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
> > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in release
> > branch numbers, where
> > a leading zero does not occur.
> >
> Note that you also
Tom Tromey ok'd this for the sourceware side, but thinks I
need explicit approval on the gcc side. Ok to commit?
--- Start of forwarded message ---
From: Hans-Peter Nilsson
To: "binut...@sourceware.org" ,
"gdb-patc...@sourceware.org"
Subject: [PATCH] toplevel: Makefile.def:
On 09/03/2022 16:29, Tobias Burnus wrote:
This shows up with with OpenMP offloading as libgomp since a couple
of months uses __atomic_compare_exchange (see PR for details),
causing link errors when the gcn libgomp.a is linked.
It also shows up with sollve_vv.
The implementation does a bit
This shows up with with OpenMP offloading as libgomp since a couple
of months uses __atomic_compare_exchange (see PR for details),
causing link errors when the gcn libgomp.a is linked.
It also shows up with sollve_vv.
The implementation does a bit copy'n'paste from the current
implementation +
On Wed, 2022-03-09 at 15:55 +0100, Richard Biener wrote:
> isn't it better to make targetm.const_anchor unsigned?
> The & and ~ are not subject to overflow rules.
It's not enough: if n is the minimum value of HOST_WIDE_INT and
const_anchor = 0x8000 (the value for MIPS), we'll have a signed
On Tue, Mar 08, 2022 at 02:47:42PM -0500, Jason Merrill wrote:
> On 3/2/22 14:31, Marek Polacek wrote:
> > 104752 points out that
> >
> >template
> >concept C = true;
> >auto y = C auto(1);
> >
> > is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type
> > conversion,
>
On 09/03/22 12:15 +, Richard Earnshaw wrote:
The -n option to echo is non-portable. The generally recommended
alternative is to use the shell printf command.
contrib/ChangeLog:
PR other/102664
* gcc-git-customization.sh (ask): Use printf instead of echo -n.
diff --git
On Wed, Mar 9, 2022 at 12:20 PM Xi Ruoyao via Gcc-patches
wrote:
>
> Bootstrapped and tested on mips64el-linux-gnuabi64, and MIPS is the only
> port with a non-zero targetm.const_anchor. Ok for trunk?
>
> -- >8 --
>
> With a non-zero const_anchor, the behavior of this function relied on
> signed
On Wed, Mar 09, 2022 at 10:43:56PM +0800, Chung-Lin Tang wrote:
> when troubleshooting building/running SPEC HPC 2021 with GCC with OpenMP
> offloading,
> specifically 534.hpgmgfv_t, an issue encountered in the benchmark was:
> when the benchmark was initializing and creating its data environment
Hi all,
when troubleshooting building/running SPEC HPC 2021 with GCC with OpenMP
offloading,
specifically 534.hpgmgfv_t, an issue encountered in the benchmark was:
when the benchmark was initializing and creating its data environment on the
GPU,
it was trying to map array sections where the
On Tue, 8 Mar 2022, Jason Merrill wrote:
> On 3/2/22 14:32, Patrick Palka wrote:
> > In order to be able to perform CTAD for a dependently-scoped template
> > such as A::B in the testcase below, we need to permit a
> > typename-specifier to resolve to a template as per [dcl.type.simple]/2,
> > at
On Wed, Mar 09, 2022 at 03:21:53PM +0100, Richard Biener wrote:
> As noticed we are looking for INDIRECT_REF with allows_mem to avoid
> a copy since then we're sure the operand is in memory (assuming
> *& is folded). But INDIRECT_REFs are no longer a thing, the following
> replaces the check with
As noticed we are looking for INDIRECT_REF with allows_mem to avoid
a copy since then we're sure the operand is in memory (assuming
*& is folded). But INDIRECT_REFs are no longer a thing, the following
replaces the check with a check for a MEM_REF with a non-ADDR_EXPR
operand. This should fix
On Wed, 9 Mar 2022 at 13:27, Jakub Jelinek wrote:
> On Mon, Mar 07, 2022 at 03:37:18PM -0600, Segher Boessenkool wrote:
> > > * config/rs6000/rs6000-gen-builtins.cc (TYPE_MAP_SIZE): Set to
> > > 85 instead of 86.
> >
> > This should be auto-generated, or just not exist at all
> > ("sizeof
Hello,
Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in release
branch numbers, where
a leading zero does not occur.
Note that you also changed some gcc-[0-9]* to gcc-[1-9]*, which is a
typo/thinko I guess?
This adjusts gcc.dg/vect/vect-multitypes-12.c to just look for the
interesting loop vectorization.
tested on x86_64-unknown-linux-gnu, pushed.
2022-03-09 Richard Biener
PR testsuite/104759
* gcc.dg/vect/vect-multitypes-12.c: Adjust.
---
On Mon, Mar 07, 2022 at 03:37:18PM -0600, Segher Boessenkool 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
On Fri, Feb 11, 2022 at 12:05 AM Martin Sebor via Gcc-patches
wrote:
>
> On 2/8/22 15:37, Jason Merrill wrote:
> > On 2/8/22 16:59, Martin Sebor wrote:
> >> Transforming a by-value arguments to by-reference as GCC does for some
> >> class types can trigger -Wdangling-pointer when the argument is
On 2/22/22 14:55, Tom de Vries wrote:
Hi,
For the nvptx port, with -mptx-comment we have in pr53465.s:
...
// #APP
// 9 "gcc/testsuite/gcc.c-torture/execute/pr53465.c" 1
// Start: Added by -minit-regs=3:
// #NO_APP
mov.u32 %r26, 0;
// #APP
//
The -n option to echo is non-portable. The generally recommended
alternative is to use the shell printf command.
contrib/ChangeLog:
PR other/102664
* gcc-git-customization.sh (ask): Use printf instead of echo -n.diff --git a/contrib/gcc-git-customization.sh
On Wed, Mar 09, 2022 at 08:26:11AM +0100, Sören Tempel wrote:
> Ian Lance Taylor wrote:
> > Have you tested this in 32-bit mode? It does not look correct based
> > on the glibc definitions. Looking at glibc it seems that it ought to
> > be
>
> As stated in the commit message, I have only
On Wed, Mar 09, 2022 at 12:30:08PM +0100, Richard Biener wrote:
> The following fixes an ICE observed with a MEM_REF allows_mem asm
> operand referencing a VLA. The following makes sure to not attempt
> to go the temporary creation way when we cannot.
>
> 2022-03-09 Richard Biener
>
>
On Wed, 9 Mar 2022, Jakub Jelinek wrote:
> On Wed, Mar 09, 2022 at 08:18:38AM +0100, Richard Biener wrote:
> > I wonder if this is a good case for general-regs-only instead? At
> > least no-sse cannot be functionally equivalent (since then we would
> > not have needed general-regs-only ...).
>
On Wed, 9 Mar 2022, Jakub Jelinek wrote:
> On Wed, Mar 09, 2022 at 11:07:21AM +0100, Richard Biener wrote:
> > The following fixes an ICE observed with a MEM_REF allows_mem asm
> > operand. There's code expecting INDIRECT_REFs that are now never
> > going to appear. The following simply treats
Bootstrapped and tested on mips64el-linux-gnuabi64, and MIPS is the only
port with a non-zero targetm.const_anchor. Ok for trunk?
-- >8 --
With a non-zero const_anchor, the behavior of this function relied on
signed overflow.
gcc/
PR rtl-optimization/104843
* cse.cc
Hi Jakub,
Now in OpenMP 5.x, static members are supposed to be not a barrier for a class
to be target-mapped.
There is the related issue of actually providing access to static
const/constexpr
members on the GPU (probably a case of
https://github.com/OpenMP/spec/issues/2158)
but that is for
On Tue, 2022-03-08 at 18:20 +, Richard Sandiford wrote:
> Xi Ruoyao writes:
> > I think this one obvious. Ok for trunk?
> OK, thanks.
Committed r12-7555.
/* snip */
> > #define LUI_OPERAND(VALUE) \
> > (((VALUE) | 0x7fff) == 0x7fff
On Wed, 2022-03-09 at 09:37 +0100, Richard Biener wrote:
> On Wed, Mar 9, 2022 at 5:06 AM Xi Ruoyao via Gcc-patches
> wrote:
> >
> > This should be obvious, OK for trunk?
>
> OK.
Committed r12-7559.
> > -- >8 --
> >
> > Calling VECTOR_MODE_P with MAX_MACHINE_MODE has caused out-of-bound
> >
On Wed, Mar 09, 2022 at 11:07:21AM +0100, Richard Biener wrote:
> The following fixes an ICE observed with a MEM_REF allows_mem asm
> operand. There's code expecting INDIRECT_REFs that are now never
> going to appear. The following simply treats all tcc_reference
> operands the same.
The
> -Original Message-
> From: Andre Vieira (lists)
> Sent: Tuesday, March 8, 2022 3:16 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Sandiford
>
> Subject: [aarch64] update reg-costs to include predicate move costs
>
> Hi,
>
> This patch adds predicate move costs to
The following fixes an ICE observed with a MEM_REF allows_mem asm
operand. There's code expecting INDIRECT_REFs that are now never
going to appear. The following simply treats all tcc_reference
operands the same.
A more conservative approach would be to use INDIRECT_REF || MEM_REF
which would
On Wed, Mar 09, 2022 at 08:18:38AM +0100, Richard Biener wrote:
> I wonder if this is a good case for general-regs-only instead? At
> least no-sse cannot be functionally equivalent (since then we would
> not have needed general-regs-only ...).
I think general-regs-only is approx. equivalent to
On Wed, Mar 9, 2022 at 5:06 AM Xi Ruoyao via Gcc-patches
wrote:
>
> This should be obvious, OK for trunk?
OK.
> -- >8 --
>
> Calling VECTOR_MODE_P with MAX_MACHINE_MODE has caused out-of-bound
> access.
>
> gcc/
>
> PR tree-optimization/104851
> * optabs-query.cc
Hi Tobias,
Thanks for the patch and the particularly comprehensive testcase.
OK for mainline as far as I am concerned.
Paul
On Tue, 8 Mar 2022 at 20:06, Tobias Burnus wrote:
> Fix SIZEOF handling.
>
> I have to admit that I do understand what the current code does,
> but do not understand
On Tue, Mar 8, 2022 at 4:44 PM H.J. Lu wrote:
>
> On Mon, Mar 7, 2022 at 5:45 AM Richard Biener
> wrote:
> >
> > 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
72 matches
Mail list logo
