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

Re: The COBOL front end, in 8 notes + toplevel patch

On Mon, 16 Dec 2024, Matthias Klose wrote: > On 14.12.24 15:38, Matthias Klose wrote: > > I tried to use the patches to build binary packages for Debian. Found some > > issues: > > tried to build libgcobol on more architectures, please find the attached patch > to disable building libgcobol on so

Re: The COBOL front end, in 8 notes

On Sat, 14 Dec 2024, Iain Sandoe wrote: > 1) to introduce new build dependencies on: > - bison (we normally commit generated files to the repo not expect the > end-user >to need bison installed). > - a version of gm4 that recognises —gnu We don't commit bison-generated files. (We don't

Re: [PATCH] COBOL 4/8 cbl: other supporting C++ files

On Thu, 12 Dec 2024, James K. Lowden wrote: > +switch(e->type) { > +case SymFilename: > + asprintf(&s, "%4zu %-18s %s", e->program, > +"Filename", e->elem.filename); > + break; You need to check for errors from allocation functions such as asprintf before using the

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

On Thu, 12 Dec 2024, James K. Lowden wrote: > +static char name[PATH_MAX]; Static buffers with a PATH_MAX size will probably break the build on Hurd host. > +__int128 get_power_of_ten(int n); GCC supports 32-bit hosts; you shouldn't rely on __int128 being available on the host. > +exter

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

The parser appears to contain calls to diagnostic functions, so seems a good point to comment on conventions for diagnostics in GCC: * Please send all diagnostics (except maybe internal ones that indicate a bug in the compiler) through the language-independent diagnostic machinery. It appears

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

On Thu, 12 Dec 2024, James K. Lowden wrote: > diff --git a/configure b/configure > index 51bf1d1add1..2a8f0cadc0e 100755 > --- a/configure > +++ b/configure > @@ -775,6 +775,7 @@ infodir > docdir > oldincludedir > includedir > +runstatedir > localstatedir > sharedstatedir > sysconfdir Pleas

Re: The COBOL front end, in 8 notes

On Thu, 12 Dec 2024, James K. Lowden wrote: > A word about C style, always a lively topic. For any files already > present in gcc, the existing style was followed, and any variation from > it is unintentional. Files related to the parser use K&R style. The > GENERIC interface and runtime librar

Re: [PATCH] driver: fix crash with --diagnostics-plain-output [PR117942]

On Mon, 9 Dec 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > We are crashing here because decode_cmdline_options_to_array has: > > if (!strcmp (opt, "-fdiagnostics-plain-output")) > ... > > but that doesn't handle the '--FLAG' vari

Re: [PATCH v6 2/7] Drop targetm.promote_prototypes from C, C++ and Ada frontends

On Fri, 6 Dec 2024, Richard Biener wrote: > On Wed, Dec 4, 2024 at 9:48 PM H.J. Lu wrote: > > > > Remove the targetm.calls.promote_prototypes call from C, C++ and Ada > > frontends. > > I'm conditionally approving this unless FE maintainers complain before > holidays > (the effect of the hook i

Re: [PATCH] config: nvptx: fix bashisms with gen-copyright.sh use

On Fri, 6 Dec 2024, Thomas Schwinge wrote: > First: Tom, what was your original intention why we'd keep the generated > files in the sources? (..., instead of just generating them at build > time, like 'gcc/config/nvptx/t-omp-device' does for > 'omp-device-properties-nvptx', for example. In that

Re: [PATCH] c: Diagnose unexpected va_start arguments in C23 [PR107980]

On Thu, 5 Dec 2024, Jakub Jelinek wrote: > 2024-12-05 Jakub Jelinek > > PR c/107980 > gcc/ > * ginclude/stdarg.h (va_start): For C23+ change parameters from > v, ... to just ... and define to __builtin_c23_va_start(__VA_ARGS__) > rather than __builtin_va_start(v, 0). >

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

On Wed, 4 Dec 2024, Prathamesh Kulkarni wrote: > Hi Joseph, > Updated the assert together with setting of CFLAGS in attached patch. > Bootstrapped+tested on aarch64-linux-gnu (so far). > Does it look OK ? This version is OK. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH 2/2] maintainer-scripts: build the libgdiagnostics docs for the website [PR117883]

On Tue, 3 Dec 2024, David Malcolm wrote: > Tested locally. > > OK for trunk? > > maintainer-scripts/ChangeLog: > PR web/117883 > * update_web_docs_git: Introduce SPHINX_VENV to make > it easier to test the script. Add the libgdiagnostics docs > and testsuite to the files

Re: [PATCH 1/2] maintainer-scripts: fix jit docs on website

On Tue, 3 Dec 2024, David Malcolm wrote: > I noticed whilst working on the libgdiagnostics docs > that some errors like this were occurring in the jit docs: > > /tmp/gcc-doc-update.3782849/gcc/gcc/jit/docs/cp/topics/asm.rst:63: WARNING: > Include file > '/tmp/gcc-doc-update.3782849/gcc/gcc/test

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

