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

Re: [PATCH] c-family, docs: Adjust descriptions/documentation for C23 publication

On Wed, 20 Nov 2024, Jakub Jelinek wrote: > --- gcc/c-family/c.opt.jj 2024-11-20 14:45:02.092732924 +0100 > +++ gcc/c-family/c.opt2024-11-20 17:08:03.230401954 +0100 > @@ -2609,7 +2609,7 @@ Conform to the ISO 2017 C standard (publ > > std=c23 > C ObjC > -Conform to the ISO 2023 C s

[committed] c: Fix ICE for integer constexpr initializers of wrong type [PR115515]

Bug 115515 (plus its duplicate 117139) reports an ICE with constexpr initializer for an integer type variable that is not of integer type. Fix this by not calling int_fits_type_p unless the previous check for an integer constant expression passes. Bootstrapped with no regressions for x86_64-pc-lin

Re: [PATCH] Use nonnull_if_nonzero attribute rather than nonnull on various builtins [PR117023]

On Thu, 14 Nov 2024, Jakub Jelinek wrote: > The patch adjusts builtins (when we have them) corresponding to the APIs > mentioned in the C2Y N3322 paper: > 1) strndup and memset get one nonnull_if_nonzero attribute instead of >nonnull > 2) memcpy, memmove, strncpy, memcmp, strncmp get two nonnu

Re: [PATCH] v2: Add support for nonnull_if_nonzero attribute [PR117023]

On Wed, 13 Nov 2024, Jakub Jelinek wrote: > On Tue, Nov 12, 2024 at 06:34:39PM +0100, Jakub Jelinek wrote: > > What do you think about this? So far lightly tested. > > Unfortunately bootstrap/regtest revealed some issues in the patch, > the tree-ssa-ccp.cc changes break bootstrap because fntype

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

On Tue, 15 Oct 2024, Jakub Jelinek 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-10-15 16:31:02.302984714 > +0200 > @@ -0,0 +1,199 @@ > +/* Test GNU C11 support for empty initializers. */

[committed] c: Do not register nullptr_t built-in type [PR114869]

As reported in bug 114869, the C front end wrongly creates nullptr_t as a built-in typedef; it should only be defined in . While the type node needs a name for debug info generation, it doesn't need to be a valid identifier; use typeof (nullptr) instead, similar to how the C++ front end uses declt

Re: [PATCH] c: Fix up __builtin_stdc_rotate_{left,right} lowering [PR117456]

On Tue, 19 Nov 2024, Jakub Jelinek wrote: > Hi! > > Apparently the middle-end/expansion can only handle {L,R}ROTATE_EXPR > on types with mode precision, or large/huge BITINT_TYPE. > So, the following patch uses the rotate exprs only in those cases > where it can be handled, and emits code with sh

Re: [PATCH] build: Discard obsolete references to $(GCC_PARTS)

On Mon, 18 Nov 2024, Maciej W. Rozycki wrote: > The $(GCC_PARTS) variable was deleted with the Makefile rework in commit > fa9585134f6f ("libgcc move to the top level")[1] back in 2007, and yet > the Ada and Modula 2 frontends added references to this variable later > on, with commit e972fd5281

Re: [PATCH] c: fix incorrect TBAA for tagged types across translation units [PR117490]

On Sat, 16 Nov 2024, Martin Uecker wrote: > c: fix incorrect TBAA for tagged types across translation units [PR117490] > > Two different declarations of tagged types in the same translation unit > are incompatible in C before C23 and without tag also in C23. Still, > two such

[committed] c: Allow bool and enum null pointer constants [PR112556]

As reported in bug 112556, GCC wrongly rejects conversion of null pointer constants with bool or enum type to pointers in convert_for_assignment (assignment, initialization, argument passing, return). Fix the code there to allow BOOLEAN_TYPE and ENUMERAL_TYPE; it already allowed INTEGER_TYPE and B

[committed] c: Default to -std=gnu23

