Re: [C PATCH 1/6] c: reorganize recursive type checking

On Sat, 26 Aug 2023, Martin Uecker via Gcc-patches wrote: > -static int > +static bool > comp_target_types (location_t location, tree ttl, tree ttr) The comment above this function should be updated to refer to returning true, not to returning 1. And other comments on common_pointer_type and

Re: [PATCH] c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

On Tue, 5 Sep 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > Now that _Float{16,32,64,128,32x,64x,128x} and > {f,F}{16,32,64,128,32x,64x,128x} literal suffixes are in C23 standard, > I think it is undesirable to pedwarn about these for -std=c2x, so this > patch uses pedwarn_c11 instead.

Re: [PATCH 13/12 v2] C _BitInt incremental fixes [PR102989]

On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > On Thu, Aug 10, 2023 at 12:10:07PM +0200, Jakub Jelinek via Gcc-patches wrote: > > Here is an incremental patch which does that: > > Bootstrap/regtest on i686-linux (next to x86_64-linux where it went fine) > revealed I forgot to add {

Re: [PATCH 10/12] C _BitInt support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > This patch adds the C FE support, c-family support, small libcpp change > so that 123wb and 42uwb suffixes are handled plus glimits.h change > to define BITINT_MAXWIDTH macro. > > The previous patches really do nothing without

Re: [PATCH 9/12] libgcc _BitInt support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > I know that soft-fp is owned by glibc and I think the op-common.h change > should be propagated there, but the bitint stuff is really GCC specific > and IMHO doesn't belong into the glibc copy. The op-common.h change is OK for glibc.

Re: [PATCH 14/12] libgcc _BitInt helper documentation [PR102989]

On Tue, 22 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > +significant limb if @var{N} is not divisible by @var{N} should be @var{n}, throughout. > +@deftypefn {Runtime Function} void __bid_fixsdbitint (@code{UBILtype} > *@var{r}, int32_t @var{rprec}, _Decimal32 @var{a}) > +@deftypefnx

Re: [PATCH 8/12] libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following patch adds a header with generated helper tables to support > computation of powers of 10 from 10^0 to 10^6111 inclusive into a > sufficiently large array of _BitInt limbs. This is split from the rest > of the

Re: [PATCH v2 1/4] LoongArch: improved target configuration interface

On Thu, 31 Aug 2023, Yujie Yang wrote: > -If none of such suffix is present, the configured value of > -@option{--with-multilib-default} can be used as a common default suffix > -for all library ABI variants. Otherwise, the default build option > -@code{-march=abi-default} is applied when

Re: [PATCH v2 1/4] LoongArch: improved target configuration interface

On Wed, 30 Aug 2023, Yang Yujie wrote: > +A suffix @code{[/ARCH][/OPTION]...]} may follow immediately after the ABI > +identifier to customize the compiler options for building the given set of > +libraries. @code{ARCH} denotes the architecture name recognized by the > +@code{-march=ARCH}

Re: Darwin: Replace environment runpath with embedded [PR88590]

On Tue, 29 Aug 2023, FX Coudert via Gcc-patches wrote: > > The driver changes are still OK. > > Just to be clear: apart from you and Iain, whose approval do I need (and > for what parts)? I think a build machinery review is needed. -- Joseph S. Myers jos...@codesourcery.com

Re: Darwin: Replace environment runpath with embedded [PR88590]

On Fri, 25 Aug 2023, FX Coudert via Gcc-patches wrote: > Hi, > > Thanks Joseph for the review. > > > The driver changes are OK. > > > > I think the new configure options and the new -nodefaultrpaths compiler > > option need documenting > > Doc patch was added, and okay’ed by Iain. I see

Re: [PATCH v7 1/4] driver: add a spec function to join arguments

On Wed, 23 Aug 2023, Jason Merrill via Gcc-patches wrote: > Joseph, any thoughts on these issues or the workaround? I don't have any comments here. -- Joseph S. Myers jos...@codesourcery.com

