Re: [PATCH] x86: Remove BREG from ix86_class_likely_spilled_p

Uros Bizjak writes: > On Wed, Apr 30, 2025 at 11:31 PM H.J. Lu wrote: >> >> On Wed, Apr 30, 2025 at 7:37 PM Uros Bizjak wrote: >> > >> > On Tue, Apr 29, 2025 at 11:40 PM H.J. Lu wrote: >> > > >> > > AREG, DREG, CREG and AD_REGS are kept in ix86_class_likely_spilled_p to >> > > avoid the followi

[PATCH] c++: Implement C++26 P1061R10 - Structured Bindings can introduce a Pack [PR117783]

Hi! The following patch implements the C++26 P1061R10 - Structured Bindings can introduce a Pack paper. One thing unresolved in the patch is mangling, I've raised https://github.com/itanium-cxx-abi/cxx-abi/issues/200 for that but no comments there yet. One question is if it is ok not to mention t

[PATCH v2 1/1] Fix BZ 119317: named loops (C2y) with debug info

Named loops (C2y) could not previously be compiled with -O1 and -ggdb2 or higher because the label preceding a loop (or switch) could not be found when using such command lines. This could be observed by compiling gcc/gcc/testsuite/gcc.dg/c2y-named-loops-1.c with the provoking command line (or any

[PATCH v2 0/1] Fix BZ 119317: named loops (C2y) with debug info

Fixed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119317 Tested v2 on AArch64 using a new regression test, which is simply a wrapper around an existing test for named loops that sets the provoking options. Confirmed that the new test passes with the fix and fails if the fix is reverted. e.g., FA

Re: [PATCH] x86: Remove BREG from ix86_class_likely_spilled_p

On Thu, May 1, 2025 at 1:21 PM Richard Sandiford wrote: > > Uros Bizjak writes: > > On Wed, Apr 30, 2025 at 11:31 PM H.J. Lu wrote: > >> > >> On Wed, Apr 30, 2025 at 7:37 PM Uros Bizjak wrote: > >> > > >> > On Tue, Apr 29, 2025 at 11:40 PM H.J. Lu wrote: > >> > > > >> > > AREG, DREG, CREG and

Re: [PATCH] aarch64: Optimize SVE extract last to Neon lane extract for 128-bit VLS.

> On 28 Apr 2025, at 16:29, Richard Sandiford wrote: > > External email: Use caution opening links or attachments > > > Jennifer Schmitz writes: >>> On 27 Apr 2025, at 08:42, Tamar Christina wrote: >>> >>> External email: Use caution opening links or attachments >>> >>> -Origina

Re: [PATCH v2 0/1] Fix BZ 119317: named loops (C2y) with debug info

On Thu, 1 May 2025, Christopher Bazley wrote: > Changes in v2: > - Fixed a formatting issue. > - Added a test. Thanks. I have no further comments; I hope someone more familiar with debug info handling can review this version. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] x86: Update TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P

On Thu, May 1, 2025 at 12:49 AM H.J. Lu wrote: > > On Wed, Apr 30, 2025 at 7:48 PM Uros Bizjak wrote: > > > > On Tue, Apr 29, 2025 at 11:40 PM H.J. Lu wrote: > > > > > > SMALL_REGISTER_CLASSES was added by > > > > > > commit c98f874233428d7e6ba83def7842fd703ac0ddf1 > > > Author: James Van Artsda

Re: [PATCH] x86: Remove BREG from ix86_class_likely_spilled_p

On Thu, May 1, 2025 at 2:56 PM Uros Bizjak wrote: > > On Wed, Apr 30, 2025 at 11:31 PM H.J. Lu wrote: > > > > On Wed, Apr 30, 2025 at 7:37 PM Uros Bizjak wrote: > > > > > > On Tue, Apr 29, 2025 at 11:40 PM H.J. Lu wrote: > > > > > > > > AREG, DREG, CREG and AD_REGS are kept in ix86_class_likely

[PATCH] c++: Small build_vec_init improvement [PR117827]

