pr118182-2.c fails on gcc-14 because it lacks the late_combine passes,
particularly the one that runs after register allocation.
Even in the trunk, the predicate broadcast for the add reduction is
expanded and register-allocated as _zvfh, taking up an unneeded scalar
register to hold the constan
> Am 11.04.2025 um 20:54 schrieb Jakub Jelinek :
>
> Hi!
>
> Here is an optional incremental tweak to the previous patch.
> Instead of
>
> ./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ; grep
> -B1 '^\(;; \)\?Cannot tail-call:' pr119718.c.*
> pr119718.c.222t.tailc-_7
> Am 11.04.2025 um 21:10 schrieb Jakub Jelinek :
>
> Hi!
>
> With --enable-host-pie -freport-bug almost never prepares preprocessed
> source and instead emits
> The bug is not reproducible, so it is likely a hardware or OS problem.
> message even for bogus which are 100% reproducible.
> The w
> Am 11.04.2025 um 21:06 schrieb Jakub Jelinek :
>
> Hi!
>
> The following patch is miscompiled, because during the limited
> SSA name coalescing the bitintlower pass does we incorrectly don't
> register a conflict.
> This is on
> [local count: 1073741824]:
> # b_17 = PHI
> g.4_13 = g;
> _1
> Am 11.04.2025 um 21:00 schrieb Jakub Jelinek :
>
> Hi!
>
> The following patch makes some adjustments so that users can analyze what
> calls weren't tail called even without using musttail attribute (though I'm
> still not convinced it should be a warning, because we don't distinguish
> bet
> -Original Message-
> From: Richard Biener
> Sent: Monday, April 7, 2025 03:19
> To: Robert Dubner
> Cc: Sam James ; GCC Patches ;
> Richard Biener
> Subject: Re: [committed] cobol: Eliminate cobolworx UAT errors when
> compiling with -Os
>
> On Fri, Apr 4, 2025 at 11:50 PM Robert Du
> -Original Message-
> From: Robert Dubner
> Sent: Friday, April 11, 2025 23:06
> To: 'Patches GCC'
> Subject: [committed] cobol: Eliminate many getenv() calls. [PR119694]
>
> A lot of those debugging getenv() calls were accumulated cruft. We took
> this opportunity to get rid of most o
A lot of those debugging getenv() calls were accumulated cruft. We took
this opportunity to get rid of most of them.
The few that remain have been disabled with a #define gcobol_genenv() that
returns NULL. Thank you, Richard.
The remaining getenv() calls use GCOBOL_ prefixes on the environment
gcc/ChangeLog
PR c++/106618
* doc/invoke.texi (Option Summary): Remove -fargs-in-order, add
-fstrong-eval-order.
(C++ Dialect Options): Explicitly document that -fstrong-eval-order
takes an optional argument and what the choices are. Generalize
refer
Hello,
On Wed, Apr 09 2025, Martin Jambor wrote:
> Hi,
>
> On Tue, Apr 08 2025, Jan Hubicka wrote:
>>> After the propagation of constants and value ranges, it turns out
>>> that the propagation of known bits also needs to be made aware of any
>>> intermediate types in which any arithmetic operatio
Hi,
On Tue, Apr 08 2025, Jan Hubicka wrote:
>> In order to replace the use of somewhat unweildy
>> expr_type_first_operand_type_p we need to record and stream the types
>> of results of operations recorded in arithmetic jump functions. This
>> is necessary so that we can then simulate them at the
gcc/ChangeLog
PR middle-end/105548
* doc/invoke.texi (Optimize Options): Delete misleading sentence
about conversions.
---
gcc/doc/invoke.texi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ffde9df85f
On 4/11/25 11:30 AM, Indu Bhagat wrote:
Hi,
For MTE stack tagging support in the GNU toolchain, one of the key pieces is
the memtag sanitizer in GCC. The current series is V2 of the previously sent
RFC series https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668017.html.
This is now al
Vishnu Mohandas writes:
> Hello,
> This is a possible fix for Wnarrowing warning issues.
> Bootstrapped on x86_64 Linux.
Please see my remarks at
https://inbox.sourceware.org/gcc-patches/87iknbzfw4@gentoo.org/.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
GCC 15 perhaps?
-- >8 --
Here checking
static_assert(0 == big_calc());
takes twice as much time as
constexpr int ret = big_calc();
static_assert(0 == ret);
ultimately because in the former, we first constexpr evalu
Boostrapped and regtested on x86_64-pc-linux- gnu, does this look OK
for GCC 15 perhaps?
-- >8 --
This patch improves upon r15-6052-g12de1942a0a673 by performing prvalue
folding with mce_false rather than mce_unknown when it's safe to do so
(i.e. the caller passed ff_mce_false), so that we can al
> On Apr 11, 2025, at 14:24, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 18:14 + schrieb Qing Zhao:
>>
>>> On Apr 11, 2025, at 13:37, Martin Uecker wrote:
>>>
>>> Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
> On Apr 11, 2025, at 12:20, Martin Uecker
On Fri, Apr 11, 2025 at 12:00:27PM -0700, Andrew Pinski wrote:
> On Fri, Apr 11, 2025 at 11:54 AM Jakub Jelinek wrote:
> >
> > Hi!
> >
> > Here is an optional incremental tweak to the previous patch.
> > Instead of
> >
> > ./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ;
>
Memory tagging is used for detecting memory safety bugs. On AArch64, the
memory tagging extension (MTE) helps in reducing the overheads of memory
tagging:
- CPU: MTE instructions for efficiently tagging and untagging memory.
- Memory: New memory type, Normal Tagged Memory, added to the Arm
Ar
From: Iain Sandoe
V2 adds a comment as suggested, otherwise NFC, re-tested on
x86_64-Darwin. Unless there are further comments in the next 48h, I plan
to apply this (since it is Darwin-specific) and modules is unusable without.
thanks,
Iain
--- 8< ---
Recent changes to the OS SDKs have altered
On Fri, Apr 11, 2025 at 11:54 AM Jakub Jelinek wrote:
>
> Hi!
>
> Here is an optional incremental tweak to the previous patch.
> Instead of
>
> ./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ; grep
> -B1 '^\(;; \)\?Cannot tail-call:' pr119718.c.*
> pr119718.c.222t.tailc-_7
Hi!
With --enable-host-pie -freport-bug almost never prepares preprocessed
source and instead emits
The bug is not reproducible, so it is likely a hardware or OS problem.
message even for bogus which are 100% reproducible.
The way -freport-bug works is that it reruns it 3 times, capturing stdout
a
Hi!
The following patch is miscompiled, because during the limited
SSA name coalescing the bitintlower pass does we incorrectly don't
register a conflict.
This is on
[local count: 1073741824]:
# b_17 = PHI
g.4_13 = g;
_14 = g.4_13 >> 50;
_15 = (unsigned int) _14;
_21 = b_17;
_16 = (unsigned int)
On Fri, Apr 11, 2025 at 6:23 PM Vladimir Makarov wrote:
>
>
> On 4/11/25 2:29 AM, Uros Bizjak wrote:
> > Hello!
> >
> > I would like to backport PR115568 and PR119689 to release branches.
> >
> > Author: Richard Biener
> > Date: Wed Apr 9 14:36:19 2025 +0200
> >
> > rtl-optimization/119689
In context of stack tagging, the AArch64 Memtag ABI Extension to ELF
specifies the usage of two dynamic tags for the dynamic loader to do the
necessary tasks:
- If DT_AARCH64_MEMTAG_MODE is present, the dynamic loader should (in
a platform-specific specific way) enable MTE for the process.
Hi!
The following patch makes some adjustments so that users can analyze what
calls weren't tail called even without using musttail attribute (though I'm
still not convinced it should be a warning, because we don't distinguish
between calls in return call (...); statements vs. calls that just happ
Emit .cfi_mte_memtag_frame after .cfi_startproc for each function where
the stack memory uses MTE protection.
TBD:
- Need to double check if checking on frame_size is the right thing to
do. clang generates cfi_mte_tagged_frame directive irrespective of
whether the function ended up taggi
gcc.dg/pr87600.h and gcc.dg/pr89313.c test for __powerpc__ and
__POWERPC__ to choose ppc register names, but ppc-elf defines neither;
it defines __PPC__, so test for that as well.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for
Hi!
Here is an optional incremental tweak to the previous patch.
Instead of
./xgcc -B ./ -S -O2 -fdump-{tree-tailc,rtl-expand}-details pr119718.c ; grep
-B1 '^\(;; \)\?Cannot tail-call:' pr119718.c.*
pr119718.c.222t.tailc-_7 = bar (0);
pr119718.c.222t.tailc:Cannot tail-call: call invocation refe
Check for SANITIZER_MEMTAG in the gate function for pass_asan gimple
pass; enable it.
TBD:
- This commit was initially carved out in order to ensure each patch
works in isolation. Need to revisit and double check this.
gcc/ChangeLog:
* asan.cc (memtag_sanitize_p): Fix definition.
MEMTAG sanitizer, which is based on the HWASAN sanitizer, will invoke
the target-specific hooks to create a random tag, add tag to memory
address, and finally tag and untag memory.
Implement the target hooks to emit MTE instructions if MEMTAG sanitizer
is in effect. Continue to use the default ta
Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE)
instruction. It stores an allocation tag to two tag granules of memory.
TBD:
- Not too sure what is the best way to generate the st2g yet; A
subsequent patch will emit them in one of the target hooks.
gcc/ChangeLog:
Add new command line option -fsanitize-memtag-mode with three possible
values:
- sync (default)
- async
- asymm
This allows the user to select the fault conveyance model when using MTE
instructions for their applications.
This option is not (sanity checked) processed in GCC at all currently.
Add new command line option -fsanitize=memtag with the following
new params:
--param memtag-instrument-stack [0,1] (default 1) to use MTE
insns for enabling dynamic checking of stack variables.
--param memtag-instrument-alloca [0,1] (default 1) to use MTE
insns for enabling dynamic checking of st
Currently, the data type of sanitizer flags is unsigned int, with
SANITIZE_SHADOW_CALL_STACK (1UL << 31) being highest individual
enumerator for enum sanitize_code. Use 'unsigned HOST_WIDE_INT' data
type to allow for more distinct instrumentation modes be added when
needed.
FIXME:
1. Is using d_u
Add basic tests for MEMTAG sanitizer. MEMTAG sanitizer uses target
hooks to emit AArch64 specific MTE instructions.
Add new target-specific tests.
The currently generated code currently has the following known
limitations:
1. For basic-1.c testcase, currently we generate:
subgx0, x0
Add a new target hook TARGET_MEMTAG_TAG_MEMORY to tag (and untag)
memory. The default implementation is empty.
Hardware-assisted sanitizers on architectures providing instructions to
tag/untag memory can then make use of this target hook. On AArch64,
e.g., the MEMTAG sanitizer will use this hook
Using post-index st2g is a faster way of memory tagging/untagging.
Because a post-index 'st2g tag, [addr], #32' is equivalent to:
stg tag, addr, #0
stg tag, addr, #16
add addr, addr, #32
TBD:
- Currently generated by in the aarch64 backend. Not sure if this is
the right way to do i
> On Apr 11, 2025, at 14:12, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar:
>> On 2025-04-11 13:37, Martin Uecker wrote:
My understanding is that such issue with the implicit data flow dependency
information missing is only for the
>>>
Hi,
For MTE stack tagging support in the GNU toolchain, one of the key pieces is
the memtag sanitizer in GCC. The current series is V2 of the previously sent
RFC series https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668017.html.
The other two pieces, which (work in progress) are needed
Using post-index stg is a faster way of memory tagging/untagging.
TBD:
- Currently generated by in the aarch64 backend. Not sure if this
is the right way to do it.
- Also not clear how to weave in the generation of stzg.
ChangeLog:
* gcc/config/aarch64/aarch64.md
---
[New in RF
subg (Subtract with Tag) is an Armv8.5-A memory tagging (MTE)
instruction. It can be used to subtract an immediate value scaled by
the tag granule from the address in the source register.
gcc/ChangeLog:
* config/aarch64/aarch64.md (subg): New definition.
---
gcc/config/aarch64/aarch64.m
> On Apr 11, 2025, at 13:55, Siddhesh Poyarekar wrote:
>
> On 2025-04-11 13:37, Martin Uecker wrote:
>>> My understanding is that such issue with the implicit data flow dependency
>>> information missing is only for the
>>> counted_by attribute, not for the other TYPE which already have the bo
The overriding of dg-do in gcc.target/powerpc/vec-mul.c I put there
last year didn't quite work. It needed the newly-added dg-do-if to
work the way I wished. Fix it, and simplify it.
While at that, I found out that when target matched, dg-do-if didn't
call dg-do correctly, because it dropped t
Am Freitag, dem 11.04.2025 um 18:14 + schrieb Qing Zhao:
>
> > On Apr 11, 2025, at 13:37, Martin Uecker wrote:
> >
> > Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
> > >
> > > > On Apr 11, 2025, at 12:20, Martin Uecker wrote:
> > > >
> > > > Am Freitag, dem 11.04.2025 um 1
Hello,
This is a possible fix for Wnarrowing warning issues.
Bootstrapped on x86_64 Linux.
diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc
2 │ index 45edd180173..535f1bdfa3e 100644
3 │ --- a/gcc/cp/typeck2.cc
4 │ +++ b/gcc/cp/typeck2.cc
5 │ @@ -1142,6 +1142,10 @@ check_narro
The gcc.target/powerpc/vec-cmpne.c and .../vec-cmpne-runnable.c tests
need both vsx and vmx support, but vsx is taken for granted, which
doesn't hold on ppc-elf. Add the appropriate requirements and
options.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerp
gcc.target/powerpc/vsx-builtin-7.c uses fewer xxpermdi insns than
expected on ilp32. Adjust.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/vsx-builtin-7.c: Adjust xxpermdi
gcc.target/powerpc/pr99708.c uses -mfloat128, and that causes the
usual "may not be fully supported" warning that we need to prune on
such tests. Tolerate it.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/Chang
> On Apr 11, 2025, at 13:37, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
>>
>>> On Apr 11, 2025, at 12:20, Martin Uecker wrote:
>>>
>>> Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
> On Apr 11, 2025, at 10:53, Martin Uecker
Testing ppc-elf with -mhard-float conflicts with explicit -msoft-float
in gcc.target/powerpc/ppc-fma-6.c and gcc.target/powerpc/pr105334.c.
Skip these tests under -mhard-float.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gc
gcc.target/powerpc/pr92661.c expects and tolerates errors about dfp
builtins when dfp is not supported, but the C front end no longer
accepts calls of undeclared functions by default, even with -w.
Adding -fpermissive would do, but I thought it would be too broad, so
I went for -Wno-error=implici
gcc.target/powerpc/pr111449-1.c's expected results only come about
without strict alignment, so disable it explicitly.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/pr1114
gcc.target/powerpc/power11-3.c uses target_clones, that depends on
ifunc. Require ifunc support.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/powerpc/power11-3.c: Require ifunc
gcc.target/powerpc/pr111380-2.c requires altivec to be enabled to hit
the expected option mismatch and inline error, so enable it after
checking for compiler support.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuit
Below power7, it seems to be more profitable to compress the
floating-point constants and use an additional fp register move to
"extend" it. Only at power7 and above do we keep the constants
separate and load them, getting to the expected 'fmr' count.
Regstrapped on powerpc64le-linux-gnu. Also
gcc.target/powerpc/pr67808.c in some cases expects both 128-bit long
double types to be defined, but -mlong-double-128 doesn't guarantee
that without -mfloat128 on targets that would get the IEEE128 type as
long double. Add -mfloat128 to ensure the desired IBM 128-bit
floating-point type is avai
Am Freitag, dem 11.04.2025 um 13:55 -0400 schrieb Siddhesh Poyarekar:
> On 2025-04-11 13:37, Martin Uecker wrote:
> > > My understanding is that such issue with the implicit data flow
> > > dependency information missing is only for the
> > > counted_by attribute, not for the other TYPE which alre
gcc.target/powerpc/block-cmp-8.c is an execution test on ilp32. It
tests for support for the 64-bit ISA in the compiler, but not for the
ability to execute powerpc64 instructions, so the test fails on 32-bit
hardware. Require powerpc64 instead.
Regstrapped on powerpc64le-linux-gnu. Also teste
Multiple tests on ilp32 get TARGET_POWERPC64 enabled by -mdejagnu-cpu
options, but the results they expect are only attained without
enabling it, so disable it explicitly.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/tes
The implementation of the fe*except primitives in newlib sets the
FE_VXSOFT bit when raising FE_INVALID, and the test doesn't expect
that. Skip it: the tested builtin expansions are for glibc only
anyway.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-e
Like pr91323.c, pr52451.c fails on all powerpc variants (except where
already skipped), because it uses fcmpu even when qNaNs should flag FP
exceptions.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
Some ppc bfp tests use __ieee128 without ensuring it's available.
Require ppc_ieee128_ok, add -mfloat128 to get the type defined,
and tolerate the warning that this option may trigger.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
Like other ppc targets, powerpc-*-elf needs -Wno-psabi to compile
gcc.dg/ipa/ipa-sra-19.c without an undesired warning about vector
argument passing.
Regstrapped on powerpc64le-linux-gnu. Also tested with gcc-14 on
x86_64-linux-x-powerpc-elf. Ok to install?
for gcc/testsuite/ChangeLog
The rs6000.md copysign3 expander requires the mode to satisfy
FLOAT128_IEEE_P, so requiring float128 on ppc for ifn_copysign
effective target is hopefully a close-enough approximation.
gcc.dg/fold-copysign-1.c and gcc.dg/pr55152-2.c fail on ppc-elf
without this.
Regstrapped on powerpc64le-linux
g++.dg/pr112822.C uses altivec vectors explicitly, but it expects this
feature to be enabled by default on targets that recognize the
attribute, which is not a given on older ppc cpus, where the compiler
recommends recompiling with -mvsx.
Since it's just a compilation test, we don't seem to need t
On 2025-04-11 13:37, Martin Uecker wrote:
My understanding is that such issue with the implicit data flow dependency
information missing is only for the
counted_by attribute, not for the other TYPE which already have the bound
information there.
The dependency issue is only for the size, but
On Fri, 11 Apr 2025 at 15:14, Tomasz Kaminski wrote:
>
>
>
> On Fri, Apr 11, 2025 at 2:25 PM Jonathan Wakely wrote:
>>
>> On Fri, 11 Apr 2025 at 08:23, Tomasz Kaminski wrote:
>> >
>> >
>> >
>> > On Thu, Apr 10, 2025 at 6:27 PM Jonathan Wakely wrote:
>> >>
>> >> The std::atomic constructor clear
Am Freitag, dem 11.04.2025 um 17:08 + schrieb Qing Zhao:
>
> > On Apr 11, 2025, at 12:20, Martin Uecker wrote:
> >
> > Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
> > >
> > > > On Apr 11, 2025, at 10:53, Martin Uecker wrote:
> > > >
> > > > Am Freitag, dem 11.04.2025 um 1
Hi Thomas!
Am 11.04.25 um 17:50 schrieb Thomas Koenig:
Hello world,
the attached patch fixes an ICE by setting the typespec of a dummy
argument from a global function if known. plus setting the correct flag.
This also removes the corresponding assert. I'm not quite sure that the
code with the
> On Apr 11, 2025, at 12:20, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
>>
>>> On Apr 11, 2025, at 10:53, Martin Uecker wrote:
>>>
>>> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
On 4/11/25 10:27, Qing Zhao wrote:
>
>
On 4/11/25 2:29 AM, Uros Bizjak wrote:
Hello!
I would like to backport PR115568 and PR119689 to release branches.
Author: Richard Biener
Date: Wed Apr 9 14:36:19 2025 +0200
rtl-optimization/119689 - compare-debug failure with LRA
The previous change to fix LRA rematerialization b
The test was designed to pass with thumb2, but code generation changed
with the introduction of Low Overhead Loops, so the test can fail if
one overrides the flags when running the testsuite.
In addition, useless subtract / extension instructions require -O2 to
remove them (-O is not sufficient),
On 4/11/25 10:27, Qing Zhao wrote:
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the
suggestion is that pointe
Hi!
On Thu, 10 Apr 2025 at 19:13, Richard Earnshaw (lists)
wrote:
>
> On 10/04/2025 14:55, Christophe Lyon wrote:
> > All arm effective-targets using check_runtime use the "_hw" or
> > "_multilib" suffix, so rename arm_v8_1_lob_ok into arm_v8_1_lob_hw for
> > consistency.
> >
> > gcc/testsuite/Ch
Andreas Schwab writes:
> On Apr 11 2025, Rainer Orth wrote:
>
>> All users of symbols.h fail to compile on Solaris:
>>
>> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
>> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: ‘NAME_MAX’
>> was not declared in this
Hello world,
the attached patch fixes an ICE by setting the typespec of a dummy
argument from a global function if known. plus setting the correct flag.
This also removes the corresponding assert. I'm not quite sure that the
code with the subroutine attribute can be reached, but I thought better
Am Freitag, dem 11.04.2025 um 16:01 + schrieb Qing Zhao:
>
> > On Apr 11, 2025, at 10:53, Martin Uecker wrote:
> >
> > Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> > > On 4/11/25 10:27, Qing Zhao wrote:
> > > >
> > > > > On Apr 10, 2025, at 11:12, Martin Uecker wrote
> On Apr 11, 2025, at 10:53, Martin Uecker wrote:
>
> Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
>> On 4/11/25 10:27, Qing Zhao wrote:
>>>
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyar
On 4/11/25 11:36, Qing Zhao wrote:
On Apr 11, 2025, at 10:42, Andrew MacLeod wrote:
On 4/11/25 10:27, Qing Zhao wrote:
On Apr 10, 2025, at 11:12, Martin Uecker wrote:
Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote:
It
On Thu, Apr 10, 2025 at 02:48:36PM -0700, Edwin Lu wrote:
> [1] https://github.com/riscv/riscv-zalasr
>
> Add minimal support for the zalasr (load-acquire/store-release)
> extension
>
> Currently there is no toggle to opt into the abi-breaking note 3
> mappings in the PSABI doc so support for tha
This adds an automatic downloader for the latest test results from
the mailing list archive and supports diffing test_summary to it.
Useful if you don't want to run your own baseline.
contrib/ChangeLog:
* diffsummary.py: New file.
---
contrib/diffsummary.py | 104
Right now ggc has a single free list for multiple sizes. In some cases
the list can get mixed by orders and then the allocator may spend a lot
of time walking the free list to find the right sizes.
This patch splits the free list into multiple free lists by order
which allows O(1) access in most c
Hi,
this applies the same magic to config/i386/gthr-win32.h that was applied to
gthr-posix.h (https://gcc.gnu.org/cgit/gcc/commit/?id=6a4d1c374eed17) for the
sake of C++ modules (thanks to Andrew for the pointer!).
Built for {i686,x86_64}-w64-mingw32, OK for the mainline?
2025-04-11 Eric Botc
On Fri, 11 Apr 2025 at 14:47, Jonathan Wakely wrote:
>
> This includes the P2810R4 (is_debugger_present is_replaceable) changes,
> allowing std::is_debugger_present to be replaced by the program.
>
> It would be good to provide a macOS definition of is_debugger_present as
> per https://developer.a
> On Apr 11, 2025, at 10:42, Andrew MacLeod wrote:
>
>
> On 4/11/25 10:27, Qing Zhao wrote:
>>
>>> On Apr 10, 2025, at 11:12, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
On 2025-04-10 10:50, Andrew MacLeod wrote:
> Its not c
Jakub Jelinek writes:
> Hi!
>
> During make gcc.pot I've noticed among tons of other warnings (e.g. because
> can't appears in non-C/C++ style comment and so gettext considers it
> unterminated) a warning where the lack of " looked unintentional.
>
> Committed to trunk as obvious.
>
> 2025-04-09
On Fri, Apr 11, 2025 at 2:25 PM Jonathan Wakely wrote:
> On Fri, 11 Apr 2025 at 08:23, Tomasz Kaminski wrote:
> >
> >
> >
> > On Thu, Apr 10, 2025 at 6:27 PM Jonathan Wakely
> wrote:
> >>
> >> The std::atomic constructor clears padding bits so that compare_exchange
> >> will not fail due to dif
Am Freitag, dem 11.04.2025 um 10:42 -0400 schrieb Andrew MacLeod:
> On 4/11/25 10:27, Qing Zhao wrote:
> >
> > > On Apr 10, 2025, at 11:12, Martin Uecker wrote:
> > >
> > > Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
> > > > On 2025-04-10 10:50, Andrew MacLeod wrote:
On 4/11/25 10:05, Qing Zhao wrote:
On Apr 10, 2025, at 10:55, Siddhesh Poyarekar wrote:
On 2025-04-10 10:50, Andrew MacLeod wrote:
Its not clear to me exactly what is being asked, but I think the suggestion is
that pointer references are being replaced with a builtin function called
.ACC
Tested by me on x86_64-pc-linux-gnu and Sam James on
armv7a-unknown-linux-gnueabihf, applying to trunk.
-- 8< --
Because of the __builtin_is_constant_evaluated, maybe_constant_init in
expand_default_init fails, so the constexpr constructor isn't folded until
cp_fold, which then calls cp_build_ini
> On Apr 10, 2025, at 10:55, Siddhesh Poyarekar wrote:
>
> On 2025-04-10 10:50, Andrew MacLeod wrote:
>> Its not clear to me exactly what is being asked, but I think the suggestion
>> is that pointer references are being replaced with a builtin function called
>> .ACCESS_WITH_SIZE ?and I
Recent changes have started triggering:
Tests that now fail, but worked before (3 tests):
unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc:
gcc.target/riscv/rvv/base/pr115068-run.c (test for excess errors)
unix/-march=rv64gc_zba_zbb_zbs_zicond: gcc:
gcc.target/riscv/rvv/base/pr115068.c (test for ex
> On Apr 10, 2025, at 11:12, Martin Uecker wrote:
>
> Am Donnerstag, dem 10.04.2025 um 10:55 -0400 schrieb Siddhesh Poyarekar:
>> On 2025-04-10 10:50, Andrew MacLeod wrote:
>>> Its not clear to me exactly what is being asked, but I think the
>>> suggestion is that pointer references are being
The gcc4-compatible copy-on-write std::string does not conform to the
C++11 requirements on data race avoidance in standard containers.
Specifically, calling non-const member functions such as begin() and
data() needs to do the "copy on write" operation and so is most
definitely a modification of t
This includes the P2810R4 (is_debugger_present is_replaceable) changes,
allowing std::is_debugger_present to be replaced by the program.
It would be good to provide a macOS definition of is_debugger_present as
per https://developer.apple.com/library/archive/qa/qa1361/_index.html
but that isn't inc
libstdc++-v3/ChangeLog:
* src/c++17/fast_float/LOCAL_PATCHES: Update.
---
Pushed to trunk.
libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES | 1 +
1 file changed, 1 insertion(+)
diff --git a/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCHES
b/libstdc++-v3/src/c++17/fast_float/LOCAL_PATCH
On Thu, 10 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> As noted by Richi on a large testcase, there are unnecessary paddings
> in some heavily used dwarf2out.{h,cc} structures on 64-bit hosts.
>
> struct dw_val_node {
> enum dw_val_class val_class;/* 0 4 */
>
>
with GCC 15.1 in sight... ping on
gcobc wrapper fixes and additions:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680218.html
(note: obviously it would be good if -Wall [1] would work (the "global"
PR for -Wall was postponed to GCC16, so possibly add to gcobol as
intermediate?), then
On Fri, Apr 11, 2025 at 2:14 PM Rainer Orth
wrote:
>
> Andreas Schwab writes:
>
> > On Apr 11 2025, Rainer Orth wrote:
> >
> >> All users of symbols.h fail to compile on Solaris:
> >>
> >> /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope:
> >> /vol/gcc/src/hg/master/local/gcc/co
1 - 100 of 156 matches
Mail list logo
