On Thu, Apr 15, 2021 at 6:50 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi,
>
> the gimplefe40 and gimplefe41.c tests expect vector capabilities
> (vect_float etc.) yet are not in the vect subdirectory. This causes
> both to be called unconditionally without prior target-specific vector
> setup nor
The new testcase was breaking because constexpr evaluation was simplifying
Bar{Baz<42>{}} to Bar{empty}, but then we weren't treating them as
equivalent. Poking at this revealed that the code for eliding trailing
zero-initialization in class non-type template argument mangling was pretty
broken, i
On 4/15/21 10:02 PM, Marek Polacek wrote:
On Thu, Apr 15, 2021 at 03:31:24PM -0400, Jason Merrill wrote:
On 4/14/21 9:21 PM, Marek Polacek wrote:
Here we ICE when compiling this code in C++20, because we're trying to
slam a 'typename' after the ->. The cp_parser_template_id call just
before th
On Thu, Apr 15, 2021 at 03:31:24PM -0400, Jason Merrill wrote:
> On 4/14/21 9:21 PM, Marek Polacek wrote:
> > Here we ICE when compiling this code in C++20, because we're trying to
> > slam a 'typename' after the ->. The cp_parser_template_id call just
> > before the spot I'm changing parsed A::te
- ping
[A sincere and special thanks for the sustained perseverance of the
reviewers in pointing me in the proper direction to get this patch
polished. The original proposal was June 1, 2020 and only covered
double precision. The current version is dramatically better, both
from extending coverag
On 4/14/21 3:10 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs in tsubst_decomp_names because the assumptions
that the structured binding artificial var is followed in DECL_CHAIN by
the corresponding structured binding vars is violated.
I've tracked it to extract_locals* which is done
Hello everybody,
we currently write the interface for intrinsic procedures to module
files although that should not be necessary. (F2018:15.4.2.1 actually
states that interfaces e.g. of intrinsic procedures are 'explicit'.)
This lead to bogus errors due to an apparently bogus ambiguity.
A simple
Unfortunately it appears that this PR is on nobody's radar.
Xfailing it to get an arguably artificial zero regression
state (since T0=2007-01-05) helps my autotester.
Caveat: the pass/fail state of this test, as long as stack
alignment isn't adjusted, is dependent on the alignment of
the stack at
When calling a static member function we still need to evaluate an explicit
object argument. But we don't want to force a load of the entire object
if the argument is volatile, so we take its address. If as a result it no
longer has any side-effects, we don't need to evaluate it after all.
Teste
On Thu, 8 Apr 2021, Martin Sebor via Gcc-patches wrote:
> There's another similar piece of code in pushdecl() that I didn't
> touch, although I couldn't come up with a test case showing it's
> necessary. Both hunks go back ages so I wonder if they might have
> been obviated by other improvements
The false positives have disappeared thanks to
g:520d5ad337eaa15860a5a964daf7ca46cf31c029. I have added the two
test cases in the attached diff in r11-8202 after testing on aarch64,
arm, powerpc64le, and x86_64, out of an abundance of caution.
Martin
commit 2dbbbe893f75f587c48111ab4c97cf5e74fb91
On 4/15/21 3:51 PM, Patrick Palka wrote:
Here, reduced_constant_expression_p is incorrectly returning true for a
partially initialized array CONSTRUCTOR, because when the
CONSTRUCTOR_NO_CLEARING flag is set the predicate doesn't check that
every array element is initialized by the CONSTRUCTOR, it
Here, reduced_constant_expression_p is incorrectly returning true for a
partially initialized array CONSTRUCTOR, because when the
CONSTRUCTOR_NO_CLEARING flag is set the predicate doesn't check that
every array element is initialized by the CONSTRUCTOR, it just checks
that every initializer within
On 4/14/21 3:18 PM, Jakub Jelinek wrote:
The requires clause parsing has code to suggest users wrapping
non-primary expressions in (), so if it e.g. parses a primary expression
and sees it is followed by ++, --, ., ( or -> among other things it
will try to reparse it as assignment expression or w
On 4/14/21 9:21 PM, Marek Polacek wrote:
Here we ICE when compiling this code in C++20, because we're trying to
slam a 'typename' after the ->. The cp_parser_template_id call just
before the spot I'm changing parsed A::template A as a BASELINK
that contains a constructor, but make_typename_type
Here instantiating the noexcept-specifier for bar() means
instantiating A::value, which complains about the conversion from 0 to
int* in the default argument of foo. Since my patch for PR99583, printing
the error context involves looking at C::type, which again wants to
instantiate A::value, which
On Thu, Apr 15, 2021 at 07:11:11PM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > --- gcc/config/aarch64/aarch64.md.jj2021-04-15 10:45:02.798853095
> > +0200
> > +++ gcc/config/aarch64/aarch64.md 2021-04-15 13:28:04.734754364 +0200
> > @@ -3572,6 +3572,18 @@ (define_insn "*
Hi All!
Proposed patch to:
PR100103 - Automatic reallocation fails inside select rank
Patch tested only on x86_64-pc-linux-gnu.
Add select rank temporary associated names as possible targets of
automatic reallocation.
The patch depends on PR100097 and PR100098.
Thank you very much.
Best r
Jakub Jelinek writes:
> --- gcc/config/aarch64/aarch64.md.jj 2021-04-15 10:45:02.798853095 +0200
> +++ gcc/config/aarch64/aarch64.md 2021-04-15 13:28:04.734754364 +0200
> @@ -3572,6 +3572,18 @@ (define_insn "*neg__si2_uxtw"
>[(set_attr "autodetect_type" "alu_shift__op2")]
> )
>
> +(def
On Thu, Apr 15, 2021 at 6:51 PM H.J. Lu wrote:
>
> On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak wrote:
> >
> > On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu wrote:
> > >
> > > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu wrote:
> > > > >
>
On s390* the only missing part for the mentioned testcases was a load of
a double floating-point zero via a move (in particular for quite old
machines) which was added in commit 46c47420a5fefd4d9d02b0db347235dd74e20fb2.
Common code implementation is sufficient in order to clear volatile
GPRs, FPRs,
Looks good in general, but like you say, it's GCC 12 material.
Alex Coplan writes:
> diff --git a/gcc/config/aarch64/aarch64-bti-insert.c
> b/gcc/config/aarch64/aarch64-bti-insert.c
> index 936649769c7..943fa3c1097 100644
> --- a/gcc/config/aarch64/aarch64-bti-insert.c
> +++ b/gcc/config/aarch64
On Thu, Apr 15, 2021 at 9:53 AM Uros Bizjak wrote:
>
> On Thu, Apr 15, 2021 at 6:51 PM H.J. Lu wrote:
> >
> > On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak wrote:
> > >
> > > On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak wrote:
> > > >
Hi!
On 2021-02-26T04:34:50-0800, Julian Brown wrote:
> This patch
Thanks, Julian, for your continued improving of these changes!
This has iterated through several conceptually different designs and
implementations, by several people, over the past several years.
It's now been made my task to f
On Thu, Apr 15, 2021 at 6:51 PM H.J. Lu wrote:
>
> On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak wrote:
> >
> > On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu wrote:
> > >
> > > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak wrote:
> > > >
> > > > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu wrote:
> > > > >
>
On Thu, Apr 15, 2021 at 9:34 AM Uros Bizjak wrote:
>
> On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu wrote:
> >
> > On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak wrote:
> > >
> > > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu wrote:
> > > >
> > > > Use crc32 target option for CRC32 intrinsics to support CRC
On 15/04/21 18:23 +0200, Eric Botcazou wrote:
Without this I see a number of tests failing when -m32 is used.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (add_options_for_libatomic): Also
add libatomic options for 32-bit sparc*-*-linux-gnu.
Eric, are you OK with this
My patch for 99478 relied on local_variables_forbidden_p for distinguishing
between a template parameter and its default argument, but that flag wasn't
set for a default type template-argument.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/100091
PR c++/
On Thu, Apr 15, 2021 at 6:26 PM H.J. Lu wrote:
>
> On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak wrote:
> >
> > On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu wrote:
> > >
> > > Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
> > > without enabling SSE vector instructions.
> >
>
On Thu, Apr 15, 2021 at 9:14 AM Uros Bizjak wrote:
>
> On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu wrote:
> >
> > Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
> > without enabling SSE vector instructions.
>
> There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
>
> Without this I see a number of tests failing when -m32 is used.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/lib/dg-options.exp (add_options_for_libatomic): Also
> add libatomic options for 32-bit sparc*-*-linux-gnu.
>
> Eric, are you OK with this? It adds -latomic and the appropria
On April 15, 2021 6:08:44 PM GMT+02:00, Martin Sebor wrote:
>On 4/15/21 5:01 AM, Richard Biener wrote:
>> This adds a deprecation note to the undocumented gimple-builder.h
>> API only used by asan and sancov.
>>
>> Pushed.
>>
>> 2021-04-15 Richard Biener
>>
>> * gimple-builder.h: Add de
On Thu, Apr 15, 2021 at 5:11 PM H.J. Lu wrote:
>
> Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
> without enabling SSE vector instructions.
There is no CRC32 ISA. crc32 is part of SSE4.2 [1] and current
situation reflects that correctly.
[1] https://en.wikipedia.org/w
The changes for PR libstdc++/64735 mean that libsupc++ function might
now depend on the __exchange_and_add and __atomic_add functions defined
in config/cpu/*/atomicity.h which is not compiled into libsupc++. This
causes a link failure for some targets when trying to use libsupc++
without the rest o
On 4/15/21 5:01 AM, Richard Biener wrote:
This adds a deprecation note to the undocumented gimple-builder.h
API only used by asan and sancov.
Pushed.
2021-04-15 Richard Biener
* gimple-builder.h: Add deprecation note.
---
gcc/gimple-builder.h | 2 ++
1 file changed, 2 insertions(
[PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC.
This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max.
In this patch, I simplified things. Instead of allowing any four of the modes
to be used for the conditional
Without this I see a number of tests failing when -m32 is used.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (add_options_for_libatomic): Also
add libatomic options for 32-bit sparc*-*-linux-gnu.
Eric, are you OK with this? It adds -latomic and the appropriate -L
option
[PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.
This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions. The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.
I removed the FLOAT128_M
These patches add support for the XSMAXCQP, XSMINCQP, XSCMPEQQP, XSCMPGTQP, and
XSCMPGEQP instructions that were added to the PowerPC ISA 3.1 (power10).
These patches address the comments raised from the last version of the patches.
In this iteration, I simplified the first patch, eliminating a n
Hi,
the gimplefe40 and gimplefe41.c tests expect vector capabilities
(vect_float etc.) yet are not in the vect subdirectory. This causes
both to be called unconditionally without prior target-specific vector
setup normally performed by vect/vect.exp.
There is a target-specific option for po
Hi!
The testcase used to be compiled at -O2 by GCC8 and earlier to:
f1:
neg w1, w0, asr 16
and w1, w1, 65535
orr w0, w1, w0, lsl 16
ret
f2:
neg w1, w0
extrw0, w1, w0, 16
ret
but since GCC9 (r9-3594 for f1 and r9-6926 for f
Hi All!
Proposed patch to:
PR100097 - Unlimited polymorphic pointers and allocatables have
incorrect rank
PR100098 - Polymorphic pointers and allocatables have incorrect rank
Patch tested only on x86_64-pc-linux-gnu.
Pointers, and allocatables, must carry TKR information even when
undefined
This patch follows on from a previous one and adds -mtune=generic
to the SVE ACLE assembler tests. These tests are pure assembly
tests (execution tests are elsewhere) and they already require
dg-additional-options to be used to add new options. We therefore
don't need aarch64-with-arch-dg-options
A lot of the SVE assembly tests are for generic-tuned SVE codegen
and so can fail when run on a toolchain configured with --with-cpu.
This could easily be solved by forcing -mtune=generic, like we already
do for -moverride=tune=none. However, the testsuite also has some
useful execution tests tha
Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
without enabling SSE vector instructions.
* config/i386/gnu-property.c
(file_end_indicate_exec_stack_and_gnu_property): Also check
TARGET_CRC32 for GNU_PROPERTY_X86_ISA_1_V2.
* config/i386/i386
Hi all,
The PR shows two ICEs with __sync_bool_compare_and_swap and
-mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one
later on, after the CAS insn is split.
The LRA ICE occurs because the
@atomic_compare_and_swap_1 pattern attempts to tie
two output operands together (opera
On Thu, Apr 15, 2021 at 2:51 PM Stefan Schulze Frielinghaus via
Gcc-patches wrote:
>
> For z10 and newer inner loops are completely unrolled which leaves no
> inner loops to jam which renders this testcase to fail. Reverting
> max-completely-peel-times to the default value fixes this testcase.
>
Hi,
On Wed, 14 Apr 2021 at 02:20, Jason Merrill via Gcc-patches
wrote:
>
> PR49951 complained about the debugger jumping back to the declaration of a
> local variable when we run its destructor. That was fixed in 4.7, but broke
> again in 4.8. PR58123 fixed an inconsistency in the behavior, but
gcc/ChangeLog:
* doc/invoke.texi: Other params don't use it, remove it.
---
gcc/doc/invoke.texi | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 17551246477..096cebc8562 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -13049,
On 23/03/21 12:00 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
* This patch addresses jwakely's previous feedback.
* This patch also subsumes thiago.macie...@intel.com 's 'Uncontroversial
If this part is intended as part of the commit msg let's put Thiago's
name rather than email address
On 15.04.21 13:56, José Rui Faustino de Sousa via Gcc-patches wrote:
Proposed patch to:
PR100094 - Undefined pointers have incorrect rank when using optimization
Patch tested only on x86_64-pc-linux-gnu.
LGTM - thanks!
Tobias
Pointers, and allocatables, must carry TKR information even when
On Thu, 2021-04-15 at 11:45 +0200, Jan Hubicka wrote:
> Hi,
> this is patch fixing the underlying issue of function missing
> lto_prepare_function_for_streaming because gimple_has_body_p is not
> the
> same thing as node.has_gimple_body (which needs to be clarified next
> stage1 by finding better n
Hi!
I'd like to ping this patch, it is one of the last 4 P1s we have for GCC11.
Thanks.
On Thu, Apr 08, 2021 at 04:15:42PM -0600, Martin Sebor via Gcc-patches wrote:
> PR c/99420 - bogus -Warray-parameter on a function redeclaration in function
> scope
> PR c/99972 - missing -Wunused-result on
On Wed, Apr 14, 2021 at 07:50:37PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 14, 2021 at 10:49:42AM -0600, Martin Sebor via Gcc-patches wrote:
> > Apparently the IL GCC emits on some targets (arm and aarach64 with
> > mabi=ilp32, and powerpc64 to name the three where the failures have
> > been poin
For z10 and newer inner loops are completely unrolled which leaves no
inner loops to jam which renders this testcase to fail. Reverting
max-completely-peel-times to the default value fixes this testcase.
gcc/testsuite/ChangeLog:
* gcc.dg/unroll-and-jam.c: Revert max-completely-peel-times
Pushed to master in commit 9a0e09f3dd5339bb18cc47317f2298d9157ced29
Thanks
Paul
On Wed, 14 Apr 2021 at 14:51, Tobias Burnus wrote:
> On 11.04.21 09:05, Paul Richard Thomas wrote:
> > Tobias noticed a major technical fault with the resubmission below: I
> > forgot to attach the patch :-(
>
> L
Hi All!
Proposed patch to:
PR100094 - Undefined pointers have incorrect rank when using optimization
Patch tested only on x86_64-pc-linux-gnu.
Pointers, and allocatables, must carry TKR information even when
undefined. The patch adds code to initialize both pointers and
allocatables element
On Thu, 15 Apr 2021, Xionghu Luo wrote:
> Thanks,
>
> On 2021/4/14 14:41, Richard Biener wrote:
> >> "#538,#235,#234,#233" will all be sunk from bb 35 to bb 37 by rtl-sink,
> >> but it moves #538 first, then #235, there is strong dependency here. It
> >> seemsdoesn't like the LCM framework that c
This removes the legacy gimplify_buildN API use from complex lowering.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress, queued for
stage1
2021-04-15 Richard Biener
* tree-complex.c: Include gimple-fold.h.
(expand_complex_addition): Use gimple_build.
(exp
This removes use of the legacy gimplify_buildN API from phiopt.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1
2021-04-15 Richard Biener
* tree-ssa-phiopt.c (two_value_replacement): Remove use
of legacy gimplify_buildN API.
---
gcc/tree-ssa-phiopt.c |
This adds a deprecation note to the undocumented gimple-builder.h
API only used by asan and sancov.
Pushed.
2021-04-15 Richard Biener
* gimple-builder.h: Add deprecation note.
---
gcc/gimple-builder.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/gimple-builder.h b/gcc/gi
Hi José,
first, I think you did not yet commit the approved patch for PR100018,
did you?
On 11.04.21 02:34, José Rui Faustino de Sousa via Fortran wrote:
Proposed patch to:
PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS entity
PR100027 - ICE on storage_size with polymorphic a
Hi,
this is patch fixing the underlying issue of function missing
lto_prepare_function_for_streaming because gimple_has_body_p is not the
same thing as node.has_gimple_body (which needs to be clarified next
stage1 by finding better names for this I suppose).
I commited it to gcc 11 even though we
Hi!
On 2021-04-09T13:00:39+0200, I wrote:
> On 2021-03-25T12:02:15+0100, I wrote:
>> On 2021-03-11T17:52:55+0100, I wrote:
>>> On 2021-02-23T22:52:38+0100, Jakub Jelinek via Gcc-patches
>>> wrote:
On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
> On 19/02/2021 7:12 pm
64 matches
Mail list logo