Hi! As discussed in the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674492.html thread, the following patch attempts to improve build_vec_init generated code. E.g. on g++.dg/eh/aggregate1.C test the patch has differences like: D.2988 = &D.2950->e1;

Re: [PATCH] x86: Remove SSE_FIRST_REG from ix86_class_likely_spilled_p

On Wed, Apr 30, 2025 at 11:43 PM H.J. Lu wrote: > > On Wed, Apr 30, 2025 at 8:12 PM Uros Bizjak wrote: > > > > On Tue, Apr 29, 2025 at 11:40 PM H.J. Lu wrote: > > > > > > SSE_FIRST_REG was added to CLASS_LIKELY_SPILLED_P, which became > > > TARGET_CLASS_LIKELY_SPILLED_P, for > > > > > > https://

[committed htdocs v2] bugs: improve "ABI changes" subsection

C++ ABI for C++ standards with full support by GCC (rather than those marked as experimental per https://gcc.gnu.org/projects/cxx-status.html) should be stable. It's certainly not the case in 2025 that one needs a full world rebuild for C++ libraries using e.g. the default standard or any other sup

Re: [PATCH v5 05/10] libstdc++: Implement layout_left from mdspan.

On Wed, Apr 30, 2025 at 7:13 AM Tomasz Kaminski wrote: > Hi, > > As we will be landing patches for extends, this will become a separate > patch series. > I would prefer, if you could commit per layout, and start with > layout_right (default) > I try to provide prompt responses, so if that works b

Re : [PATCH v4] RISC-V: Fix missing implied Zicsr from Zve32x

Seems CI still fail: Patch Status 46835-v4_RISCV_Fix_missing_implied_Zicsr_from_Zve32x-1 · Issue #3283 · ewlu/gcc-precommit-ci /home/ewlu/precommit-03/_work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.targe

[PATCH] get_known_nonzero_bits_1 should use wi::bit_and_not [PR118659]

While looking into bitwise optimizations, I noticed that get_known_nonzero_bits_1 does `bm.value () & ~bm.mask ()` which is ok except it creates a temporary wide_int. Instead if we use wi::bit_and_not, we can avoid the temporary and on some targets use the andn/bic instruction. Bootstrapped and te

Re: [Stage 1][Middle-end][PATCH v5 0/3] Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

On Mon, Apr 07, 2025 at 03:04:56PM +, Qing Zhao wrote: > Adding -fdiagnotics-details into GCC to provide more hints to the > end users on how the warnings come from, in order to help the user > to locate the exact location in source code on the specific warnings > due to compiler optimizations.

[PATCH v2] i386/cygming: Decrease default preferred stack boundary for 32-bit targets

For i686-w64-mingw32, both the incoming and preferred stack boundaries are decreased to 4 bytes (32 bits), same as MSVC. The change has no effect on 64-bit targets. Documentation of `force_align_arg_pointer` attribute seems to say that it realigns the stack to 16-byte boundaries, so it now has

Re: [PATCH] c++: Small build_vec_init improvement [PR117827]

On 5/1/25 3:00 AM, Jakub Jelinek wrote: Hi! As discussed in the https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674492.html thread, the following patch attempts to improve build_vec_init generated code. E.g. on g++.dg/eh/aggregate1.C test the patch has differences like:

[Patch fortran] PR119948 - Source allocation of pure function result rejected

Committed as r16-329-g0abc77da9d704bba55a376bb5c162a54826ab94a following OK by Jerry on PR. I am ready to backport in a few weeks time if that is wanted. Regards Paul Fortran: Source allocation of pure function result rejected [PR119948] 2025-05-01 Paul Thomas gcc/fortran

Re: [GCC16,RFC,V2 08/14] aarch64: memtag: implement target hooks

Indu Bhagat writes: > 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.

Re: [GCC16, RFC, V2 12/14] memtag: doc: add new option -fsanitize-memtag-mode=

Indu Bhagat writes: > 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. Not sure about the name "asymm": it

[PATCH 0/4] gimple: Rework the bit-test switch lowering algorithm

Hi, while developing GCC 15, we found out that the bit-test switch lowering algorithm is quadratic and that it is possible to construct a switch that causes huge compile time (PR117091). Andi Kleen came up with a fast bit-test lowering algorithm which was 1) linear 2) in some cases better than th

