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
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
> 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
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
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
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
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
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
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
> 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
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
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
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
> 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
>>>
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
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
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
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 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
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.
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:
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
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.
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
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
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
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
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.
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
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)
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
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
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
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
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 ;
>
> 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
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
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
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/.
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
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
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
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
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
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 differences in padding bits. But we can only do
> that for C++14 and later, because in C++11 a constexpr constructor must
> have an empty body.
On Wed, 2 Apr 2025 13:41:33 -0600, Jeff Law wrote:
>
>
> On 4/2/25 1:01 AM, Jin Ma wrote:
> > Assuming we have the following variables:
> >
> > unsigned long long a0, a1;
> > unsigned int a2;
> >
> > For the expression:
> >
> > a0 = (a0 << 50) >> 49; // slli a0, a0, 50 + srli a0, a0, 49
> > a
Could you break this patch into two pieces:
1) Add new extensions.
2) Add new core (for -mcpu), pipeline model and cost model
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 1326c67563a..d2642390b2a
> 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,24 @@
> +2025-04-09 Umesh K
On Thu, Apr 10, 2025 at 6:53 PM Jonathan Wakely wrote:
> 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 included in this change.
>
> libstdc++-v3/ChangeLog:
>
> * config.h.in
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
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
> -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
> -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
> 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
> 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: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 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
101 - 156 of 156 matches
Mail list logo
