Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Mon, 11 Aug 2025, Bill Wendling wrote: > On Thu, Jul 31, 2025 at 12:01 PM Joseph Myers wrote: > > > > On Thu, 24 Jul 2025, Aaron Ballman wrote: > > > > > Question on the .N syntax: I thought I heard that this was something > > > GCC could handle, but

Re: [PATCH v9 3/4] Use the counted_by attribute of pointers in array bound checker.

On Fri, 1 Aug 2025, Qing Zhao wrote: > + /* For a poiner array address as: "poiner" should be "pointer". OK with that fix, in the absence of objections within the next week from other maintainers or reviewers. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] Get rid of `with_multisrctop`

On Thu, 7 Aug 2025, John Ericson wrote: > The VPATH workaround however is akin to: > > mkdir -p $build/mach0/mach1/libgcc > cd $build/mach0/mach1/libgcc > ln -s $gcc_source/libgcc/* ./ > ./configure > > and it's that --- using the build dir with the symlinked sources inside > as the src/obj dir

Re: [PATCH v9 4/4] Generate a call to a .ACCESS_WITH_SIZE for a FAM with counted_by attribute only when it's read from.

On Fri, 1 Aug 2025, Qing Zhao wrote: > Currently, we generate a call to a .ACCESS_WITH_SIZE for a FAM with counted_by > attribute for every component_ref that corresponds to such an object. > Actually, such .ACCESS_WITH_SIZE calls are useless when they are generated > for a written site or an addr

Re: [PATCH v9 1/4] Extend "counted_by" attribute to pointer fields of structures.

On Fri, 1 Aug 2025, Qing Zhao wrote: > gcc/c-family/ChangeLog: > > * c-attribs.cc (handle_counted_by_attribute): Accept counted_by > attribute for pointer fields. > > gcc/c/ChangeLog: > > * c-decl.cc (verify_counted_by_attribute): Change the 2nd argument > to a vector of

Re: [PATCH v7 0/6] c, dwarf, btf: Add btf_decl_tag and btf_type_tag C attributes

On Thu, 7 Aug 2025, David Faust wrote: > Changes from v6: > - Patch 1: Check for and reject wide string arguments in the attribute >handlers. Factor common argument checking shared by both attribute >handlers to a small helper. I think there should be testcases for this error (with L",

Re: [PATCH] Get rid of `with_multisrctop`

On Thu, 7 Aug 2025, John Ericson wrote: > I think upon further reflection, I have a slightly different read of > what's going on. > > See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html / > https://www.airs.com/ian/configure/configure_8.html (rendering of > since-deleted from the

Re: [PATCH v6 0/6] c, dwarf, btf: Add btf_decl_tag and btf_type_tag C attributes

On Wed, 6 Aug 2025, David Faust wrote: > So IMO the best option will be to reject wide strings in the attribute > handler. (The alternative, I guess, is to ensure the argument is > always exported to UTF-8 before being written (?)) > > I see that we can get the character size from the TREE_TYPE

Re: [PATCH] c++, c, v3: Introduce -Wkeyword-macro warning/pedwarn - part of C++26 P2843R3 [PR120778]

On Wed, 6 Aug 2025, Jakub Jelinek wrote: > On Tue, Aug 05, 2025 at 03:52:12PM -0700, Jason Merrill wrote: > > Hmm, the names in "Table 4" > > https://eel.is/c++draft/lex.name#tab:lex.name.special are also > > context-sensitive. I agree with ignoring the ObjC keywords because they > > aren't part

Re: [PATCH] Get rid of `with_multisrctop`

On Wed, 6 Aug 2025, John Ericson wrote: > I can't quite tell, but I have a nagging suspicion that this is unused. > It would be nice to simplify some of the multilib stuff, and the > complexity around source directory (rather than build directory) > handling seems like it ought not to be so necess

Re: [PATCH] Use regular libdir/includedir in libgcc Makefiles

On Tue, 5 Aug 2025, John Ericson wrote: > > That's unavoidable to some extent, given that the GCC libraries have > > additional concepts for installation directories (such as a directory for > > shared libgcc used at runtime separate from directories used at compile > > time). > > What's the r

Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions

On Tue, 5 Aug 2025, Yuao Ma wrote: > On 8/5/2025 4:05 AM, Joseph Myers wrote: > > On Sun, 3 Aug 2025, Yuao Ma wrote: > > > > > By the way, could you please take another look at the libquadmath update? > > > > > > https://inbox.sourceware.org/for

Re: [PATCH 0/4] implement defer statements as per ts 25755

On Mon, 4 Aug 2025, Anna (navi) Figueiredo Gomes wrote: > On Mon Aug 4, 2025 at 9:49 PM CEST, Joseph Myers wrote: > > On Sun, 3 Aug 2025, Anna (navi) Figueiredo Gomes wrote: > > > >> based on n3589[1], this feature mostly makes use of already-established > >> l

Re: [PATCH v6 0/6] c, dwarf, btf: Add btf_decl_tag and btf_type_tag C attributes

On Mon, 4 Aug 2025, David Faust wrote: > Hi Joseph, > > Could you please take a look at the front-end portion of this > series when you have a moment? > > New attributes/handlers - Patch 1: > https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690142.html It looks like the front-end code wou

Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions

On Sun, 3 Aug 2025, Yuao Ma wrote: > By the way, could you please take another look at the libquadmath update? > > https://inbox.sourceware.org/fortran/kl1pr0601mb4291e1457dc09fe3aa6652c884...@kl1pr0601mb4291.apcprd06.prod.outlook.com/ > > This update uses a script to transform glibc's implement

Re: [PATCH] Use regular libdir/includedir in libgcc Makefiles

On Sun, 3 Aug 2025, John Ericson wrote: > > and "get those settings passed down from top level" is one plausible > > end state - sharing logic implicitly that way rather than expanding it > > all locally in each target library configure script, even if expanding > > it locally for each library

Re: [PATCH 0/4] implement defer statements as per ts 25755

On Sun, 3 Aug 2025, Anna (navi) Figueiredo Gomes wrote: > based on n3589[1], this feature mostly makes use of already-established > logic, namely push_cleanup used by the cleanup attribute, and the > constraints put in place for checking local jumps against statement > expressions > > 1: https://

Re: [C PATCH] Evaluate size expression only in the active branch of conditional operator [PR108931]

On Sat, 2 Aug 2025, Martin Uecker wrote: > In preparation N3652, this removes some UB from the conditional > operator when forming a composite type. This is an improvement > also for earlier language modes (previously I submitted PR108931 > for this). > > Bootstrapped and regression tested on x8

Re: [PATCH] [hardbool] implement OP=, ++ and --, volatile and atomics

On Thu, 24 Jul 2025, Alexandre Oliva wrote: > hardbools didn't behave quite like bools when incremented, > decremented, or otherwise modified using their previous value, as in > += et al. Fix that. > > Also fix some checking errors that come up when using qualified base > types. > > Regstrapped

Re: [C PATCH] c: rewrite implementation of `arg spec' attribute.

On Sun, 27 Jul 2025, Martin Uecker wrote: > gcc/c/ChangeLog: > * c/c-decl.cc (get_parm_array_spec): Remove. > (push_parm_decl): Do not add `arg spec` attribute. > (build_arg_spec_attribute): New function. > (grokdeklarator): Add `arg spec` attrib

Re: [PATCH] Use regular libdir/includedir in libgcc Makefiles

On Thu, 17 Jul 2025, John Ericson wrote: > This current patch doesn't go as far as removing all such subdir logic > from the libgcc build --- rather, as an intermediate goal, it moves it > out of the Makefiles and into the configure script. That is to say, in > the makefiles there is no longer any

Re: [PATCH v4] Factor out thread model detection with new `GCC_AC_THREAD_MODEL` macro

On Wed, 30 Jul 2025, John Ericson wrote: > This macro deduplicates the > > $CC -v 2>&1 | sed -n 's/^Thread model: //p' > > check that was occurring in various runtime libs. > > Additionally, as a bit of an Easter egg, this also allows overriding > what the compiler would return by setting t

Re: [PATCH v4] Move NO_PIE_CFLAGS logic from gcc to libgcc

On Wed, 30 Jul 2025, John Ericson wrote: > My goal is to be able to build libgcc cleanly in isolation --- today one > needs to figure `make ...` misc things in the gcc subdir. > > Following Andrew Pinski's suggestions in > https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this > co

Re: [C PATCH] Fix ICE on invalid code involving bit fields [PR121217]

On Tue, 29 Jul 2025, Martin Uecker wrote: > Fixes an ICE on invalid code (15/16 regression). > > Bootstrapped and regression tested on x86_64. > > > c: Fix ICE on invalid code involving bit fields [PR121217] > > Under some error condition we can end up with NULL_TREEs for > the

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Thu, 24 Jul 2025, Aaron Ballman wrote: > Question on the .N syntax: I thought I heard that this was something > GCC could handle, but that it still requires late parsing to ensure > type information for N is available and that was a problem. e.g., > > void func(char *buffer __counted_by(.N * s

Re: [PATCH v2 01/18] Multilib changes

On Wed, 23 Jul 2025, Aleksandar Rakic wrote: > Public > > Hi, > > > So I'm not at all concerned about the mips specific bits of this patch. > > After all, they only affect mips ports and the changes seem sensible. > > They would need a ChangeLog entry to go forward through. > > > What is concer

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

On Thu, 17 Jul 2025, Simon Marchi wrote: > On 6/26/25 12:14 PM, Simon Marchi wrote: > > I keep hitting the bug fixed by this patch with gcc 15.1: > > > > make[3]: Entering directory > > '/home/simark/build/binutils-gdb-all-targets/sim' > > CC bfin/gui.o > > In file included from /usr/inc

Re: [PATCH v3 2/2] libgcc: Dont use TARGET_SYSTEM_ROOT from gcc

On Wed, 16 Jul 2025, John Ericson wrote: > From: John Ericson > > Following Andrew Pinski's suggestions in > https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just > use the output of: > >$(CC) -print-sysroot > > It is just used in one spot, in an AIX code-path. I just made

Re: [PATCH v3 1/2] Move NO_PIE_CFLAGS logic from gcc to libgcc

On Wed, 16 Jul 2025, John Ericson wrote: > gcc/ChangeLog: > > * Makefile.in:: Remove NO_PIE_CFLAGS logic, since it is now in > libgcc. > * configure.ac: Remove the enable_default_pie substitution, since > libgcc now has its own logic. > > libgcc/ChangeLog: > > * Ma

Re: [PATCH v3] Factor out thread model detection with new `GCC_AC_THREAD_MODEL` macro

On Wed, 16 Jul 2025, John Ericson wrote: > config/ChangeLog: > > * gthr.m4: Create new GCC_AC_THREAD_MODEL macro > > libatomic/ChangeLog: > > * configure.ac: Use GCC_AC_THREAD_MODEL instead of hand-rolled > > libgcc/ChangeLog: > > * configure.ac: Use GCC_AC_THREAD_MODEL inst

Re: [PING*4][PATCH 1/1] config: Handle dash in library name for AC_LIB_LINKAGEFLAGS_BODY

On Tue, 15 Jul 2025, Ijaz, Abdul B wrote: > config/ChangeLog: > > * lib-link.m4: Handle dash in the library name for > AC_LIB_LINKFLAGS_BODY. OK. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions

On Sun, 6 Jul 2025, Yuao Ma wrote: > +#ifndef HAVE_COSPI > +#define HAVE_COSPI 1 > +double cospi (double); > + > +double > +cospi (double x) > +{ > + return cos (x * pihi_d + x * pilo_d); For reasonable results for large x you should first reduce mod 2 to the range [-1, 1] (or reduce mod 1 and

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, 23 Jul 2025, Martin Uecker wrote: > IMHO there are enough reasons to reject delayed parsing > as bad design for C. We should work towards proper > language features that cleanly fit into the language, > instead of pushing the boundaries with macros. At the last WG14 meeting it was said t

Re: [PATCH] libquadmath: add quad support for trig-pi functions

On Thu, 3 Jul 2025, Michael Matz wrote: > Yes. And then the above is multiplied by PI, passed to cos/sin and that > one then tries to figure out the multiple of PI (i.e. the 'x' above) again > via range reduction (not a _terribly_ slow one anymore in a good > implementation, because of the lim

Re: [PATCH] libquadmath: add quad support for trig-pi functions

On Thu, 3 Jul 2025, Jakub Jelinek wrote: > > Isn't the whole raison d'etre for the trig-pi functions that the internal > > argument reduction against multiples of pi becomes trivial and hence (a) > > performant, and (b) doesn't introduce rounding artifacts? Expressing the > > trig-pi functions

Re: [PATCH RFC] libgcc: don't use a weak ref for __cxa_finalize

On Sat, 28 Jun 2025, Jason Merrill wrote: > + if (!flag_use_cxa_atexit != !DEFAULT_USE_CXA_ATEXIT) > +{ > + const char *opt, *copt; > + if (flag_use_cxa_atexit) > + opt = "-fuse-cxa-atexit", copt = "--enable-__cxa_atexit"; > + else > + opt = "-fno-use-cxa-atexit", copt

Re: [PATCH][RFC] c/96570 - diagnostics for conversions to/from time_t

On Fri, 27 Jun 2025, Richard Biener wrote: > > I think such a warning should be based on an attribute on the time_t type > > that means "warn for implicit truncation of this type" (I'm less clear on > > why warnings for implicit widening conversions *to* time_t are supposed to > > be useful), r

Re: [PATCH][RFC] c/96570 - diagnostics for conversions to/from time_t

On Thu, 26 Jun 2025, Richard Biener wrote: > The following prototypes diagnostics for conversions to/from time_t > where the source/destination does not have sufficient precision for it. > I've lumped this into -Wconversion for the moment and didn't bother > fixing up the testcase for !ilp32 or th

Re: [wwwdocs] Add C2y status table

On Mon, 23 Jun 2025, Marek Polacek wrote: > Thanks for the review. Ok? OK. -- Joseph S. Myers josmy...@redhat.com

Re: C++ patch ping

On Mon, 23 Jun 2025, Jakub Jelinek wrote: > Hi! > > I'd like to ping some C family patches: > > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681741.html > - PR44677 - c, c++: Extend -Wunused-but-set-* warnings > > https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685543.html > - P

Re: [wwwdocs v2] Add C23 status table

On Fri, 13 Jun 2025, Marek Polacek wrote: > doesn't need any changes, I think. Another is "modified existing functions > to preserve the const-ness of the type placed into the function", I don't > what this is talking about. It's a duplicate of the entry "added qualifier preserving macros for b

Re: [PATCH 2/2] Fix non-std float suffices [PR92826]

On Wed, 18 Jun 2025, Gábor Németh wrote: > > If normal user code that includes gets this warning (built with > > an installed compiler), that needs fixing in some way. If not, what is > > different about how GCC uses its own libstdc++? (For example, it's > > important to include system headers

Re: [PATCH v5 3/3][C sanitizer] Use the counted_by attribute of pointers in array bound checker.

On Mon, 16 Jun 2025, Qing Zhao wrote: > Current array bound checker only instruments ARRAY_REF, and the INDEX > information is the 2nd operand of the ARRAY_REF. > > When extending the array bound checker to pointer references with > counted_by attributes, the hardest part is to get the INDEX of t

Re: [PATCH v5 1/3][C FE] Extend "counted_by" attribute to pointer fields of structures.

On Mon, 16 Jun 2025, Qing Zhao wrote: > +The counted_by attribute is not allowed for a pointer to @code{void}, @code{counted_by}. This patch is OK with that fix once the rest of this series is approved. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] Add string_slice class.

On Wed, 18 Jun 2025, Alfie Richards wrote: > gcc/c-family/ChangeLog: > > * c-format.cc (local_string_slice_node): New node type. > (asm_fprintf_char_table): New entry. > (init_dynamic_diag_info): Add support for string_slice. > * c-format.h (T_STRING_SLICE): New node type.

Re: [PATCH] configury: replace autoconf obsolete macros [PR/103459]

On Fri, 13 Jun 2025, Pietro Monteiro wrote: > > Adding this \ at end of file looks suspect. > > > > OK with that ChangeLog entry fixed and the stray \ at end of file removed > > (assuming the same output files are still generated after that change). > > I applied the patch on top of trunk (), re

Re: [PATCH] configury: replace autoconf obsolete macros [PR/103459]

On Wed, 21 May 2025, Pietro Monteiro wrote: > lto-plugin/ChangeLog: > > * configure: Regenerate. > * configure.ac: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_SYSTEM. That ChangeLog entry is clearly incorrect. > diff --git a/config/asmcfi.m4 b/config/asmcfi.m4 > index a725aa11de4.

Re: [PATCH 2/2] Fix non-std float suffices [PR92826]

On Fri, 13 Jun 2025, Gábor Németh wrote: > > > A new option is added to warn if floating point literals have non-standard > > > suffices (currently Q and W) in pedantic mode. The option is ON by > > > default. > > > > I don't think we should turn this off when building GCC itself (as opposed > >

Re: [PATCH] driver: Try to read spec from gcc_exec_prefix if possible

On Tue, 10 Jun 2025, Kito Cheng wrote: > GCC will try to read the spec file from the directory where it is > installed, but it should try to read from gcc_exec_prefix rather than > standard_exec_prefix, because the latter is not the right one if > compiler has been relocated into other places othe

Re: [wwwdocs] Add C2y status table

On Thu, 12 Jun 2025, Marek Polacek wrote: > + > + > +Support ++ and -- on complex values > + href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3259.pdf";>N3259 > +15 > + > + This should be when the feature was supported (either GCC 2.5 when complex types were introd

Re: [PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

On Thu, 12 Jun 2025, Qing Zhao wrote: > > In general I think we'd only expect an error if the information required > > to give it is visible at the point where the counted_by attribute is used. > > There might be a possibility of giving an error for this case when the > > pointer gets derefere

Re: [wwwdocs] Add C23 status table

On Wed, 11 Jun 2025, Marek Polacek wrote: > This patch adds the C23 Support in GCC table (compiler features only). > > While creating it, I've consulted Annex M.2, our own changes.html, > Joseph's "ISO C23 support in the GNU Toolchain" Cauldron presentation, > https://en.cppreference.com/w/c/comp

Re: [PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

On Wed, 11 Jun 2025, Qing Zhao wrote: > Then how about the following case: > > typedef struct item3 Item3; > struct pointer_array_9 { > > int count3; > Item3 *array_3 __attribute__ ((counted_by (count3))); > } > > struct item3 { > int a; > float b[]; > } > > In the above, the “Item3”

Re: [PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

On Wed, 11 Jun 2025, Qing Zhao wrote: > When I was adding more testing cases for the pointee type being > structure/union, I have a question for the following case: > > struct item5 { > int a; > float b[]; > }; > > struct pointer_array_9 { >... > int count5; > struct item5 *array_5

Re: [PATCH v2] c: remaining fix for the composite type inconsistency [PR120510]

On Wed, 11 Jun 2025, Uecker, Martin wrote: > c: remaining fix for the composite type inconsistency [PR120510] > > There is an old GNU extension which allows overriding the > promoted old-style arguments when there is an earlier prototype > An example (from a test added for PR1

Re: [PATCH] c: remaining fix for the composite type inconsistency [PR120510]

On Tue, 10 Jun 2025, Martin Uecker wrote: > Here I simply override the type with the one with the prototype. > This is not a perfect replacement for forming the composite type, > but I assume this does not matter for any existing code. But if > you think it is better to keep forming the composite

Re: c: clean up some functions in c-typeck.cc

On Tue, 10 Jun 2025, Martin Uecker wrote: > When looking for the casue of PR120510 I noticed there > is some minor issues that make the code harder to understand > which are left over from previous changes. > > Bootstrapped and regression tested for x86_64. > > > c: clean up some functions

Re: [PATCH] c: fix ICE for invalid code in generic selection [PR120303]

On Tue, 10 Jun 2025, Martin Uecker wrote: > Small fix. > > Bootstrapped and regression tested for x86_64. > > Martin > > c: fix ICE for invalid code in generic selection [PR120303] > > Fix an error recovery ICE that occurs when a type name > can not be parsed correctly in the c

Re: [PATCH v4 1/3][C FE]Extend "counted_by" attribute to pointer fields of structures.

On Tue, 13 May 2025, Qing Zhao wrote: > + /* This attribute cannot be applied to a pointer type whose pointee type > + is void. */ > + else if (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE > +&& TREE_CODE (TREE_TYPE (TREE_TYPE (decl))) == VOID_TYPE) > +{ > + error_at (DECL_

Re: [wwwdocs] Add C status page (C11 table)

On Tue, 10 Jun 2025, Marek Polacek wrote: > + > +Anonymous structures and unions > + href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1406.pdf";>N1406 > +4.6 > + > + 4.6 is probably a reasonable version to list here given that a significant piece (support for designato

Re: [PATCH 2/2] Fix non-std float suffices [PR92826]

On Tue, 10 Jun 2025, Gábor Németh wrote: > A new option is added to warn if floating point literals have non-standard > suffices (currently Q and W) in pedantic mode. The option is ON by default. > The negative form `-Wno-non-standard-suffix` is expected to be used typically, > as is done for GCC

Re: [PATCH 1/2] Fix non-std float suffices [PR92826]

On Tue, 10 Jun 2025, Gábor Németh wrote: > diff --git a/gcc/testsuite/c-c++-common/pr92826.c > b/gcc/testsuite/c-c++-common/pr92826.c > new file mode 100644 > index 000..ea2e20c6331 > --- /dev/null > +++ b/gcc/testsuite/c-c++-common/pr92826.c > @@ -0,0 +1,6 @@ > +/* { dg-options "-pedanti

Re: [wwwdocs] Add C status page (check, small tweaks)

On Mon, 9 Jun 2025, Marek Polacek wrote: > I've checked our C99 status table against the list in Annex M.5 in C23 > (n3220). > I found no issues. For this it probably makes sense to refer to the latest C2y draft, but there shouldn't be any significant changes to the pre-C23 lists there. (C2y

Re: [PATCH] c, c++: Save 8 bytes of memory in lang_type for non-ObjC*

On Mon, 9 Jun 2025, Jakub Jelinek wrote: > Hi! > > For C++26 P2786R13 I'm afraid I'll need 4 new flags on class types > in struct lang_type (1 bit for trivially_relocatable_if_eligible, > 1 for replaceable_if_eligible, 1 for not_trivially_relocatable and > 1 for not_replaceable) and there are jus

Re: [PATCH 3/3] c: Add remove_qualifier helper function [PR120510]

On Sat, 7 Jun 2025, Martin Uecker wrote: > Add a helper function to replace repeated code for removing > qualifiers but not atomic. Make sure to also remove qualifiers > but not atomic on the element type of arrays. > > PR c/120510 > > gcc/c/ChangeLog: > * c-typeck.c (remove_qualifi

Re: [PATCH 2/3] c: partial fix for qualifier inconsistency II [PR120510]

On Sat, 7 Jun 2025, Martin Uecker wrote: > This fixes a case where we invoke composite_type with types > that do not have matching qualifiers. With this change, we can > activate the checking assertion that makes sure the composite > type is compatible with the two original types also for arrays.

Re: [PATCH 1/3] c: partial fix for qualifier inconsistency [PR120510]

On Sat, 7 Jun 2025, Martin Uecker wrote: > Checking assertion revealed that we sometimes produce > composite types with incorrect qualifiers, e.g. the example > > int f(int [_Atomic]); > int f(int [_Atomic]); > int f(int [_Atomic]); > > was rejected because atomic was lost in the second declarat

Re: [wwwdocs] Add C status page (rename c99status.html)

On Thu, 5 Jun 2025, Marek Polacek wrote: > On Thu, Jun 05, 2025 at 08:46:25PM +0000, Joseph Myers wrote: > > On Thu, 5 Jun 2025, Marek Polacek wrote: > > > > > Also adjust redirects. > > > > I don't see the .htaccess updates here, the existing redirects

Re: [wwwdocs] Add C status page (rename c99status.html)

On Thu, 5 Jun 2025, Marek Polacek wrote: > Also adjust redirects. I don't see the .htaccess updates here, the existing redirects should be updated and a new one for /c99status.html added. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] doc: update links to c99status.html

On Thu, 5 Jun 2025, Marek Polacek wrote: > Once we rename and move c99status.html, we also have to > update the links in the manual. > > -- >8 -- > gcc/ChangeLog: > > * doc/invoke.texi: Update a link to c99status.html. > * doc/standards.texi: Likewise. OK. -- Joseph S. Myers josmy

Re: [wwwdocs] Add C status page (rename c99status.html)

On Thu, 5 Jun 2025, Marek Polacek wrote: > Coming back to a project I first attempted here: > > but this time following steps as outlined by Joseph here: > . > > This patch

Re: [PATCH] Move get_call_rtx_from to final.c

On Mon, 2 Jun 2025, Jeff Law wrote: > On 6/1/25 1:12 AM, H.J. Lu wrote: > > Move get_call_rtx_from to final.c and call call_from_call_insn. > > > > PR other/120493 > > * final.cc (call_from_call_insn): Change the argument type to > > const rtx_call_insn *. > > (get_call_rtx_from): New. > > * rtl.

Re: [PATCH] opt: Detect the wrong case of flags option

On Tue, 3 Jun 2025, Andrew Pinski wrote: > This is just a simple check to see if the flags like LangEnabledBy > have the correct case. By putting everything into upper case and > seeing if there is a match (if previously there was not a match). > This would have caught PR 120078 much earlier. > Te

Re: [PATCH] c: Enable -Wjump-misses-init for -Wc++-compat

On Tue, 3 Jun 2025, Martin Uecker wrote: > This version only contains the fix for -Wc++-compat. > > Bootstrapped and regression tested for x86_64. > > Martin > > > c: Enable -Wjump-misses-init for -Wc++-compat > > Fix a typo that prevented the warning from being activated with >

Re: [PATCH] c: Enable -Wjump-misses-init in -Wextra and -Wc++-compat [PR87038]

On Mon, 2 Jun 2025, Martin Uecker wrote: > Am Montag, dem 02.06.2025 um 18:45 + schrieb Joseph Myers: > > On Mon, 2 Jun 2025, Martin Uecker wrote: > > > > > According to the discussion in the bugzilla there seems to be > > > some consensus to activate t

Re: [PATCH] c: fix ICE with enum completed with packed attribute after forward decl [PR116892]

On Mon, 2 Jun 2025, Martin Uecker wrote: > I *believe* TYPE_PACKED should be propagated to existing main > variants. > > > Bootstrapped and regression tested for x86_64. > > Martin > > > c: fix ICE with enum completed with packed attribute after forward decl > [PR116892] > > Aft

Re: [PATCH] c: Enable -Wjump-misses-init in -Wextra and -Wc++-compat [PR87038]

On Mon, 2 Jun 2025, Martin Uecker wrote: > According to the discussion in the bugzilla there seems to be > some consensus to activate the warning for -Wextra (I am also > looking into implementing the suggested improvements that may > make it suitable fo r-Wall). When making this change, I also

Re: [PING * 3][PATCH v3] Add new warning Wmissing-designated-initializers [PR39589]

On Sun, 1 Jun 2025, Peter Frost wrote: > Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html This needs various coding style fixes. Lines should be broken before binary operators such as && or || rather than after, and there should be a space before '(' in function and macr

Re: [PATCH] c: Move checking assertions from recursion when forming composite types to avoid ICE.

On Sun, 1 Jun 2025, Martin Uecker wrote: > This patch now moves the checking assertion out of the recursion, > which seems better anyhow. I could not do the check unconditionally > for all types. because we sometimes call composite_type for with > mismatching qualifiers. Calling composite_type wi

Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

On Sun, 1 Jun 2025, Yuao Ma wrote: > For MPFR versions older than 4.2.0, we've included our own folding functions. I think the normal practice in GCC would be to avoid the optimizations when the MPFR support is absent, instead of working around the absence with possibly less accurate implementa

[committed] c: Update description of C library facilities provided by GCC for C23

The documentation of which standard C library facilities (headers) are provided by GCC, as being those required of freestanding implementations, is reasonably accurate for C99 and before (if you ignore the provision of for non-GNU targets). It's less accurate for C11, since we provide although t

Re: [PATCH] C: Flex array in union followed by a structure field is not reported [PR120354]

On Fri, 30 May 2025, Qing Zhao wrote: > Thanks. > Pushed to trunk. > And will pushed to GCC14 after 2-3 weeks. Is that okay? As with the other patch, subject to applying to GCC 15 before GCC 14 (and testing on each release branch before applying it there), yes unless other release managers exp

Re: [PATCH] C: Flex array in the middle via type alias is not reported [PR120353]

On Fri, 30 May 2025, Qing Zhao wrote: > Thanks. > Pushed to trunk. > And will pushed to GCC14 after 2-3 weeks. Is that okay? Subject to applying to GCC 15 before GCC 14 (and testing on each release branch before applying it there), yes unless other release managers express concerns. (There is

Re: [PATCH v2] c: fix ICE related to tagged types with attributes in diagnostics [PR120380]

On Fri, 30 May 2025, Martin Uecker wrote: > c: fix ICE related to tagged types with attributes in diagnostics > [PR120380] > > get_aka_type will create a new type for diagnostics, but for tagged types > attributes will then be ignored with a warning. This can lead to > reenteri

Re: [PATCH] C: Flex array in union followed by a structure field is not reported [PR120354]

On Fri, 30 May 2025, Qing Zhao wrote: > There is only one last_field for a structure type, but there might > be multiple last_fields for a union type, therefore we should ORed > the result of TYPE_INCLUDES_FLEXARRAY for multiple last_fields of > a union type. > > The patch has been bootstrapped a

Re: [PATCH] C: Flex array in the middle via type alias is not reported [PR120353]

On Thu, 29 May 2025, Qing Zhao wrote: > The root cause of the bug is: the TYPE_INCLUDES_FLEXARRAY marking of the > structure type is not copied to its aliased type. > The fix is to copy this marking to all the variant types of the current > structure type. > > The patch has been bootstrapped and

Re: [PATCH] c: fix ICE related to tagged types with attributes in diagnostics [PR120380]

On Thu, 29 May 2025, Martin Uecker wrote: > get_aka_type will create a new type for diagnostics, but for tagged types > attributes will then be ignored with a warning. This can lead to > reentering > warning code which leads to an ICE. Fix this by ignoring the attributes > for t

Re: [PATCH] c: fix ICE for mutually recursive structures [PR120381]

On Thu, 29 May 2025, Martin Uecker wrote: > > This is a fun one.  > > Bootstrapped and regression tested for x86_64. > > Martin > > > c: fix ICE for mutually recursive structures [PR120381] > > For invalid nesting of a structure definition in a definition > of itself or when

Re: [PATCH] libgcc: Add DPD support + fix big-endian support of _BitInt <-> dfp conversions

On Tue, 20 May 2025, Jakub Jelinek wrote: > Tested on x86_64-linux, i686-linux and s390x-linux with > make check-gcc dfp.exp > ok for trunk? OK. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] doc: Correct the return type of float comparison

On Fri, 23 May 2025, Trevor Gross wrote: > +Comparison functions return a CMPtype which is a signed integer of > +target-depdent size. Typically CMPtype will be word-sized, but other > backends > +may override this with the TARGET_LIBGCC_CMP_RETURN_MODE hook. Of note, > +AArch64 uses an single-

Re: [PATCH v25 0/3] c: Add _Countof and

Thanks, I've committed these patches, with additional commit message changes to reference PR117025 in the standard way for GCC so that Bugzilla picks up the commits automatically. -- Joseph S. Myers josmy...@redhat.com

[committed] c: Document C23 implementation-defined behavior

Add references to C23 subclauses to the documentation of implementation-defined behavior, and new entries for implementation-defined behavior new in C23; change some references in the text to e.g. "C99 and C11" to encompass C23 as well. Tested with "make info html pdf". * doc/implement-c.

Re: [PATCH v23 1/3] c: Add _Countof operator

On Wed, 21 May 2025, Alejandro Colomar wrote: > Makes sense. I'm unsure where exactly I should put it. Is this okay? > > diff --git i/gcc/c/c-parser.cc w/gcc/c/c-parser.cc > index 87700339394b..08350a216dd8 100644 > --- i/gcc/c/c-parser.cc > +++ w/gcc/c/c-parser.cc >

Re: [PATCH v23 1/3] c: Add _Countof operator

On Wed, 21 May 2025, Alejandro Colomar wrote: > @@ -10572,6 +10583,8 @@ c_parser_unary_expression (c_parser *parser) > case CPP_KEYWORD: >switch (c_parser_peek_token (parser)->keyword) > { > + case RID_COUNTOF: > + return c_parser_countof_expression (parser); > c

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

On Wed, 21 May 2025, Christopher Bazley wrote: > Would you agree this is adequate? If anyone wants different source code > locations to be highlighted then a future commit could change that. In this case the locations seem reasonable. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v2 1/1] Add warnings of potentially-uninitialized padding bits

On Tue, 20 May 2025, Christopher Bazley wrote: > + if (!cleared) > + { > + if (complete_p.padded_non_union > + && warn_zero_init_padding_bits >= ZERO_INIT_PADDING_BITS_ALL) > + { > + warning (OPT_Wzero_init_padding_bits_, > +

Re: [PATCH v22 0/3] c: Add _Countof and

On Tue, 20 May 2025, Alejandro Colomar wrote: > Could you please clarify if I need to do anything or if this is already > scheduled for review when you have some time? Also please clarify if > you're okay with amending that or if you prefer that I send v23. I have it on my list for review. I'd

Re: [PATCH v22 0/3] c: Add _Countof and

On Fri, 16 May 2025, Alejandro Colomar wrote: > Hmmm, I've been trying to find a compromise between readability and > simplicity, and I think I have something. I've seen some tests that > define assert() themselves. I like assert(3) because it's more > readable compared to a conditional plus abo

Re: [PATCH v22 0/3] c: Add _Countof and

On Fri, 16 May 2025, Alejandro Colomar wrote: > - Add (and NDEBUG) to some test files that were missing it, >and also the forward declaration of strcmp(3). Depending on libc headers like this in tests is discouraged. The usual idiom is to use abort () on failure of a runtime check (rather

Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins

On Wed, 14 May 2025, Yuao Ma wrote: > Hi Joseph, > > I have updated the patch based on your review comments. I added the > newly introduced builtin to extend.texi and mentioned the PR in the > commit message. Could you please take another look when you have a > moment? This version is OK in t

  1   2   3   4   5   6   7   8   9   10   >