[PATCH 1/4] gimple: Merge slow and fast bit-test switch lowering [PR117091]

PR117091 showed that bit-test switch lowering can take a lot of time. The algorithm was O(n^2). We therefore came up with a faster algorithm (O(n * BITS_IN_WORD)) and made GCC choose between the slow and the fast algorithm based on how big the switch is. Here I combine the algorithms so that we g

[PATCH 2/4] gimple: Make bit-test switch lowering more powerful

A reasonable goal for bit-test lowering is to produce the least amount of clusters for a given switch (a cluster is basically a group of cases that can be handled by constantly many operations). The current algorithm doesn't always give optimal solutions in that sense. This patch should fix this.

[PATCH 3/4] gimple: Don't warn about using different algs for big switch lowering [PR117091]

We currently don't switch to a faster switch lowering algorithm when a switch is too big. This patch removes a warning about this. PR middle-end/117091 gcc/ChangeLog: * tree-switch-conversion.cc (switch_decision_tree::analyze_switch_statement): Remove warning about usin

[PATCH 4/4] gimple: Switch bit-test lowering testcases for the more powerful alg

This patch adds 2 testcases. One tests that GCC is able to create bit-test clusters of size 64. The other one contains two switches which GCC wouldn't completely cover with bit-test clusters before the changes from this patch set. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/switch-5.c: N

[PATCH] Fixup vect_remove_slp_scalar_calls

There's a logic error for vect_remove_slp_scalar_calls where it simply ignores pattern stmts but it should instead look at the original stmt. Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. * tree-vect-slp.cc (vect_remove_slp_scalar_calls): Look at the original stmt.

[PATCH] Fix gcc.dg/tree-ssa/ssa-dom-thread-7.c for aarch64

So on another machine with a cross I see 17 jumps threaded, so adjusted like that. Pushed. PR tree-optimization/120003 * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust aarch64 expected thread2 number of threads. --- gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c | 2 +- 1 f

Re: [PATCH RFA (fold)] c++: remove TREE_STATIC from constexpr heap vars [PR119162]

On Mon, 21 Apr 2025, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, OK for trunk? > > -- 8< -- > > While working on PR119162 it occurred to me that it would be simpler to > detect the problem of a value referring to a heap allocation if we stopped > setting TREE_STATIC on them so they natura

Re: [PATCH] sreal.h: fix typo in the comment for sreal::max

On Wed 2025-04-30 08:44:11, Vojtěch Káně wrote: > --- > gcc/sreal.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/sreal.h b/gcc/sreal.h > index 8700807a131..c5aef1f3a82 100644 > --- a/gcc/sreal.h > +++ b/gcc/sreal.h > @@ -118,7 +118,7 @@ public: > return min; >

Re: [PATCH v4 2/2] Aarch64: Add __sqrt and __sqrtf intrinsics and corresponding tests

> On 1 May 2025, at 14:02, Ayan Shafqat wrote: > > On Thu, May 01, 2025 at 08:09:18AM +, Kyrylo Tkachov wrote: >> >> I was going to ask why not use the standard __buuiltin_sqrt builtins but I >> guess those don’t guarantee that we avoid a libcall in all cases. >> So this is ok. >> > > Y

Re: [GCC16, RFC, V2 01/14] opts: use unsigned HOST_WIDE_INT for sanitizer flags

Indu Bhagat writes: > 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 >

Re: [PATCH] (not just) AArch64: Fold unsigned ADD + LSR by 1 to UHADD

Thank you for the comments. > I don't think we can use an unbounded recursive walk, since that > would become quadratic if we ever used it when optimising one > AND in a chain of ANDs. (And using this function for ANDs > seems plausible.) Maybe we should be handling the information > in a simila

