Re: [PATCH 0/8] [RFC] Introduce floating point fetch_add builtins

On Thu, 19 Sep 2024, mmalcom...@nvidia.com wrote: > 6) Anything special about floating point maths that I'm tripping up on? Correct atomic operations with floating-point operands should ensure that exceptions raised exactly correspond to the operands for which the operation succeeded, and not t

Re: [C PATCH] fix crash when checking for compatibility of structures [PR116726]

On Tue, 17 Sep 2024, Martin Uecker wrote: > Here is a fix for a mistake I made when recursively checking for > type compatibility. > > > Bootstrapped and regression tested on x86-64. > > > c: fix crash when checking for compatibility of structures [PR116726] > > When checking for

Re: *PING* [PATCH v3 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]

On Fri, 13 Sep 2024, Mikael Morin wrote: > *PING* > > Joseph, could you take a quick look at the handling of the new option? > > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661267.html Individual new options like this are expected to be reviewed by maintainers / reviewers for the rel

Re: [PATCH] libcpp, v5: Add support for gnu::base64 #embed parameter

On Thu, 12 Sep 2024, Jakub Jelinek wrote: > On Wed, Sep 11, 2024 at 10:23:20PM +0000, Joseph Myers wrote: > > On Fri, 30 Aug 2024, Jakub Jelinek wrote: > > > > > +should be no newlines in the string literal and because this parameter > > > +is meant namely f

Re: [PATCH] libcpp, v4: Add support for gnu::base64 #embed parameter

On Fri, 30 Aug 2024, Jakub Jelinek wrote: > +should be no newlines in the string literal and because this parameter > +is meant namely for use by the preprocessor itself, there is no support > +for any escape sequences in the string literal argument. If > @code{gnu::base64} Given the "no escape

Re: [PATCH] libcpp, v3: Add support for gnu::offset #embed/__has_embed parameter

On Fri, 30 Aug 2024, Jakub Jelinek wrote: > On Fri, Aug 16, 2024 at 04:58:58PM +0000, Joseph Myers wrote: > > On Thu, 15 Aug 2024, Jakub Jelinek wrote: > > > > > + else > > > + { > > > + if (res > INTTYPE_MAXIMUM (off_t)) > > > +

Re: [PATCH] libcpp, c-family, v4: Add (dumb) C23 N3017 #embed support [PR105863]

On Fri, 30 Aug 2024, Jakub Jelinek wrote: > Here is an updated version of the patch which uses a new flag in lang_flags > to control this. > I haven't touched the macro expansion or lack thereof from the earlier > version though. This patch is OK. -- Joseph S. Myers josmy...@redhat.com

Re: [RFC 0/4] Hard Register Constraints

A new feature for asm statements definitely needs documenting in the GCC manual. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] c, v2: Add support for unsequenced and reproducible attributes

On Fri, 30 Aug 2024, Jakub Jelinek wrote: > Here is the full updated patch. This patch is OK. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH RFC] libcpp: adjust pedwarn handling