Change the default language version for C compilation from -std=gnu17 to -std=gnu23. A few tests are updated to remove local definitions of bool, true and false (where making such an unconditional test change seemed to make more sense than changing the test conditionally earlier or building it wit

Re: [PATCH] c: Implement -Wdeprecated-non-prototype

On Sat, 16 Nov 2024, Florian Weimer wrote: > +@opindex Wdeprecated-non-prototype > +@opindex Wno-deprecated-non-prototype > +@item -Wdeprecated-non-prototype @r{(C and Objective-C only)} > +Warn if a function declarated with an empty parameter list @samp{()} is > +called with one or more arguments

Re: [PATCH] c: Fix ICE when forming composite type for two structures / unions [PR117548]

On Fri, 15 Nov 2024, Martin Uecker wrote: > Bootstrapped and regression tested on x86_64. > > > c: Fix ICE when forming composite type for two structures / unions > [PR117548] > > When forming the composite type from two tagged type, we need to find the > original type for a ty

tree-nested: Do not inline or clone functions with nested functions with VM return type [PR117164]

Bug 117164 is an ICE on an existing test with -std=gnu23 involving a nested function returning a variable-size structure (and I think the last bug needing to be resolved before switching to -std=gnu23 as the default, as without fixing this would be a clear regression from a change in default). The

Re: [PATCH] c: Introduce -Wmissing-parameter-name

On Thu, 14 Nov 2024, Florian Weimer wrote: > * c-family/c-opts.cc (c_common_post_options): Initialize > warn_missing_parameter_name. > * c-family/c.opt (Wmissing-parameter-name): New. > * c/c-decl.cc (store_parm_decls_newstyle): Use > OPT_Wmissing_parameter_name for m

Re: [PATCH] c, v2: Add _Decimal64x support

On Thu, 14 Nov 2024, Jakub Jelinek wrote: > Here is an updated patch, in addition to removing the DEC64X_SUBNORMAL_MIN > redefinition I've also adjusted the c23-decimal64x-4.c test to use > the __STDC_WANT_IEC_60559_TYPES_EXT__ macro which is now needed and > test DEC64X_TRUE_MIN rather than DEC64

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

On Thu, 14 Nov 2024, mmalcom...@nvidia.com wrote: > N.b. I would appreciate any feedback about how one should handle such a > situation when working with C11 _Atomic types. They have the same > problem that they require libatomic and sometimes libatomic is not > available. Is this just something

Re: [PATCH] c: Add _Decimal64x support

On Thu, 14 Nov 2024, Jakub Jelinek wrote: > Should DEC64X_SUBNORMAL_MIN/DEC64X_TRUE_MIN macros be defined at all and if > yes, under the same conditions as the rest? > C23 only talks about *_TRUE_MIN, not about *_SUBNORMAL_MIN. So there should be no DEC64X_SUBNORMAL_MIN (but should be DEC64X_TRUE

Re: [PATCH] c: Add _Decimal64x support

On Thu, 14 Nov 2024, Jakub Jelinek wrote: > --- gcc/ginclude/float.h.jj 2024-10-25 10:00:29.472767800 +0200 > +++ gcc/ginclude/float.h 2024-11-13 17:50:46.625592746 +0100 > @@ -515,51 +515,63 @@ see the files COPYING3 and COPYING.RUNTI > #undef DEC32_MANT_DIG > #undef DEC64_MANT_DIG > #u

Re: [PATCH v5] c: add Wzero-as-null-pointer-constant [PR117059]

On Tue, 12 Nov 2024, Martin Uecker wrote: > Added tests with some non-NPC pointers converted to bool. This version is OK. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v4] c: add Wzero-as-null-pointer-constant [PR117059]

On Mon, 11 Nov 2024, Martin Uecker wrote: > The fourth version also adds a documentation change. For now, > I simply decided to remove the comment about C++11 because it > seems not that useful anymore with nullptr_t now fully > established in C++. I added the requested tests at the end  > (I h

Re: [PATCH] c: Handle C23 floating constant {d, D}{32, 64, 128} suffixes like {df,dd,dl}

On Mon, 11 Nov 2024, Jakub Jelinek wrote: > Hi! > > C23 roughly says that {d,D}{32,64,128} floating point constant suffixes > are alternate spellings of {df,dd,dl} suffixes in annex H. > > So, the following patch allows that alternate spelling. This is OK. > Or is it intentional it isn't enabl

Re: Fwd: [PATCH v3] C: Support Function multiversionsing in the C front end

On Mon, 11 Nov 2024, Alfie Richards wrote: > I see this code is very unclear in hindsight. The logic of this code > relies on that FMV functions are only allowed at file scope. > This should have a DECL_FILE_SCOPE_P check to avoid some of the ridiculous > cases you mentioned. If you have an actua

Re: [PATCH] c: Implement C2Y N3298 - Introduce complex literals [PR117029]

On Mon, 11 Nov 2024, Jakub Jelinek wrote: > Hi! > > The following patch implements the C2Y N3298 paper Introduce complex literals > by providing different (or no) diagnostics on imaginary constants (except > for integer ones). > For _DecimalN constants we don't support _Complex _DecimalN and erro

Re: [committed] contrib: Add 2 further ignored commits

On Sun, 10 Nov 2024, Jakub Jelinek wrote: > On Sun, Nov 10, 2024 at 01:30:06PM -0300, Alexandre Oliva wrote: > > On Nov 9, 2024, Jakub Jelinek wrote: > > > > > r15-4998 and r15-5004 had wrong commit message, add those to > > > ignored commits. > > > > Ugh, sorry and thanks. > > Was that .c vs

Re: [PATCH v3] c: add Wzero-as-null-pointer-constant [PR117059]

On Mon, 11 Nov 2024, Martin Uecker wrote: > This patch enables the Wzero-as-null-pointer-constant for C. > The third version adds more tests. The various tests for boolean operations should also test those for pointers that are *not* null pointers (to verify that the implicit 0 being compared

Re: [PATCH v2] c: add Wzero-as-null-pointer-constant [PR117059]

Other cases to test: the != operator (should warn in same cases as ==); boolean uses of pointers such as if (p), !p, p?x:y, and implicit or explicit conversion to bool (none of those boolean uses of pointers should warn since there's no explicit integer null pointer constant involved in the imp

Re: [PATCH v3] C: Support Function multiversionsing in the C front end

I should also add: the ACLE specification for the details of how function multiversioning is supposed to work in terms of interactions of declarations for different versions in the same or different scopes and what happens regarding forming composite types seems rather vague. So maybe it would

Re: [PATCH v3] c: Implement C2y N3356, if declarations [PR117019]

On Fri, 8 Nov 2024, Marek Polacek wrote: > OK, I've reworded the comment to > > /* The call above already performed convert_lvalue_to_rvalue, but > if it parsed an expression, read_p was false. Make sure we mark > the expression as read. */ > > though it's questionable

Re: [PATCH v3] C: Support Function multiversionsing in the C front end

On Mon, 4 Nov 2024, alfie.richa...@arm.com wrote: > /* Subroutine of duplicate_decls. Compare NEWDECL to OLDDECL. > Returns true if the caller should proceed to merge the two, false > if OLDDECL should simply be discarded. As a side effect, issues > @@ -3365,11 +3382,53 @@ pushdecl (tre

Re: [PATCH v2] c: Implement C2y N3356, if declarations [PR117019]

On Thu, 7 Nov 2024, Marek Polacek wrote: > @@ -8355,7 +8492,9 @@ c_parser_switch_statement (c_parser *parser, bool > *if_p, tree before_labels) >if (c_parser_next_token_is (parser, CPP_OPEN_PAREN) > && c_token_starts_typename (c_parser_peek_2nd_token (parser))) > explicit_ca

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Fri, 8 Nov 2024, Alejandro Colomar wrote: > Hi Joseph, > > This is a gentle ping about this patch set, 10 days before the start of > stage 3. It's obviously not ready to include in its current form (using a name different from that actually accepted into C2Y). Since it requires significant

Re: [PATCH] c: Implement C2y N3356, if declarations [PR117019]

On Wed, 6 Nov 2024, Marek Polacek wrote: > On Wed, Nov 06, 2024 at 09:42:02AM -0500, Marek Polacek wrote: > > On reflection, I'm not so sure about these anymore: > > > > On Mon, Nov 04, 2024 at 06:26:47PM -0500, Marek Polacek wrote: > > > + switch (extern int i = 0); /* { dg-error "in condition

Re: [PATCH] c: minor fixes related to arrays of unspecified size [PR116284,PR117391]

On Sat, 2 Nov 2024, Martin Uecker wrote: > c: minor fixes related to arrays of unspecified size > > The patch for PR117145 and PR117245 also fixed PR100420 and PR116284 > which are bugs related to arrays of unspecified. Those are now > represented > as variable size arrays w

Re: [pushed: r15-4760] diagnostics: support multiple output formats simultaneously [PR116613]

On Thu, 31 Oct 2024, David Malcolm wrote: > That said, I think setting LANG=C when running selftests is probably > the best solution. How does the attached (untested) patch look? LC_ALL takes precedence over LANG. OK with LC_ALL instead of or alongside LANG (assuming that passes testing). (No

  1   2   3   4   5   6   7   8   9   10   >