[PATCH v3] i386/cygming: Decrease default preferred stack boundary for 32-bit targets

Remove `STACK_REALIGN_DEFAULT` for this target, because now the default value of `incoming_stack_boundary` equals `MIN_STACK_BOUNDARY` and it doesn't have an effect any more. -- Best regards, LIU Hao From eeb30bf621baa3af1a73e8e91bff297ef478 Mon Sep 17 00:00:00 2001 From: LIU Hao Date:

Re: [PATCH v4 1/2] Aarch64: Use BUILTIN_VHSDF_HSDF for vector and scalar sqrt builtins

> On 28 Apr 2025, at 21:27, Ayan Shafqat wrote: > > Rebased with gcc 15.1 > > This patch changes the `sqrt` builtin definition from `BUILTIN_VHSDF_DF` > to `BUILTIN_VHSDF_HSDF` in `aarch64-simd-builtins.def`, ensuring the > builtin covers half, single, and double precision variants. The redun

Re: [PATCH] x86: Remove BREG from ix86_class_likely_spilled_p

> Am 01.05.2025 um 09:53 schrieb Uros Bizjak : > > On Thu, May 1, 2025 at 9:10 AM H.J. Lu wrote: >> >>> On Thu, May 1, 2025 at 2:56 PM Uros Bizjak wrote: >>> >>> On Wed, Apr 30, 2025 at 11:31 PM H.J. Lu wrote: On Wed, Apr 30, 2025 at 7:37 PM Uros Bizjak wrote: > > On

Re: [PATCH] x86: Remove BREG from ix86_class_likely_spilled_p

On Thu, May 1, 2025 at 9:10 AM H.J. Lu wrote: > > On Thu, May 1, 2025 at 2:56 PM Uros Bizjak wrote: > > > > On Wed, Apr 30, 2025 at 11:31 PM H.J. Lu wrote: > > > > > > On Wed, Apr 30, 2025 at 7:37 PM Uros Bizjak wrote: > > > > > > > > On Tue, Apr 29, 2025 at 11:40 PM H.J. Lu wrote: > > > > > >

Re: [PATCH v4 2/2] Aarch64: Add __sqrt and __sqrtf intrinsics and corresponding tests

> On 28 Apr 2025, at 21:29, Ayan Shafqat wrote: > > Rebased with gcc 15.1 > > This patch introduces two new inline functions, __sqrt and __sqrtf, in > arm_acle.h for Aarch64 targets. These functions wrap the new builtins > __builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively, >

Re: [PATCH v4 2/2] Aarch64: Add __sqrt and __sqrtf intrinsics and corresponding tests

On Thu, May 01, 2025 at 08:09:18AM +, Kyrylo Tkachov wrote: > > I was going to ask why not use the standard __buuiltin_sqrt builtins but I > guess those don’t guarantee that we avoid a libcall in all cases. > So this is ok. > Yes, __builtin_sqrt will generate calls to sqrt(3) with default co

Re: [PING^5][PATCH] Alpha: Fix base block alignment calculation regression

On Sat, 19 Apr 2025, Maciej W. Rozycki wrote: > > > > Address this issue by recursing into COMPONENT_REF tree nodes until the > > > > outermost one has been reached, which is supposed to be a MEM_REF one, > > > > accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha: > > > > Also

[COMMITTED, OBVIOUS] OpenMP: Restore lost Fortran testcase for 'omp allocate'

Tobias asked me to push the attached patch on his behalf. I verified that the testcase still does pass on mainline. :-) -Sandra From 08ce1b9f6707e00089c4d77d2bb82963d531bb1d Mon Sep 17 00:00:00 2001 From: Tobias Burnus Date: Thu, 1 May 2025 15:39:42 + Subject: [COMMITTED, OBVIOUS] OpenMP

Re: [GCC16,RFC,V2 02/14] aarch64: add new define_insn for subg

