On 2025-01-12 01:04, Jonathan Wakely wrote:
On Sat, 11 Jan 2025, 19:14 Torbjorn SVENSSON,
mailto:torbjorn.svens...@foss.st.com>>
wrote:
On 2025-01-11 20:05, Jonathan Wakely wrote:
>
>
> On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
> mailto:torbjorn.svens...@fos
On 2025-01-12 01:05, Jonathan Wakely wrote:
On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
mailto:torbjorn.svens...@foss.st.com>>
wrote:
Ok for trunk and releases/gcc-14?
OK
Pushed as r15-6828-g4b0ef49d02f and r14.2.0-680-gd82fc939f91.
Kind regards,
Torbjörn
--
Test
On 1/3/25 11:46 AM, Richard Sandiford wrote:
Jeff Law writes:
This resurrects a patch from a bit over 2 years ago that I never wrapped
up. IIRC, I ended up up catching covid, then in the hospital for an
unrelated issue and it just got dropped on the floor in the insanity.
The basic idea he
On Mon, 23 Dec 2024, 19:05 Torbjörn SVENSSON,
wrote:
> Ok for trunk and releases/gcc-14?
>
OK
> --
>
> Test assumes libatomic.a is always available, but for some embedded
> targets, there is no libatomic.a and the test thus fail.
>
> libstdc++/ChangeLog:
>
> * 29_atomics/atomic_float/
On Sat, 11 Jan 2025, 19:14 Torbjorn SVENSSON,
wrote:
>
>
> On 2025-01-11 20:05, Jonathan Wakely wrote:
> >
> >
> > On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
> > mailto:torbjorn.svens...@foss.st.com>>
> > wrote:
> >
> > Ok for trunk and releases/gcc-14?
> >
> >
> > OK, thanks
>
> Oh, mid-a
This seeming benign mistake caused a massive SPEC2017 Cactu regression
(2.1 trillion insn to 2.5 trillion) wiping out all the gains from my
recent sched1 improvement. Thankfully the issue was trivial to fix even
if hard to isolate.
On BPI3:
Before bug
--
| Performance counter stats for '
On 1/11/25 2:20 PM, Jakub Jelinek wrote:
On Sat, Jan 11, 2025 at 01:52:59AM -0800, Andrew Pinski wrote:
The problem is for inline-asm goto, the outer rtl insn type
is a jump_insn and get_attr_length does not handle ASM specially
unlike if the outer rtl insn type was just insn.
This fixes the
Hi Harald,
Thanks for pointing this out! I've also added a few gcc_unreachable()
to prevent other potential false positives, see attached.
Just a couple of documentation nits: The documentation says INTEGER
or REAL only, but it also works (as an extension) for UNSIGNED. Also,
OUT_OF_RANGE is
On 1/10/25 1:47 PM, David Malcolm wrote:
On Thu, 2025-01-09 at 22:28 -0500, David Malcolm wrote:
On Thu, 2025-01-09 at 21:15 -0500, Jason Merrill wrote:
On 1/9/25 7:00 PM, David Malcolm wrote:
On Thu, 2025-01-09 at 14:21 -0500, Jason Merrill wrote:
Thanks for taking a look...
On 1/9/25 2:11
On Sat, Jan 11, 2025 at 01:52:59AM -0800, Andrew Pinski wrote:
> The problem is for inline-asm goto, the outer rtl insn type
> is a jump_insn and get_attr_length does not handle ASM specially
> unlike if the outer rtl insn type was just insn.
>
> This fixes the issue by adding support for both CAL
On 1/11/25 2:08 PM, Andrew Pinski (QUIC) wrote:
-Original Message-
From: Jeff Law
Sent: Saturday, January 11, 2025 8:12 AM
To: Andrew Pinski (QUIC) ; gcc-
patc...@gcc.gnu.org
Subject: Re: [PATCH] final: Fix get_attr_length for asm goto
[PR118411]
On 1/11/25 2:52 AM, Andrew Pinski w
> -Original Message-
> From: Jeff Law
> Sent: Saturday, January 11, 2025 8:12 AM
> To: Andrew Pinski (QUIC) ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] final: Fix get_attr_length for asm goto
> [PR118411]
>
>
>
> On 1/11/25 2:52 AM, Andrew Pinski wrote:
> > The problem is for in
сб, 11 янв. 2025 г. в 22:15, Denis Chertykov :
> after LRA:
> --
> insn 543 r14 {r66} = [sfp+7]# reload insn
> insn 269 r14 {r66} ^= r2 {r67}
> insn 544 [sfp+24] = r14 {r66} # reload insn -- bug is here !
>
> insn 545 r14 {r69} = [sfp+24] # reload insn
> insn
On Sat, Jan 11, 2025 at 08:25:32PM +0100, Jakub Jelinek wrote:
> That is not true.
Implementation-wise, in C17 say
void foo ();
void bar (void);
TYPE_ARG_TYPES (TREE_TYPE (foo_decl)) == NULL
TYPE_ARG_TYPES (TREE_TYPE (bar_decl)) == void_list_node
but in C23 both have TYPE_ARG_TYPES void_list_node,
On Sat, Jan 11, 2025 at 01:55:42PM -0500, David Malcolm wrote:
> + if ((takes_void_p (fntype_a) && takes_int_p (fntype_b))
> + || (takes_int_p (fntype_a) && takes_void_p (fntype_b)))
> +{
> + inform (UNKNOWN_LOCATION,
> + "the meaning of %<()%> in function declarations chan
Gentle ping :)
Kind regards,
Torbjörn
On 2024-12-23 20:00, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Test assumes libatomic.a is always available, but for some embedded
targets, there is no libatomic.a and the test thus fail.
libstdc++/ChangeLog:
* 29_atomics/ato
On 2025-01-11 20:05, Jonathan Wakely wrote:
On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
mailto:torbjorn.svens...@foss.st.com>>
wrote:
Ok for trunk and releases/gcc-14?
OK, thanks
Oh, mid-air-collision.
Thanks for the fast review Jonathan!
I suppose my v2 should also be ok as it
Changes since v1:
- Found out that 27_io/print/3.cc has the same kind of issue.
Ok for trunk and releases/gcc-14?
--
When running tests using the "sim" config, the command is launched in
non-readonly mode and the text retrieved from the expect command will
then replace all LF with CRLF. (The pr
On Sat, 11 Jan 2025, 18:31 Torbjörn SVENSSON,
wrote:
> Ok for trunk and releases/gcc-14?
>
OK, thanks
> --
>
> When running tests using the "sim" config, the command is launched in
> non-readonly mode and the text retrieved from the expect command will
> then replace all LF with CRLF. (The pr
On Sat, 2025-01-11 at 13:55 -0500, David Malcolm wrote:
> PR c/116871 notes that our diagnostics about incompatible function
> types
> could be improved.
>
> In particular, for the case of migrating to C23 I'm seeing a lot of
> build failures with signal handlers similar to this (simplified from
>
PR c/116871 notes that our diagnostics about incompatible function types
could be improved.
In particular, for the case of migrating to C23 I'm seeing a lot of
build failures with signal handlers similar to this (simplified from
alsa-tools-1.2.11, envy24control/profiles.c; see rhbz#2336278):
type
Ok for trunk and releases/gcc-14?
--
When running tests using the "sim" config, the command is launched in
non-readonly mode and the text retrieved from the expect command will
then replace all LF with CRLF. (The problem can be found in sim_load
where it calls remote_spawn without an input file).
The fix for PR117868.
In brief:
this is an LRA bug derived from reuse spilling slots after frame pointer
spilling.
The slot was created for QImode (1 byte) and it was reused after spilling of the
frame pointer for TImode register (16 bytes long) and it overlaps other slots.
Wrong things happene
Tested on x86_64-pc-linux-gnu, committing as obvious.
-- >8 --
GCC14 doesn't have the new spelling '-fmodules' for enabling modules;
use the old '-fmodules-ts' spelling instead.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr114630_a.C: Use -fmodules-ts instead of
-fmodules in test
On 1/7/25 12:06 PM, Jerry D wrote:
On 9/25/24 3:18 AM, Andre Vehreschild wrote:
Hi all,
I finally managed to apply the fixed patch. It still had some stray
line break
so check_GNU_style.py wouldn't succeed. But with that fixed I agree to
have
only some nonsense bickering of the script.
As t
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
The ICE in the linked PR is caused because name lookup finds duplicate
copies of the deduction guides, causing a checking assert to fail.
This is ultimately because we're exporting an imported guide; when name
lookup proce
On Linux/x86_64,
7c013a681cc138b8f191b75e408fe322d7fd998c is the first bad commit
commit 7c013a681cc138b8f191b75e408fe322d7fd998c
Author: Nathaniel Shead
Date: Fri Jan 10 01:06:37 2025 +1100
c++/modules: Handle chaining already-imported local types [PR114630]
caused
FAIL: g++.dg/modules/
On 1/11/25 2:52 AM, Andrew Pinski wrote:
The problem is for inline-asm goto, the outer rtl insn type
is a jump_insn and get_attr_length does not handle ASM specially
unlike if the outer rtl insn type was just insn.
This fixes the issue by adding support for both CALL_INSN and JUMP_INSN
with a
Hi All,
When both -mcpu and -march are specified, the value of -march wins out.
This is done correctly for the calls to cc1 and for the assembler directives we
put out in assembly files.
However in the call to as we don't do this and instead use the arch from the
cpu. This leads to a situation
Hi All,
in g:e91a17fe39c39e98cebe6e1cbc8064ee6846a3a7 we added the ability for
-mcpu=native on unknown CPUs to still enable architecture extensions.
This has worked great but was only added for homogenous systems.
However the same thing works for big.LITTLE as in such system the cores must
have
Hi,
I originally made this patch for the Darwin Arm64 development branch,
however in discussions on IRC, it seems that it is also relevant to
Linux - since there are implementations running on Apple hardware with
the M1..3 CPUs. It might also be helpful to the resolution of
PR113257 - although it
The patch below is for trunk.
Andrew Pinski says he has a patch to fix it, bit that won't materialize
before v16.
AVR: PR118012 - Try to work around sick code from match.pd.
This patch tries to work around PR118012 which may use a
full fledged multiplication instead of a simple bit test.
This i
This breaks m68k:
$ ./xgcc -B./ -xc -nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc/testsuite/selftests
../../gcc/simplify-rtx.cc:8600: test_comparisons: FAIL: ASSERT_RTX_EQ (val,
folded)
expected: (const_int -1 [0x])
actual: (const_int 0 [0])
cc1: internal compile
I'm so sorry that I didn't describe the patch clearly. I refactored the patch
and added some new changes. Initially I split them into two patches, which is
probably not right.
Thanks,
Zhijin
>From ca072f040c876df4117f475eeb74c7eb8882bed8 Mon Sep 17 00:00:00 2001
From: Zhijin Zeng
Date: Sat, 1
> Am 11.01.2025 um 11:29 schrieb Andrew Pinski :
>
> On Sat, Jan 11, 2025 at 2:10 AM Richard Biener
> wrote:
>>
>>
>>
Am 11.01.2025 um 09:49 schrieb Andrew Pinski :
>>>
>>> In this case, early phiopt would get rid of the user provided predicator
>>> for hot/cold as it would remove t
On Sat, Jan 11, 2025 at 2:10 AM Richard Biener
wrote:
>
>
>
> > Am 11.01.2025 um 09:49 schrieb Andrew Pinski :
> >
> > In this case, early phiopt would get rid of the user provided predicator
> > for hot/cold as it would remove the basic blocks. The easiest and best
> > option is
> > for early p
> Am 11.01.2025 um 09:49 schrieb Andrew Pinski :
>
> In this case, early phiopt would get rid of the user provided predicator
> for hot/cold as it would remove the basic blocks. The easiest and best option
> is
> for early phi-opt don't do phi-opt if the middle basic-block(s) have either
> a
The problem is for inline-asm goto, the outer rtl insn type
is a jump_insn and get_attr_length does not handle ASM specially
unlike if the outer rtl insn type was just insn.
This fixes the issue by adding support for both CALL_INSN and JUMP_INSN
with asm.
OK? Bootstrapped and tested on x86_64-lin
In this case, early phiopt would get rid of the user provided predicator
for hot/cold as it would remove the basic blocks. The easiest and best option is
for early phi-opt don't do phi-opt if the middle basic-block(s) have either
a hot or cold predict statement. Then after inlining, jump threading
> Am 10.01.2025 um 22:17 schrieb Jeff Law :
>
>
>
>> On 1/10/25 4:41 AM, Richard Biener wrote:
>> The following puts in a hard limit on ext-dce because it might end
>> up requiring memory on the order of the number of basic blocks
>> times the number of pseudo registers. The limiting follow
40 matches
Mail list logo
