Re: [PATCH v1] RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args

WTF? ../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node* riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree, vec*)': ../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error: misspelled term 'args' in format; use 'arguments' instead [-Werror=forma

[PATCH] Use HOST_SIZE_T_PRINT_* and HOST_WIDE_INT_T_PRINT_* some more

Hi! I went through suspicios %l in format strings of *printf family functions combined with casts to (long) or (unsigned long) and tried to find out the types of the original expressions that were cast. Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_* macros together with cast

[PATCH] Add %[zt][diox] support to pretty-print

Hi! In the previous patch I haven't touched the gcc diagnostic routines, using HOST_SIZE_T_PRINT* for those is obviously undesirable because we want the strings to be translatable. We already have %w[diox] for HOST_WIDE_INT arguments, this patch adds t and z modifiers for those. Bootstrapped/reg

[PATCH] gimple-low: Fix up handling of volatile automatic vars in assume attribute [PR110754]

Hi! As the following testcases show, the gimple-low outlining of assume magic functions handled volatile automatic vars (including parameters/results) like non-volatile ones except it copied volatile to the new PARM_DECL, which has the undesirable effect that a load from the volatile var is passed

Re: [PATCH] Use HOST_SIZE_T_PRINT_* and HOST_WIDE_INT_T_PRINT_* some more

> Am 10.02.2024 um 10:39 schrieb Jakub Jelinek : > > Hi! > > I went through suspicios %l in format strings of *printf family functions > combined with casts to (long) or (unsigned long) and tried to find out the > types of the original expressions that were cast. > Quite a few had size_t type

Re: [PATCH] gimple-low: Fix up handling of volatile automatic vars in assume attribute [PR110754]

> Am 10.02.2024 um 10:46 schrieb Jakub Jelinek : > > Hi! > > As the following testcases show, the gimple-low outlining of assume > magic functions handled volatile automatic vars (including > parameters/results) like non-volatile ones except it copied volatile > to the new PARM_DECL, which ha

Re: [PATCH] Add %[zt][diox] support to pretty-print

> Am 10.02.2024 um 10:41 schrieb Jakub Jelinek : > > Hi! > > In the previous patch I haven't touched the gcc diagnostic routines, > using HOST_SIZE_T_PRINT* for those is obviously undesirable because we > want the strings to be translatable. We already have %w[diox] for > HOST_WIDE_INT argum

[PATCH] libgcc: Fix BIL_TYPE_SIZE == 32 support in _BitInt <-> dfp support

Hi! I've tried last night to enable _BitInt support for i?86-linux, and a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly didn't do what it was supposed to do. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux (together with patch which enabled the bitint

[PATCH] libgcc: Fix a bug in _BitInt -> dfp conversions

Hi! The ia32 _BitInt support revealed a bug in floatbitint?d.c. As can be even guessed from how the code is written in the loop, the intention was to set inexact to non-zero whenever the remainder after division wasn't zero, but I've ended up just checking whether the 2 least significant limbs of

[PATCH] lower-bitint: Fix up .{ADD,SUB}_OVERFLOW lowering

Hi! torture/bitint-37.c test FAILed on i686-linux e.g. on signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575) __builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in the IL, 2 in a loop (which handles the first 8 limbs), then one partial limb (we use 63 bits from that)

Re: [PATCH] libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]

Il 09/02/24 15:18, Matteo Italia ha scritto: The Win32 threading model uses __gthr_win32_abs_to_rel_time to convert the timespec used in gthreads to specify the absolute time for end of the condition variables timed wait to a milliseconds value relative to "now" to pass to the Win32 SleepConditio

[RFC PATCH] i386: Enable _BitInt support on ia32

Hi! Given the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837#c9 comment, the following patch just attempts to implement what I think is best for ia32. Compared to https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 , like that patch for _BitInt(64) or smaller it uses the smallest containing {,

Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]

> On 9 Feb 2024, at 23:21, Iain Sandoe wrote: > > > >> On 9 Feb 2024, at 10:56, Iain Sandoe wrote: >>> On 8 Feb 2024, at 21:44, Jason Merrill wrote: >>> >>> On 2/8/24 12:55, Paolo Bonzini wrote: On 2/8/24 18:16, Jason Merrill wrote: >>> >> >> Hmm. In stage 1, when we b

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