Sorry for the late reply. Indu Bhagat writes: > On 4/22/25 11:00 AM, Indu Bhagat wrote: >> On 4/15/25 8:35 AM, Richard Sandiford wrote: >>> Hi, >>> >>> Indu Bhagat writes: subg (Subtract with Tag) is an Armv8.5-A memory tagging (MTE) instruction.  It can be used to subtract an immediat

[pushed] c++: avoid weird #line paths in std-name-hint.h

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- etags was getting confused by the #line pathnames in std-name-hint.h that don't match my directory layout; let's avoid encoding information about a particular developer's $(srcdir) in the generated file. gcc/cp/ChangeLog: * Make-la

Re: [GCC16, RFC, V2 06/14] opts: doc: aarch64: add new memtag sanitizer

Indu Bhagat writes: > [...] > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index ffde9df85fd3..de651183a703 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -17079,6 +17079,14 @@ and @option{-fsanitize=kernel-hwaddress}. > To disable instrumentation of builtin funct

Ping: Re: [Stage 1][Middle-end][PATCH v5 0/3] Provide more contexts for -Warray-bounds and -Wstringop-* warning messages

Hi, A gentle ping on review of the Middle-end of change of this patch set. The diagnostic part has been reviewed and approved by David last year already. The 4th version of the patch set has been sent for review since Nov 5, 2024. Pinged 5 times since then. Linux Kernel has been using this f

[PATCH v4] libstdc++: Implement C++26 features (P2546R5)

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

Re: [PATCH] phiopt: Remove special case for a sequence after match and simplify for early phiopt

On Thu, May 1, 2025 at 6:26 AM Andrew Pinski wrote: > > r16-189-g99aa410f5e0a72 fixed the case where match-and-simplify there was an > extra > assignment happening inside the sequence return. phiopt_early_allow had code > to > workaround that issue but now can be removed and simplify down to onl

Re: [GCC16,RFC,V2 04/14] aarch64: add new definition for post-index st2g

Indu Bhagat writes: > On 4/15/25 11:52 AM, Richard Sandiford wrote: >> Indu Bhagat writes: >>> 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 add

Re: [GCC16, RFC, V2 13/14] gcc: aarch64: memtag: update link spec to pass arguments to linker

Indu Bhagat writes: > 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)

Re: [PATCH v2 0/1] Fix BZ 119317: named loops (C2y) with debug info

On Thu, May 01, 2025 at 04:30:56PM +, Joseph Myers wrote: > On Thu, 1 May 2025, Christopher Bazley wrote: > > > Changes in v2: > > - Fixed a formatting issue. > > - Added a test. > > Thanks. I have no further comments; I hope someone more familiar with > debug info handling can review thi

Re: [GCC16, RFC, V2 09/14] hwasan: add support for generating MTE instructions for memory tagging

Indu Bhagat writes: > 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

Re: [GCC16,RFC,V2 03/14] aarch64: add new insn definition for st2g

Indu Bhagat writes: > On 4/15/25 9:21 AM, Richard Sandiford wrote: >> Indu Bhagat writes: >>> 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 ge

Re: [PATCH] libgomp: Update SVE test

Tejas Belagod writes: > Fix udr-sve.c target test that to check for the correct results based on the > OpenMP clauses used. The test was first written with a misunderstood > functionality of the reduction clause. > > Tested with aarch64-linux-gnu. OK for trunk? > > libgomp/ChangeLog: > > *

Re: [PATCH v2 0/1] Fix BZ 119317: named loops (C2y) with debug info

Jakub Jelinek writes: > On Thu, May 01, 2025 at 04:30:56PM +, Joseph Myers wrote: >> On Thu, 1 May 2025, Christopher Bazley wrote: >> >> > Changes in v2: >> > - Fixed a formatting issue. >> > - Added a test. >> >> Thanks. I have no further comments; I hope someone more familiar with >> d

[PATCH PING] OpenMP: Implement "begin declare variant"

Hi all, The first two pieces of this patch series https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675464.html were approved and committed for GCC 15, but the remaining 5 parts are still awaiting review. I was hoping that I could get these in early in stage 1, or at least be told earl

