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

Re: [14.x PATCH] c: Allow bool and enum null pointer constants [PR112556]

On Wed, 14 May 2025, Sam James wrote: > > (cherry picked from commit 3d525fce70fa0ffa0b22af6e213643e1ceca5ab5) > > --- > > As discussed on the PR, I feel like this is worth having for 14 as we're > > asking upstreams to try reproduce issues w/ -std=gnu23 (or -std=c23) if > > they don't have access

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

On Wed, 14 May 2025, Yuao Ma wrote: > Hi all, > > This patch adds trigonometric pi-based functions as gcc builtins: acospi, > asinpi, atan2pi, > atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for > these functions, which we plan to leverage in future gfortran implementati

RE: [PATCH 2/4][c-frontend]: implement pragma unroll n for C [PR116140]

On Tue, 13 May 2025, Tamar Christina wrote: > > -Original Message- > > From: Joseph Myers > > Sent: Tuesday, May 13, 2025 12:35 PM > > To: Tamar Christina > > Cc: gcc-patches@gcc.gnu.org; nd > > Subject: Re: [PATCH 2/4][c-frontend]: implement

Re: [PATCH 2/4][c-frontend]: implement pragma unroll n for C [PR116140]

On Tue, 13 May 2025, Tamar Christina wrote: > To know whether this should be possible to do or not this proposes an > extension > to the pragma GCC unroll with an argument to indicate if we can override the > value or not. This patch is missing updates to the documentation for that pragma. --

Re: [PATCH v21 2/3] c: Add

On Mon, 12 May 2025, Alejandro Colomar wrote: > + if (strcmp (xstr(countof), "_Alignas") != 0) countof should definitely not expand to _Alignas! I don't recommend posting untested patches. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v20 2/4] c: Add _Countof operator

On Sun, 11 May 2025, Alejandro Colomar wrote: > +/* { dg-options "-Wno-declaration-after-statement -Wno-pedantic -Wno-vla" } > */ > +/* { dg-options "-Wno-pedantic -Wvla-parameter" } */ > +/* { dg-options "-Wno-declaration-after-statement -Wno-pedantic -Wno-vla" } > */ Most of these options a

Re: [PATCH v20 3/4] c: Add

On Sun, 11 May 2025, Alejandro Colomar wrote: > gcc/ChangeLog: > > * Makefile.in (USER_H): Add . > * ginclude/stdcountof.h: Add countof macro. This is missing tests for the header. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v20 0/4] c: Add _Countof and

On Sun, 11 May 2025, Alejandro Colomar wrote: > Hi, > > Here's the list of changes in v20: > > - Drop changes to support Cc tags in commit messages (but keep the >patch to add support for Link tags). That patch *does not belong in this series*. Keep the series to only those patches conce

Re: [PATCH v19 1/3] contrib/: Add support for Cc: and Link: tags

On Fri, 9 May 2025, Alejandro Colomar wrote: > Hi Joseph, > > On Fri, May 09, 2025 at 09:00:58PM +0000, Joseph Myers wrote: > > On Fri, 9 May 2025, Alejandro Colomar wrote: > > > > > contrib/ChangeLog: > > > > > > * gcc-changelog/git_commit.py

Re: [PATCH v19 1/3] contrib/: Add support for Cc: and Link: tags

On Fri, 9 May 2025, Alejandro Colomar wrote: > contrib/ChangeLog: > > * gcc-changelog/git_commit.py (GitCommit): > Add support for 'Cc: ' and 'Link: ' tags. Please remove this patch from this patch series; it has nothing to do with _Countof and would probably be reviewed by differen

Re: [PATCH v19 3/3] c: Add

On Fri, 9 May 2025, Alejandro Colomar wrote: > > This should define also > > __STDC_VERSION_STDCOUNTOF_H__ > > macro (guess to 202502L or when the paper has been approved for now > > or maybe 202500L as something clearly before that). > > Hmmm, I was wondering what value I should put there, and e