On Mon, 2 Dec 2024, Prathamesh Kulkarni wrote: > Thanks for the suggestions! Unfortunately, it seems to me that AC_PROG_CC > also does run tests that > need modified CFLAGS. I tried the following assertion before invoking > AC_PROG_CC (for stage-1 build): > > if test -z "${CFLAGS}"; then > AC

Re: gimplify: Handle void BIND_EXPR as asm input [PR100501]

On Fri, 29 Nov 2024, Richard Biener wrote: > I think we're trying to handle errorneous cases by setting TREE_VALUE > to error_mark_node > before this, so how about the following instead? Yes, that works, and also fixes the test in bug 100792 unlike my previous patch. Here's a full, tested patch

Re: [C PATCH] c: Set attributes for fields when forming a composite type [PR117806]

On Fri, 29 Nov 2024, Martin Uecker wrote: > It seems we also miss a decl_attributes call for the fields > when building the composite type. > > > Bootstrapped and regression tested on x86_64. > > > c: Set attributes for fields when forming a composite type [PR117806] > > We need t

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

On Fri, 29 Nov 2024, Prathamesh Kulkarni wrote: > > My expectation is that CFLAGS should not be modified until after > > save_CFLAGS is set, which should not be until after configure has > > executed the logic that sets a -g -O2 default. Is there some problem > > with that ordering (e.g. configur

gimplify: Handle void BIND_EXPR as asm input [PR100501]

As reported in bug 100501 (plus duplicates), the gimplifier ICEs for C tests involving a statement expression not returning a value as an asm input. The expected diagnostic for this case (as seen for C++ input) is one coming from the gimplifier and so it seems reasonable to fix the gimplifier to h

Re: [PATCH] c: correct type compatibility for bit-fields [PR117828]

On Thu, 28 Nov 2024, Martin Uecker wrote: > Bit-fields need additional checks for type compatiblity. > > > Bootstrapped and regression tested on x86_64. > > > > c: correct type compatibility for bit-fields [PR117828] > > Add missing test for consistency of bit-fields when compari

[committed] c: Fix gimplification ICE for shifts with invalid redeclarations

As reported in bug 117757, there is a C gimplification ICE for shifts involving a variable that was incompatibly redeclared (and thus had its type changed to error_mark_node). Fix this with an appropriate error_operand_p check. Note that this is not the same issue as any of the other bugs reporte

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

On Tue, 19 Nov 2024, Prathamesh Kulkarni wrote: > +#ifdef USE_LD_AS_NEEDED > +#define LINK_LIBATOMIC_SPEC "%{!fno-link-libatomic:" LD_AS_NEEDED_OPTION \ > + " -latomic " LD_NO_AS_NEEDED_OPTION "} " > +#else > +#define LINK_LIBATOMIC_SPEC "" > +#endif I'd expect conditional

[committed] c: Fix ICE using function name in parameter type in old-style function definition [PR91193]

As reported in bug 91193, if an old-style function definition redeclares a typedef name as a function, then uses that function name at the start of the first old-style parameter definition, then the parser interprets that token as a typedef name (because lookahead occurred before processing of the

c: Do not remove _Atomic from array element type for typeof_unqual [PR117781]

As reported in bug 117781, my fix for bug 112841 broke the case of typeof_unqual applied to an array of _Atomic elements, which should not have _Atomic removed since only the element type is atomic, not the array type. Fix with logic to ensure that atomic element types are preserved as such, while

Re: [PATCH v2] c: Introduce -Wfree-labels

On Mon, 18 Nov 2024, Florian Weimer wrote: > This is another recent GCC extension whose use is apparently > difficult to spot in code reviews. > > The name of the option is due to Jonathan Wakely. Part of it > could apply to C++ as well (for labels at the end of a compound > statement). > > gcc

[committed] c: Fix ICEs from invalid atomic compound assignment [PR98195, PR117755]

As reported in bug 98195, there are ICEs from an _Atomic compound assignment with an incomplete type on the RHS, arising from an invalid temporary being created with such a type. As reported in bug 117755, there are also (different) ICEs in cases with complete types where the binary operation itse

Re: [PATCH] Introduce feeble_inline attribute [PR93008]

On Thu, 14 Nov 2024, Jakub Jelinek wrote: > This patch introduces a new attribute for weaker inline semantics (basically > it behaves as inline for the FE/debug info purposes, just for the > optimization decisions acts as if it wasn't explicitly inline); I haven't > used weak_inline for the attrib

RE: [committed] c: Default to -std=gnu23

On Mon, 25 Nov 2024, Jiang, Haochen wrote: > A quick question: Should we add this in gcc-wwwdocs porting doc or > somewhere else? The upgrade does cause some old code fail to compile > although it should fail. In general we should (collectively, by the time GCC 15 is out) update changes.html wit

Re: [PATCH] C/C++: add fix-it hints for missing '&' and '*' (v5) [PR87850]

On Fri, 22 Nov 2024, David Malcolm wrote: > Revisiting this patch from 2018 that didn't quite make it; > earlier versions were: > v1: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00802.html > v2: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-11/msg01408.html > v3: https://gcc.gnu.org/legac

[committed] c: Fix typeof_unqual handling of qualified array types [PR112841]

As reported in bug 112841, typeof_unqual fails to remove qualifiers from qualified array types. In C23 (unlike in previous standard versions), array types are considered to have the qualifiers of the element type, so typeof_unqual should remove such qualifiers (and an example in the standard shows

Re: [PATCH] inline asm, v3: Add new constraint for symbol definitions

On Fri, 22 Nov 2024, Jakub Jelinek wrote: > On Thu, Nov 21, 2024 at 11:57:13PM +0000, Joseph Myers wrote: > > On Wed, 6 Nov 2024, Jakub Jelinek wrote: > > > > > + error_at (loc, "%<:%> constraint operand is not address " > > > +

Re: Stage1 patch ping

On Tue, 19 Nov 2024, Jakub Jelinek wrote: > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667737.html > inline-asm: Add support for cc operand modifier > https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667949.html > inline-asm, i386: Add "redzone" clobber support > This on

Re: [PATCH] inline-asm: Add - constraint modifier support for toplevel extended asm [PR41045]

On Mon, 18 Nov 2024, Jakub Jelinek wrote: > +@smallexample > +extern void foo (void), bar (void); > +int v; > +extern int w; > +asm (".globl %cc0, %cc2; .text; %cc0: call %cc1; ret; .data; %cc2: .word > %cc3" > + :: ":" (foo), "-s" (&bar), ":" (&w), "-i" (&v)); > +@end smallexample > + > +Thi

Re: [RFC PATCH] inline asm, v2: Add new constraint for symbol definitions

On Wed, 6 Nov 2024, Jakub Jelinek wrote: > + error_at (loc, "%<:%> constraint operand is not address " > + "of a function or non-automatic variable"); I think a testcase for this error is needed. -- Joseph S. Myers josmy...@redhat.com

[committed] c: Give errors more consistently for void parameters [PR114816]

Cases of void parameters, other than a parameter list of (void) (or equivalent with a typedef for void) in its entirety, have been made a constraint violation in C2Y (N3344 alternative 1 was adopted), as part of a series of changes to eliminate unnecessary undefined behavior by turning it into cons

Re: [PATCH] Allow limited extended asm at toplevel [PR41045]

On Sat, 2 Nov 2024, Jakub Jelinek wrote: > +Extended @code{asm} statements outside of functions may not use any > +qualifiers, may not specify clobbers, may not use @code{%}, @code{+} or > +@code{&} modifiers in constraints and can only use constraints which don%'t > +allow using any register. Ju

Re: [PATCH 08/11] c: c++: flag to disable fetch_op handling fenv exceptions

On Thu, 21 Nov 2024, Matthew Malcomson wrote: > Based on that -- should the same reasoning apply to the new builtins? > I.e. do you believe it would be reasonable to say that the new builtins > require libatomic, and remove this flag entirely? I think it's reasonable to say that atomic built-in f

Re: [PATCH] doc/cpp: Document __has_include_next

On Fri, 18 Oct 2024, Arsen Arsenović wrote: > -The @code{__has_include} operator by itself, without any @var{operand} or > -parentheses, acts as a predefined macro so that support for it can be tested > -in portable code. Thus, the recommended use of the operator is as follows: > +The @code{__has

Re: [PATCH] libcpp: Fix ICE lexing invalid raw string in a deferred pragma [PR117118]

On Wed, 16 Oct 2024, Lewis Hyatt wrote: > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117118 > > This fixes an old regression from GCC 11. Is it OK for trunk and all > backports please? Bootstrap + regtested all languages on x86-64 Linux. > Thanks! > > -Lewis > > -- >8 -- > > The

Re: [PATCH] c: Add u{,l,ll,imax}abs builtins [PR117024]

On Wed, 16 Oct 2024, Jakub Jelinek wrote: > Hi! > > The following patch adds u{,l,ll,imax}abs builtins, which just fold > to ABSU_EXPR, similarly to how {,l,ll,imax}abs builtins fold to > ABS_EXPR. > > Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest > on x86_64-linux and

Re: [PATCH] expr, c, gimplify, v3: Don't clear whole unions [PR116416]

On Wed, 20 Nov 2024, Jakub Jelinek wrote: > On Tue, Nov 19, 2024 at 11:08:03PM +0000, Joseph Myers wrote: > > > --- gcc/testsuite/gcc.dg/gnu11-empty-init-1.c.jj 2024-10-15 > > > 16:14:23.411063701 +0200 > > > +++ gcc/testsuite/gcc.dg/gnu11-empty-init-1.c 2024-1

[committed] c: Diagnose compound literal for empty array [PR114266]

As reported in bug 114266, GCC fails to pedwarn for a compound literal, whose type is an array of unknown size, initialized with an empty initializer. This case is disallowed by C23 (which doesn't have zero-size objects); the case of a named object is diagnosed as expected, but not that for compou

  1   2   3   4   5   6   7   8   9   10   >