Hi Florian, that's been quite a bit. Thank you for putting this together so comprehensively and thoughtfully, with examples and background! Note many of my points are suggestions or questions, especially if phrased as questions or using maybe or similar, so for your consideration. On Fri, 2 Fe

[PATCH v1] RISC-V: Fix misspelled term args in error_at message

From: Pan Li When build with "-Werror=format-diag", there will be one misspelled term args as below. This patch would like fix it by taking the term arguments instead. ../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node* riscv_vector::resolve_overloaded_builtin(location_t, un

Re: [RFC PATCH] i386: Enable _BitInt support on ia32

On Sat, Feb 10, 2024 at 11:19:16AM +0100, Jakub Jelinek wrote: > And bitint-24.c case seems to be miscompilation of __floatbitintxf > when built with -O2 -m32, it works fine when compiled with -O0 -m32. > Will address that next week. Ugh, -O2 -m32 -march=i686 works fine, -O2 -m32 -march=i686 -mtun

Re: [PATCH] libgcc: Fix BIL_TYPE_SIZE == 32 support in _BitInt <-> dfp support

> Am 10.02.2024 um 10:50 schrieb Jakub Jelinek : > > Hi! > > I've tried last night to enable _BitInt support for i?86-linux, and > a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly > didn't do what it was supposed to do. > > Fixed thusly, bootstrapped/regtested on x86

Re: [PATCH] libgcc: Fix a bug in _BitInt -> dfp conversions

> Am 10.02.2024 um 10:56 schrieb Jakub Jelinek : > > Hi! > > The ia32 _BitInt support revealed a bug in floatbitint?d.c. > As can be even guessed from how the code is written in the loop, > the intention was to set inexact to non-zero whenever the remainder > after division wasn't zero, but I

Re: [PATCH] lower-bitint: Fix up .{ADD,SUB}_OVERFLOW lowering

> Am 10.02.2024 um 11:03 schrieb Jakub Jelinek : > > Hi! > > torture/bitint-37.c test FAILed on i686-linux e.g. on > signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575) > __builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in > the IL, 2 in a loop (which handles t

[PATCH] Darwin, testsuite: -bind_at_load is deprecated

With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning: ld: warning: -bind_at_load is deprecated on macOS The patches ignores the warning when present. OK to push? FX 0001-Darwin-testsuite-bind_at_load-is-deprecated.patch Description: Binary data

Re: [PATCH] Darwin, testsuite: -bind_at_load is deprecated

Hi FX, > On 10 Feb 2024, at 11:58, FX Coudert wrote: > > With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning: > ld: warning: -bind_at_load is deprecated on macOS > > The patches ignores the warning when present. > OK to push? Yes, thanks. Iain I guess for GCC-15 we might need to see w

Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]

On 2/10/24 05:46, Iain Sandoe wrote: On 9 Feb 2024, at 23:21, Iain Sandoe wrote: On 9 Feb 2024, at 10:56, Iain Sandoe wrote: On 8 Feb 2024, at 21:44, Jason Merrill wrote: On 2/8/24 12:55, Paolo Bonzini wrote: On 2/8/24 18:16, Jason Merrill wrote: Hmm. In stage 1, when we build w

Re: [PATCH 1/2] c++/modules: reduce lazy loading recursion

On 2/9/24 16:50, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk -- >8 -- It turns out that with modules we can call mangle_decl recursively, which is a problem because the global mangling state isn't recursion aware. The recursion happens fr

Re: [PATCH 2/2] c++/modules: ICE with modular fmtlib

On 2/9/24 17:11, Patrick Palka wrote: On Fri, 9 Feb 2024, Patrick Palka wrote: Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk? I'll try to reduce and add testcases overnight for these separate bugs before pushing. -- >8 -- Building modular fmtlib triggered two

Re: [PATCH RFA] build: drop target libs from LD_LIBRARY_PATH [PR105688]

> On 10 Feb 2024, at 12:07, Jason Merrill wrote: > > On 2/10/24 05:46, Iain Sandoe wrote: >>> On 9 Feb 2024, at 23:21, Iain Sandoe wrote: >>> >>> >>> On 9 Feb 2024, at 10:56, Iain Sandoe wrote: > On 8 Feb 2024, at 21:44, Jason Merrill wrote: > > On 2/8/24 12:55, Paolo B

