On Tue, 4 Feb 2025 at 14:19, Andreas Schwab wrote:
>
> On Feb 04 2025, Jonathan Wakely wrote:
>
> > I think this will cause check-abi failures on risc-v because the new
> > symbols are added to CXXABI_1.3.16 but the "latest_p" map says that
> > new symbols (i.e. ones not present in the baseline_sy
Richard Sandiford writes:
> Alfie Richards writes:
>> ---
>> gcc/cgraph.cc| 39 +++---
>> gcc/config/aarch64/aarch64.cc| 37 +++-
>> gcc/config/i386/i386-features.cc | 33 -
>> gcc/config/riscv/riscv.
Hi Jerry,
committed as r15-7345 .
Thanks for the review!
Best regards
Thomas
[Well, that was interesting. Some combination of fat fingers crashed
my mail client and sent the incomplete message. Continued below]
From: "James K. Lowden"
To: Matthias Klose
Cc: gcc-patches@gcc.gnu.org
Date: Tue, 4 Feb 2025 04:25:23 -0500
Subject: Re: The COBOL front end, in 8 notes + tople
Hi Jason,
On 4 Feb 2025, at 16:39, Jason Merrill wrote:
> On 1/15/25 9:56 AM, Jason Merrill wrote:
>> On 1/15/25 7:24 AM, Simon Martin wrote:
>>> Hi,
>>>
>>> On 14 Jan 2025, at 23:31, Jason Merrill wrote:
>>>
On 1/14/25 2:13 PM, Simon Martin wrote:
> On 10 Jan 2025, at 19:10, Andrew Pins
On Tue, Feb 04, 2025 at 10:39:44AM -0500, Jason Merrill wrote:
> Does this also fix 118304? If so, let's go ahead and apply it to GCC 15.
It does not, with this patch we emit an error, but still crash on
struct A {
*A() = default;
};
Marek
On Wed, 18 Dec 2024 20:37:13 + (UTC)
Joseph Myers wrote:
> So make sure your patches include the changes required to
> update_web_docs_git to install HTML and PDF versions of those man
> pages, and point to somewhere we can see the formatted versions.
> That will then provide a way to compar
On 2/4/25 5:20 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for stage 1?
Yes, OK for stage 1.
-- >8 --
Here the PR's testcase demonstrates that the cp_fully_fold calls in
cp_build_binary_op (for diagnosing arithmetic overflow) lead to
quadrati
Like RISC-V, on LoongArch we don't really support %cN for SYMBOL_REFs
even with -fno-pic.
gcc/testsuite/ChangeLog:
* c-c++-common/toplevel-asm-1.c: Use %cc3 %cc4 instead of %c3
%c4 on LoongArch.
---
Ok for trunk?
gcc/testsuite/c-c++-common/toplevel-asm-1.c | 2 +-
1 file change
With things like
// signed char a_14, a_16;
a.0_4 = (unsigned char) a_14;
_5 = (int) a.0_4;
b.1_6 = (unsigned char) b_16;
_7 = (int) b.1_6;
c_17 = _5 - _7;
_8 = ABS_EXPR ;
r_18 = _8 + r_23;
An ABD pattern will be recognized for _8:
patt_31 = .ABD (a.0_4, b.1_6);
It's still cor
Committed as:
commit e41a5a2a0832509fa1c0b7cab0c8001fadbd23d4 (HEAD -> master,
origin/master, origin/HEAD)
Author: Jerry DeLisle
Date: Tue Feb 4 17:21:42 2025 -0800
Fortran: Fix PR 47485.
The -MT and -MQ options should replace the default target in the
generated dependency file
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for stage 1?
-- >8 --
Here the PR's testcase demonstrates that the cp_fully_fold calls in
cp_build_binary_op (for diagnosing arithmetic overflow) lead to
quadratic behavior when building up a large arithmetic constant
expression
W3 validated. Pushed.
commit 3c9e703a45f36113ace827463e6f0240fea334a2
Author: Marek Polacek
Date: Tue Feb 4 17:20:18 2025 -0500
Document some further C++ FE changes.
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 14dea6f4..18484915 100644
--- a/htdocs/gcc-15/c
On Tue, 4 Feb 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> 14 (after a long while)?
>
> -- >8 --
>
> LWG 4027 effectively makes the const range access CPOs ranges::cfoo behave
> more consistently across C++23 and C++20 (pre-P2278R4) and mo
Hi Robin,
Sorry, I should have simplified the problem by presenting it in terms of
Zve32x, because Zve32f implies Zve32x.
As the specification states, the requirement is to support LMUL ≥ SEW/ELEN.
Regarding the implementation,
I followed this rule to fix the problem.
In this link: https://godbolt
Found using UBSAN - and thanks to Martin for running it with UBSAN
and reporting it!
append_args and adjust_args can be easily confused being spelled
rather similarly and being used in the same code. Still, it makes
sense to use the right list...
(It seems as if the pointer dereferencing actuall
On Tue, 4 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled on x86_64 during postreload.
> After reload (with IPA-RA figuring out the calls don't modify any
> registers but %rax for return value) postreload sees
> (insn 14 12 15 2 (set (mem:DI (plus:DI (reg/f:DI 7 sp)
On Feb 04 2025, Jonathan Wakely wrote:
> I think this will cause check-abi failures on risc-v because the new
> symbols are added to CXXABI_1.3.16 but the "latest_p" map says that
> new symbols (i.e. ones not present in the baseline_symbols.txt file)
> should be in CXXABI_1.3.15
There is effectiv
On 04/02/2025 15:11, Richard Sandiford wrote:
Richard Sandiford writes:
Alfie Richards writes:
---
gcc/cgraph.cc| 39 +++---
gcc/config/aarch64/aarch64.cc| 37 +++-
gcc/config/i386/i386-features.cc | 33 --
On 1/15/25 9:56 AM, Jason Merrill wrote:
On 1/15/25 7:24 AM, Simon Martin wrote:
Hi,
On 14 Jan 2025, at 23:31, Jason Merrill wrote:
On 1/14/25 2:13 PM, Simon Martin wrote:
On 10 Jan 2025, at 19:10, Andrew Pinski wrote:
On Fri, Jan 10, 2025 at 3:18 AM Simon Martin
wrote:
We currently acce
Christophe Lyon writes:
> On Sun, 2 Feb 2025 at 21:18, Thiago Jung Bauermann
> wrote:
>>
>> Since commit r15-491-gc290e6a0b7a9de this failure happens on on
>> armv8l-linux-gnueabihf and arm-eabi:
>>
>> Running gcc:gcc.target/arm/simd/simd.exp ...
>> gcc.target/arm/simd/mve-vabs.c: memmove foun
> This adds missing code to correctly set the counts of the exit blocks we
> create when building the CFG for a vectorized early break loop.
>
> Tested as a series on aarch64-linux-gnu, arm-linux-gnueabihf, and
> x86_64-linux-gnu. OK for trunk?
>
> Thanks,
> Alex
>
> gcc/ChangeLog:
>
> P
On 2/4/25 10:56 AM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 16:39, Jason Merrill wrote:
On 1/15/25 9:56 AM, Jason Merrill wrote:
On 1/15/25 7:24 AM, Simon Martin wrote:
Hi,
On 14 Jan 2025, at 23:31, Jason Merrill wrote:
On 1/14/25 2:13 PM, Simon Martin wrote:
On 10 Jan 2025, at 1
Hi Jason,
On 4 Feb 2025, at 1:11, Jason Merrill wrote:
> On 1/31/25 11:12 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 31 Jan 2025, at 16:29, Jason Merrill wrote:
>>
>>> On 1/31/25 9:52 AM, Simon Martin wrote:
Hi Jason,
On 9 Jan 2025, at 22:55, Jason Merrill wrote:
> On 1
From: Andi Kleen
Document new params in invoke.texi.
The auto tuning description was on the wrong tunable, move to lines.
Comitted as obvious.
gcc/ChangeLog:
* doc/invoke.texi: Document file cache tunables.
* params.opt: Move auto tuning description to lines.
---
gcc/doc/invo
On 4 Feb 2025, at 17:17, Jason Merrill wrote:
> On 2/4/25 10:56 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Feb 2025, at 16:39, Jason Merrill wrote:
>>
>>> On 1/15/25 9:56 AM, Jason Merrill wrote:
On 1/15/25 7:24 AM, Simon Martin wrote:
> Hi,
>
> On 14 Jan 2025, at 23:31, Jaso
On Tue, Feb 4, 2025 at 8:42 AM Andrew Pinski wrote:
>
> r15-4317-ga6f4404689f12 tried to add support for widending optabs
> for vec-mode -> scalar-mode but it misunderstood how FOR_EACH_MODE worked,
> the limit in this case is not inclusive. Which means setting limit to from,
> would cause the loo
On Tue, 4 Feb 2025 at 12:48, Rainer Orth wrote:
>
> This patch
>
> commit c6977f765838a5ca8d321d916221a7368622bdd9
> Author: Andreas Schwab
> Date: Tue Jan 21 23:50:15 2025 +0100
>
> libstdc++: correct symbol version of typeinfo for bfloat16_t on RISC-V
>
> broke the libstdc++-abi/abi_check
Hello Andi,
On Sat, Jan 25 2025, Andi Kleen wrote:
> From: Andi Kleen
>
> The input machinery to read the source code independent of the lexer
> has a range of hard coded maximum array sizes that can impact performance.
> Make them tunable.
>
> input.cc is part of libcommon so it cannot direct ac
Applied to master with the requested change (to XFAIL for ilp32).
Thanks,
Philipp.
On Tue, 4 Feb 2025 at 12:45, Richard Biener
wrote:
> On Tue, Feb 4, 2025 at 12:36 PM Konstantinos Eleftheriou
> wrote:
> >
> > From: kelefth
> >
> > The match.pd canonicalization that this testcase checks for,
On Tue, Feb 4, 2025 at 12:36 PM Konstantinos Eleftheriou
wrote:
>
> From: kelefth
>
> The match.pd canonicalization that this testcase checks for,
> is not applied on ilp32 targets.
>
> This prevents the test from running on ilp32 targets.
>
> PR116845
>
> gcc/testsuite/ChangeLog:
>
>
Alfie Richards writes:
> This patch adds support for the combination of target_clones and
> target_version in the definition of a versioned function.
>
> This patch changes is_function_default_version to consider a function
> declaration annotated with target_clones containing default to be a
> de
On Tue, Feb 04, 2025 at 11:53:21AM +0100, Richard Biener wrote:
> > + if (sp_derived_base)
> > + if (cselib_val *v3
> > + = cselib_lookup_1 (stack_pointer_rtx, Pmode, 0, VOIDmode))
> > + {
> > + bool ok = false;
> > + HOST_WIDE
Hi Monk,
could you detail the issue/patch a bit? Are we generally violating
LMUL >= SEW/ELEN with zve32f (zve32x as well then)? And what's
"implicit zve32f"? In the test case it's specified explicitly.
> According to Section 3.4.2, Vector Register Grouping, in the RISC-V
> Vector Specification
The GIMPLE FE currently invokes parser_build_unary_op to build
unary GENERIC which has the operand subject to C promotion rules
which does not match GIMPLE. The following adds a wrapper around
the build_unary_op worker which conveniently has an argument to
indicate whether to skip such promotion.
Alfie Richards writes:
> This adds the assembler_name member to cgraph_function_version_info
> to store the base assembler name for the function to be mangled. This is
> used in later patches for refactoring FMV mangling.
>
> gcc/c/ChangeLog:
>
> * c-decl.cc (start_decl): Record assembler_na
On Mon, 16 Dec 2024 10:24:23 +0100
Matthias Klose wrote:
> On 14.12.24 15:38, Matthias Klose wrote:
> > I tried to use the patches to build binary packages for Debian.
> > Found some issues:
>
> tried to build libgcobol on more architectures, please find the
> attached patch to disable building
On Tue, 4 Feb 2025, Jakub Jelinek wrote:
> On Tue, Feb 04, 2025 at 11:53:21AM +0100, Richard Biener wrote:
> > > + if (sp_derived_base)
> > > + if (cselib_val *v3
> > > + = cselib_lookup_1 (stack_pointer_rtx, Pmode, 0, VOIDmode))
> > > + {
> > > + bo
> Hello,
>
> On Mon, 3 Feb 2025, H.J. Lu wrote:
>
> > Author: Surya Kumari Jangala
> > Date: Tue Jun 25 08:37:49 2024 -0500
> >
> > ira: Scale save/restore costs of callee save registers with block
> > frequency
> >
> > scales the cost of saving/restoring a callee-save hard register in
When there's an inner loop without virtual header PHI but the outer
loop has one the fusion process cannot handle the need to create
an inner loop virtual header PHI. Punt in this case.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/117113
* gim
Alfie Richards writes:
> The string_slice inherits from array_slice and is used to refer to a
> substring of an array that is memory managed elsewhere without modifying
> the underlying array.
>
> For example, this is useful in cases such as when needing to refer to a
> substring of an attribute i
Hi!
The following testcase is miscompiled on x86_64 during postreload.
After reload (with IPA-RA figuring out the calls don't modify any
registers but %rax for return value) postreload sees
(insn 14 12 15 2 (set (mem:DI (plus:DI (reg/f:DI 7 sp)
(const_int 16 [0x10])) [0 S8 A64])
On Tue, 4 Feb 2025, Tamar Christina wrote:
> Looks like a last minute change I made accidentally blocked SVE. Fixed and
> re-sending:
>
> Hi All,
>
> This fixes two PRs on Early break vectorization by delaying the safety checks
> to
> vectorizable_load when the VF, VMAT and vectype are all kno
On 04/02/2025 03:20, Sebastian Huber wrote:
> - Am 4. Feb 2025 um 4:15 schrieb Sebastian Huber
> sebastian.hu...@embedded-brains.de:
>
>> Enable use of Armv8-M instruction set.
>>
>> Account for CVE-2021-35465 mitigation [PR102035]. The
>> -mfix-cmse-cve-2021-35465 enabled by default, if -mc
This patch
commit c6977f765838a5ca8d321d916221a7368622bdd9
Author: Andreas Schwab
Date: Tue Jan 21 23:50:15 2025 +0100
libstdc++: correct symbol version of typeinfo for bfloat16_t on RISC-V
broke the libstdc++-abi/abi_check test on Solaris: the log shows
1 incompatible symbols
0
Argument
It's just a missing test for the presence of a nonempty parameter.
Tested on x86-64/Linux, applied on the mainline.
2025-02-04 Eric Botcazou
PR ada/118731
* sem_aggr.adb (Resolve_Iterated_Association): Add missing guard.
--
Eric Botcazoudiff --git a/gcc/ada/sem_aggr.adb b/g
On 2/4/25 9:29 AM, Jerry D wrote:
On 2/3/25 4:46 PM, Vincent Vanlaer wrote:
On 4/02/2025 01:42, Jerry D wrote:
On 2/3/25 2:14 PM, Vincent Vanlaer wrote:
Hi all,
Gentle ping for the patch below: https://gcc.gnu.org/pipermail/
fortran/2024-December/061467.html
Best wishes,
Vincent
On 30/
On Tue, 4 Feb 2025, James K. Lowden wrote:
> It's not clear to me there should be an install target for PDF because
> there's no pdfdir variable defined (akin to htmldir).
pdfdir is passed down from the top-level Makefile.
> I guess when this script runs, nothing has been configured and no
> M
> This patch series improves the support for the mips64r6 target in GCC,
> includes the enhancements to the general bug fixes and contains other
> MIPS ISA and processor enablement.
>
> These patches are cherry-picked from the mips_rel/11_2_0/master
> and mips_rel/9_3_0/master branches from the MI
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14 (after a long while)?
-- >8 --
LWG 4027 effectively makes the const range access CPOs ranges::cfoo behave
more consistently across C++23 and C++20 (pre-P2278R4) and more
consistently with the std::cfoo range accessors, as t
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
The recent r15-7339-g26d3424ca5d9f4 fixed this test too.
PR c++/94100
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/variadic188.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/variadic188.C | 23 +++
1 file chang
The -mcpu=tt-ascalon-d8 option for the test implies D extension, which
is not compatible with the ILP32E and ILP64E ABIs.
Pushed to trunk as obvious.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr118170.c: Ignore for E ABI.
Signed-off-by: Dimitar Dimitrov
---
gcc/testsuite/gcc.target/
On 2/3/25 4:46 PM, Vincent Vanlaer wrote:
On 4/02/2025 01:42, Jerry D wrote:
On 2/3/25 2:14 PM, Vincent Vanlaer wrote:
Hi all,
Gentle ping for the patch below: https://gcc.gnu.org/pipermail/
fortran/2024-December/061467.html
Best wishes,
Vincent
On 30/12/2024 00:19, Vincent Vanlaer wrot
Hi,
One of our big application segv in libgcc code while unwinding the stack.
This is a random crash while the application throws a c++ exception and
unwinds the stack. Incidents are random and never can be reproduced by any
test case.
The libgcc that is used is based on GCC 8.
Fortunately, we
On 2/4/25 11:25 AM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 1:11, Jason Merrill wrote:
On 1/31/25 11:12 AM, Simon Martin wrote:
Hi Jason,
On 31 Jan 2025, at 16:29, Jason Merrill wrote:
On 1/31/25 9:52 AM, Simon Martin wrote:
Hi Jason,
On 9 Jan 2025, at 22:55, Jason Merrill wrote:
On 2/4/25 11:45 AM, Simon Martin wrote:
On 4 Feb 2025, at 17:17, Jason Merrill wrote:
On 2/4/25 10:56 AM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 16:39, Jason Merrill wrote:
On 1/15/25 9:56 AM, Jason Merrill wrote:
On 1/15/25 7:24 AM, Simon Martin wrote:
Hi,
On 14 Jan 2025, at 23
On 1/27/25 6:49 PM, Jakub Jelinek wrote:
Hi!
The following testcases ICE with RAW_DATA_CSTs (so the first one since
introduction of #embed C++ optimizations and the latter since optimization
of large sequences of comma separated literals).
I've missed the fact that implicit_conversion can embed
On 2/4/25 3:03 PM, Jason Merrill wrote:
On 2/4/25 11:45 AM, Simon Martin wrote:
On 4 Feb 2025, at 17:17, Jason Merrill wrote:
On 2/4/25 10:56 AM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 16:39, Jason Merrill wrote:
On 1/15/25 9:56 AM, Jason Merrill wrote:
On 1/15/25 7:24 AM, Simon
Hi Sandra, hello world,
Sandra Loosemore wrote:
gcc/fortran/ChangeLog
PR middle-end/107067
* parse.cc (parse_omp_do): Diagnose missing "OMP END METADIRECTIVE"
after loop.
(parse_omp_structured_block): Likewise for strictly structured block.
(parse_omp_meta
From: kelefth
The match.pd canonicalization that this testcase checks for,
is not applied on ilp32 targets.
This prevents the test from running on ilp32 targets.
PR116845
gcc/testsuite/ChangeLog:
* gcc.dg/pr109393.c: Exclude ilp32 targets.
---
gcc/testsuite/gcc.dg/pr109393.c
Alfie Richards writes:
> This changes behavior of target_clones and target_version attributes
> to be inline with what is specified in the Arm C Language Extension.
>
> Notably this changes the scope and signature of multiversioned functions
> to that of the default version, and changes the resol
Hi!
On Tue, Jan 28, 2025 at 12:49:54AM +0100, Jakub Jelinek wrote:
> The following testcases ICE with RAW_DATA_CSTs (so the first one since
> introduction of #embed C++ optimizations and the latter since optimization
> of large sequences of comma separated literals).
> I've missed the fact that im
Alfie Richards writes:
> This patch is an overhaul of how FMV name mangling works. Previously
> mangling logic was duplicated in several places across both target
> specific and independent code. This patch changes this such that all
> mangling is done in targetm.mangle_decl_assembler_name (includ
Hi Jason,
On 4 Feb 2025, at 1:10, Jason Merrill wrote:
> On 1/31/25 12:11 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 27 Jan 2025, at 16:49, Jason Merrill wrote:
>>
>>> On 1/27/25 10:41 AM, Simon Martin wrote:
Hi Jason,
On 17 Jan 2025, at 23:33, Jason Merrill wrote:
> On
64 matches
Mail list logo