Re: Patch Submission: Optimize Size of true and false Macros in C

On Tue, 6 May 2025, SAKSHAM JOSHI wrote: > I am submitting a patch for the GCC compiler's "stdbool.h" to optimize the > size of the true and false macros in the C programming language. Currently, > the size of the true and false macros is 4 bytes, whereas the _Bool > datatype is 1 byte in size. Th

Re: [PATCH] c: Fix up RAW_DATA_CST handling in check_constexpr_init [PR120057]

On Fri, 2 May 2025, Jakub Jelinek wrote: > Hi! > > The pr120057-1.c testcase is incorrectly rejected since > r15-4377 (and for a while it also ICEd after the error), i.e. > the optimization of large C initializers using RAW_DATA_CST. > Similarly, the embed-18.c testcase is incorrectly rejected s

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 1/1] Fix BZ 119317: named loops (C2y) with debug info

On Tue, 29 Apr 2025, Christopher Bazley wrote: > 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.

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

On Sat, 26 Apr 2025, Florian Weimer wrote: > 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. > >

Re: [PATCH] c: fix checking for a tag for variably modified tagged types [PR119612]

On Sat, 5 Apr 2025, Martin Uecker wrote: > > > The checking assertion added for PR118765 > > https://gcc.gnu.org/cgit/gcc/commit/?id=accbc1b90bd942aa36ac1485a21056b774ce02df > > did indeed catch some case I hadn't considered. I think there > might be other cases in the C FE where we test for

Re: [PATCH] c++, libcpp: Allow some left shifts in the preprocessor [PR119391]

On Fri, 4 Apr 2025, Jason Merrill wrote: > Incidentally, does anyone know the status of the parallel WG14 proposal > (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm)? Signed integer types are two's complement in C23. That did not involve any changes to the rules on shifts; it was pu

Re: [PATCH] libcpp: Add missing configure check for setlocale.

On Wed, 26 Mar 2025, Roland McGrath wrote: > The libcpp code uses `#ifdef HAVE_SETLOCALE` but its configure doesn't > have the corresponding check. > > Ok for trunk and 14 branch? OK, but watch out for what look like spurious changes in the generated configure (maybe resulting from a patched au

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

On Wed, 26 Mar 2025, Yeoul Na wrote: > Hi all, > > Thanks for all the discussions. > > I posted the design rationale for our current approach in > https://discourse.llvm.org/t/rfc-forward-referencing-a-struct-member-within-bounds-annotations/85510. > > This clarifies some of the questions tha

Re: [PATCH v2] c: Fix tagname confusion for typedef redefinitions [PR118765]

On Wed, 26 Mar 2025, Martin Uecker wrote: > I looked at this again and do not need a workaround anymore. > > I did not implement any restrictions preventing typedef  > redeclarations from having different alignment, because > merge_decls does not include any such restrictions at this > time. I c

Re: [PATCH] Fix up some further cases of missing or extraneous spaces in diagnostics

On Sat, 22 Mar 2025, Jakub Jelinek wrote: > On Sat, Mar 22, 2025 at 08:18:27AM +0100, Andreas Schwab wrote: > > On Mär 22 2025, Jakub Jelinek wrote: > > > > > I think just the c.opt change needs an explanation, the "" in the > > > description is simply eaten up somewhere during the option process

Re: [PATCH] c: pedwarn on flexible array member initialization with {} for C23+ [PR119350]

On Wed, 19 Mar 2025, Jakub Jelinek wrote: > Hi! > > Even in C23/C2Y any initialization of flexible array member is still > invalid, so we should emit a pedwarn on it. But we no longer do for > initialization with {}. The reason is that for C17 and earlier, > we already emitted a pedwarn on the

