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

Re: [PATCH] c: Don't emit -Wunterminated-string-initialization warning for multi-dimensional nonstring array initializers [PR117178]

On Tue, 11 Mar 2025, Jakub Jelinek wrote: > Hi! > > My/Kees' earlier patches adjusted -Wunterminated-string-initialization > warning so that it doesn't warn about initializers of nonstring decls > and that nonstring attribute is allowed on multi-dimensional arrays. > Unfortunately as this testcas

Re: [PATCH] c-family, tree: Allow nonstring attribute on multidimensional arrays [PR117178]

On Fri, 14 Feb 2025, Jakub Jelinek wrote: > --- gcc/testsuite/c-c++-common/attr-nonstring-9.c.jj 2025-02-13 > 16:32:38.375848629 +0100 > +++ gcc/testsuite/c-c++-common/attr-nonstring-9.c 2025-02-14 > 10:58:08.557320758 +0100 > @@ -0,0 +1,51 @@ > +/* Test to exercise attribute "nonstring" sy

Re: [PATCH] c, v2: do not warn about truncating NUL char when initializing nonstring arrays [PR117178]

On Thu, 13 Feb 2025, Jakub Jelinek wrote: > 2025-02-13 Kees Cook > Jakub Jelinek > > PR c/117178 > gcc/ > * doc/invoke.texi (Wunterminated-string-initialization): Document > the new interaction between this warning and -Wc++-compat and that > initialization

Re: [PATCH] c: Fix warning after an error on a return statment [PR60440]

On Thu, 6 Mar 2025, Andrew Pinski wrote: > Like r5-6912-g3dbb84276aca10 but this is for the C front-end. > Basically we have an error on a return statement, we just return > error_mark_node and then the warning happens as there is no return > statement. Anyways instead mark the current function fo

Re: [PATCH] c: Assorted fixes for flexible array members in unions [PR119001]

On Wed, 26 Feb 2025, Jakub Jelinek wrote: > Hi! > > r15-209 allowed flexible array members inside of unions, but as the > following testcase shows, not everything has been adjusted for that. > Unlike structures, in unions flexible array member (as an extension) > can be any of the members, not ju

Re: [PATCH] c: stddef.h C23 fixes [PR114870]

On Wed, 26 Feb 2025, Jakub Jelinek wrote: > In any case, the following patch has been bootstrapped/regtested on > x86_64-linux and i686-linux, ok for trunk? Or something else? > > 2025-02-26 Jakub Jelinek > > PR c/114870 > * ginclude/stddef.h (__STDC_VERSION_STDDEF_H__, unreachab

Re: The COBOL front end, version 3, now in 14 easy pieces (+NIST)

On Thu, 20 Feb 2025, James K. Lowden wrote: > The Makefile fetches the NIST archive from our website. (We originally > got it from NIST, but their site was reorganized last year. The file > went missing, as apparently did my email to the webmaster. > Technology!) The file might have 100 targets

Re: [PATCH] COBOL 8/8 bld: "meta" files, such a gcc/cobol/Make-lang.in

On Tue, 4 Feb 2025, James K. Lowden wrote: > It's not clear to me there should be an install target for PDF because > there's no pdfdir variable defined (akin to htmldir). pdfdir is passed down from the top-level Makefile. > I guess when this script runs, nothing has been configured and no > M

Re: [PATCH] c: For array element type drop qualifiers but keep other properties of the element type [PR116357]

On Sat, 25 Jan 2025, Jakub Jelinek wrote: > The following patch uses build_qualified_type with TYPE_UNQUALIFIED instead, > which will be in the common case the same as TYPE_MAIN_VARIANT if the > checks are satisfied for it, but if not, will look up different unqualified > type or even create it if

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Fri, 24 Jan 2025, Bill Wendling wrote: > > First, I should point out that the proposed standard feature in this area > > (which received along-the-lines support at the WG14 meeting in Strasbourg > > last year, though with a very large number of issues with the proposed > > wording that would ne

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Fri, 24 Jan 2025, Martin Uecker wrote: > No doubt, but this is a semantic difference which does necessarily imply > that the syntax has to be different. The syntax of initialization seems > intentionally designed to look like assignment to be intuitive.  > The "=" in designators otherwise seems

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Thu, 23 Jan 2025, Martin Uecker wrote: > I can see why it could be seen in this way. But the designator > syntax could also be seen (more or less) as a tiny subset of > the expression syntax allowing only assignments. It is just Initializers are not assignments. They should not be confused wi

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Tue, 21 Jan 2025, Martin Uecker wrote: > The bigger issue seems that if you forward reference a member, you > do not yet know its type. So whatever syntax we pick, general expressions > seem problematic anyway: > > struct { > char *buf [[counted_by(2 * .n + 3)]]; > unsigned int n; That's

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Tue, 21 Jan 2025, Martin Uecker wrote: > Coudn't you use the rule that .len refers to the closest enclosing structure > even without __self__ ? This would then also disambiguate between designators > and other uses. Right now, an expression cannot start with '.', which provides the disambigu

Re: Calling Convention Semantics for FCSR (was Re: gcc mode switching issue)

On Tue, 21 Jan 2025, Vineet Gupta wrote: > Silly question, what exactly is the procedure calling convention rule for > FCSR/FRM ? Is it a Caller saved or a Callee saved Reg. > The psABI CC doc is not explicit in those terms at least [1] > > |   "The Floating-Point Control and Status Register (fcs

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Tue, 21 Jan 2025, Qing Zhao wrote: > > On Jan 20, 2025, at 16:19, Joseph Myers wrote: > > > > On Sat, 18 Jan 2025, Kees Cook wrote: > > > >> Gaining access to global variables is another gap Linux has -- e.g. we > >> have arrays that are s

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Tue, 21 Jan 2025, Qing Zhao wrote: > So, even after we introduce the designator syntax for counted_by attribute, > arbitrary expressions as: > > counted_by (.len1 + const) > counted_by (.len1 + .len2) > > Still cannot be supported? Indeed. Attempting to use ".len1" inside something that

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Sat, 18 Jan 2025, Kees Cook wrote: > Gaining access to global variables is another gap Linux has -- e.g. we > have arrays that are sized by the global number-of-cpus variable. :) Note that it's already defined that counted_by takes an identifier for a structure member (i.e. not an expression,

Re: [GCC16 stage 1][RFC][PATCH 0/3]extend "counted_by" attribute to pointer fields of structures

On Fri, 17 Jan 2025, Qing Zhao wrote: > struct fc_bulk { > ... > struct fs_bulk fs_bulk; > struct fc fcs[] __counted_by(fs_bulk.len); > }; > > i.e, the “counted_by” field is in the inner structure of the current > structure of the FAM. > With the current syntax, it’s not easy to extend to

Re: [PATCH] c, c++: Return 1 for __has_builtin(__builtin_va_arg) and __has_builtin(__builtin_c23_va_start)

On Fri, 17 Jan 2025, Jakub Jelinek wrote: > Bootstrapped on x86_64-linux and i686-linux, regtest ongoing, ok for trunk > if it passes? > > 2025-01-17 Jakub Jelinek > > gcc/c/ > * c-decl.cc (names_builtin_p): Return 1 for RID_C23_VA_START and > RID_VA_ARG. > gcc/cp/ > * cp-ob

RE: [RFC] PR81358: Enable automatic linking of libatomic

On Thu, 16 Jan 2025, Prathamesh Kulkarni wrote: > Hi Joseph, > Does the above patch in: > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673155.html look OK to > commit (altho it's stage-4 now) ? > It fixes all the fallouts observed so far (multilib, nvptx offloading, > libdruntime). M

Re: [PATCH] wwwdocs: experiments with a Python postprocessing script

On Wed, 15 Jan 2025, David Malcolm wrote: > I've never managed to build MetaHTML and have always just > crossed my fingers and hoped when making edits to the GCC > website; bin/preprocess just errors out for me immediately > due to not finding mhc. I think that replacing MetaHTML with a Python sc

Re: [wwwdocs, PATCH] gcc-15/porting_to: add section on new C23 keywords

On Wed, 15 Jan 2025, David Malcolm wrote: > + > + In C99 and later you can use #include > + which provides a definition of bool compatible with C23. > + > + Note that the bool type is not the same > + as int at ABI level, and so care may be needed porting > + declarations that app

Re: [PATCH] wwwdocs: gcc-15: start adding notes on C23

On Wed, 15 Jan 2025, David Malcolm wrote: > Here's an updated version of the patch > > OK to push? (we could tweak it in followups) This will need updating to work together with Jakub's patch that also adds the C section to changes.html. > +Function declarations without > parameters > + > +

Re: [PATCH] wwwdocs: Document some user visible C, C++ and C/C++ changes in GCC 15

On Wed, 15 Jan 2025, Jakub Jelinek wrote: > Hi! > > The following patch attempts to document in similar style to last years > new C++23/26 papers and DRs implemented in GCC 15 (for > the papers I've used https://gcc.gnu.org/projects/cxx-status.html > as source, for DRs skimmed gcc-cvs commits wit

Re: [PATCH v2] c: improve UX for -Wincompatible-pointer-types [PR116871]

On Sun, 12 Jan 2025, David Malcolm wrote: > So I've dropped the takes_int_p, takes_void_p, and > maybe_inform_empty_args_c23_transition from the patch. Here's an > updated version that keeps the rest of the changes. I'd like to get > this into GCC 15 to make build failures due to C23-incompatibi

Re: [PATCH] c: Restore warning for incomplete structures declared in parameter list [PR117866]

On Mon, 6 Jan 2025, Martin Uecker wrote: > > Happy new year! Please consider the following patch. > > Bootstrapped and regression tested on x86_64. > > > c: Restore warning for incomplete structures declared in parameter list > [PR117866] > > In C23 mode the warning about declari

Re: [PATCH] COBOL 1/8 hdr: header files

On Sat, 4 Jan 2025, James K. Lowden wrote: > On Fri, 3 Jan 2025 19:46:38 +0100 > Jakub Jelinek wrote: > > > Again, the question is if it needs to be supported everywhere, or > > just error out on targets which don't have _Float128 > > Our preference is simply to error out on targets that don't

Re: [PATCH] testsuite: libitm: Adjust how libitm.c++ passes link flags

Does this patch cover everything dealt with by ([PATCH] testsuite: libitm: Remove build directory path from test names), or would some separate fix for that issue still be needed in the presence of this patch? -- Joseph S.

RE: [RFC] PR81358: Enable automatic linking of libatomic

On Fri, 20 Dec 2024, Prathamesh Kulkarni wrote: > Hi, > The previous patch (now reverted) had two different issues both stemming from > the rule added in libatomic/Makefile.am: > (1) As mentioned above, it broke multilib builds because it incorrectly > copies libatomic.a in $(gcc_objdir). The at

RE: [PATCH] COBOL 1/8 hdr: header files

On Thu, 19 Dec 2024, Robert Dubner wrote: > At compile-time (or on the host), we also do numeric calculations. The > ISO specification allows for compile-time computations specified in the > source code. In addition, at times I put initial values for the COBOL > variables into the run-time struc

Re: [PATCH] c/c++: UX improvements to 'too {few, many} arguments' errors [PR118112]

On Thu, 19 Dec 2024, David Malcolm wrote: > gcc/c/ChangeLog: > PR c/118112 > * c-typeck.cc (inform_declaration): Add "function_expr" param and > use it for cases where we couldn't show the function decl to show > field decls for callbacks. > (build_function_call_vec):

Re: [PATCH] c: special-case some "bool" errors with C23 (v2) [PR117629]

On Thu, 19 Dec 2024, David Malcolm wrote: > Here's an updated version of the patch. > > Changed in v2: > - distinguish between "bool" and "_Bool" when determining > standard version > - more test coverage > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > OK for trunk? OK.

Re: The COBOL front end, in 8 notes

On Wed, 18 Dec 2024, James K. Lowden wrote: > I think the issue that raised the most concern is the one I think is > most important: diagnostics. It was unclear -- still is, to me -- > whether the COBOL front end must or should use the gcc diagnostic > framework. (In my defense, the system goes u

Re: [PATCH] COBOL 1/8 hdr: header files

On Thu, 19 Dec 2024, Andrew Pinski wrote: > Maybe it is better to just use _BitInt instead of __int128. Yes the > number of targets that support _BitInt for C is less than __int128 but > in the future _BitInt will be more supported than __int128 especially > on 32bit targets. E.g. _BitInt(128) is

Re: The COBOL front end, in 8 notes

On Wed, 18 Dec 2024, James K. Lowden wrote: > * Please make sure to do all regeneration with *unmodified* versions > [Joseph] > - I don't understand. You appeared to have regenerated a configure script built with a version of autoconf from a GNU/Linux distribution that patched autoconf to add

Re: [PATCH] COBOL 1/8 hdr: header files

On Wed, 18 Dec 2024, James K. Lowden wrote: > On Mon, 16 Dec 2024 23:36:37 + (UTC) > Joseph Myers wrote: > > > > +extern "C" _Float128 __gg__float128_from_qualified_field > > > > I'm not entirely sure whether this is host or target code (y

Re: [PATCH] COBOL 8/8 bld: "meta" files, such a gcc/cobol/Make-lang.in

On Tue, 17 Dec 2024, James K. Lowden wrote: > On Tue, 17 Dec 2024 18:04:01 + (UTC) > Joseph Myers wrote: > > > I don't think we should introduce man pages as a new source format > > for documentation in GCC. Either .texi or .rst (with generated man > > pages

Re: [PATCH] COBOL 8/8 bld: "meta" files, such a gcc/cobol/Make-lang.in

On Fri, 13 Dec 2024, David Malcolm wrote: > For the rest of GCC we use either texinfo (.texi files) or sphinx > (.rst) files; the manpages and HTML are both generated from the same > sources. I don't if using these formats is a hard requirement. If so > one converter I know of that can supposedl

Re: The COBOL front end, in 8 notes

On Mon, 16 Dec 2024, James K. Lowden wrote: > On Mon, 16 Dec 2024 23:48:52 + (UTC) > Joseph Myers wrote: > > > However, if introducing a Bison dependency, it needs to be documented > > (being specific about version requirements) in install.texi. > > Under &q

Re: [PATCH] COBOL 2/8 par: parser

A further diagnostic remark: * When moving to the GCC diagnostic functions, please prefer the versions that take an explicit location (which should be based on the locations of the relevant source tokens in the COBOL source - preferably an accurate range for exactly which tokens are relevant fo

  1   2   3   4   5   6   7   8   9   10   >