[PATCH] expand: Remove unsignedp argument from get_compare_parts [PR118090]

While helping Eikansh with a patch to ccmp, it was noticed that the result stored in the up pointer that gets passed to get_compare_parts was unused on all call sites. It was always unused since get_compare_parts was added in r8-1717-gf580a969d7fbab. It looks it was not noticed it became unused whe

[PATCH] ctf: emit CTF_K_ARRAY for GNU vector types

Currently, there is a check in gen_ctf_array_type that prevents GNU vectors generated by the vector attribute from being emitted (e.g. typedef int v8si __attribute__ ((vector_size (32)));). Because this check happens in dwarf2ctf.cc, this prevents GNU vectors from being emitted not only in CTF, but

Re: [PATCH] libgomp: Update SVE test

On Thu, May 01, 2025 at 08:38:57PM +0100, Richard Sandiford wrote: > Tejas Belagod writes: > > Fix udr-sve.c target test that to check for the correct results based on the > > OpenMP clauses used. The test was first written with a misunderstood > > functionality of the reduction clause. > > > > T

Re: [PATCH][stage1] middle-end/60779 - LTO vs. -fcx-fortran-rules and -fcx-limited-range

Hi Richard, On Mon, Apr 28, 2025 at 11:26:50AM +0200, Richard Biener wrote: > On Tue, Feb 18, 2025 at 1:44 PM Richard Biener wrote: > > > > The following changes how flag_complex_method is managed towards > > being able to record that in the optimization set so we can stream > > and restore it pe

Re: [PATCH v6 1/2] RISC-V: Add intrinsics support for SiFive Xsfvcp extensions.

Hi Kito, Unfortunately this breaks bootstrap for riscv: ../../gcc/gcc/config/riscv/genrvv-type-indexer.cc: In function ‘int main(int, const char**)’: ../../gcc/gcc/config/riscv/genrvv-type-indexer.cc:302:7: error: this ‘for’ clause does not guard... [-Werror=misleading-indentation] 302 |

Re: [PATCH] c: Suppress -Wdeprecated-non-prototype warnings for builtins

Florian Weimer writes: > Builtins defined with BT_FN_INT_VAR etc. show as functions without > a prototype and trigger the warning. > > gcc/c/ > > PR c/119950 > * c-typeck.cc (convert_arguments): Check for built-in > function declaration before warning. > > gcc/testsuite/ > >

[pushed] c++: add missing -fabi-version docs

Tested x86_64-pc-linux-gnu, applying to trunk. -- 8< -- Looks like I've forgotten to update the docs for -fabi-version for a couple of my changes. gcc/ChangeLog: * doc/invoke.texi: Add -fabi-version detail. * common.opt: Likewise. --- gcc/doc/invoke.texi | 9 +++-- gcc/comm

[PATCH RFA] i386: -Wabi false positive with indirect call

Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- This warning relies on the TRANSLATION_UNIT_WARN_EMPTY_P flag (set in cxx_init_decl_processing) to decide whether we want to warn about the GCC 8 empty class parameter passing fix, but in a call through a function pointer we don't have a translat

Re: [PATCH v2 0/1] Fix BZ 119317: named loops (C2y) with debug info

On Thu, May 01, 2025 at 10:02:06PM +0100, Richard Sandiford wrote: > Jakub Jelinek writes: > > On Thu, May 01, 2025 at 04:30:56PM +, Joseph Myers wrote: > >> On Thu, 1 May 2025, Christopher Bazley wrote: > >> > >> > Changes in v2: > >> > - Fixed a formatting issue. > >> > - Added a test. >

[PATCH] ctf: use CTF_FP_LDOUBLE encoding for 128-bit floats

Currently, gen_ctf_base_type will obtain the bit_size of a given DWARF DIE based on the system GCC is compiling for. For DIEs with a DW_ATE_float encoding, this is used to determine whether to classify a given DIE as a single, double, or long double. However, on some systems, a long double will not