[PATCH] [X86_64]: Enable support for next generation AMD Zen5 CPU with znver5 scheduler Model

[Public] Hi all, PFA, the patch that enables support for the next generation AMD Zen5 CPU via -march=znver5 with basic znver5 scheduler Model. We may update the scheduler model going forward. Good for trunk? Thanks and Regards Karthiban Resending the patch, as unable to inline the patch

ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

Hello- https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html May I please ping this one? Thanks! On Sat, Jan 13, 2024 at 5:12 PM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704 > > The below patch fixes the issue noted in the PR that extended c

[PATCH] Darwin, testsuite: -multiply_defined is obsolete

With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is obsolete The patches ignores the warning when present. OK to push? FX 0001-Darwin-testsuite-multiply_defined-is-obsolete.patch Description: Binary data

Re: [PATCH] Darwin, testsuite: -multiply_defined is obsolete

> On 10 Feb 2024, at 14:54, FX Coudert wrote: > > With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is > obsolete > > The patches ignores the warning when present. > OK to push? yes, thanks. Iain … although part of me is curious about whether we still have any support

[PATCH] testsuite: Update test case to comply with GCC14 changes

I have confirmed that this updated pr97969.c file still hangs with gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969. Ok for trunk? -- The test case for PR97969 needs updates in order to comply with recent changes in GCC14. Without these changes, failures like this can be

[PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].

I have so far tested this on i686-darwin17 and on x86_64-linux (with 32b multilib )with the following permutations: C (dg.exp=*nest*), Ada : \{-m64,-m32\}\{,-ftrampoline-impl=heap\}\{,-shared-libgcc\} Fortran \{-m64,-m32\}\{,-ftrampoline-impl=heap\} The only fails [gnat] are expected (scanning fo

[PATCHv2 0/2] Changes to libiberty buildargv

I realise that these patches are not going to get merged until GCC is back in stage 1, but thought I'd post my latest set of changes for the libiberty buildargv function. Patch #1 is unchanged from V1. Patch #2 is new in V2. Thanks, Andrew --- Andrew Burgess (2): libiberty/buildargv: POSIX b

[PATCHv2 2/2] libiberty/buildargv: handle input consisting of only white space

GDB makes use of the libiberty function buildargv for splitting the inferior (program being debugged) argument string in the case where the inferior is not being started under a shell. I have recently been working to improve this area of GDB, and noticed some unexpected behaviour to the libiberty

[PATCHv2 1/2] libiberty/buildargv: POSIX behaviour for backslash handling

GDB makes use of the libiberty function buildargv for splitting the inferior (program being debugged) argument string in the case where the inferior is not being started under a shell. I have recently been working to improve this area of GDB, and have tracked done some of the unexpected behaviour

Re: [PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].

On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote: > PR target/113855 > > gcc/ChangeLog: > > * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be > available to all sub-targets. > * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete. > * config/i3

[pushed] Darwin, testsuite: skip some -mcmodel=large tests

Three new tests using -mcmodel=large, which darwin does not support. Skipping them. Pushed as obvious. FX 0001-Darwin-testsuite-skip-some-mcmodel-large-tests.patch Description: Binary data

Re: [PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].

> On 10 Feb 2024, at 17:46, Jakub Jelinek wrote: > > On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote: >> PR target/113855 >> >> gcc/ChangeLog: >> >> * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be >> available to all sub-targets. >> * config/i386/darwi

Re: [PATCH] x86, libgcc: Implement ia32 basic heap trampoline [PR113855].

On Sat, Feb 10, 2024 at 9:46 AM Jakub Jelinek wrote: > > On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote: > > PR target/113855 > > > > gcc/ChangeLog: > > > > * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be > > available to all sub-targets. > > * config/i

[PATCH] i386, testsuite: adjust asm patterns

The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is partly because symbols are prefixed with underscore, and also because the order of operands in the addition is reversed (but I think it’s valid still). The code generated is this: _func: LFB0: pushq %rbp LCFI0:

Re: [PATCH 2/2] c++/modules: ICE with modular fmtlib

On Sat, 10 Feb 2024, Jason Merrill wrote: > On 2/9/24 17:11, Patrick Palka wrote: > > On Fri, 9 Feb 2024, Patrick Palka wrote: > > > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > > > OK for trunk? > > > > > > I'll try to reduce and add testcases overnight for these sepa

[PATCH] Add Myself to Write After Approval and DCO List

Hello, I have added myself to write after approval. Thanks, Alexander Westbrooks >From 564b307970d3be7a02e827420f0fad87bd335d9b Mon Sep 17 00:00:00 2001 From: Alexander Westbrooks Date: Sat, 10 Feb 2024 12:20:00 -0600 Subject: [PATCH] Add Myself to Write After Approval and DCO List ChangeLog:

[PATCH] c++: SFINAE-unfriendly error on throwing pointer [PR112436]

Probably stage1 material but it should be safe... Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- On the heels of r14-8903, this patch adds further complain parameters so that we don't emit "invalid use of incomplete type" from inside a concept. PR c++/112436 gcc/c

Re: [April 2022 PING] cpp: new built-in __EXP_COUNTER__

On 2023-08-28 10:09, Kaz Kylheku wrote: > On 2022-06-13 16:13, Kaz Kylheku wrote: >> Pinging this item: >> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593473.html >> >> Thanks. Again.

Re: [PATCH] rtl-optimization/113597 - recover base term for argument pointers

I managed to try this patch on aarch64-linux-gnu: This is the test run without your patch: https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807637.html And this is the "result" with your patch: https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807645.html For me, as for y

Re: [PATCH] Revert "Pass GUILE down to subdirectories"

> "Andrew" == Andrew Burgess writes: Andrew> Tom Tromey writes: >> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f. >> >> This patch caused problems for some users when building gdb, because >> it would cause 'guild' to be invoked with the wrong versin of guile. >> On the whole

Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty

Hi! On Tue, 6 Feb 2024 at 06:37, Alexandre Oliva wrote: > > Hello, Christophe, > > Thanks for the patch. > > On Feb 5, 2024, Christophe Lyon wrote: > > > In order to save build time, our CI overrides BUILD_INFO="", which > > works when invoking 'make all' but not for 'make install' in case some

[PATCH] c++: ICE with reinterpret_cast and switch [PR113545]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- Jason, this is the patch you proposed for PR113545. It looks very safe so I'm posting it here so that it's not forgotten. PR c++/113545 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_switch_expr): If the conditio