On Wed, 28 Aug 2024, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu. Any objections? Should I change all the other > instances of > > if (CPP_PEDANTIC... > cpp_error (...CPP_DL_PEDWARN > > the same way? Yes, I think that's a good change. A followup question might be whether cases such a

Re: [PATCH] c, v2: Add support for unsequenced and reproducible attributes

On Thu, 1 Aug 2024, Jakub Jelinek wrote: > +Unsequenced functions without pointer or reference arguments are similar > +to functions with the @code{const} attribute, except that @code{const} > +attribute also requires finitness. So, both functions with @code{const} s/finitness/finiteness/ (in al

Re: [PATCH] libcpp, v3: Add support for gnu::base64 #embed parameter

On Thu, 15 Aug 2024, Jakub Jelinek wrote: > +#embed __FILE__ gnu::base64(1) prefix() suffix() /* { dg-error "expected > character string literal" } */ > +#embed __FILE__ gnu::base64() prefix() suffix() /* { dg-error "expected > character string literal" } */ Maybe also test this error with a no

Re: [PATCH] libcpp, c-family, v3: Add (dumb) C23 N3017 #embed support [PR105863]

On Fri, 16 Aug 2024, Jakub Jelinek wrote: > Ok. So for now, should I work on a patch variant which tries to follow > what is in C23 right now? Not sure how useful having such a patch variant would be until we have a better idea of what the desired semantics actually are. -- Joseph S. Myers jo

Re: [PATCH] libcpp, v2: Add support for gnu::offset #embed/__has_embed parameter

On Thu, 15 Aug 2024, Jakub Jelinek wrote: > + else > + { > + if (res > INTTYPE_MAXIMUM (off_t)) > + cpp_error_with_line (pfile, CPP_DL_ERROR, loc, 0, > + "too large 'gnu::offset' argument"); Having a testcase for this diagnostic

Re: [PATCH] libcpp, c-family, v3: Add (dumb) C23 N3017 #embed support [PR105863]

On Fri, 16 Aug 2024, Jakub Jelinek wrote: > On Fri, Aug 16, 2024 at 01:43:58AM +0200, Jakub Jelinek wrote: > > My reading of it wasn't that whether it is > > # embed < h-char-sequence > embed-parameter-sequence[opt] new-line > > or > > # embed < h-char-sequence > embed-parameter-sequence[opt] new-

Re: [PATCH] libcpp, c-family, v3: Add (dumb) C23 N3017 #embed support [PR105863]

On Fri, 16 Aug 2024, Jakub Jelinek wrote: > > Apart from any consequences for arguments of prefix/suffix/is_empty (where > > there is a plausible argument that the argument should get expanded at > > some point and that the current wording is undesirable for usability), > > this would also mean

Re: [PATCH] libcpp, c-family, v3: Add (dumb) C23 N3017 #embed support [PR105863]

On Thu, 15 Aug 2024, Jakub Jelinek wrote: > + D(embed, T_EMBED,STDC23,INCL | EXPAND) \ I'd like to query the macro expansion handling. My understanding is that a #embed directive only gets macro-expanded if it fails to match either of the forms # embed < h-char-

Re: [PATCH] libcpp, c-family, v2: Add (dumb) C23 N3017 #embed support [PR105863]

On Tue, 18 Jun 2024, Jakub Jelinek wrote: > The following patch implements the C23 N3017 "#embed - a scannable, > tooling-friendly binary resource inclusion mechanism" paper. Some initial comments, not yet reviewed the whole patch. > The patch uses --embed-dir= option that clang plans to add abo

Re: [PATCH] c: Enable -f{,no-}char8_t option for C/ObjC

On Wed, 14 Aug 2024, Jakub Jelinek wrote: > The following patch enables the option also for C/ObjC. I still disapprove of creating the combinatorial complexity of language variants with individual small features like this enabled / disabled, as I said in

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

On Thu, 8 Aug 2024, Alejandro Colomar wrote: > Here are the suspects: > > ./gcc/testsuite/gcc.target/powerpc/sse3-addsubps.c:80: > for (i = 0; i < sizeof (vals) / sizeof (vals); i += 8) The key question for testcases is *does the test actually test what was intended*? We never want to

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

On Thu, 8 Aug 2024, Alejandro Colomar wrote: > How about having __lengthof__ behave like sizeof, but deprecate it in > sizeof too? Deprecation would be a matter for WG14. > We could start by adding a -Wall warning for sizeof without parens, and > promote it to an error a few versions later. Thi

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

On Thu, 8 Aug 2024, Jens Gustedt wrote: > No, the ambiguity is there because the first ( after the keyword could > start either a type in parenthesis or an expression, and among these a > compound literal. If that first parenthesis would be part of the > construct (as for the typeof or offsetof

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

On Thu, 8 Aug 2024, Alejandro Colomar wrote: > Hi Jens, > > On Thu, Aug 08, 2024 at 11:13:02AM GMT, Jens Gustedt wrote: > > > but to maintain expectations, I think it would be better to do > > > the same here. > > > > Just to compare, the recent additions in C23 typeof etc. only have the > > par

Re: [PATCH v5 3/3] c: Add __lengthof__ operator

On Wed, 7 Aug 2024, Alejandro Colomar wrote: > +@node Length > +@section Determining the Length of Arrays > +@cindex lengthof > +@cindex length > +@cindex array length > + > +The keyword @code{__lengthof__} determines the length of an array operand, > +that is, the number of elements in the array.

Re: [RFC v4 0/4] c: Add __lengthof__ operator

On Tue, 6 Aug 2024, Alejandro Colomar wrote: > > Next question for the specification, implementation and tests: how does > > this feature interact with the rules on external definitions (the contexts > > in which it's OK to refer to an identifier with internal or external > > linkage that's nev

Re: [RFC v4 0/4] c: Add __lengthof__ operator

On Tue, 6 Aug 2024, Alejandro Colomar wrote: > - The tests seem to work as expected if I compile them manually, and >run (the one that should be run) as a normal program. The one that >should not be run also gives the expected diagnostics. >Can anyone give advice of why it's not runn

Re: Ping^6: [PATCH 0/2] Fix two test failures with --enable-default-pie [PR70150]

On Mon, 22 Jul 2024, Xi Ruoyao wrote: > On Mon, 2024-05-06 at 12:45 +0800, Xi Ruoyao wrote: > > In GCC 14.1-rc1, there are two new (comparing to GCC 13) failures if > > the build is configured --enable-default-pie.  Let's fix them. > > > > Tested on x86_64-linux-gnu.  Ok for trunk and releases/gc

Re: [PATCH v2] c: Add support for byte arrays in C2Y

On Sat, 13 Jul 2024, Martin Uecker wrote: > This marks structures which include a byte array > as typeless storage for all C language modes. > > > Bootstrapped and regression tested on x86_64. > > > > > c: Add support for byte arrays in C2Y > > To get correct aliasing behavior r

Re: [pushed] maintainer-scripts: Switch bug reporting URL to https

On Sun, 7 Jul 2024, Gerald Pfeifer wrote: > However, wouldn't it be so much better if we could import (or "import") > BUGURL from gcc/ where it is also set? Yes, it would seem reasonable to parse the ACX_BUGURL line in gcc/configure.ac. (It's not obvious that the URL should change more frequen

Re: [RFC v1 0/2] c: Add _Lengthof operator

On Sun, 28 Jul 2024, Alejandro Colomar wrote: > gcc/Makefile.in | 1 + > gcc/c-family/c-common.cc | 20 + > gcc/c-family/c-common.def | 4 ++ > gcc/c-family/c-common.h | 2 + > gcc/c/c-parser.cc | 35 +++ > gcc/c/c-tree.h

Re: [PATCH] c: Fix ICE for incorrect code in comptypes_verify [PR115696]

On Sat, 29 Jun 2024, Martin Uecker wrote: > This adds missing code for handling error marks. > > > Bootstrapped and regression tested on x86_64. > > > > c: Fix ICE for incorrect code in comptypes_verify [PR115696] > > The new verification code produces an ICE for incorrect code.

Re: [PATCH] c: Fix ICE for redeclaration of structs with different alignment [PR114727]

On Sat, 29 Jun 2024, Martin Uecker wrote: > This fixes an ICE when redeclaring a struct and having > an aligned attribute in one version in C23. > > > Bootstrapped and regression tested on x86_64. > > > > c: Fix ICE for redeclaration of structs with different alignment > [PR114727] >

Re: [PATCH] c: Add support for byte arrays in C2Y

On Sat, 29 Jun 2024, Martin Uecker wrote: > + bool typeless = flag_isoc2y > + && ((char_type_p (type) > + && !(type_quals & TYPE_QUAL_ATOMIC)) > + || (AGGREGATE_TYPE_P (type) > +

Re: [PATCH] c: ICE on invalid with attribute optimize [PR115549]

On Thu, 27 Jun 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > I had this PR in my open tabs so why not go ahead and fix it. > > decl_attributes gets last_decl, the last already pushed declaration, > to be used in common_handle_aligned_att

Re: [PATCH] c: ICE with invalid sizeof [PR115642]

On Wed, 26 Jun 2024, Marek Polacek wrote: > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > -- >8 -- > Here we ICE in c_expr_sizeof_expr on an erroneous expr.value. The > code checks for expr.value == error_mark_node but here the e_m_n is > wrapped in a C_MAYBE_CONST_EXPR. I do

Re: [PATCH] Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545]

On Sun, 23 Jun 2024, Martin Uecker wrote: > This fixes the test failures introduced by the fix for PR115109. > > Tested on x86_64 and also tested with -m32. > > > > Fix test errors after r15-1394 for sizeof(int)==sizeof(long) [PR115545] > > Some tests added to test the type of red

Re: [PATCH] c, v3: Fix ICE related to incomplete structures in C23 [PR114930]

On Thu, 20 Jun 2024, Jakub Jelinek wrote: > 2024-06-19 Jakub Jelinek > Martin Uecker > > PR c/114930 > PR c/115502 > gcc/c/ > * c-decl.cc (c_update_type_canonical): Assert t is main variant > with 0 TYPE_QUALS. Simplify and don't use check_qualified_type. >

Re: [PATCH] diagnostics: Fix add_misspelling_candidates [PR115440]

On Mon, 17 Jun 2024, Jakub Jelinek wrote: > 2024-06-17 Jakub Jelinek > > PR driver/115440 > * opts-common.cc (add_misspelling_candidates): If opt1 is non-NULL, > add a space and opt1 to the alternative suggestion text. > > * g++.dg/cpp1z/pr115440.C: New test. OK. --

[committed] c: Implement C2Y alignof on incomplete arrays

C2Y has adopted support for alignof applied to incomplete array types (N3273). Add this support to GCC. As the relevant checks are in c-family code that doesn't have access to functions such as pedwarn_c23, this remains a hard error for older versions and isn't handled by -Wc23-c2y-compat, althou

Re: [C PATCH, v3] Fix for redeclared enumerator initialized with different type [PR115109]

On Sat, 15 Jun 2024, Martin Uecker wrote: > The patch fails on arm because the tests make assumptions > about enums that are not true everywhere. Should we just  > limit the tests to x86? For compilation tests, using -fno-short-enums should work. That won't work for link / execute tests, but in

Re: [PATCH 2/3] Enabled LRA for ia64.

On Fri, 14 Jun 2024, Jonathan Wakely wrote: > Both, ideally. The libstdc++ test should definitely be fixed because > it fails with released versions of glibc already in the wild. But > glibc should also be fixed because it's a standards conformance issue. The __ctx macro used in various sys/ucont

[committed] c: Implement C2Y complex increment/decrement support

Support for complex increment and decrement (previously supported as an extension) was voted into C2Y today (paper N3259). Thus, change the pedwarn to a pedwarn_c23 and add associated tests. Note: the type of the 1 to be added / subtracted is underspecified (to be addressed in a subsequent paper)

Re: [PATCH] [alpha] adjust MEM alignment for block move [PR115459] (was: Re: [PATCH v2] [PR100106] Reject unaligned subregs when strict alignment is required)

On Thu, 13 Jun 2024, Maciej W. Rozycki wrote: > > This was tricky to duplicate without access to an alpha-linux-gnu > > machine. I ended up building an uberbaum tree with --disable-shared > > --disable-threads --enable-languages=ada up to all-target-libgcc, then I > > replaced gcc/collect2 with a

[committed] c: Add -std=c2y, -std=gnu2y, -Wc23-c2y-compat, C2Y _Generic with type operand

The first new C2Y feature, _Generic where the controlling operand is a type name rather than an expression (as defined in N3260), was voted into C2Y today. (In particular, this form of _Generic allows distinguishing qualified and unqualified versions of a type.) This feature also includes allowin

Re: [PATCH] c: Fix up pointer types to may_alias structures [PR114493]

On Tue, 4 Jun 2024, Jakub Jelinek wrote: > Hi! > > The following testcase ICEs in ipa-free-lang, because the > fld_incomplete_type_of > gcc_assert (TYPE_CANONICAL (t2) != t2 > && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE > (t))); > assertion doesn't hold. >

Re: [PATCH 06/52] m2: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE

On Sun, 2 Jun 2024, Kewen Lin wrote: > diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc > index 571923c08ef..d52cbdf0b99 100644 > --- a/gcc/m2/gm2-gcc/m2type.cc > +++ b/gcc/m2/gm2-gcc/m2type.cc > @@ -1420,7 +1420,7 @@ build_m2_short_real_node (void) >/* Define `REAL'. */ > >

Re: [PATCH 09/52] Replace {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE with new hook mode_for_floating_type

On Sun, 2 Jun 2024, Kewen Lin wrote: > +value less than or equal to mode precision of the mode used for C type > +@code{long double} (from hook @code{targetm.c.mode_for_floating_type} > +with tree_index TI_LONG_DOUBLE_TYPE). If you do not define this macro, > +mode precision of the mode used for

Re: [C PATCH, v3] Fix for redeclared enumerator initialized with different type [PR115109]

On Sat, 1 Jun 2024, Martin Uecker wrote: > This is a new version of the patch. I changed the overflow warning to > an error and added your other example to the test case. > > Bootstrapped and regression tested on x86_64. > > > c23: Fix for redeclared enumerator initialized with different t

Re: [PATCH v10 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

On Thu, 30 May 2024, Qing Zhao wrote: > In order to make this working, the routine digest_init in c-typeck.cc > is updated to fold calls to .ACCESS_WITH_SIZE to its first argument > when require_constant is TRUE. The new changes here are OK. -- Joseph S. Myers josmy...@redhat.com

Re: [RFC/PATCH] Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook

On Wed, 29 May 2024, Kewen.Lin wrote: > > Note that when removing a target macro, it's a good idea to add it to the > > "Old target macros that have moved to the target hooks structure." list > > (of #pragma GCC poison) in system.h to ensure any new target that was > > originally written before

Re: [C23 PATCH]: allow aliasing for types derived from structs with variable size

On Sun, 26 May 2024, Martin Uecker wrote: > +/* Helper function for comptypes. For two compatible types, return 1 > + if they pass consistency checks. In particular we test that > + TYPE_CANONICAL ist set correctly, i.e. the two types can alias. */ s/ist/is/. OK with that fix. -- Joseph

Re: [C23 PATCH, v2] fix aliasing for structures/unions with incomplete types

On Sun, 26 May 2024, Martin Uecker wrote: > This is the patch I sent previously, but I tried to improve the > description and added a long comment. This patch is needed so > that we do not have to update TYPE_CANONICAL of structures / unions > when a tagged type is completed that is (recursively)

Re: [C PATCH, v2]: allow aliasing of compatible types derived from enumeral types [PR115157]

On Fri, 24 May 2024, Martin Uecker wrote: > This is another version of this patch with two changes: > > - I added a fix (with test) for PR 115177 which is just the same > issue for hardbools which are internally implemented as enums. > > - I fixed the golang issue. Since the addition of the main

Re: [RFC/PATCH] Replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE with new hook

On Fri, 24 May 2024, Kewen.Lin wrote: > Following your suggestion and comments, I made this patch > for mode_for_floating_type first, considering this touches > a few FE and port specific code, I think I have to split > it into a patch series. Before making that, I'd like to > ensure this meets w

Re: [C PATCH]: allow aliasing of compatible types derived from enumeral types [PR115157]

On Tue, 21 May 2024, Martin Uecker wrote: > > C: allow aliasing of compatible types derived from enumeral types > [PR115157] > > Aliasing of enumeral types with the underlying integer is now allowed > by setting the aliasing set to zero. But this does not allow aliasing > of

Re: [C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

On Tue, 21 May 2024, Martin Uecker wrote: > > The constraint violated is the general one "If an identifier has no > > linkage, there shall be no more than one declaration of the identifier (in > > a declarator or type specifier) with the same scope and in the same name > > space, except that: .

Re: [C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

On Sun, 19 May 2024, Martin Uecker wrote: > c23 specifies that the type of a redeclared enumerator is the one of the > previous declaration. Convert initializers with different type > accordingly > and add -Woverflow warning. It doesn't make sense to use -Woverflow. Either the valu

Re: [C PATCH] Fix for some variably modified types not being recognized [PR114831]

On Sat, 18 May 2024, Martin Uecker wrote: > We did not propagate C_TYPE_VARIABLY_MODIFIED to pointers in all > cases.   I added this directly in two places, but maybe we should > check all cases of build_pointer_type or integrate this into  > c_build_pointer_type and use this everywhere (but I do

Re: [PATCH 1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

On Mon, 13 May 2024, Kewen.Lin wrote: > > In fact replacing all of X_TYPE_SIZE with a single hook might be worthwhile > > though this removes the "convenient" defaulting, requiring each target to > > enumerate all standard C ABI type modes. But that might be also a good > > thing. > > > > I gu

Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

On Wed, 8 May 2024, Richard Biener wrote: > So it's reasonable to require -fnon-call-exceptions (which now enables > -fexceptions) and -fno-delete-dead-exceptions to have GCC preserve > a change of control flow side-effect of x*x? We do not preserve > FP exception bits set by otherwise unused ope

Re: [PATCH] driver: Move -fdiagnostics-urls= early like -fdiagnostics-color= [PR114980]

On Wed, 8 May 2024, Xi Ruoyao wrote: > In GCC 14 we started to emit URLs for "command-line option is > valid for but not " and "-Werror= argument > '-Werror=' is not valid for " warnings. So we should > have moved -fdiagnostics-urls= early like -fdiagnostics-color=, or > -fdiagnostics-urls= wou

Re: [PATCH 1/4] rs6000: Make all 128 bit scalar FP modes have 128 bit precision [PR112993]

On Wed, 8 May 2024, Kewen.Lin wrote: > to widen IFmode to TFmode. To make build_common_tree_nodes > be able to find the correct mode for long double type node, > it introduces one hook mode_for_longdouble to offer target > a way to specify the mode used for long double type node. I don't really

Re: [PATCH 3/4] gcc/c-family/c-opts: fix quoting for `-fdeps-format=` error message

On Sat, 4 May 2024, Ben Boeckel wrote: > diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc > index be3058dca63..4a164ad0c0b 100644 > --- a/gcc/c-family/c-opts.cc > +++ b/gcc/c-family/c-opts.cc > @@ -370,7 +370,7 @@ c_common_handle_option (size_t scode, const char *arg, > HOST_WIDE_INT

Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

On Fri, 3 May 2024, Richard Biener wrote: > So what I do not necessarily agree with is that we need to preserve > the multiplication with -fsignaling-nans. Do we consider a program doing > > handler() { exit(0); } > > x = sNaN; > ... > sigaction(SIGFPE, ... handler) > x*x; > format_hard_dri

Re: [PATCH] libcpp: Adjust __STDC_VERSION__ for C23

On Thu, 25 Apr 2024, Jakub Jelinek wrote: > Hi! > > While the C23 standard isn't officially release yet, > in 2011 we've changed __STDC_VERSION__ value for C11 already > in the month in which the new __STDC_VERSION__ value has been > finalized, so we want to change this now or wait > until we imp

Re: [PATCH] libgcc: Do use weakrefs for glibc 2.34 on GNU Hurd

On Mon, 29 Apr 2024, Jakub Jelinek wrote: > On Mon, Apr 29, 2024 at 01:44:24PM +0000, Joseph Myers wrote: > > > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is > > > a > > > dummy shared library with just some symbol versions f

Re: [PATCH] libgcc: Don't use weakrefs for glibc 2.34

On Thu, 25 Apr 2024, Jakub Jelinek wrote: > Hi! > > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a > dummy shared library with just some symbol versions for compatibility, but > all the pthread_* APIs are in libc.so.6). I suspect this has caused link failures in the

Re: [RFC][PATCH v1 2/4] C and C++ FE changes to support flexible array members in unions and alone in structures.

On Fri, 19 Apr 2024, Qing Zhao wrote: > gcc/c/ChangeLog: > > * c-decl.cc (finish_struct): Change errors to pedwarns for the cases > flexible array members in union or alone in structures. The C front-end changes are OK for GCC 15 once everything else in the series is ready for inclu

Re: [RFC][PATCH v1 1/4] Documentation change

On Tue, 23 Apr 2024, Qing Zhao wrote: > However, I am not very confident on the wording of the doc, is the > current wording good enough for this? Or do you have any suggestion on > how to make it better? I'm not convinced the statement about size (in relation to a structure with the member om

Re: [RFC][PATCH v1 3/4] Add testing cases for flexible array members in unions and alone in structures.

On Fri, 19 Apr 2024, Qing Zhao wrote: > gcc/testsuite/ChangeLog: > > * gcc.dg/flex-array-in-union-1.c: New test. > * gcc.dg/flex-array-in-union-2.c: New test. There should also be a -pedantic-errors test that these constructs get errors with -pedantic-errors. The tests mix two case

Re: [RFC][PATCH v1 1/4] Documentation change

On Fri, 19 Apr 2024, Qing Zhao wrote: > +The size of the union is as if the flexiable array member were omitted > +except that it may have more trailing padding than the omission would imply. "trailing padding" is more a concept for structures than for unions (where padding depends on which unio

Re: [PATCH v9 1/5] Provide counted_by attribute to flexible array member field (PR108896)

This version of patch 1/5 is OK for GCC 15. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] c-family: Allow arguments with NULLPTR_TYPE as sentinels [PR114780]

On Fri, 19 Apr 2024, Jakub Jelinek wrote: > Ok for trunk and later 13.3 if it passes bootstrap/regtest (so far just > checked on the sentinel related C/C++ tests)? > > 2024-04-19 Jakub Jelinek > > PR c/114780 > * c-common.cc (check_function_sentinel): Allow as sentinel any >

Re: [PATCH] c, v3: Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

On Mon, 15 Apr 2024, Jakub Jelinek wrote: > 2024-04-15 Martin Uecker > Jakub Jelinek > > PR lto/114574 > PR c/114361 > gcc/c/ > * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not > ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY. > (parser_xr

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

On Wed, 10 Apr 2024, Qing Zhao wrote: > Okay, the above is very clear, thanks a lot for the explanation. > So, basically, for “counted-by” attribute: > **The following is good: > struct f { > int b; > int c; > int a[] __attribute__ ((counted_by (b))) }; > struct f { > int b; > int c; >

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

On Wed, 10 Apr 2024, Qing Zhao wrote: > A stupid question first, the same scope means the same file? (Or same > function) struct X { int a; }; struct X { int a; }; is an example of the same scope (file scope, in this case). The structures must have the same contents (in an appropriate sense)

Re: [PATCH v8 5/5] Add the 6th argument to .ACCESS_WITH_SIZE

The C front-end changes in this patch are OK for GCC 15. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v8 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

On Fri, 29 Mar 2024, Qing Zhao wrote: > +/* For a SUBDATUM field of a structure or union DATUM, generate a REF to > + the object that represents its counted_by per the attribute counted_by > + attached to this field if it's a flexible array member field, otherwise > + return NULL_TREE. > +

Re: [PATCH v8 4/5] Use the .ACCESS_WITH_SIZE in bound sanitizer.

The C front-end changes in this patch are OK for GCC 15. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)

On Fri, 29 Mar 2024, Qing Zhao wrote: > + /* Issue error when there is a counted_by attribute with a different > + field as the argument for the same flexible array member field. */ There's another case of this to consider, though I'm not sure where best to check for it (Martin might have

[committed] wwwdocs: gcc-14: Add release notes for C23 features

Add release notes for C23 features added in GCC 14. This doesn't cover any non-C23 new C features; any such features should also have release notes added. diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 934cd1ad..045893cf 100644 --- a/htdocs/gcc-14/changes.html +++ b/ht

Re: [C PATCH] fix aliasing for structures/unions with incomplete types

On Tue, 2 Apr 2024, Martin Uecker wrote: > Am Dienstag, dem 02.04.2024 um 20:42 + schrieb Joseph Myers: > > On Tue, 2 Apr 2024, Martin Uecker wrote: > > > > > [C23]fix aliasing for structures/unions with incomplete types > > > > > > When incomplete

Re: [C PATCH] fix aliasing for structures/unions with incomplete types

On Tue, 2 Apr 2024, Martin Uecker wrote: > [C23]fix aliasing for structures/unions with incomplete types > > When incomplete structure/union types are completed later, compatibility > of struct types that contain pointers to such types changes. When forming > equivalence classes for TYPE_CANONIC

Re: [C PATCH] Fix ICE with -g and -std=c23 related to incomplete types [PR114361]

On Tue, 2 Apr 2024, Martin Uecker wrote: > Fix ICE with -g and -std=c23 related to incomplete types [PR114361] > > We did not copy TYPE_CANONICAL to the incomplete variants when > completing a structure. > > PR c/114361 > > gcc/c/ > * c-decl.c (finish_struct): Set TY

Re: [PATCH] c-family: Cast __atomic_load_*/__atomic_exchange_* result to _BitInt rather then VCE it [PR114469]

On Wed, 27 Mar 2024, Jakub Jelinek wrote: > Hi! > > As written in the PR, torture/bitint-64.c test fails with -O2 -flto > and the reason is that on _BitInt arches where the padding bits > are undefined, the padding bits in the _Atomic vars are also undefined, > but when __atomic_load or __atomic_

Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)

On Tue, 26 Mar 2024, Qing Zhao wrote: > > What happens when there are multiple counted_by attributes on the same > > field? As far as I can see, all but one end up being ignored (by the code > > that actually uses the attribute). > > In general, is there any rule for handling multiple same att

Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)

On Tue, 26 Mar 2024, Qing Zhao wrote: > >> +@cindex @code{counted_by} variable attribute > >> +@item counted_by (@var{count}) > >> +The @code{counted_by} attribute may be attached to the C99 flexible array > >> +member of a structure. It indicates that the number of the elements of > >> the > >>

Re: [PATCH v7 3/5] Use the .ACCESS_WITH_SIZE in builtin object size.

On Wed, 20 Mar 2024, Qing Zhao wrote: > + the size of the element can be retrived from the result type of the call, > + which is the pointer to the array type. */ Again, start a sentence with an uppercase letter. > + /* if not for dynamic object size, return. */ > + /* result type is a

Re: [PATCH v7 2/5] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

On Wed, 20 Mar 2024, Qing Zhao wrote: > + /* get the TYPE of the counted_by field. */ Start comments with an uppercase letter. > + The type of the first argument of this function is a POINTER type > + to the orignal flexible array type. s/orignal/original/ > + If HANDLE_COUNTED_BY

Re: [PATCH v7 1/5] Provide counted_by attribute to flexible array member field (PR108896)

On Wed, 20 Mar 2024, Qing Zhao wrote: > + /* This attribute only applies to a C99 flexible array member type. */ > + else if (! c_flexible_array_member_type_p (TREE_TYPE (decl))) > +{ > + error_at (DECL_SOURCE_LOCATION (decl), > + "%qE attribute is not allowed for a non" >

Re: [PATCH] c-family, c++: Handle EXCESS_PRECISION_EXPR in pretty printers

On Fri, 22 Mar 2024, Jakub Jelinek wrote: > Hi! > > I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux: > PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for > warnings, line 15) > FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for > w

Re: [PATCH V2] Document -fexcess-precision=16.

On Wed, 20 Mar 2024, liuhongt wrote: > gcc/ChangeLog: > > * doc/invoke.texi: Document -fexcess-precision=16. OK. -- Joseph S. Myers josmy...@redhat.com

Re: [PATCH] Document -fexcess-precision=16.

On Tue, 19 Mar 2024, Hongtao Liu wrote: > On Tue, Mar 19, 2024 at 12:16 AM Joseph Myers wrote: > > > > On Mon, 18 Mar 2024, liuhongt wrote: > > > > > +If @option{-fexcess-precision=16} is specified, casts and assignments of > > > +@code{_Float16} and @cod

Re: [PATCH] Document -fexcess-precision=16.

On Mon, 18 Mar 2024, liuhongt wrote: > +If @option{-fexcess-precision=16} is specified, casts and assignments of > +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to their > +semantic types if they're supported by the target. Isn't that option about rounding results of all operat

Re: [PATCH] gcc_update: Add missing generated files

On Fri, 1 Mar 2024, Jonathan Wakely wrote: > I'm seeing errors for --enable-maintainer-mode builds due to incorrectly > regenerating these files. They should be touched by gcc_update so they > aren't regenerated unnecessarily. > > contrib/ChangeLog: > > * gcc_update: Add more generated fil

Re: [PATCH] libgcc: Fix quotient and/or remainder negation in __divmodbitint4 [PR114327]

On Fri, 15 Mar 2024, Jakub Jelinek wrote: > Hi! > > While for __mulbitint3 we actually don't negate anything and perform the > multiplication in unsigned style always, for __divmodbitint4 if the operands > aren't unsigned and are negative, we negate them first and then try to > negate them as nee

Re: [PATCH] libcpp: Fix __has_include_next ICE in the last directory of the path [PR80755]

On Thu, 21 Dec 2023, Lewis Hyatt wrote: > In libcpp/files.cc, the function _cpp_has_header(), which implements > __has_include and __has_include_next, does not check for a NULL return value > from search_path_head(), leading to an ICE tripping an assert when > _cpp_find_file() tries to use it. Fix

Re: [PATCH] libcpp: Fix macro expansion for argument of __has_include [PR110558]

On Tue, 12 Dec 2023, Lewis Hyatt wrote: > When the file name for a #include directive is the result of stringifying a > macro argument, libcpp needs to take some care to get the whitespace > correct; in particular stringify_arg() needs to see a CPP_PADDING token > between macro tokens so that it c

Re: [PATCH] doc: Fix docs for -dD regarding predefined macros

On Tue, 5 Mar 2024, Jakub Jelinek wrote: > I can't bisect that far, supposedly predefined macros weren't included back > in 1996 when this was written but maybe it changed in 1999 or even earlier. It looks like this changed in 3.0 (so probably with the move to cpplib to provide the default prepr

Re: [PATCH v5 RESEND] C, ObjC: Add -Wunterminated-string-initialization

On Mon, 26 Feb 2024, Alejandro Colomar wrote: > > The idea seems reasonable, but the patch needs documentation for the new > > option in invoke.texi. > > Thanks! Will do. > > I don't see an obvious order in that file. Where would you put the > option? Do you want me to sort(1) it first, and

  1   2   3   4   5   6   7   8   9   10   >