Re: [PATCH] c: Fix handling of [[gnu::musttail] return in if and else bodies [PR119311]

On Tue, 18 Mar 2025, Jakub Jelinek wrote: > Hi! > > The following new testcase FAILs with C (and succeeds with C++). > c_parser_handle_musttail is used in c_parser_compound_statement_nostart > where it is directly passed to c_parser_statement_after_labels, and in > c_parser_all_labels where it is

Re: [PATCH] c, c++, v5: Support musttail attribute even using __attribute__ form [PR116545]

On Tue, 18 Mar 2025, Jakub Jelinek wrote: > On Mon, Mar 17, 2025 at 06:38:34PM +0100, Jakub Jelinek wrote: > > Anyway, below is a patch which accepts all kinds of > > ordering and mixing of standard and GNU attributes at the start of > > statements (for C++). > > Bootstraps/regtests (on x86_64-li

Re: [PATCH] c: Fix tagname confusion for typedef redefinitions [PR118765]

On Tue, 18 Mar 2025, Martin Uecker wrote: > > I think different alignment should be considered different types, so an > > error. > > We currently allow different alignment to be added in typedefs > as in the new typedef-redecl3.c test: I don't think we should. Typedef reclarations must have th

Re: [PATCH] c: Fix ICE in error recovery when checking struct compatibility [PR118061]

On Sun, 16 Mar 2025, Martin Uecker wrote: > > Here is a small patch fixing an error recovery issue. > > Bootstrapped and regression tested on x86_64. > > > commit 465773af2bdd552184b935e5dc6b3db9e0e4e327 > Author: Martin Uecker > Date: Sat Mar 1 17:21:25 2025 +0100 > > c: Fix ICE in er

Re: [PATCH] c: Fix tagname confusion for typedef redefinitions [PR118765]

On Sun, 16 Mar 2025, Martin Uecker wrote: > This is a workaround for another issue related to PR118765. > I do not yet understand what goes wrong in merge_decls in > this case (somehow we end up with TYPE_DECLS where > DECL_ORIGINAL_TYPE is not set correctly, so we can not > determine the correct

Re: [PATCH] c: Fix bug in typedef redefinitions of tagged types [PR118765]

On Sun, 16 Mar 2025, Martin Uecker wrote: > This is a partial fix for PR118765. > > > Bootstrapped and regression tested on x86_64. > > > commit 84ba284a14bb5249d923affbf3f0f95a993c3a29 > Author: Martin Uecker > Date: Sat Mar 1 21:32:21 2025 +0100 > > c: Fix bug in typedef redefinition

Re: [PATCH] c, c++: Support musttail attribute even using __attribute__ form [PR116545]

On Thu, 13 Mar 2025, Jason Merrill wrote: > > I'd be afraid that would be quite significant change of behavior everywhere, > > something that C doesn't allow (like mixing std and GNU attributes in any > > orders or [[]] __attribute__(()) [[]][[]] __attribute__(()) > > expression-statement). Or it

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

On Thu, 13 Mar 2025, JeanHeyd Meneide wrote: > On Thu, Mar 13, 2025 Qing Zhao wrote: > > > ... > > > > Is N3188 the following: > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3188.htm > > > > What’s the status of this proposal? > > > N3188 was discussed during the January 2024 Meeti

Re: [RFC] [C]New syntax for the argument of counted_by attribute for C language

On Wed, 12 Mar 2025, Martin Uecker wrote: > For a designator > > struct foo { int n; } a = { .n = 1 }; > > we also refer to a member 'n' of an instance 'a' of a structure type. > The instance is simply implied by the context. > > For > > struct foo { int n; char *x __counted_by(.n) }; > > is

Re: [TO-BE-COMMITED,PATCH] s390: Deprecate ESA/390 support

This commit has changed int __attribute__ ((__mode__ (__word__))) on s390 -m31 from int to long long. That introduces a glibc testsuite failure - the glibc testsuite verifies the expected C++ name mangling of various types, including register_t (which is defined with that attribute). https://s

  1   2   3   4   5   6   7   8   9   10   >