Hi Jakub,
> -Original Message-
> From: Jakub Jelinek
> Sent: 13 March 2021 20:34
> To: Richard Sandiford ; Richard Earnshaw
> ; Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] aarch64: Fix up
> aarch64_simd_clone_compute_vecsize_and_simdlen [PR99542]
>
> Hi!
>
> As the
Kyrylo Tkachov writes:
> Hi Jakub,
>
>> -Original Message-
>> From: Jakub Jelinek
>> Sent: 13 March 2021 20:34
>> To: Richard Sandiford ; Richard Earnshaw
>> ; Kyrylo Tkachov
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: [PATCH] aarch64: Fix up
>> aarch64_simd_clone_compute_vecsize_and_simd
On Tue, Mar 16, 2021 at 9:43 AM Richard Sandiford via Gcc-patches
wrote:
>
> Kyrylo Tkachov writes:
> > Hi Jakub,
> >
> >> -Original Message-
> >> From: Jakub Jelinek
> >> Sent: 13 March 2021 20:34
> >> To: Richard Sandiford ; Richard Earnshaw
> >> ; Kyrylo Tkachov
> >> Cc: gcc-patches@
On 3/15/21 9:57 PM, Martin Sebor wrote:
Any plans to integrate it into the testsuite? (That way we presumably
wouldn't need to remember to run it by hand.)
Likely not, I'm not so big friend with DejaGNU.
Are you willing to help me with that?
Thanks,
Martin
On Tue, Mar 16, 2021 at 09:46:33AM +0100, Richard Biener wrote:
> > shows we have an interface problem here -- we shouldn't need something this
> > convoluted to walk through an argument list. But that's not your problem
> > or a problem with the patch.
>
> The caller side should IMHO always look
On Tue, Mar 16, 2021 at 10:29 AM Jakub Jelinek wrote:
>
> On Tue, Mar 16, 2021 at 09:46:33AM +0100, Richard Biener wrote:
> > > shows we have an interface problem here -- we shouldn't need something
> > > this
> > > convoluted to walk through an argument list. But that's not your problem
> > > o
On Tue, Mar 16, 2021 at 10:36:35AM +0100, Richard Biener wrote:
> On Tue, Mar 16, 2021 at 10:29 AM Jakub Jelinek wrote:
> >
> > On Tue, Mar 16, 2021 at 09:46:33AM +0100, Richard Biener wrote:
> > > > shows we have an interface problem here -- we shouldn't need something
> > > > this
> > > > convo
Hi!
My r10-6451-gb7b3378f91c0641f2ef4d88db22af62a571c9359 fix for
vzeroupper vs. ms ABI apparently broke the explicit vzeroupper handling
when the implicit vzeroupper handling is disabled.
The epilogue_completed splitter for vzeroupper now adds clobbers for all
registers which don't have explicit
On Tue, Mar 16, 2021 at 10:51 AM Jakub Jelinek wrote:
>
> Hi!
>
> My r10-6451-gb7b3378f91c0641f2ef4d88db22af62a571c9359 fix for
> vzeroupper vs. ms ABI apparently broke the explicit vzeroupper handling
> when the implicit vzeroupper handling is disabled.
> The epilogue_completed splitter for vzero
Hi!
As the testcase shows, the compiler hangs and eats all memory when compiling
it. This is because in r11-7274-gdecd8fb0128870d0d768ba53dae626913d6d9c54
I have changed the ix86_avoid_lea_for_addr splitting from a splitter
into a peephole2 (because during splitting passes we don't have guarantee
On Tue, Mar 16, 2021 at 10:40 AM Jakub Jelinek wrote:
>
> On Tue, Mar 16, 2021 at 10:36:35AM +0100, Richard Biener wrote:
> > On Tue, Mar 16, 2021 at 10:29 AM Jakub Jelinek wrote:
> > >
> > > On Tue, Mar 16, 2021 at 09:46:33AM +0100, Richard Biener wrote:
> > > > > shows we have an interface prob
On Tue, Mar 16, 2021 at 11:16:54AM +0100, Richard Biener wrote:
> > Not varargs semantics, but unprototyped function semantics, i.e. the same
> > as for
> > int foo ();
> > Which means callers can pass anything, but it is not ..., i.e. callee can't
> > use va_start/va_end/va_arg and the ... calling
On Tue, Mar 16, 2021 at 11:19 AM Jakub Jelinek wrote:
>
> On Tue, Mar 16, 2021 at 11:16:54AM +0100, Richard Biener wrote:
> > > Not varargs semantics, but unprototyped function semantics, i.e. the same
> > > as for
> > > int foo ();
> > > Which means callers can pass anything, but it is not ..., i
Hi.
For an unknown reason the following commit modified ChangeLog file
together with other changes:
$ git show --stat c2be82058fb40f3ae891c68d185ff53e07f14f45
...
libstdc++-v3/ChangeLog | 9 +
libstdc++-v3/src/Makefile.am | 4 +++-
libstdc++-v3/src/Makefile.in | 3 ++-
Let's ignor
On Tue, Mar 16, 2021 at 11:10 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the testcase shows, the compiler hangs and eats all memory when compiling
> it. This is because in r11-7274-gdecd8fb0128870d0d768ba53dae626913d6d9c54
> I have changed the ix86_avoid_lea_for_addr splitting from a splitter
> into
Status
==
GCC trunk which eventually will become GCC 11 is still in
regression and documentation fixes only mode (Stage 4).
If history should repeat itself then a first release candidate
of GCC 11 will be released mid April. For this to happen
we need to resolve the remaining 17 P1 regress
Hi Jan-Benedict,
With my re-started testing efforts, I've got another one for you I
guess (`./configure --target=v850-elf && make all-gcc`):
../.././gcc/config/v850/v850.c: In function ‘char* construct_restore_jr(rtx)’:
../.././gcc/config/v850/v850.c:2260:22: error: ‘%s’ directive writing up to
On 3/15/21 7:29 PM, Jakub Jelinek wrote:
On Mon, Mar 15, 2021 at 03:28:06PM -0400, Nathan Sidwell wrote:
I'd failed to correctly restrict some checks to lp64 x86 targets.
PR c++/99601
gcc/testsuite/
* g++.dg/modules/builtin-3_a.C: Fix lp64 x86 detection.
* g++.d
Hi Ian,
One of the static analyzers we use is throwing up an error report for
one of the libiberty source files:
Error: BUFFER_SIZE (CWE-474):
libiberty/sha1.c:261: overlapping_buffer: The source buffer "&ctx->buffer[16]"
potentially overlaps with the destination buffer "ctx->buffer", which
On Tue, Mar 16, 2021 at 11:55:01AM +0100, Uros Bizjak wrote:
> Maybe we could simply emit a special form of a ASHIFT pattern, tagged
> with some unspec (similar to e.g. divmod4_1), and teach
> ix86_split_lea_for_addr to emit it instead? Peephole pass is so late
> in the pass sequence that we won't
On Tue, Mar 16, 2021 at 12:52 PM Jakub Jelinek wrote:
>
> On Tue, Mar 16, 2021 at 11:55:01AM +0100, Uros Bizjak wrote:
> > Maybe we could simply emit a special form of a ASHIFT pattern, tagged
> > with some unspec (similar to e.g. divmod4_1), and teach
> > ix86_split_lea_for_addr to emit it instea
On 12/03/21 17:46 +, Jonathan Wakely wrote:
This removes the new symbols added for the new futex-based
std::call_once implementation. These symbols were new on trunk, so not
in any released version. However, they are already present in some
beta distro releases (Fedora Linux 34) and in Fedora
One more exception for cl_optimization_compare.
Pushed to master,
thanks,
Martin
gcc/ChangeLog:
PR target/99592
* optc-save-gen.awk: Add flag_ipa_ra to exceptions for
cl_optimization_compare function.
gcc/testsuite/ChangeLog:
PR target/99592
* gcc.targe
On Mon, 2021-03-15 at 11:11 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>
> This patch adds const_anchor for rs6000. The const_anchor is used
> in cse pass.
>
> The attachment are the patch diff and change log file.
>
> Bootstrapped and tested on powerpc64le with no regressi
On Mon, 2021-03-15 at 11:11 +0800, HAO CHEN GUI via Gcc-patches wrote:
> Hi,
>
> This patch adds const_anchor for rs6000. The const_anchor is
> used
> in cse pass.
>
> The attachment are the patch diff and change log file.
>
> Bootstrapped and tested on powerpc64le with no regres
I suspect that this is incorrect. Did you look at the discussion of
the choice of anchor limits when first implemented? We specifically
chose 32 bit range.
Thanks, David
On Tue, Mar 16, 2021 at 10:21 AM will schmidt wrote:
>
> On Mon, 2021-03-15 at 11:11 +0800, HAO CHEN GUI via Gcc-patches wro
On Tue, Mar 16, 2021, 4:48 AM Nick Clifton via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi Ian,
>
> One of the static analyzers we use is throwing up an error report for
> one of the libiberty source files:
>
> Error: BUFFER_SIZE (CWE-474):
> libiberty/sha1.c:261: overlapping_buffer: Th
On 3/16/21 3:08 AM, Martin Liška wrote:
On 3/15/21 9:57 PM, Martin Sebor wrote:
Any plans to integrate it into the testsuite? (That way we presumably
wouldn't need to remember to run it by hand.)
Likely not, I'm not so big friend with DejaGNU.
Are you willing to help me with that?
I'm not a
[updating subject for greater visibility]
On Tue, 2021-03-16 at 08:51 -0600, Martin Sebor wrote:
> On 3/16/21 3:08 AM, Martin Liška wrote:
> > On 3/15/21 9:57 PM, Martin Sebor wrote:
> > > Any plans to integrate it into the testsuite? (That way we presu
> > > mably
> > > wouldn't need to remember
On 3/16/21 4:09 PM, David Malcolm wrote:
[updating subject for greater visibility]
On Tue, 2021-03-16 at 08:51 -0600, Martin Sebor wrote:
On 3/16/21 3:08 AM, Martin Liška wrote:
On 3/15/21 9:57 PM, Martin Sebor wrote:
Any plans to integrate it into the testsuite? (That way we presu
mably
wou
On Sun, Mar 14, 2021 at 1:31 PM H.J. Lu wrote:
>
> On Sun, Mar 14, 2021 at 12:43 PM Uros Bizjak wrote:
> >
> > On Sun, Mar 14, 2021 at 8:14 PM H.J. Lu wrote:
> > > > > Done. Here is the updated patch. Tested on Linux/x86-64. OK for
> > > > > master?
> > > >
> > > > I don't understand the pur
Hi!
On Mon, Mar 15, 2021 at 11:11:32AM +0800, HAO CHEN GUI via Gcc-patches wrote:
> This patch adds const_anchor for rs6000. The const_anchor is used
> in cse pass.
1) This isn't suitable for stage 4.
2) Please add a test case, which shows what it does, that it is useful.
3) Does this work o
Hi Everybody,
Although this is 'obvious' I thought that I should post it because I
believe that it was triggered by the fix for PR99602 but I just do not have
the bandwidth at the moment to test that. The ChangeLog together with the
patch is more than sufficient explanation.
Regtests OK on FC33/x
Ping...
On 2/22/2021 5:08 PM, Patrick McGehearty via Gcc-patches wrote:
Changes in this version from Version 7:
gcc/c-family/c-cppbuiltin.c
Changed modename to float_h_prefix
Removed (mode == TYPE_MODE...) code left over from earlier approach.
libgcc/libgcc2.c
R
Hi Paul,
On 16.03.21 17:42, Paul Richard Thomas via Gcc-patches wrote:
Fortran: Fix runtime errors for class actual arguments [PR99602].
* trans-array.c (gfc_conv_procedure_call): For class formal
arguments, use the _data field attributes for runtime errors.
* gfortran.dg/pr99602.f90: New test.
[snip]
Please find attached a new version of the patch. A major change compared to
the previous patch is that I created a separate pass which hopefully makes
reviewing also easier since it is almost self-contained. After realizing that
detecting loops which mimic the behavior of rawmemchr/strlen
On Sat, 13 Mar 2021 at 21:34, Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> As the patch shows, there are several bugs in
> aarch64_simd_clone_compute_vecsize_and_simdlen.
> One is that unlike for function declarations that aren't definitions
> it completely ignores argument types. Such decls
On Tue, Mar 16, 2021 at 06:34:34PM +0100, Christophe Lyon wrote:
> On Sat, 13 Mar 2021 at 21:34, Jakub Jelinek via Gcc-patches
> Unfortunately, the last new warning does not happen when running the
> tests with -mabi=ilp32.
> Is that small patch OK?
With a proper ChangeLog entry, sure.
Though perh
On Tue, 16 Mar 2021 at 18:38, Jakub Jelinek wrote:
>
> On Tue, Mar 16, 2021 at 06:34:34PM +0100, Christophe Lyon wrote:
> > On Sat, 13 Mar 2021 at 21:34, Jakub Jelinek via Gcc-patches
> > Unfortunately, the last new warning does not happen when running the
> > tests with -mabi=ilp32.
> > Is that s
Hi!
Honza has fairly recently changed operand_equal_p to compare
DECL_FIELD_OFFSET for COMPONENT_REFs when comparing addresses.
As the first testcase in this patch shows, while that is very nice
for optimizations, for the -Wduplicated-branches warning it causes
regressions. Pedantically a union i
Hi!
As mentioned in the PR, if end of two constructions of local statics
is strongly ordered, their destructors should be run in the reverse order.
As we run __cxa_guard_release before calling __cxa_atexit, it is possible
that we have two threads that access two local statics in the same order
for
Just a note that I do not have write access, so I will need someone who does
to commit this patch, if approved.
Richard
> -Original Message-
> From: Richard Wai
> Sent: March 11, 2021 9:13 AM
> To: 'Arnaud Charlet'
> Cc: 'gcc-patches@gcc.gnu.org' ; 'Bob Duff'
>
> Subject: RE: [PATCH] A
On Thu, Mar 11, 2021 at 07:57:23AM +0800, Xionghu Luo via Gcc-patches wrote:
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index ec068c58aa5..48eb91132a9 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -7000,11 +7000,15 @@ rs6000_expand_v
The bcdinvalid_ RTL instruction uses the "unordered" comparison,
which cannot be used if we have -ffinite-math-only. We really need
CCMODEs that describe what bits in a CR field are set by other insns
than just comparisons, but that is a lot more surgery, and it is stage 4
now. This patch does a
On 3/8/21 4:33 AM, Martin Liška wrote:
On 3/4/21 9:54 PM, Jason Merrill wrote:
On 3/4/21 10:52 AM, Martin Liška wrote:
On 3/4/21 4:45 PM, Jason Merrill wrote:
Sure, I guess you do need to set that flag for the local decls, but
that should be all.
Jason
Doing that also fails :/
This time
On 3/16/21 2:08 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, if end of two constructions of local statics
is strongly ordered, their destructors should be run in the reverse order.
As we run __cxa_guard_release before calling __cxa_atexit, it is possible
that we have two threads that acc
On 3/11/21 1:06 PM, Martin Sebor wrote:
More extensive testing of the patch I just committed in r11-7563 to
avoid the false positive -Warray-bounds on accesses to members of
virtual bases has exposed a couple of problems that cause many false
negatives for even basic bugs like:
typedef struc
On 3/11/21 3:52 AM, Jakub Jelinek wrote:
Hi!
build_cxx_call calls convert_from_reference at the end, so if an immediate
function returns a reference, we were constant evaluating not just that
call, but that call wrapped in an INDIRECT_REF. That unfortunately means
it can constant evaluate to so
Hi Tobias,
> Shouldn't there be also a testcase which triggers this run-time error?
The testcase is there, it simply has the wrong dg-foo:
! { dg-do compile }
which should be
! { dg-do run }
*-*-*
There are certainly more cases which should insert checks but currently don't,
like:
subrouti
Following:
https://gcc.gnu.org/pipermail/libstdc++/2021-March/052158.html
Here is the patch to complete __gnu_debug::basic_string support.
Contrarily to what I thought code in std::basic_string to generate a
basic_string_view works just fine for __gnu_debug::basic_string.
libstdc++: [_GL
C++20 allows floating-point types for non-type template parameters;
floating-point values are considered to be equivalent template arguments if
they are "identical", which conveniently seems to map onto an existing GCC
predicate.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
Hi!
On Tue, Mar 16, 2021 at 07:57:17PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 11, 2021 at 07:57:23AM +0800, Xionghu Luo via Gcc-patches wrote:
> > diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> > index ec068c58aa5..48eb91132a9 100644
> > --- a/gcc/config/rs6000/rs6000.c
In gcc-10, we don't handle disassembling a vector pair in little-endian mode
correctly. The solution is to make use of the disassemble accumulator code
that is endian friendly.
Trunk does not have this bug, as the use of opaque modes for the MMA types
"fixed" this issue there.
This passed bootst
On Tue, Mar 16, 2021 at 06:56:47PM +0100, Jakub Jelinek wrote:
> Hi!
>
> Honza has fairly recently changed operand_equal_p to compare
> DECL_FIELD_OFFSET for COMPONENT_REFs when comparing addresses.
> As the first testcase in this patch shows, while that is very nice
> for optimizations, for the -
Hi!
On 2021-03-17T00:24:55+0100, I wrote:
> Now, walking each function backwards (!), [...]
> I've now got a simple 'callback_op', which for '!is_lhs' looks at
> 'get_base_address ([op])', and if that 'var' is contained in the set of
> current candidates (initialized per containg 'bind's, which w
On 3/16/21 11:56 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
Honza has fairly recently changed operand_equal_p to compare
DECL_FIELD_OFFSET for COMPONENT_REFs when comparing addresses.
As the first testcase in this patch shows, while that is very nice
for optimizations, for the -Wduplicated-bra
Segher,
The const_anchor should work on both 64 and 32 bit. I think the
constant loading is cheap on 32 bit platform, so I only enabled it on
64 bit. I will add a test case and verify the patch on Darwin and AIX.
Thanks.
On 17/3/2021 上午 12:35, Segher Boessenkool wrote:
Hi!
On Mon, Mar
Thanks Jakub & Segher,
On 2021/3/17 06:47, Segher Boessenkool wrote:
Hi!
On Tue, Mar 16, 2021 at 07:57:17PM +0100, Jakub Jelinek wrote:
On Thu, Mar 11, 2021 at 07:57:23AM +0800, Xionghu Luo via Gcc-patches wrote:
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ec068
On 3/16/2021 5:32 AM, Nick Clifton via Gcc-patches wrote:
Hi Jan-Benedict,
With my re-started testing efforts, I've got another one for you I
guess (`./configure --target=v850-elf && make all-gcc`):
../.././gcc/config/v850/v850.c: In function ‘char*
construct_restore_jr(rtx)’:
../.././gcc/c
59 matches
Mail list logo
