On Wed, Oct 2, 2024 at 8:26 PM Jonathan Wakely wrote:
>
> On Wed, 2 Oct 2024 at 19:16, Jonathan Wakely wrote:
> >
> > On Wed, 2 Oct 2024 at 19:15, Dmitry Ilvokhin wrote:
> > >
> > > Instead of looping over every byte of the tail, unroll loop manually
> > > using switch statement, then compilers
On Thu, Oct 3, 2024 at 1:30 PM Georg-Johann Lay wrote:
>
> gcc.c-torture/execute/ieee/pr108540-1.c obviously requires that double
> is a 64-bit type, hence add pr108540-1.x as an according filter.
>
> Ok for trunk?
>
> And is there a reason for why we are still putting test cases in
> these old pa
On Thu, Oct 3, 2024 at 6:09 PM Andrew Pinski wrote:
>
> The comment here is not wrong, just it would be better if mentioning
> the C++ front-end instead of just the nested function lowering.
OK
> gcc/ChangeLog:
>
> * cfgexpand.cc (add_scope_conflicts_1): Expand comment
> on when
On Wed, Oct 2, 2024 at 3:48 PM Richard Sandiford
wrote:
>
> This patch tries to make check-function-bodies automatically
> choose between reading the regular assembly file and reading the
> LTO assembly file. There should only ever be one right answer,
> since check-function-bodies doesn't make s
On Wed, Oct 2, 2024 at 5:01 PM Georg-Johann Lay wrote:
>
> This test failed on int != 32-bit targets due to
> a[0] = b[0] = INT_MIN instead of using INT32_MIN.
OK.
Richard.
> Johann
>
> --
>
> testsuite/52641 - Fix gcc.dg/signbit-6.c for int != 32-bit targets.
>
> PR testsuite
On Thu, Oct 3, 2024 at 3:15 AM Andrew Waterman wrote:
>
> On Wed, Oct 2, 2024 at 4:41 PM Jeff Law wrote:
> >
> >
> >
> > On 10/2/24 4:39 PM, Andrew Waterman wrote:
> > > On Wed, Oct 2, 2024 at 5:56 AM Jeff Law wrote:
> > >>
> > >>
> > >>
> > >> On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
> > >>> W
On 10/2/24 7:53 AM, Richard Biener wrote:
For a specific testcase a lot of compile-time is spent in re-hashing
hashtable elements upon expansion. The following records the hash
in the hash element. This speeds up compilation by 20%.
There's probably module-related uses that need to be adjusted
On 10/3/24 7:09 PM, Eric Gallager wrote:
On Thu, Oct 3, 2024 at 12:41 PM Jason Merrill wrote:
By default -Wdeprecated warns about deprecations in the active standard.
When specified explicitly, let's also warn about deprecations in later
standards.
This strikes me as slightly dangerous. At t
Jason Merrill writes:
> On 10/3/24 7:09 PM, Eric Gallager wrote:
>> On Thu, Oct 3, 2024 at 12:41 PM Jason Merrill wrote:
>>>
>>> By default -Wdeprecated warns about deprecations in the active standard.
>>> When specified explicitly, let's also warn about deprecations in later
>>> standards.
>> T
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and perhaps
13?
-- >8 --
This implements the following small LWG issues:
3848. adjacent_view, adjacent_transform_view and slide_view missing base
accessor
3851. chunk_view::inner-iterator missing custom iter_move and iter_swap
Tested on x86_64-pc-linux-gnu, so far just dg.exp with
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26,impcx.
OK for trunk if full bootstrap + regtest passes?
-- >8 --
[temp.arg.nontype] changed in C++11 to allow naming internal-linkage
variables and functions. We currently already handle internal-link
On 10/3/24 10:41 PM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu, so far just dg.exp with
GXX_TESTSUITE_STDS=98,11,14,17,20,23,26,impcx.
OK for trunk if full bootstrap + regtest passes?
-- >8 --
[temp.arg.nontype] changed in C++11 to allow naming internal-linkage
variables and functio
On 10/3/24 8:52 PM, Nathaniel Shead wrote:
Tested on x86_64-pc-linux-gnu (so far just dg.exp), OK for trunk if full
bootstrap + regtest passes?
OK.
-- >8 --
Users of pushdecl assume that the returned decl will be a possibly
updated decl matching the one that was passed in. My r15-3910 chang
On 10/2/24 4:51 AM, Simon Martin wrote:
This is a follow-up to the discussion about testing changes to the C++
front end in
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664258.html
It also clarifies that the make invocation examples should be made from
the *build* tree.
Validated fine
Simon Martin writes:
> This is a follow-up to the discussion about testing changes to the C++
> front end in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664258.html
>
> It also clarifies that the make invocation examples should be made from
> the *build* tree.
>
> Validated fine via
gcc/ChangeLog:
* gimplify.cc (gimple_add_init_for_auto_var): Fix 'variable' typo.
---
Committed as obvious.
gcc/gimplify.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index ceb53e5d5bb7..dd7efa71b742 100644
--- a/gcc/gimplify.cc
Fix incorrect use of '[' rather than '{' in 'dg-...' directives.
gcc/testsuite/ChangeLog:
* gnat.dg/pack13.adb: Fix 'dg-...' directive syntax.
* gnat.dg/size_attribute.adb: Ditto.
* gnat.dg/subp_elim_errors.adb: Ditto.
---
Committed as obvious.
gcc/testsuite/gnat.dg/pack
These patches fix several warnings which appeared when building libgcc
for aarch64.
* Patch 1 fixes a redefinition of macro 'L' in lse.S after a recent
patch.
* Patch 2 adds prototypes to avoid a warning emitted because we build
with -Wmissing-prototypes.
* Patch 3 adds support for -Werror i
When --enable-werror is enabled when running the top-level configure,
it passes --enable-werror-always to subdirs. Some of them, like
libgcc, ignore it.
This patch adds support for it, enabled only for aarch64, to avoid
breaking bootstrap for other targets.
The patch also adds -Wno-prio-ctor-dto
Since
Commit c608ada288ced0268c1fd4136f56c34b24d4
Author: Zac Walker
CommitDate: 2024-01-23 15:32:30 +
Ifdef `.hidden`, `.type`, and `.size` pseudo-ops for `aarch64-w64-mingw32`
target
lse.S includes aarch64-asm.h, leading to a conflicting definition of macro 'L':
- in lse.S
Add prototypes for __init_cpu_features_resolver and
__init_cpu_features to avoid warnings due to -Wmissing-prototypes.
libgcc/
* config/aarch64/cpuinfo.c (__init_cpu_features_resolver): Add
prototype.
(__init_cpu_features): Likewise.
---
libgcc/config/aarch64/cpuin
On Thu, 3 Oct 2024, Jeff Law wrote:
> We can remove a couple of XFAILs in the rv32 space as it's behaving much more
> like rv64 at this point.
I'm glad to see them gone. I have a couple of concerns with your change
though.
Given:
* gcc.target/riscv/cset-sext.c: Similarly. No longer
On Thu, Oct 3, 2024 at 4:41 PM Maciej W. Rozycki wrote:
>
> On Thu, 3 Oct 2024, Jeff Law wrote:
>
> > We can remove a couple of XFAILs in the rv32 space as it's behaving much
> > more
> > like rv64 at this point.
>
> I'm glad to see them gone. I have a couple of concerns with your change
> thou
On Thu, Oct 3, 2024 at 12:41 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> By default -Wdeprecated warns about deprecations in the active standard.
> When specified explicitly, let's also warn about deprecations in later
> standards.
>
> gcc/c-family/C
Tested on x86_64-pc-linux-gnu (so far just dg.exp), OK for trunk if full
bootstrap + regtest passes?
-- >8 --
Users of pushdecl assume that the returned decl will be a possibly
updated decl matching the one that was passed in. My r15-3910 change
broke this since in some cases we would now return
On 01.10.24 18:02, Jonathan Wakely wrote:
On Tue, 1 Oct 2024 at 16:53, Frank Scheiner wrote:
Though I don't understand why. From the error message it sounds like 'u'
was replaced with '(' before the __ctx macro could do its job.
But Joseph also wrote that it "prepends __ in standards conforman
We see:
```
FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors)
FAIL: 17_intro/names_pstl.cc -std=gnu++17 (test for excess errors)
FAIL: experimental/names.cc -std=gnu++17 (test for excess errors)
```
...on ia64-linux.
This is due to:
* /usr/include/bits/sigcontext.h:32-38:
```
32
On Thu, Mar 21, 2024 at 06:21:48PM +0530, jeevitha wrote:
Hi!
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
Please send v2 patches as their own, new thread. Replies are for
replies (duh), and for patch series. If you mix several versions in one
thread things be
On 10/3/24 2:24 PM, Segher Boessenkool wrote:
> On Thu, Mar 21, 2024 at 06:21:48PM +0530, jeevitha wrote:
>> PTImode assists in generating even/odd register pairs on 128 bits. When the
>> user
>> specifies PTImode as an attribute, it breaks because there is no internal
>> type
>> to handle this
On 10/3/24 12:38 PM, Jason Merrill wrote:
On 10/2/24 7:50 AM, Richard Biener wrote:
This reduces peak memory usage by 20% for a specific testcase.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
It's very ugly so I'd appreciate suggestions on how to handle such
situations better?
I'm pu
From: Saurabh Jha
This is a revised version of this patch series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664329.html
Unfortunately, I had test case failures which I missed but shouldn't
have. Apologies for that.
This version fixes the failing test cases in the second patch with
The AArch64 FEAT_FAMINMAX extension introduces instructions for
computing the floating point absolute maximum and minimum of the
two vectors element-wise.
This patch adds code generation for famax and famin in terms of existing
unspecs. With this patch:
1. famax can be expressed as taking UNSPEC_
The AArch64 FEAT_FAMINMAX extension introduces instructions for
computing the floating point absolute maximum and minimum of the
two vectors element-wise.
This patch introduces SVE2 faminmax intrinsics. The intrinsics of this
extension are implemented as the following builtin functions:
* sva[max
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage, calls, and
condition coverage.
$ gcc --coverage -fpath-coverage hello.c -o hello
$ ./hello
Before:
$ gcov -
This is both a ping and a minor update. A few of the patches from the
previous set have been merged, but the big feature still needs review.
Since then it has been quiet, but there are two notable changes:
1. The --prime-paths-{lines,source} flags take an optional argument to
print covered or
Hi!
On 2024-09-06T11:30:06+0200, Richard Biener wrote:
> On Thu, 5 Sep 2024, Richard Biener wrote:
>> The following enables single-lane loop SLP discovery for non-grouped stores
>> and adjusts vectorizable_store to properly handle those.
> I have now pushed this as r15-3509-gd34cda72098867
>> -
Ping.
> On 24 Sep 2024, at 2:00 PM, Soumya AR wrote:
>
> This patch implements constant folding for svlsl. Test cases have been added
> to
> check for the following cases:
>
> Zero, merge, and don't care predication.
> Shift by 0.
> Shift by register width.
> Overflow shift on signed and unsig
On Wed, 2 Oct 2024, Andrew Pinski wrote:
> On Tue, Oct 1, 2024 at 5:04 AM Richard Biener wrote:
> >
> > The following adds SLP support for vectorizing single-lane inductions
> > with variable length vectors.
>
> This introduces a bootstrap failure on aarch64 due to a maybe
> uninitialized variab
This zero-initializes vec_init to avoid a bogus maybe-uninitialized
diagnostic.
Built on x86_64-unknown-linux-gnu, pushed as obvious.
* tree-vect-loop.cc (vectorizable_induction): Initialize
vec_init.
---
gcc/tree-vect-loop.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
gcc.c-torture/execute/ieee/pr108540-1.c obviously requires that double
is a 64-bit type, hence add pr108540-1.x as an according filter.
Ok for trunk?
And is there a reason for why we are still putting test cases in
these old parts of the testsuite that don't support dg-magic-comments
like
/* {
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/locale_facets_nonio.tcc (money_put::__do_get):
Ignore -Wformat warning for __ibm128 arguments.
* include/tr1/tuple (ignore): Ignore -Wunused warning.
---
libstdc++-v3/include/bits/local
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/unicode.h (__unicode::__is_incb_linker): Use
_GLIBCXX_STD_A namespace for std::find.
---
libstdc++-v3/include/bits/unicode.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Tested x86_64-linux. Pushed to trunk.
-- >8 --
The pragmas to disable warnings need to be moved before the first use of
the deprecated classes.
libstdc++-v3/ChangeLog:
PR libstdc++/116944
* include/parallel/base.h: Move diagnostic pragmas earlier.
---
libstdc++-v3/include/paral
On Thu, 3 Oct 2024, Thomas Schwinge wrote:
> Hi!
>
> On 2024-09-06T11:30:06+0200, Richard Biener wrote:
> > On Thu, 5 Sep 2024, Richard Biener wrote:
> >> The following enables single-lane loop SLP discovery for non-grouped stores
> >> and adjusts vectorizable_store to properly handle those.
>
On Wed, Oct 2, 2024 at 10:43 PM Sam James wrote:
>
> Valgrind doesn't error out by default which means bootstrap issues like
> in PR116945 can easily be missed: pass --exit-errorcode=1 to handle this.
>
> gcc/ChangeLog:
> PR other/116945
> PR other/116947
>
> * gcc.cc (exec
On Wed, Oct 02, 2024 at 08:15:38PM +0100, Jonathan Wakely wrote:
> On Wed, 2 Oct 2024 at 19:25, Jonathan Wakely wrote:
> >
> > On Wed, 2 Oct 2024 at 19:16, Jonathan Wakely wrote:
> > >
> > > On Wed, 2 Oct 2024 at 19:15, Dmitry Ilvokhin wrote:
> > > >
> > > > Instead of looping over every byte of
gcc.dg/c23-stdarg-9.c failed because the code requested too
much stack memory. With less stack allocated, this test passes.
Applied as obvious.
Johann
--
AVR: Make gcc.dg/c23-stdarg-9.c work.
gcc/testsuite/
* gcc.dg/c23-stdarg-9.c (struct S) [AVR]: Only use int a[500].
di
Some of the musttail tests (eg musttail7.c) fail on arm-eabi because
check_effective_target_musttail pass, but the actual code in the test
is rejected.
The reason is that on arm-eabi with the default configuration, the
compiler targets armv4t for which TARGET_INTERWORK is true, making
arm_function
On Thu, Oct 03, 2024 at 01:48:35PM +, Christophe Lyon wrote:
> Some of the musttail tests (eg musttail7.c) fail on arm-eabi because
> check_effective_target_musttail pass, but the actual code in the test
> is rejected.
Looks good to me. Thanks.
-Andi
On Thu, 2024-10-03 at 00:37 -0700, Andi Kleen wrote:
> > Note that if the user requests SARIF output e.g. with
> > -fdiagnostics-format=sarif-stderr
> > then any timevar data from -ftime-report is written in JSON form as
> > part of the SARIF, rather than in text form to stderr (see
> > 75d623946
Soumya AR writes:
> From 7fafcb5e0174c56205ec05406c9a412196ae93d3 Mon Sep 17 00:00:00 2001
> From: Soumya AR
> Date: Thu, 3 Oct 2024 11:53:07 +0530
> Subject: [PATCH] aarch64: Optimise calls to ldexp with SVE FSCALE instruction
>
> This patch uses the FSCALE instruction provided by SVE to impleme
Eric Botcazou writes:
> Hi,
>
> the macro is documented like this in the internal manual:
>
> -- Macro: WIDEST_HARDWARE_FP_SIZE
> A C expression for the size in bits of the widest floating-point
> format supported by the hardware. If you define this macro, you
> must specify a val
> On 1 Oct 2024, at 14:27, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, 1 Oct 2024, Jennifer Schmitz wrote:
>
>> This patch implements 4 rules for logarithmic identities in match.pd
>> under -funsafe-math-optimizations:
>> 1) logN(1.0/a) ->
GCC maintainers:
The builtins-1-10-runnable.c has the debugging inadvertently enabled.
The test uses #ifdef to enable/disable the debugging. Unfortunately, the
#define DEBUG was set to 0 to disable debugging and enable the call to
abort in case of error. The #define should have been removed
Currently, we lack support for TARGET_CAN_INLINE_P on the RISC-V
ISA. As a result, certain functions cannot be optimized with inlining
when specific options, such as __attribute__((target("arch=+v"))) .
This can lead to potential performance issues when building
retargetable binaries for RISC-V.
T
> On 3 Oct 2024, at 16:41, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Soumya AR writes:
>> From 7fafcb5e0174c56205ec05406c9a412196ae93d3 Mon Sep 17 00:00:00 2001
>> From: Soumya AR
>> Date: Thu, 3 Oct 2024 11:53:07 +0530
>> Subject: [PATCH] a
The comment here is not wrong, just it would be better if mentioning
the C++ front-end instead of just the nested function lowering.
gcc/ChangeLog:
* cfgexpand.cc (add_scope_conflicts_1): Expand comment
on when non-var clobbers show up.
Signed-off-by: Andrew Pinski
---
gcc/cfge
After fixing loop-im to do the correct overflow rewriting
for pointer types too. We end up with code like:
```
_9 = (unsigned long) &g;
_84 = _9 + 18446744073709551615;
_11 = _42 + _84;
_44 = (signed char *) _11;
...
*_44 = 10;
g ={v} {CLOBBER(eos)};
...
n[0] = &f;
*_44 = 8;
g ={v
While looking into the ifcombine, I noticed that rewrite_to_defined_overflow
was rewriting already defined code. In the previous attempt at fixing this,
the review mentioned we should not be calling rewrite_to_defined_overflow
in those cases. The places which called rewrite_to_defined_overflow didn
On 9/28/24 2:39 AM, Jakub Jelinek wrote:
On Fri, Sep 27, 2024 at 04:01:33PM +0200, Jakub Jelinek wrote:
So, I think we should go with (but so far completely untested except
for pr78687.C which is optimized with Marek's patch and the above testcase
which doesn't have the clearing anymore) the fol
Andrew P's recent improvements to phiopt regressed on the riscv testsuite.
Essentially the new code presented to the RTL optimizers is straightline
code rather than branchy for the CE pass to analyze and optimize. In
the absence of conditional move support or sfb, the new code would be
better
On 10/2/24 7:50 AM, Richard Biener wrote:
This reduces peak memory usage by 20% for a specific testcase.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
It's very ugly so I'd appreciate suggestions on how to handle such
situations better?
I'm pushing this alternative patch, tested x86_64
I am working on some changes to GNAT to emit hierarchical DWARF --
i.e., where entities will have simple names nested in a DW_TAG_module.
While working on this I found a couple of paths in modified_type_die
where "mod_scope" should be used, but is not. I suspect these cases
are only reachable by
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
By default -Wdeprecated warns about deprecations in the active standard.
When specified explicitly, let's also warn about deprecations in later
standards.
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Explicit -Wdepr
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
C++23 CWG issue 2521 (https://wg21.link/cwg2521) deprecates user-defined
literal operators declared with the optional space between "" and the
suffix.
Many testcases used that syntax; I removed the space from most of them, and
added C++23 w
On 02/10/2024 19:07, Jonathan Wakely wrote:
On Wed, 2 Oct 2024 at 17:39, Jonathan Wakely wrote:
On Wed, 25 Sept 2024 at 18:22, François Dumont wrote:
Hi
Once https://gcc.gnu.org/pipermail/libstdc++/2024-September/059568.html
will be accepted we will be able fix this long lasting issue that
Eric Botcazou writes:
> Hi,
>
> this changes the stack checking method (that of -fstack-check) used on Linux
> from the traditional model (probe then move SP) to the model implemented for
> -fstack-clash-protection (probe while moving SP). The rationale is that the
> latter is in widespread use o
Alexander Monakov writes:
> I would like to propose Valgrind integration previously sent as RFC for trunk.
>
> Arsen and Sam, since you commented on the RFC I wonder if you can have
> a look at the proposed configure and documentation changes and let me
> know if they look fine for you? For refer
avr_out_sbxx_branch calls jump_over_one_insn_p which may clobber
recog_data.operand as is calls extract on the next insn.
A fix is to make a copy of avr_out_sbxx_branch`s incoming operands.
Ok to apply?
Johann
--
AVR: target/116953 - ICE due to operands clobber in avr_out_sbxx_branch.
Tamar Christina writes:
> Hi,
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, September 30, 2024 6:33 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; ktkac...@gcc.gnu.org
>> Subject: Re: [PATCH 2/2]AArch64: su
Andrew Pinski writes:
> Early-RA was considering throwing instructions as being dead and removing
> them even if -fno-delete-dead-exceptions was in use. This fixes that
> oversight.
>
> Built and tested for aarch64-linux-gnu.
>
> PR target/116927
>
> gcc/ChangeLog:
>
> * config/aarch6
> Note that if the user requests SARIF output e.g. with
> -fdiagnostics-format=sarif-stderr
> then any timevar data from -ftime-report is written in JSON form as
> part of the SARIF, rather than in text form to stderr (see
> 75d623946d4b6ea80a777b789b116d4b4a2298dc).
>
> I see that the proposed
> On 1 Oct 2024, at 1:18 PM, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi Soumya,
>
> Nice patch!
>
>> -Original Message-
>> From: Kyrylo Tkachov
>> Sent: Tuesday, October 1, 2024 7:55 AM
>> To: Soumya AR
>> Cc: gcc-patches@gcc.gnu.org; R
Ping.
> On 20 Sep 2024, at 11:28, Jennifer Schmitz wrote:
>
> For svmul, if one of the operands is a constant vector with a uniform
> power of 2, this patch folds the multiplication to a left-shift by
> immediate (svlsl).
> Because the shift amount in svlsl is the second operand, the order of th
From: Kito Cheng
This provides a common abstraction layer to probe the available extensions at
run-time. These functions can be used to implement function multi-versioning or
to detect available extensions.
The advantages of providing this abstraction layer are:
- Easy to port to other new platf
> The only consumer I know of for the JSON time report data is in the
> integration tests I wrote for -fanalyzer, which assumes that all fields
> are present when printing, and then goes on to use the "user" times for
> summarizing; see this commit FWIW:
> https://github.com/davidmalcolm/gcc-analyz
From: Kito Cheng
This provides a common abstraction layer to probe the available extensions at
run-time. These functions can be used to implement function multi-versioning or
to detect available extensions.
The advantages of providing this abstraction layer are:
- Easy to port to other new platf
77 matches
Mail list logo