[PATCH] c++: Support lambdas attached to FIELD_DECLs in modules [PR111710]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? Or should I re-introduce the tree checking and just add checks for the new kinds of declarations that could be have keyed decls? -- >8 -- The fix for PR107398 weakened the restrictions that lambdas must belong to namespace scope. H

[PATCH] Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268]

Hello, I have implemented a patch that fixes compile time errors for valid PDT type-bound procedures. I wrote 4 new tests that address the test-cases in PR 82943, PR 86148, and PR 86268, since the patch fixes all three of them. All regression tests pass, including the new ones. This was tested on

Re: [PATCH] coreutils-sum-pr108666.c: fix spurious LLP64 warnings

On 2/2/24 23:55, Jonathan Yong wrote: Attached patch OK? Fixes the following warnings: coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch]    17 | memcpy(void*

[PATCH 2/1] c++: Also support lambdas attached to TYPE_DECLs in modules

Bootstrapped and regtested (so far just modules.exp and dg.exp) on x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? (Also I noticed I forgot to add the PR to the changelog in my last patch, I've fixed that locally.) -- >8 -- After fixing PR111710, I noticed that we currently ICE when

Re: [PATCH 2/1] c++: Also support lambdas attached to TYPE_DECLs in modules

On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead wrote: > > Bootstrapped and regtested (so far just modules.exp and dg.exp) on > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? > > (Also I noticed I forgot to add the PR to the changelog in my last > patch, I've fixed that locally.) > >

Re: [PATCH 2/1] c++: Also support lambdas attached to TYPE_DECLs in modules

On Sat, Feb 10, 2024 at 08:01:46PM -0800, Andrew Pinski wrote: > On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead > wrote: > > > > Bootstrapped and regtested (so far just modules.exp and dg.exp) on > > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds? > > > > (Also I noticed I forgot to a

Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty

Hello, Christophe, On Feb 10, 2024, Christophe Lyon wrote: > gcc/ > * Makefile.in: Add no-info dependency. > * configure.ac: Set BUILD_INFO=no-info if makeinfo is not > available. > * configure: Regenerate. Thank you, this is ok. Now, this doesn't fix a regression