Andreas Krebbel via Gcc-patches writes:
> On 1/14/22 20:41, Andreas Krebbel via Gcc-patches wrote:
>> On 1/14/22 08:37, Richard Biener wrote:
>> ...
>>> Can the gist of this bug be put into the GCC bugzilla so the rev can
>>> refer to it?
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
>>
On 1/20/22 23:52, Richard Sandiford wrote:
> cc:ing the x86 and s390 maintainers
>
> soeren--- via Gcc-patches writes:
>> From: Sören Tempel
>>
>> The -fsplit-stack option requires the pthread_t TCB definition in the
>> libc to provide certain struct fields at specific hardcoded offsets. As
>> f
On Fri, 21 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> A warning regression fix I'm about to post warns (and breaks bootstrap due
> to that) on the following spot. Seems it is a copy and paste from
> earlier code that mentions the %qD variable instead of talking about
> unnamed temporary.
>
> Boot
On Fri, 21 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> cond traps can be created during ce3 after reload (and e.g. PR103028
> recently fixed some ce3 cond trap related bug, so I think often that
> works fine and we shouldn't disable cond traps after RA altogether),
> but it calls prepare_cmp_insn.
Hi!
As can be seen on the testcase, GCC 11 no longer warns if the format
string is wrapped inside of ()s.
This regressed with r11-2457-gdf5cf47a978, which added
if (TREE_NO_WARNING (param)) return;
to check_function_arguments_recurse. That function is used with a callback
for two cases, for -Wfor
Hi!
A warning regression fix I'm about to post warns (and breaks bootstrap due
to that) on the following spot. Seems it is a copy and paste from
earlier code that mentions the %qD variable instead of talking about
unnamed temporary.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for t
Hi!
cond traps can be created during ce3 after reload (and e.g. PR103028
recently fixed some ce3 cond trap related bug, so I think often that
works fine and we shouldn't disable cond traps after RA altogether),
but it calls prepare_cmp_insn. This function can fail, so I don't
see why we couldn't
Thanks so much for your advice. Please see my comments.
On 21/1/2022 上午 5:42, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jan 20, 2022 at 01:46:48PM -0500, David Edelsohn wrote:
>> On Thu, Jan 20, 2022 at 2:36 AM HAO CHEN GUI wrote:
>>>This patch adds a combine pattern for "CA minus one". As
The recent multiply-highpart work twiddled code generation on the MIPS
targets and is causing mips.exp failures.
The resultant code is actually better and matches a comment in the test
files which indicates that it would be better to generate a
mult-highpart. So I'm pretty confident in removi
This libgo patch builds panic32.go on amd64p32 (that is, x86 x32
mode). This fixes GCC PR 104149. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu, and H.J. tested the patch on x32 (thanks!).
Committed to mainline.
Ian
4f614712c908ca00fdb83057420e0023c9171477
diff --git a/gcc/go/gofronte
On Thu, Jan 20, 2022 at 03:23:24PM -0500, Jason Merrill wrote:
> On 1/18/22 11:05, Marek Polacek wrote:
> > On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote:
> > > On 1/14/22 19:22, Marek Polacek wrote:
> > > > This is a "canonical types differ for identical types" ICE, which
> > > >
PR analyzer/94362 reports a false positive from
-Wanalyzer-null-dereference seen when analyzing OpenSSL.
The root cause is that the analyzer's path feasibility checker
erroneously considers this to be feasible:
(R + 1 > 0) && (R < 0)
for int R (the return value from sk_EVP_PKEY_ASN1_METHOD_num),
PR analyzer/103685 reports a false positive from -Wanalyzer-null-dereference
seen at -O2 with GCC 11. I can reproduce it with GCC 11, but not with
trunk; this patch adds a reduced test case that reproduces it with
GCC 11 as a regression test for GCC 12 onwards.
Successfully regrtested on x86_64-p
On Thu, 20 Jan 2022 13:33:35 PST (-0800), Palmer Dabbelt wrote:
On Thu, 20 Jan 2022 13:20:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On Thu, Jan 20, 2022 at 01:13:45PM -0800, Palmer Dabbelt wrote:
On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> riscv*-*-* are the
The updated patch ensures the tighter bound isn't used to compute
the sprintf result and adds a test to verify that. (This is messy
in the strlen/sprintf pass and should be cleaned up to avoid this
mistake in the future.)
Rested on x86_64-linux.
On 1/19/22 18:20, Martin Sebor wrote:
The attach
cc:ing the x86 and s390 maintainers
soeren--- via Gcc-patches writes:
> From: Sören Tempel
>
> The -fsplit-stack option requires the pthread_t TCB definition in the
> libc to provide certain struct fields at specific hardcoded offsets. As
> far as I know, only glibc provides these fields at the
On Thu, 20 Jan 2022, Andrew Waterman wrote:
> The old formulation of the instructions were never ratified as a
> RISC-V standard. I don't think we need to hamstring ourselves here by
> assuming the possibility of their implementation.
If you ignore the old version, then the instructions can unco
On Thu, Jan 20, 2022 at 12:30 PM Palmer Dabbelt wrote:
>
> On Thu, 20 Jan 2022 07:44:25 PST (-0800), ma...@embecosm.com wrote:
> > RISC-V FMIN and FMAX machine instructions are IEEE-754-conformant[1]:
> >
> > "For FMIN and FMAX, if at least one input is a signaling NaN, or if both
> > inputs are q
Dear Fortranners,
when simplifying TRANSFER with a MOLD argument of type character
and with SIZE=0 we lose the character length.
This happens in all gfortran versions and results in wrong code.
The purported regression is that at some point in the 9-development
this lead to a (previously possibly
Hi!
On Thu, Jan 20, 2022 at 01:46:48PM -0500, David Edelsohn wrote:
> On Thu, Jan 20, 2022 at 2:36 AM HAO CHEN GUI wrote:
> >This patch adds a combine pattern for "CA minus one". As CA only has two
> > values (0 or 1), we could convert following pattern
> > (sign_extend:DI (plus:SI (reg
On 1/19/22 3:01 PM, Thomas Koenig wrote:
Hi Sandra,
This patch is for PR103695, marked as a P1 regression. OK to check in?
I'm not an OpenMP expert, but this looks straightforward enough.
I assume you ran a regression-test? OK if that is the case.
Yes, test results on x86_64-linux-gnu l
On Thu, 20 Jan 2022 13:20:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On Thu, Jan 20, 2022 at 01:13:45PM -0800, Palmer Dabbelt wrote:
On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
> due to som
On Thu, 20 Jan 2022, Joseph Myers wrote:
> The C functions fmin and fmax correspond to the IEEE 754-2008 operations
> minNum and maxNum, which operate as described, and the RISC-V 'F' and 'D'
> extensions *before* version 2.2 of those extensions also corresponded to
> minNum and maxNum.
And, t
On Thu, Jan 20, 2022 at 01:13:45PM -0800, Palmer Dabbelt wrote:
> On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
> > riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
> > due to some aggressive linker optimizations).
>
> I don't really understand the
On Thu, 20 Jan 2022, Maciej W. Rozycki wrote:
> RISC-V FMIN and FMAX machine instructions are IEEE-754-conformant[1]:
>
> "For FMIN and FMAX, if at least one input is a signaling NaN, or if both
> inputs are quiet NaNs, the result is the canonical NaN. If one operand
> is a quiet NaN and the o
On Thu, 20 Jan 2022 02:45:53 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Hi!
riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
due to some aggressive linker optimizations).
I don't really understand the rest of this, but we do have a subset of
LEB128 (constant expression
Ping.
Summary: Patch disable -fstack-split on non-glibc targets to prevent
corruptions of the TCB on libcs which do not support the required
fields in pthread_t. This is an important fix for having gccgo work on
musl by default.
See: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587142.
On Thu, 20 Jan 2022 07:44:25 PST (-0800), ma...@embecosm.com wrote:
RISC-V FMIN and FMAX machine instructions are IEEE-754-conformant[1]:
"For FMIN and FMAX, if at least one input is a signaling NaN, or if both
inputs are quiet NaNs, the result is the canonical NaN. If one operand
is a quiet Na
A C++20 designator must name a direct non-static member of the class; in
this case it names a member of a base class, and we should give an error
instead of crashing.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101405
gcc/cp/ChangeLog:
* decl.cc (reshape_init_class): R
On 1/18/22 11:05, Marek Polacek wrote:
On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote:
On 1/14/22 19:22, Marek Polacek wrote:
This is a "canonical types differ for identical types" ICE, which started
with r11-4682. It's a bit tricky to explain. Consider:
template struct S
This was fixed by r12-6025 and is sufficiently different from
noexcept71.C that I think we should add it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102338
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/noexcept2.C: New test.
---
gcc/testsuite/g++.dg/cpp1y/noexcept2.C | 20
On Thu, Jan 20, 2022 at 2:36 AM HAO CHEN GUI wrote:
>
> Hi,
>This patch adds a combine pattern for "CA minus one". As CA only has two
> values (0 or 1), we could convert following pattern
> (sign_extend:DI (plus:SI (reg:SI 98 ca)
> (const_int -1 [0x]
>
On Thu, Jan 20, 2022 at 10:52:10AM -0700, Martin Sebor wrote:
> On 1/20/22 10:03, Jakub Jelinek wrote:
> > On Thu, Jan 20, 2022 at 09:56:59AM -0700, Martin Sebor wrote:
> > > > With normal -Wformat I see all expected warnings in:
> > > > char *foo (const char *) __attribute__((format_arg(1)));
> >
We accept this testcase after r12-6773 ("CTAD inside alias template").
PR c++/103631
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class51.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/nontype-class51.C | 26
1 file changed, 26 insertions(+)
create mode 100
On 1/20/22 10:03, Jakub Jelinek wrote:
On Thu, Jan 20, 2022 at 09:56:59AM -0700, Martin Sebor wrote:
With normal -Wformat I see all expected warnings in:
char *foo (const char *) __attribute__((format_arg(1)));
void bar (const char *, ...) __attribute__((format(printf, 1, 2)));
-Wformat-diag i
Sorry for the slow response.
Alex Coplan writes:
> On 20/12/2021 13:19, Richard Sandiford wrote:
>> Alex Coplan via Gcc-patches writes:
>> > Hi,
>> >
>> > This fixes PR103500 i.e. ensuring that stack slots for
>> > passed-by-reference overaligned types are appropriately aligned. For the
>> > tes
On Thu, Jan 20, 2022 at 09:56:59AM -0700, Martin Sebor wrote:
> > With normal -Wformat I see all expected warnings in:
> > char *foo (const char *) __attribute__((format_arg(1)));
> > void bar (const char *, ...) __attribute__((format(printf, 1, 2)));
>
> -Wformat-diag is internal to GCC and needs
On Wed, 19 Jan 2022 at 18:02, Ard Biesheuvel wrote:
>
> On Wed, 19 Jan 2022 at 17:54, Kyrylo Tkachov wrote:
> >
> > Hi Ard,
> >
> > > -Original Message-
> > > From: Gcc-patches > > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Ard
> > > Biesheuvel via Gcc-patches
> > > Sent: M
On 1/20/22 09:43, Jakub Jelinek wrote:
On Thu, Jan 20, 2022 at 09:33:30AM -0700, Martin Sebor wrote:
Oh, and one more thing, but this time not about this source file but about
the warning. Does it handle the gettext case?
I think -Wformat generally does, gettext has format_arg attribute.
If the
Stephan Bergmann reported that our -Wbidi-chars breaks the build
of LibreOffice because we warn about UCNs even when their usage
is correct: LibreOffice constructs strings piecewise, as in:
aText = u"\u202D" + aText;
and warning about that is overzealous. Since no editor (AFAIK)
interprets UCN
On Thu, Jan 20, 2022 at 09:33:30AM -0700, Martin Sebor wrote:
> > Oh, and one more thing, but this time not about this source file but about
> > the warning. Does it handle the gettext case?
> > I think -Wformat generally does, gettext has format_arg attribute.
> > If the warning handles
> >pp
On 1/20/22 03:28, Jakub Jelinek wrote:
On Thu, Jan 20, 2022 at 11:17:28AM +0100, Jakub Jelinek via Gcc-patches wrote:
--- a/gcc/cp/error.cc
+++ b/gcc/cp/error.cc
@@ -768,6 +768,11 @@ class_key_or_enum_as_string (tree t)
return "struct";
}
+#if __GNUC__ >= 10
+#pragma GCC diagnostic push
Hi,
this patch splits the CCSmode into an integer and a floating point
variant. This allows ifcvt to consider floating point compares which
would be rejected before because they could not be reversed.
Bootstrapped and regtested on s390x.
Is it OK?
Regards
Robin
--
gcc/ChangeLog:
*
Following the changes to the inline memcpy operations get expanded, we
now generate ld1/st1 using a 128-bit vector register rather than ldp
with Q registers. The behaviour is equivalent, so relax the tests to
permit either variant.
gcc/testsuite/ChangeLog:
PR target/102517
* gcc
RISC-V FMIN and FMAX machine instructions are IEEE-754-conformant[1]:
"For FMIN and FMAX, if at least one input is a signaling NaN, or if both
inputs are quiet NaNs, the result is the canonical NaN. If one operand
is a quiet NaN and the other is not a NaN, the result is the non-NaN
operand."
On Thu, 20 Jan 2022, Richard Biener wrote:
> On Thu, 20 Jan 2022, Jakub Jelinek wrote:
>
> > On Thu, Jan 20, 2022 at 02:58:21PM +0100, Richard Biener via Gcc-patches
> > wrote:
> > > The following avoids us ICEing doing constant folding from variables
> > > with aliases of different types. The
On Thu, 20 Jan 2022, Jakub Jelinek wrote:
> On Thu, Jan 20, 2022 at 02:58:21PM +0100, Richard Biener via Gcc-patches
> wrote:
> > The following avoids us ICEing doing constant folding from variables
> > with aliases of different types. The formerly used fold_convert
> > wasn't entirely correct e
On Thu, Jan 20, 2022 at 02:58:21PM +0100, Richard Biener via Gcc-patches wrote:
> The following avoids us ICEing doing constant folding from variables
> with aliases of different types. The formerly used fold_convert
> wasn't entirely correct even for the cases it handled and using
> a VIEW_CONVER
This patch adds a new predefined allocator named ompx_pinned_mem_alloc
as an extension to the OpenMP standard. It is intended as a convenient
way to allocate pinned memory using the Linux support patch I posted
recently. I anticipate it being used by compiler internals in future as
part of a pr
The following avoids us ICEing doing constant folding from variables
with aliases of different types. The formerly used fold_convert
wasn't entirely correct even for the cases it handled and using
a VIEW_CONVERT_EXPR avoids the ICE. Reading from a larger alias
will cause unfolded constants to app
This avoids ICEing when there is no LHS on the call by following
what foldings of other builtins do in , namely not folding.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Will push as obvious.
Richard.
2022-01-20 Richard Biener
PR target/100784
* config/i386
Tested powerpc64le-linux, pushed to trunk.
Clang doesn't support the __constinit extension that we use pre-C++20,
but it does have its own equivalent attribute that can be used instead.
This makes it a little easier to use Clang to build libstdc++ (which
isn't supported. but is sometimes attempt
On Wed, 19 Jan 2022 at 15:00, Jonathan Wakely wrote:
>
> Tested x86_64-linux, pushed to trunk.
>
>
> This makes it possible to combine --enable-libstdcxx-debug with
> --enable-libstdcxx-backtrace, by adding a rule to src/Makefile to copy
> the backtrace-supported.h header into the src/debug/libback
Thanks for the patch and sorry for the (very) slow review.
Dan Li writes:
> diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> index 007b928c54b..9b3a35c06bf 100644
> --- a/gcc/c-family/c-attribs.c
> +++ b/gcc/c-family/c-attribs.c
> @@ -56,6 +56,8 @@ static tree handle_cold_attrib
Add a testcase for the erratum mitigation. To improve coverage
use -dp on the assembler output and match the pattern names (and where
needed the alternative number).
gcc/testsuite/ChangeLog:
* gcc.target/arm/crypto-vaese-erratum1.c: New test.
---
.../gcc.target/arm/crypto-vaese-erratum
Some common cases where the AES erratum workaround are not required
are when there are 64- or 128-bit loads from memory, moving a 128-bit
value from core registers, and where a 128-bit constant is being
loaded from a literal pool. The loads may also be misaligned or
generated via a neon intrinsic
AES operations are commonly chained and since the result of one AES
operation is never a 32-bit value, they do not need an additional
mitigation instruction for the forwarded result. We handle this
common case by adding additional patterns that allow for this.
gcc/ChangeLog:
* config/ar
This patch adds the basic patterns for mitigation of the erratum, but no
attempt is made at this point to optimize the results for the cases where
the erratum mitigation is not needed.
The mitigation is done by guaranteeing that the input operands are fed
from a full-width operation by using an i
Add a new option -mfix-cortex-a-aes for enabling the Cortex-A AES
erratum work-around and enable it automatically for the affected
products (Cortex-A57 and Cortex-A72).
gcc/ChangeLog:
* config/arm/arm-cpus.in (quirk_aes_1742098): New quirk feature
(ALL_QUIRKS): Add it.
(c
A couple of patterns in the crypto support code were hard-coding the
mode rather than using the iterators. While not incorrect, it was
slightly confusing, so adapt those patterns to the style of the rest
of the file.
Also fix some white space issues.
gcc/ChangeLog:
* config/arm/crypto.
No functional change, but arm/crypto.md has multiple pattenrs all
called crypto_, which makes references to them
ambiguous, so add the iterator base to the pattern name so that it is
distinct in the commit logs.
gcc/ChangeLog:
* config/arm/crypto.md (crypto_): Add
iterator to pat
The Cortex-A57 and Cortex-A72 processors have an erratum (#1742098
and #1655431 respectively) when running in Arm (32-bit) mode where an
instruction producing a 32-bit result that feeds into an AES encode or
decode can lead to an incorrect result. The erratum does not occur when
operating in 64-bi
On 20/01/2022 10:45, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
iterator instead of HI in mve_vmvnq_n_.
2022-01-13 Christophe Lyon
gcc/
On Thu, 20 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
> due to some aggressive linker optimizations).
> As the following testcase shows, we mishandle in index_rnglists the
> !HAVE_AS_LEB128 && !have_multiple_function_sections c
Hi!
riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
due to some aggressive linker optimizations).
As the following testcase shows, we mishandle in index_rnglists the
!HAVE_AS_LEB128 && !have_multiple_function_sections case.
output_rnglists does roughly:
FOR_EACH_VEC_SAFE
"Andre Vieira (lists)" writes:
> On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
>> The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
>> iterator instead of HI in mve_vmvnq_n_.
>>
>> 2022-01-13 Christophe Lyon
>>
>> gcc/
>> * config/arm/mve.md (mve_vmvnq_
On 20/01/2022 10:40, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
On 20/01/2022 09:14, Christophe Lyon wrote:
On Wed, Jan 19, 2022 at 7:18 PM Andre Vieira (lists) via Gcc-patches
wrote:
Hi Christophe,
On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
>
"Andre Vieira (lists)" writes:
> On 20/01/2022 09:14, Christophe Lyon wrote:
>>
>>
>> On Wed, Jan 19, 2022 at 7:18 PM Andre Vieira (lists) via Gcc-patches
>> wrote:
>>
>> Hi Christophe,
>>
>> On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
>> > At some point during the de
On Wed, Jan 19, 2022 at 12:42:22PM +0100, Martin Liška wrote:
> The tests are C++ code, so use a proper file extension.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/ext/boolcomplex-1.c: Moved to...
> * g++.dg/ext/boolcomplex-1.C: ...here.
> * g++.dg/opt/pr47639.c: Moved to...
>
On Thu, Jan 20, 2022 at 11:17:28AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > --- a/gcc/cp/error.cc
> > +++ b/gcc/cp/error.cc
> > @@ -768,6 +768,11 @@ class_key_or_enum_as_string (tree t)
> > return "struct";
> > }
> > +#if __GNUC__ >= 10
> > +#pragma GCC diagnostic push
> > +#pragma GCC
On Thu, Jan 20, 2022 at 10:44:18AM +0100, Martin Liška wrote:
> The patch disables -Wformat-diag for RTL checking diagnostics.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR bootstrap/104135
>
> gcc/ChangeLog
On Thu, Jan 20, 2022 at 10:43:55AM +0100, Martin Liška wrote:
> The patch disables "-Wformat-diag" for dump_aggr_type.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR c++/104134
>
> gcc/cp/ChangeLog:
>
>
Hi,
this patch is a follow-up patch to the recent ifcvt changes. It
increased costs for a load on condition to 6. This ensures that we
if-convert sequences of three regular instructions (of cost 4) e.g. a
compare and two SETs into two loads on condition (of cost 6). With a
cost of 5, four-insn s
On Thu, Jan 20, 2022 at 09:26:50AM +0100, Thomas Schwinge wrote:
> That's what we need to look into, in particular: if we decompose (GIMPLE
> sequence) an OpenACC 'kernels' region into parts, how to move or
> otherwise handle any 'GIMPLE_DEBUG's.
I admit I haven't looked at the pass except now for
On Thu, Jan 20, 2022 at 10:38 AM Andre Simoes Dias Vieira <
andre.simoesdiasvie...@arm.com> wrote:
>
> On 20/01/2022 09:23, Christophe Lyon wrote:
>
>
>
> On Wed, Jan 19, 2022 at 8:03 PM Andre Vieira (lists) via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
>>
>> On 13/01/2022 14:56, Christoph
The patch disables -Wformat-diag for RTL checking diagnostics.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR bootstrap/104135
gcc/ChangeLog:
* emit-rtl.cc (make_insn_raw): Fix -Wformat-diag warnings.
* r
The patch disables "-Wformat-diag" for dump_aggr_type.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR c++/104134
gcc/cp/ChangeLog:
* error.cc (dump_aggr_type): Partially disable the warning.
---
gcc/cp/error.cc
On 20/01/2022 09:14, Christophe Lyon wrote:
On Wed, Jan 19, 2022 at 7:18 PM Andre Vieira (lists) via Gcc-patches
wrote:
Hi Christophe,
On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
> At some point during the development of this patch series, it
appeared
On 20/01/2022 09:23, Christophe Lyon wrote:
On Wed, Jan 19, 2022 at 8:03 PM Andre Vieira (lists) via Gcc-patches
wrote:
On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
> The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
> iterator instead of HI i
On Wed, Jan 19, 2022 at 8:03 PM Andre Vieira (lists) via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
> On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
> > The vmvnq_n* intrinsics and have [u]int[16|32]_t arguments, so use
> > iterator instead of HI in mve_vmvnq_n_.
> >
> > 2022-01
On Wed, Jan 19, 2022 at 7:25 PM Andre Vieira (lists) via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
> On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
> > VPR_REG is the only register in its class, so it should be handled by
> > TARGET_CLASS_LIKELY_SPILLED_P, which is achieved by c
On Wed, Jan 19, 2022 at 7:18 PM Andre Vieira (lists) via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi Christophe,
>
> On 13/01/2022 14:56, Christophe Lyon via Gcc-patches wrote:
> > At some point during the development of this patch series, it appeared
> > that in some cases the register all
On Wed, Jan 19, 2022 at 7:41 PM Andrew MacLeod wrote:
>
> On 1/19/22 04:33, Richard Biener wrote:
> > On Wed, Jan 19, 2022 at 2:37 AM Andrew MacLeod via Gcc-patches
> > wrote:
> >>
> >> OK for trunk?
> > OK. I don't quite understand how what you describe above works, it sounds
> > a bit odd with
Hi Jakub!
Thanks for looking into this.
On 2022-01-20T00:00:23+0100, Jakub Jelinek wrote:
> On Wed, Jan 19, 2022 at 11:29:18PM +0100, Thomas Schwinge wrote:
>> (The pass is still disabled by default, by the way.)
>>
>> We've found that 'gcc/omp-oacc-kernels-decompose.cc' is currently not at
>> a
84 matches
Mail list logo
