On Thu, Jan 28, 2021 at 11:31 AM Bin.Cheng wrote:
>
> On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gcc-patches
> > wrote:
> > >
> > > Hi,
> > > As described in commit message, we need to avoid computing niters info
On 1/28/21 10:57 PM, Marek Polacek wrote:
My r11-86 adjusted cp_parser_class_name to do
- scope = parser->scope;
+ scope = parser->scope ? parser->scope : parser->context->object_type;
if (scope == error_mark_node)
return error_mark_node;
but that caused endless looping in cp_parser
My r11-86 adjusted cp_parser_class_name to do
- scope = parser->scope;
+ scope = parser->scope ? parser->scope : parser->context->object_type;
if (scope == error_mark_node)
return error_mark_node;
but that caused endless looping in cp_parser_type_specifier_seq (the
while (true) loop) in
Hi,
This patch tries to optimize PowerPC 64 bit constant generation when
the constant can be transformed from a 32 bit or 16 bit constant by
rotating, shifting and mask AND.
The attachments are the patch diff file and change log file.
Bootstrapped and tested on powerpc64le with no r
I rebusmitted the patch after verifying it still builds and works with the
current branch as:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564486.html
| Subject: [PATCH] Add conversions between _Float128 and Decimal.
| Message-ID: <20210129024208.ga25...@ibm-toto.the-meissners.org>
--
[PATCH] Add conversions between _Float128 and Decimal.
This patch implements conversions between _Float128 and the 3 Decimal
floating types. It does by extendending the dfp-bit conversions to add a
new binary floating point type (KF), and doing the conversions in the same
mannor as the other bina
The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a
failure in the test suite for the IBM Advance Toolchain. The test in
question uses "perf probe" to set a tracepoint at "main" in a newly built
(with GCC 11) binary of "/bin/ld". With the patch applied, the command
enters an in
The go1 compiler always turns on debugging, to support Go stack traces
and functions like runtime.Callers. With the recent switch to turn on
DWARF 5 by default, this caused failures with some versions of gas,
such as 2.35.1, because the assembly code would assume DWARF 5 but the
driver would not p
The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
leading offset is in bounds but whose trailing offset is not has
been causing some confusion. When the warning is issued for
an access to an in-bounds member via a pointer to a struct that's
larger than the pointed-to object, phrasi
On Thu, Jan 28, 2021 at 11:38:34PM +0100, Eric Botcazou wrote:
> > Aware. I don't have access to, e.g., a sparc box. But the test I've added
> > uses -mstrict-align where possible to check that the issue is resolved.
>
> There are relatively fast SPARC64/Linux (gcc202) and SPARC/Solaris machines
> Aware. I don't have access to, e.g., a sparc box. But the test I've added
> uses -mstrict-align where possible to check that the issue is resolved.
There are relatively fast SPARC64/Linux (gcc202) and SPARC/Solaris machines
(gcc210 and gcc211) in the Compile Farm:
https://cfarm.tetaneutral.
On Thu, Jan 28, 2021 at 11:02:36PM +0100, Eric Botcazou wrote:
> > Bootstrapped/regtested on
> > * x86_64-pc-linux-gnu
> > * powerpc64le-unknown-linux-gnu
> > * aarch64-linux-gnu
> > ok for trunk?
>
> None of them is strict alignment though, isn't it?
Aware. I don't have access to, e.g., a sparc
> Bootstrapped/regtested on
> * x86_64-pc-linux-gnu
> * powerpc64le-unknown-linux-gnu
> * aarch64-linux-gnu
> ok for trunk?
None of them is strict alignment though, isn't it?
--
Eric Botcazou
On Thu, Jan 28, 2021 at 01:58:26PM -0600, Peter Bergner wrote:
> On 1/28/21 1:47 PM, Segher Boessenkool wrote:
> > On Thu, Jan 28, 2021 at 02:30:56PM -0500, Michael Meissner wrote:
> >> The second patch I want you to review is:
> >
> > "This patch replaces the following three patches:"
> >
> > Pl
On 1/28/21 3:36 PM, Marek Polacek wrote:
On Thu, Jan 28, 2021 at 03:18:55PM -0500, Jason Merrill via Gcc-patches wrote:
On 1/28/21 10:34 AM, Marek Polacek wrote:
A year ago I submitted this patch:
~~
Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with TY
On 1/28/21 2:22 AM, Jakub Jelinek wrote:
On Thu, Jan 28, 2021 at 09:31:46AM +0100, Richard Biener via Gcc-patches wrote:
+ if (TREE_CODE (bound) == PLUS_EXPR
+ && integer_all_onesp (TREE_OPERAND (bound, 1)))
+{
+ bound = TREE_OPERAND (bound, 0);
+ if (TREE_CODE (bound) == NOP
On 1/28/21 1:31 AM, Richard Biener wrote:
On Thu, Jan 28, 2021 at 12:08 AM Martin Sebor via Gcc-patches
wrote:
Attached is another attempt to fix the problem caused by allowing
front-end trees representing nontrivial VLA bound expressions to
stay in attribute access attached to functions. Sin
On Thu, Jan 28, 2021 at 03:18:55PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/28/21 10:34 AM, Marek Polacek wrote:
> > A year ago I submitted this patch:
> >
> > ~~
> > Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
> > gets "const d[0]" with TYPE_USER_ALIGN=0 but the
On 1/28/21 10:34 AM, Marek Polacek wrote:
A year ago I submitted this patch:
~~
Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by
build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1.
When we strip_t
On 1/28/21 1:47 PM, Segher Boessenkool wrote:
> On Thu, Jan 28, 2021 at 02:30:56PM -0500, Michael Meissner wrote:
>> The second patch I want you to review is:
>
> "This patch replaces the following three patches:"
>
> Please send a patch that modifies *current* code, and that is *tested*
> with t
On Thu, Jan 28, 2021 at 02:30:56PM -0500, Michael Meissner wrote:
> On Thu, Jan 28, 2021 at 12:59:18PM -0600, Segher Boessenkool wrote:
> > On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > > > The whole thread is at
> > > > https://patchwork.ozlabs.org/project/gcc/patch/202011
On Thu, Jan 28, 2021 at 12:59:18PM -0600, Segher Boessenkool wrote:
> On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > > The whole thread is at
> > > https://patchwork.ozlabs.org/project/gcc/patch/2020112524.ga...@ibm-toto.the-meissners.org/
> > > .
> > >
> > > I approve
On 1/28/21 10:24 AM, Jakub Jelinek wrote:
On Thu, Jan 28, 2021 at 10:04:12AM -0500, Jason Merrill wrote:
We emit a bogus warning on the following testcase, suggesting that the
operator should return *this even when it does that already.
The problem is that normally cp_build_indirect_ref_1 ensure
On Thu, Jan 28, 2021 at 01:10:39PM -0500, Michael Meissner wrote:
> > The whole thread is at
> > https://patchwork.ozlabs.org/project/gcc/patch/2020112524.ga...@ibm-toto.the-meissners.org/
> > .
> >
> > I approved *that* version of the patch.
>
> Yes you approved the built-in renaming patch
libstdc++-v3/ChangeLog:
* include/experimental/bits/numeric_traits.h: Update copyright
dates.
* include/experimental/bits/simd.h: Likewise.
* include/experimental/bits/simd_builtin.h: Likewise.
* include/experimental/bits/simd_converter.h: Likewise.
On Wed, Jan 27, 2021 at 09:11:49PM -0600, Segher Boessenkool wrote:
> On Tue, Jan 26, 2021 at 06:43:06PM -0500, Michael Meissner wrote:
> > I posted this patch on January 14th, 2021:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563498.html
> >
> > | Date: Thu, 14 Jan 2021 12:09:36 -0
Hi!
On Thu, Jan 28, 2021 at 02:40:25AM -0600, Xionghu Luo wrote:
> Move common functions to header file for cleanup.
>
> gcc/testsuite/ChangeLog:
>
> 2021-01-27 Xionghu Luo
>
> * gcc.target/powerpc/pr79251.p8.c: Move definition to ...
> * gcc.target/powerpc/pr79251.h: ...this.
>
On Wed, 27 Jan 2021 at 15:03, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 27 January 2021 13:56
> > To: Kyrylo Tkachov
> > Cc: Kyrylo Tkachov via Gcc-patches
> > Subject: Re: arm: Adjust cost of vector of constant zero
> >
> > On Wed, 27 Jan 20
Calling strncpy in libiberty's dyn_string_insert() with the last
argument equal to the length of the second triggers the warning:
/src/gcc/master/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
truncated before terminating nul copying as many bytes from a string as
its length [-Wstringo
After testing the patch I submitted on November 17th that was approved to make
sure it still works, I commited the patch to the master branch. Sorry about
the intermediate rewrites.
[PATCH] Map long double built-ins correctly with IEEE 128-bit long double.
The PowerPC has two different 128-bit l
A year ago I submitted this patch:
~~
Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by
build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1.
When we strip_typedefs the element of the array "const d",
On Thu, Jan 28, 2021 at 10:04:12AM -0500, Jason Merrill wrote:
> > We emit a bogus warning on the following testcase, suggesting that the
> > operator should return *this even when it does that already.
> > The problem is that normally cp_build_indirect_ref_1 ensures that *this
> > is folded as cur
On 1/28/21 9:54 AM, Tom Greenslade (thomgree) wrote:
While trying to fix the suggested overload resolution issue I run into another
bug:
struct A
{
char str[4];
};
void f(A) {};
int main ()
{
f({"foo"});
}
Does not compile on GCC: "error: could not convert ‘{"foo"}’ from ‘’ to ‘A’", bu
On 1/28/21 3:58 AM, Jakub Jelinek wrote:
Hi!
We emit a bogus warning on the following testcase, suggesting that the
operator should return *this even when it does that already.
The problem is that normally cp_build_indirect_ref_1 ensures that *this
is folded as current_class_ref, but in template
While trying to fix the suggested overload resolution issue I run into another
bug:
struct A
{
char str[4];
};
void f(A) {};
int main ()
{
f({"foo"});
}
Does not compile on GCC: "error: could not convert ‘{"foo"}’ from
‘’ to ‘A’", but works fine on Clang.
Is this a known bug or a new one?
> -Original Message-
> From: Jonathan Wright
> Sent: 28 January 2021 13:23
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH] aarch64: Use RTL builtins for [su]mlsl_n intrinsics
>
> Hi,
>
> As subject, this patch rewrites [su]mlsl_n Neon intrinsics to use RTL built
Pushing to fix recently-updated assembly generation.
gcc/testsuite/
* gcc.target/aarch64/narrow_high-intrinsics.c: Fix shrn2 scan.
shrn2.patch
Description: shrn2.patch
Hi,
As subject, this patch rewrites [su]mlsl_n Neon intrinsics to use RTL builtins
rather than inline assembly code, allowing for better scheduling and
optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu - no
issues.
Ok for master?
Thanks,
Jonathan
---
gcc/ChangeLog:
2
On Thu, Jan 28, 2021 at 1:21 AM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Jan 28, 2021 at 7:32 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > Hi:
> >GCC11 will be the system GCC 2 years from now, and for the
> > processors then, they shouldn't even need to split a 256-bit vector
> >
On 1/28/21 3:52 AM, Jakub Jelinek wrote:
Hi!
As the testcase shows, for vars appearing in templates, we don't attach
the asm spec string to the pattern decls, nor pass it back to cp_finish_decl
during instantiation.
The following patch does that.
Bootstrapped/regtested on x86_64-linux and i686
> -Original Message-
> From: Jonathan Wright
> Sent: 28 January 2021 12:04
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: aarch64: Use RTL builtins for [su]mlal_n intrinsics
>
> Hi,
>
> As subject, this patch rewrites [su]mlal_n Neon intrinsics to use RTL builtins
> ra
On 1/28/21 7:54 AM, Nathan Sidwell wrote:
Typedefs are streamed by streaming the underlying type, and then
recreating the typedef. But this breaks checking a duplicate is the
same as the original when it is a template alias -- we end up checking
a template alias (eg __void_t) against the underl
Typedefs are streamed by streaming the underlying type, and then
recreating the typedef. But this breaks checking a duplicate is the
same as the original when it is a template alias -- we end up checking
a template alias (eg __void_t) against the underlying type (void).
And those are not the sam
Hi,
As subject, this patch rewrites [su]mlal_n Neon intrinsics to use RTL builtins
rather than inline assembly code, allowing for better scheduling and
optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu - no
issues.
Ok for master?
Thanks,
Jonathan
---
gcc/ChangeLog:
2
Hi all,
This patch reimplements the vshrn_high_n* intrinsics that generate the SHRN2
instruction.
It is a vec_concat of the narrowing shift with the bottom part of the
destination register,
so we need a little-endian and a big-endian version and an expander to pick
between them.
Bootstrapped a
Hi all,
This patch reimplements the vshrn_n* intrinsics to use RTL builtins.
These perform a narrowing right shift.
Although the intrinsic generates the half-width mode (e.g. V8HI -> V8QI), the
new pattern
generates a full 128-bit mode (V8HI -> V16QI) by representing the
fill-with-zeroes semant
Hello,
I would like to ping the following patch:
lra: clear lra_insn_recog_data after simplifying a mem subreg
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563428.html
Best regards,
Ilya
On Thu, Jan 28, 2021 at 5:08 PM Richard Biener via Gcc-patches
wrote:
>
> On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gcc-patches
> wrote:
> >
> > Hi,
> > As described in commit message, we need to avoid computing niters info for
> > fake
> > edges. This simple patch does this by two changes.
>> * While you now define _GLIBCXX_C_LOCALE_XPG7 in
>> config/locale/xpg7/c_locale.h, config/os/aix/ctype_configure_char.cc
>> still tests the previous _GLIBCXX_C_LOCALE_IEEE_2008.
>
> Arf, I've missed that. it might not be the last patch then.
> (I've made so much versions of it as I've tried
Hi!
I've noticed we still refer to C++20 as draft standard, and there is a pasto
in C++23 description.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.
2021-01-28 Jakub Jelinek
* c.opt (-std=c++2a, -std=c++20, -std=gnu++2a, -std=gnu+
On Thu, Jan 28, 2021 at 09:31:46AM +0100, Richard Biener via Gcc-patches wrote:
> + if (TREE_CODE (bound) == PLUS_EXPR
> + && integer_all_onesp (TREE_OPERAND (bound, 1)))
> +{
> + bound = TREE_OPERAND (bound, 0);
> + if (TREE_CODE (bound) == NOP_EXPR)
> + bound = TREE_OPER
Hi Thomas,
> > Should the testcase be moved to the gomp/ subdirectory?
> Yes. It's a compile-time test, and it will then only be run
> if the the compiler can do OpenMP.
>
> You will not need the
>
> +! { dg-options "-fopenmp" }
>
> line, then.
Adjusted and committed as r11-6950-g33a7a93218b1393d
On Thu, Jan 28, 2021 at 9:35 AM Eric Botcazou wrote:
>
> The last fix made for PR lto/85574 introduced a comparison of executables and
> this cannot directly work on Windows because they are timestamped. Moreover
> nobody sets $(exeext) at top level, at least on MinGW, so you get a weird
> behavi
On Thu, Jan 28, 2021 at 7:32 AM Hongtao Liu via Gcc-patches
wrote:
>
> Hi:
>GCC11 will be the system GCC 2 years from now, and for the
> processors then, they shouldn't even need to split a 256-bit vector
> into 2 128-bits vectors.
>.i.e. Test SPEC2017 with the below 2 options on Zen3/ICL
On Thu, Jan 28, 2021 at 6:28 AM Alexandre Oliva wrote:
>
> On Jan 27, 2021, Richard Biener wrote:
>
> > That said, rather than not transforming the loop as you do I'd
> > say we want to re-inline small copies more forcefully during
> > loop distribution code-gen so we turn a loop that sets
> > 3
Hi!
We emit a bogus warning on the following testcase, suggesting that the
operator should return *this even when it does that already.
The problem is that normally cp_build_indirect_ref_1 ensures that *this
is folded as current_class_ref, but in templates (if return type is
non-dependent, otherwi
Hi!
As the testcase shows, for vars appearing in templates, we don't attach
the asm spec string to the pattern decls, nor pass it back to cp_finish_decl
during instantiation.
The following patch does that.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-01-27 Jakub Je
On Thu, Jan 28, 2021 at 3:49 AM bin.cheng via Gcc-patches
wrote:
>
> Hi,
> As described in commit message, we need to avoid computing niters info for
> fake
> edges. This simple patch does this by two changes.
>
> Bootstrap and test on X86_64, is it ok?
Hmm, so I think the patch is a bit compli
Move common functions to header file for cleanup.
gcc/testsuite/ChangeLog:
2021-01-27 Xionghu Luo
* gcc.target/powerpc/pr79251.p8.c: Move definition to ...
* gcc.target/powerpc/pr79251.h: ...this.
* gcc.target/powerpc/pr79251.p9.c: Likewise.
* gcc.target/powerp
On Thu, Jan 28, 2021 at 12:08 AM Martin Sebor via Gcc-patches
wrote:
>
> Attached is another attempt to fix the problem caused by allowing
> front-end trees representing nontrivial VLA bound expressions to
> stay in attribute access attached to functions. Since removing
> these trees seems to be
The last fix made for PR lto/85574 introduced a comparison of executables and
this cannot directly work on Windows because they are timestamped. Moreover
nobody sets $(exeext) at top level, at least on MinGW, so you get a weird
behavior because some tools add the implicit .exe suffix and others
On Wed, 27 Jan 2021, Jakub Jelinek wrote:
> On Wed, Jan 27, 2021 at 03:40:38PM +0100, Richard Biener wrote:
> > The following avoids repeatedly turning VALUE RTXen into
> > sth useful and re-applying a constant offset through get_addr
> > via DSE check_mem_read_rtx. Instead perform this once for
62 matches
Mail list logo
