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 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.
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
> > > >
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
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:"
> >
> >
> 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:
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
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,
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
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
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
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
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) ==
> 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 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
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.
*
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
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
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
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
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
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,
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 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
>
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
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,
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
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
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 =
>> * 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
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
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
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>
--
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
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)
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
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
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
[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
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
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 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
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",
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
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
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
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
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
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
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
> -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
>
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
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:
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
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
> >
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:
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
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’",
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
Pushing to fix recently-updated assembly generation.
gcc/testsuite/
* gcc.target/aarch64/narrow_high-intrinsics.c: Fix shrn2 scan.
shrn2.patch
Description: shrn2.patch
> -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
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
62 matches
Mail list logo