Re: Patch ping Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Mon, 21 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Joseph, could I ask now at least for an overall design review of the > C patches (8-10,13) whether its interfaces with middle-end are ok, > so that Richi can review the middle-end parts? I am fine with the interface to the middle-end

Re: Darwin: Replace environment runpath with embedded [PR88590]

On Fri, 18 Aug 2023, Iain Sandoe via Gcc-patches wrote: > There is quite extensive Apple Developer documentation on delivering > packages with co-installed libraries using @rpath (that is the intended > mechanism for delivery since it allows drag-and-drop installation and > moving of built

Re: Darwin: Replace environment runpath with embedded [PR88590]

On Tue, 15 Aug 2023, FX Coudert via Gcc-patches wrote: > I am currently retesting the patches on various archs (Linux and Darwin) > after a final rebase, but various previous versions were > regression-tested, and have been shipped for a long time in Homebrew. > > OK to commit? The driver

Re: [PATCH] c: Add support for [[__extension__ ...]]

On Fri, 18 Aug 2023, Richard Sandiford via Gcc-patches wrote: > [[]] attributes are a recent addition to C, but as a GNU extension, > GCC allows them to be used in C11 and earlier. Normally this use > would trigger a pedwarn (for -pedantic, -Wc11-c2x-compat, etc.). > > This patch allows the

Re: [PATCH V4] Add warning options -W[no-]compare-distinct-pointer-types

On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote: > +@opindex Wcompare-distinct-pointer-types > +@item -Wcompare-distinct-pointer-types This @item should say @r{(C and Objective-C only)}, since the option isn't implemented for C++. OK with that change. -- Joseph S. Myers

Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.

On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote: > So I guess we just need > > builtin_define ("__builtin_fabsq=__builtin_fabsf128"); > builtin_define ("__builtin_nanq=__builtin_nanf128"); > > etc. to map the "q" builtins to "f128" builtins if we really need the > "q" builtins. > >

Re: [PING] Re: [PATCH v2] Re: [WIP] Have -Wpointer-sign be enabled by -Wextra, too [PR109836]

On Wed, 16 Aug 2023, Eric Gallager via Gcc-patches wrote: > PING > > On Tue, Aug 8, 2023 at 8:17 PM Eric Gallager wrote: > > > > On Tue, May 30, 2023 at 5:42 PM Eric Gallager wrote: > > > > > > PR109836 is a request to have -Wpointer-sign enabled by default. There > > > were points of

Re: [WIP RFC] Add support for keyword-based attributes

On Wed, 16 Aug 2023, Richard Sandiford via Gcc-patches wrote: > Would it be OK to add support for: > > [[__extension__ ...]] > > to suppress the pedwarn about using [[]] prior to C2X? Then we can That seems like a plausible feature to add. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.

On Wed, 16 Aug 2023, chenxiaolong wrote: > Thanks for the tip! Similar functions (e.g. __builtin_fabsf128 > (_Float128 a) are already supported by the compiler and can be handled > correctly, but functions that can be implemented on the LoongArch > architecture directly using the "bstrins"

Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.

On Tue, 15 Aug 2023, chenxiaolong wrote: > In the implementation process, the "q" suffix function is > Re-register and associate the "__float128" type with the > "long double" type so that the compiler can handle the > corresponding function correctly. The functions

Re: [PATCH] c, v4: Add stdckdint.h header for C23

On Fri, 11 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > On Fri, Aug 11, 2023 at 01:25:38PM +0000, Joseph Myers wrote: > > On Fri, 11 Aug 2023, Jakub Jelinek wrote: > > > > > All that is diagnosed is when result is bool or enum (any kind). Even for > > &g

Re: [PATCH] c, v3: Add stdckdint.h header for C23

On Fri, 11 Aug 2023, Jakub Jelinek wrote: > All that is diagnosed is when result is bool or enum (any kind). Even for I'd suggest tests that other nonsense cases are diagnosed, such as floating-point or pointer arguments or results (hopefully such cases are already diagnosed and just need

Re: [PATCH] stdckdint.h _BitInt test

On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following patch (on top of the stdckdint.h patch and _BitInt patch > series) adds a test for _BitInt diagnostics of ckd_{add,sub,mul} macros. I remain unconvinced that diagnosing use with types where it's clear what the

Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename)

On Thu, 10 Aug 2023, Jason Merrill via Gcc-patches wrote: > On 8/10/23 11:35, Jakub Jelinek wrote: > > Hi! > > > > I'd like to ping this patch. Reposting it as I found a typo in the > > documentation - s/builtin-in/built-in/. Bootstrapped/regtested again > > on x86_64-linux and i686-linux, ok

Re: [PATCH] c, v2: Add __typeof_unqual__ and __typeof_unqual support

On Thu, 10 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > I'd like to ping this patch. Reposting it as the extend.texi hunk > didn't apply cleanly anymore. Bootstrapped/regtested again on x86_64-linux > and i686-linux, ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com

Re: Intel AVX10.1 Compiler Design and Support

On Thu, 10 Aug 2023, Richard Biener via Gcc-patches wrote: > Isn't this situation similar to the not defined ABI when passing generic > vectors (via __attribute__((vector_size))) that do not map to vectors > supported > by the current ISA? There's cases like vector<2> char or vector<1> double >

Re: c: Support for -Wuseless-cast [RR84510]

On Thu, 10 Aug 2023, Martin Uecker via Gcc-patches wrote: > c: Support for -Wuseless-cast [RR84510] > > Add support for Wuseless-cast C (and ObjC). > > PR c/84510 > > gcc/c/: > * c-typeck.cc (build_c_cast): Add warning. > > gcc/doc/: > * invoke.texi: Update. >

[PATCH] config: Fix host -rdynamic detection for build != host != target

The GCC_ENABLE_PLUGINS configure logic for detecting whether -rdynamic is necessary and supported uses an appropriate objdump for $host binaries (running on $build) in cases where $host is $build or $target. However, it is missing such logic in the case where $host is neither $build nor $target,

Re: [PATCH 0/12] GCC _BitInt support [PR102989]

On Wed, 9 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > - _Complex _BitInt(N) isn't supported; again mainly because none of the psABIs > mention how those should be passed/returned; in a limited way they are > supported internally because the internal functions into which >

RE: Intel AVX10.1 Compiler Design and Support

On Wed, 9 Aug 2023, Wang, Phoebe via Gcc-patches wrote: > Proposal 3: Change the ABI of 512-bit vector and always be > passed/returned from memory. Changing ABIs like that for existing code that has worked for some time on existing hardware is a bad idea. At this point it seems appropriate to

Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb

On Wed, 9 Aug 2023, Arsen Arsenović via Gcc-patches wrote: > Joseph Myers writes: > > > On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote: > > > >> Yes. Libtool was forked over a decade ago. My next project is syncing > >> upstream and us back up

Re: [RFC] GCC Security policy

On Tue, 8 Aug 2023, David Malcolm via Gcc-patches wrote: > However, consider a situation in which someone attempted to, say, embed > libgccjit inside a web browser to generate machine code from > JavaScript, where the JavaScript is potentially controlled by an > attacker. I think we want to

Re: Intel AVX10.1 Compiler Design and Support

Do you have any comments on the interaction of AVX10 with the micro-architecture levels defined in the ABI (and supported with glibc-hwcaps directories in glibc)? Given that the levels are cumulative, should we take it that any future levels will be ones supporting 512-bit vector width for

Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb

On Tue, 8 Aug 2023, Arsen Arsenović via Gcc-patches wrote: > Yes. Libtool was forked over a decade ago. My next project is syncing > upstream and us back up. Unsure about pkg.m4. Note as per previous discussions that libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c will need reverting

Re: [PATCH 1/5] Middle-end _BitInt support [PR102989]

On Fri, 4 Aug 2023, Richard Biener via Gcc-patches wrote: > > Sorry, I hoped it wouldn't take me almost 3 months and would be much shorter > > as well, but clearly I'm not good at estimating stuff... > > Well, it’s definitely feature creep with now the _Decimal and bitfield stuff … I think

Re: [C PATCH] _Generic should not warn in non-active branches [PR68193,PR97100]

On Fri, 4 Aug 2023, Martin Uecker via Gcc-patches wrote: > Here is a patch to reduce false positives in _Generic. > > Bootstrapped and regression tested on x86_64-linux. > > Martin > > c: _Generic should not warn in non-active branches [PR68193,PR97100] > > To avoid false

Re: [PATCH] Add documentation for -Wflex-array-member-not-at-end.

On Thu, 3 Aug 2023, Qing Zhao via Gcc-patches wrote: > +@opindex Wflex-array-member-not-at-end > +@opindex Wno-flex-array-member-not-at-end > +@item -Wflex-array-member-not-at-end I'd expect this to have @r{(C and C++ only)} to indicate what languages the option applies to. OK with that

Re: [PATCH] c-family: Add _BitInt support for __atomic_*fetch* [PR102989]

On Thu, 3 Aug 2023, Jakub Jelinek via Gcc-patches wrote: > --- gcc/testsuite/gcc.dg/bitint-18.c.jj 2023-08-03 12:26:35.510922996 > +0200 > +++ gcc/testsuite/gcc.dg/bitint-18.c 2023-08-03 12:26:42.114831050 +0200 > @@ -0,0 +1,44 @@ > +/* PR c/102989 */ > +/* { dg-do compile { target bitint

RE: [PATCH 2/2][frontend]: Add novector C pragma

On Wed, 2 Aug 2023, Tamar Christina via Gcc-patches wrote: > Ping. > > > -Original Message- > > From: Tamar Christina > > Sent: Wednesday, July 26, 2023 8:35 PM > > To: Tamar Christina ; gcc-patches@gcc.gnu.org > > Cc: nd ; jos...@codesourcery.com > > Subject: RE: [PATCH 2/2][frontend]:

Re: _BitInt vs. _Atomic

On Tue, 1 Aug 2023, Michael Matz via Gcc-patches wrote: > Only because cmpxchg is defined in terms of memcpy/memcmp. If it were > defined in terms of the == operator (obviously applied recursively > member-wise for structs) and simple-assignment that wouldn't be a problem. It also wouldn't

Re: [PATCH] preprocessor: c++: Support `#pragma GCC target' macros [PR87299]

On Mon, 31 Jul 2023, Lewis Hyatt via Gcc-patches wrote: > I added some additional testcases from the PR for x86. The other targets > that support `#pragma GCC target' (aarch64, arm, nios2, powerpc, s390) > already had tests verifying that the pragma sets macros as expected; here I > have added

Re: [PATCH RESEND] c: add -Wmissing-variable-declarations [PR65213]

On Mon, 31 Jul 2023, Hamza Mahfooz wrote: > Hey Joseph, > > On Fri, Jul 28 2023 at 08:32:31 PM +00:00:00, Joseph Myers > wrote: > > > OK. > > > > -- > > Joseph S. Myers > > jos...@codesourcery.com > > Since I don't have write access, do

Re: [PING 3] [PATCH] Less warnings for parameters declared as arrays [PR98541, PR98536]

On Mon, 31 Jul 2023, Martin Uecker via Gcc-patches wrote: > Joseph, I would appreciate if you could take a look at this? > > This fixes the remaining issues which requires me to turn the > warnings off with -Wno-vla-parameter and -Wno-nonnull in my > projects. The front-end changes are OK.

Re: [PATCH v2] c-family: Implement pragma_lex () for preprocess-only mode

On Fri, 28 Jul 2023, Jason Merrill via Gcc-patches wrote: > > Thanks, I had thought there could be a potential issue with needing to also > > check cpp_get_options(pfile)->traditional. But looking at it more, there's > > no > > code path currently that can end up here in traditional mode, so yes

Re: [PATCH] gcc-ar: Handle response files properly [PR77576]

This patch is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH RESEND] c: add -Wmissing-variable-declarations [PR65213]

On Tue, 18 Jul 2023, Hamza Mahfooz wrote: > Resolves: > PR c/65213 - Extend -Wmissing-declarations to variables [i.e. add > -Wmissing-variable-declarations] > > gcc/c-family/ChangeLog: > > PR c/65213 > * c.opt (-Wmissing-variable-declarations): New option. > > gcc/c/ChangeLog: > >

Re: [RFC WIP PATCH] _BitInt bit-field support [PR102989]

On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > But I ran into a compiler divergence on _Generic with bit-field expressions. > My understanding is that _Generic controlling expression undergoes array > to pointer and function to pointer conversions, but not integral promotions >

Re: _BitInt vs. _Atomic

On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > The C++ way of dealing with this is using __builtin_clear_padding, > done on atomic stores/updates of the atomic memory (padding is cleared > if any on the value to be stored, or on the expected and desired values). > > I don't know

Re: [PATCH 0/5] GCC _BitInt support [PR102989]

On Fri, 28 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > I had a brief look at libbid and am totally unimpressed. > Seems we don't implement {,unsigned} __int128 <-> _Decimal{32,64,128} > conversions at all (we emit calls to __bid_* functions which don't exist), That's bug 65833. > the

Re: [PATCH 5/5] testsuite part 2 for _BitInt support [PR102989]

I think there should be tests for _Atomic _BitInt types. Hopefully atomic compound assignment just works via the logic for compare-and-exchange loops, but does e.g. atomic_fetch_add work with _Atomic _BitInt types? -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH 0/5] GCC _BitInt support [PR102989]

On Thu, 27 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > - _BitInt(N) bit-fields aren't supported yet (the patch rejects them); I'd > like > to enable those incrementally, but don't really see details on how such > bit-fields should be laid-out in memory nor passed inside of function >

Re: [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]

On Mon, 24 Jul 2023, Jakub Jelinek via Gcc-patches wrote: > I believe it is only +- which has this problematic behavior and I think fma has the same property (of rounding-mode-dependent exact results), but I think that's not relevant here? -- Joseph S. Myers jos...@codesourcery.com

Re: [WIP RFC] Add support for keyword-based attributes

On Mon, 17 Jul 2023, Michael Matz via Gcc-patches wrote: > So, essentially you want unignorable attributes, right? Then implement > exactly that: add one new keyword "__known_attribute__" (invent a better > name, maybe :) ), semantics exactly as with __attribute__ (including using > the same

Re: [PATCH] [vect]Use intermiediate integer type for float_expr/fix_trunc_expr when direct optab is not existed.

On Wed, 21 Jun 2023, Richard Biener via Gcc-patches wrote: > > > int32_t x = (int32_t)0x1.0p32; > > > int32_t y = (int32_t)(int64_t)0x1.0p32; > > > > > > sets x to 2147483647 and y to 0. > > Hmm, good question. GENERIC has a direct truncation to unsigned char > for example, the C standard

Re: [PATCH] Update array address space in c_build_qualified_type

On Wed, 21 Jun 2023, Richard Biener via Gcc-patches wrote: > > This patch sets the address space of the array type to that of the > > element type. > > > > Regression tests for avr look ok. Ok for trunk? > > The patch looks OK to me but please let a C frontend maintainer > double-check

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote: > > So for > > > > struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; }; > > > > one knows during parsing that the .d is a designator > > and that .c is not. > > Therefore, the above should be invalid based on this rule since .c

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote: > > Note that no expressions can start with the '.' token at present. As soon > > as you invent a new kind of expression that can start with that token, you > > have syntactic ambiguity. > > > > struct s1 { int c; char a[(struct s2 {

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote: > B. The argument of the new attribute “counted_by” is an identifier that can be > accepted by “c_parser_attribute_arguments”: > > struct trailing_array_B { > Int count; > int array_B[] __attribute ((counted_by (count))); > }; > > > From

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote: > Comparing B with A, I don’t see too much benefit, either from > user-interface point of view, or from implementation point of view. > > For implementation, both A and B need to search the fields of the > containing structure by the name

Re: [RFC] Add stdckdint.h header for C23

On Tue, 13 Jun 2023, Paul Eggert wrote: > > There is always the possibility to have the header co-owned by both > > the compiler and C library, limits.h style. > > Just > > #if __has_include_next() > > # include_next > > #endif > > I don't see how you could implement __has_include_next() for >

Re: [RFC] Add stdckdint.h header for C23

On Tue, 13 Jun 2023, Jakub Jelinek via Gcc-patches wrote: > Yeah, having say __builtin_{clz,ctz,ffs,popcount,parity} variants which would > be typegeneric and would allow say any normal integral or _BitInt type > (or just unsigned versions thereof?) would be useful. Even without _BitInt > we

Re: [ping] driver: Forward '-lgfortran', '-lm' to offloading compilation

On Tue, 13 Jun 2023, Thomas Schwinge wrote: > Hi! > > On 2023-06-05T14:25:18+0200, I wrote: > > OK to push the attached > > "driver: Forward '-lgfortran', '-lm' to offloading compilation"? > > (We didn't have a PR open for that, or did we?) > > Ping. OK. -- Joseph S. Myers

Re: [RFC] Add stdckdint.h header for C23

On Tue, 13 Jun 2023, Jakub Jelinek via Gcc-patches wrote: > There is always the possibility to have the header co-owned by both > the compiler and C library, limits.h style. > Just > #if __has_include_next() > # include_next > #endif > perhaps guarded with some macro at the end of the GCC

Re: [RFC] Add stdckdint.h header for C23

On Sat, 10 Jun 2023, Jakub Jelinek via Gcc-patches wrote: > I have looked at gnulib stdckdint.h and they are full of workarounds > for various compilers, EDG doesn't do this, clang <= 14 can't multiply > __int128, ..., so I think the header belongs into the compiler rather > than C library,

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote: > Are you suggesting to use identifier directly as the argument of the > attribute? > I tried this in the beginning, however, the current parser for the attribute > argument can not identify that this identifier is a field identifier inside

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote: > Hi, Joseph, > > A question here: can an identifier in C be a wide char string? Identifiers and strings are different kinds of tokens; an identifier can't be a string of any kind, wide or narrow. It just so happens that the proposed

Re: [V9][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

On Tue, 30 May 2023, Qing Zhao via Gcc-patches wrote: > Joseph, > > could you please review this patch and see whether it's Okay for commit > now? This version is OK. -- Joseph S. Myers jos...@codesourcery.com

Re: [C PATCH 3/4] introduce ubsan checking for assigment of VM types 3/4

On Mon, 29 May 2023, Martin Uecker via Gcc-patches wrote: > Support instrumentation of function arguments for functions > called via a declaration. We can support only simple size What do you mean by "via a declaration"? If the *definition* is visible (and known to be the definition

Re: [C PATCH] -Wstringop-overflow for parameters with forward-declared sizes

On Fri, 26 May 2023, Martin Uecker via Gcc-patches wrote: > c: -Wstringop-overflow for parameters with forward-declared sizes > > Warnings from -Wstringop-overflow do not appear for parameters declared > as VLAs when the bound refers to a parameter forward declaration. This >

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote: > Another question: is it better for me to rearrange the Patch 1/2 and Patch > 2/2 a little bit, > to put the FE , doc change and corresponding testing case together into one > patch, (you have approved the FE part of change in Patch

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote: > > What if the string is a wide string? I don't expect that to work (either > > as a matter of interface design, or in the present code), but I think that > > case should have a specific check and error. > > Dump question: how to check

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

On Thu, 25 May 2023, Qing Zhao via Gcc-patches wrote: > > On May 25, 2023, at 4:51 PM, Joseph Myers wrote: > > > > The documentation in this case is OK, though claims about how a future > > version will behave have a poor track record (we tend to end up with suc

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

What happens if the field giving the number of elements is in a contained anonymous structure or union? struct s { struct { size_t count; }; int array[] __attribute__ ((element_count ("count"))); }; This ought to work - a general principle in C is that anonymous structures and unions are

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

The documentation in this case is OK, though claims about how a future version will behave have a poor track record (we tend to end up with such claims persisting in the documentation even though the change in question didn't get made and might sometimes no longer be considered desirable). --

Re: [C PATCH v3] Fix ICEs related to VM types in C 2/2

On Mon, 22 May 2023, Martin Uecker via Gcc-patches wrote: > +static void > +add_decl_expr(location_t loc, enum decl_context decl_context, tree type, > tree *expr) Missing space before '(', and the line should be wrapped to be no more than 80 columns. The C front-end changes are OK with those

Re: [V7][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

On Fri, 19 May 2023, Qing Zhao via Gcc-patches wrote: > +GCC extension accepts a structure containing an ISO C99 @dfn{flexible array "The GCC extension" or "A GCC extension". > +@item > +A structure containing a C99 flexible array member, or a union containing > +such a structure, is the middle

Re: [C PATCH] Remove dead code related to type compatibility across TUs.

On Fri, 19 May 2023, Martin Uecker via Gcc-patches wrote: > Repost for stage 1. > > > C: Remove dead code related to type compatibility across TUs. > > Code to detect struct/unions across the same TU is not needed > anymore. Code for determining compatibility of tagged types is

Re: [C PATCH v2] Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450]

On Fri, 19 May 2023, Martin Uecker via Gcc-patches wrote: > Thanks Joseph! > > Revised version attached. Ok? The C front-end changes and tests are OK. > But I wonder whether we generally need to do something  > about > > sizeof *x > > when x is NULL or not initialized. This is quite

[committed] c: Do not allow thread-local tentative definitions for C2x

C2x makes it clear that thread-local declarations can never be tentative definitions (the legacy feature of C where you can e.g. do "int i;" more than once at file scope, possibly with one of the declarations initialized, and it counts as exactly one definition), but are always definitions in the

Re: [PING] [C PATCH] Fix ICEs related to VM types in C [PR106465, PR107557, PR108423, PR109450]

On Thu, 18 May 2023, Martin Uecker via Gcc-patches wrote: > + /* we still have to evaluate size expressions */ Comments should start with a capital letter and end with ". ". > diff --git a/gcc/testsuite/gcc.dg/nested-vla-1.c > b/gcc/testsuite/gcc.dg/nested-vla-1.c > new file mode 100644

[committed] c: Handle printf %B like %b for C2x

WG14 decided to change the printf %B format from a recommended extension to an optional feature defined in normative text. Thus, change the format checking to handle %B like %b, so not diagnosing it with -Wformat -std=c2x -pedantic, just as with other optional normatively defined features (such

[committed] c: Remove restrictions on declarations in 'for' loops for C2X

C2X removes a restriction that the only declarations in the declaration part of a 'for' loop are declarations of objects with storage class auto or register. Implement this change, making the diagnostics into pedwarn_c11 calls instead of errors (as usual for features added in a new standard

[committed] c: Ignore _Atomic on function return type for C2x

For C2x it was decided that _Atomic would be completely ignored on function return types (just as was done for qualifiers in C11 DR#423), to eliminate the potential for an rvalue returned by a function having _Atomic-qualified type when an rvalue resulting from lvalue-to-rvalue conversion could

[committed] c: Update __has_c_attribute values for C2x

WG14 decided that __has_c_attribute should return the same value (equal to the intended __STDC_VERSION__ value) for all standard attributes in C2x, with values associated with when an attribute was added to the working draft (or had semantics added or changed in the working draft) only being used

Re: [PATCH] Add RTX codes for BITREVERSE and COPYSIGN.

On Sat, 6 May 2023, Roger Sayle wrote: > An analysis of backend UNSPECs reveals that two of the most common UNSPECs > across target backends are for copysign and bit reversal. This patch > adds RTX codes for these expressions to allow their representation to > be standardized, and them to

Re: [PATCH] c: Fix up error-recovery on non-empty VLA initializers [PR109409]

On Fri, 14 Apr 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > On the following testcase we ICE, because after we emit the > variable-sized object may not be initialized except with an empty initializer > error we don't really reset the initializer to error_mark_node and then at > -Wformat

Re: [PATCH] c: Fix up error-recovery on functions initialized as variables [PR109412]

On Fri, 14 Apr 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The change to allow empty initializers in C broke error-recovery on the > following testcase. We are emitting function %qD is initialized like a > variable error early; if the initializer is non-empty, we just emit > another

Re: Fix ICEs related to VM types in C [PR106465, PR107557, PR108424, PR109450]

On Tue, 11 Apr 2023, Martin Uecker via Gcc-patches wrote: > Ok, here is another attempt on fixing issues with size expression. > Not all are regressions, but it does not make sense to try to split > it up. This wording implies this is version 2 or later of the patch, could you please give a

Re: [PATCH 2/2] Remove Negative(gwarf-) from gdwarf

On Fri, 24 Mar 2023, Richard Biener via Gcc-patches wrote: > Prior to the removal of STABS support the gdwarf, gstabs, ... options > formed a cycle with their Negative(..) option attribute. But that > didn't actually have any effect since most of the options also > are Joined or JoinedOrMissing

Re: [PATCH 1/2] Disallow -gno-dwarf, gno-dwarf-N, -gno-gdb and -gno-vms

On Fri, 24 Mar 2023, Richard Biener via Gcc-patches wrote: > The following adds RejectNegative to the gdwarf, gdwarf-, ggdb and gvms > options since the current behavior is to treat the negative variant > the same as the positive variant. In particular -ggdb -gno-gdb > do not cancel, and plain

Re: Fwd: [V5][PATCH 2/2] Update documentation to clarify a GCC extension

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote: > +Wgnu-variable-sized-type-not-at-end > +C C++ Var(warn_variable_sized_type_not_at_end) Warning > +Warn about structures or unions with C99 flexible array members are not > +at the end of a structure. I think there's at least one word

Re: Fwd: [V5][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

On Thu, 23 Mar 2023, Qing Zhao via Gcc-patches wrote: > gcc/c/ChangeLog: > > PR tree-optimization/101832 > * c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for > struct/union type. The C front-end changes are OK (supposing the original patch has correct whitespace,

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

On Mon, 20 Mar 2023, Sandra Loosemore wrote: > Joseph, could you maybe review the last piece? A direct pointer to it in > Arsen's git is > > https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3 That's OK, assuming I understand correctly that makeinfo will still succeed

stor-layout: Set TYPE_TYPELESS_STORAGE consistently for type variants

I've observed an LTO wrong-code bug with a large testcase in GCC 12, that results from TYPE_TYPELESS_STORAGE not being set consistently on type variants. Specifically, in the LTO stage of compilation, there is an aggregate type passed to get_alias_set, whose TYPE_MAIN_VARIANT does not have

Re: Patch ping

On Wed, 1 Mar 2023, Jakub Jelinek via Gcc-patches wrote: > Hi! > > I'd like to ping a few pending patches: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html > - PR107846 - P1 - c-family: Account for integral promotions of left shifts > for -Wshift-overflow warning OK.

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > But the following: > > struct flex1 { int length1; char data1[]; }; > struct flex2 { int length2; char data2[]; }; > union union_flex { struct flex1 f1; struct flex2 f2; }; /* this is C > standard. */ > > struct out_flex { int n;

Re: Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote: > +@item > +The structure with a C99 flexible array member is the field of > +another union, for example: > + > +@smallexample > +struct flex1 @{ int length1; char data1[]; @} > +struct flex2 @{ int length2; char data2[]; @} > + > +union

Re: [PING, v2] Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere

On Tue, 21 Feb 2023, Thomas Schwinge wrote: > Is the attached v2 > "Add '-Wno-complain-wrong-lang', and use it in > 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere" > OK? OK. -- Joseph S. Myers jos...@codesourcery.com

<    1   2   3   4   5   6   7   8   9   10   >