Re: New TLS usage in libgcc_s.so.1, compatibility impact

On Mon, 15 Jan 2024, Florian Weimer via Gcc wrote: > The change conflated multiple issues: sanitizer support, > async-signal-safe TLS access, and eager allocation of all TLS-related > memory, so that subsequent accesses cannot fail. My impression was the > main point of contention was eager alloc

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote: > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM. That doesn't make sense. ATTR_TM_NOTHROW_RT_LIST is specifically a transactional memo

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

On Fri, 2 Feb 2024, Bernhard Reutner-Fischer via Gcc wrote: > Hi Joseph! > > On Tue, 30 Jan 2024 14:54:49 + (UTC) > Joseph Myers wrote: > > > On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote: > > > > > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST > > >

Re: Nested restrict pointers: missed optimization & client with UB?

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote: > int foo2(int *restrict *p, int *restrict *q) > { > **p = 10; > **q = 11; > return **p; > } In this case, *p and *q might be the same restricted pointer object. See the more detailed explanation at

Re: Nested restrict pointers: missed optimization & client with UB?

On Tue, 13 Feb 2024, Ties Klappe via Gcc wrote: > Thank you both for your quick replies. > > @Joseph, thank you for linking me to the other issue. If I understand > correctly what the point is, would you then agree that the program main > when calling foo2 has *defined* behavior? I think that's

Re: Deprecation/removal of nios2 target support

On Wed, 17 Apr 2024, Sandra Loosemore wrote: > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > support from all toolchain components after the release is made. I'm not sure > there is an established process for obsoleting/removing support in other > components; besides

Re: Updated Sourceware infrastructure plans

On Thu, 18 Apr 2024, Mark Wielaard wrote: > But we like to get more feedback on what people really think a > "pull-request" style framework should look like. We used to have a > gerrit setup which wasn't really popular. And we already have a > sourcehut mirror that can be used to turn your "pull-r

Re: Updated Sourceware infrastructure plans

On Thu, 18 Apr 2024, Frank Ch. Eigler via Gcc wrote: > Hi - > > > [...] I suggest that a basic principle for such a system is that it > > should be *easy* to obtain and maintain a local copy of the history > > of all pull requests. That includes all versions of a pull request, > > if it gets re

Re: Updated Sourceware infrastructure plans

On Mon, 22 Apr 2024, Mark Wielaard wrote: > > A system that uses git as the source of > > truth for all the pull request data and has refs through which all this > > can be located (with reasonably straightforward, documented formats for > > the data, not too closely tied to any particular im

Re: [RISC-V] Support for trapping math in RISC-V

On Wed, 24 Apr 2024, Krishna Narayanan via Gcc wrote: > Hi all, > Is the RISC-V community planning to add support for trapping math in RISC-V > in the near future!? > This LLVM thread > https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7 suggests a > software emulation of traps, is the

Re: Updated Sourceware infrastructure plans

On Thu, 2 May 2024, Fangrui Song wrote: > > On the other hand, GitHub structures the concept of pull requests > > around branches and enforces a branch-centric workflow. A pull request > > centers on the difference (commits) between the base branch and the > > feature branch. GitHub does not em

Re: Updated Sourceware infrastructure plans

On Sat, 4 May 2024, Ben Boeckel via Gcc wrote: > - every push is stored in a ghostflow-director-side unique ref > (`refs/mr/ID/heads/N` where `N` is an incrementing integer) to avoid > forge-side garbage collection (especially problematic on Github; > I've not noticed GitLab collecti

Re: configure adds -std=gnu++11 to CXX variable

On Tue, 28 May 2024, Jakub Jelinek via Gcc wrote: > -std=gnu23 support is still incomplete even in GCC 14. It doesn't involve ABI issues, however, unlike C++, so using the option with GCC 14 is comparatively safe. (It might run into a few aliasing bugs related to tag compatibility right now, b

Re: -Wcast-qual consistency with initialization conversion and double pointer types

On Sun, 16 Jun 2024, Martin Uecker via Gcc wrote: > I think it should not warn about: > > char *x; > *(char * volatile *)&x; > > as this is regular qualifier adding and this is > a bug in GCC. > > I would guess it looks at all qualifiers added at > all level but should ignore the one on the fir

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

On Wed, 10 Jul 2024, Alejandro Colomar via Gcc wrote: >6.7.13.x The restrict function attribute > Constraints > The restrict attribute shall be applied to a function. > > A 1‐based index can be specified in an attribute argument > clause, to associ

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote: > I don't see why it should not apply to void*. memcpy(3) should get this > attribute: > > [[alx::restrict(1)]] > [[alx::restrict(2)]] > void *memcpy(void *dst, const void *src, size_t n); That would disallow copying betwee

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote: > > See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor > > replying when I asked about just that paper). > > Where can I find reflector messages? https://www.open-std.org/jtc1/sc22/wg14/18575 > And another one to propose

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, 9 Aug 2024, Alejandro Colomar via Gcc wrote: > Since I don't see any legitimate uses of sizeof(aparam) as of today, I > don't expect having any consequences on existing code. (But please > point me wrong if there are any, maybe in generic macros.) It's perfectly legitimate when the user

Re: C23 status on cppreference

On Wed, 16 Oct 2024, Jakub Jelinek via Gcc wrote: > The cppreference page mentions as unimplemented on the GCC side > N2653 - Type change of u8 string literals commit 703837b2cc8ac03c53ac7cc0fb1327055acaebd2 Author: Tom Honermann Date: Tue Aug 2 14:36:01 2022 -0400 C: Implement C2X N2653

Re: Is -Wtraditional obsolete?

On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote: > One thing about -Wtraditional is that it enables a lot of different > messages, so I always thought it would make more sense as an umbrella > warning that just enables a bunch of sub-warning flags. While many of > the individual sub-warnings may

Re: C23 status on cppreference

On Wed, 16 Oct 2024, Florian Weimer wrote: > * Jakub Jelinek via Gcc: > > > Are some of the papers/features known to be fully implemented (since which > > version)? E.g. for __VA_OPT__ I remember doing (and Jason too) various > > fixes > > in the past few years, like PR89971, PR103415, PR101488

Is -Wtraditional obsolete?

One issue that showed up as test failures with a default of -std=gnu23 is that -std=gnu23 -Wtraditional produces a "traditional C rejects ISO C style function definitions" warning for function definitions with empty parentheses, as they are treated like (void) in C23, so resulting in failure of

Re: C23 status on cppreference

On Thu, 17 Oct 2024, Florian Weimer wrote: > > I'm not sure such a warning particularly helps, however; any ABI > > incompatibility occurs at the point where someone changes their code to > > stop defining bool and to use the standard bool instead. (And any problem > > code would already have

Re: Is -Wtraditional obsolete?

On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote: > > "suggest hiding %<#%s%> from traditional C with an indented %<#%>" > > This is one of the things I tested when adding gcc.dg/pragma-diag-7.c > in r8-787-g4287da829c9697: > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4287da829c9697c581316

Handling C2Y zero-length operations on null pointers

WG14 accepted https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf at this week's meeting in Minneapolis, allowing various zero-length language and library operations on null pointers in C2Y (in support of the idiom where an empty array may be represented by a null pointer with zero lengt

Re: Core Toolchain Infrastructure - October 2024 update

On Wed, 30 Oct 2024, Carlos O'Donell via Gcc wrote: > Have you broken down those project goals into actionable steps that > could be taken? > > For example filing Sourceware Infrastructure bugs for each service that > needs to be migrated into a VM and isolated (with a top level tracker > for

Re: Core Toolchain Infrastructure - October 2024 update

On Wed, 30 Oct 2024, Mark Wielaard wrote: > Yes, we did already discuss this. But it is too early for that. Richard > setup a wiki page for the Forge Experiment that includes a list of > various bugs/issues in Forgejo that we would like to see resolved > before we can call the experiment an succes

Re: -Wfloat-equal and comparison to zero

On Sat, 9 Nov 2024, Sad Clouds via Gcc wrote: > Even though there is nothing unsafe here and comparison to floating > point 0.0 value is well defined. The point of the warning is that *if you are writing code that thinks of floating-point values as being approximations to real numbers* then such

Re: VLA representation in GCC internals

On Sat, 9 Nov 2024, Martin Uecker via Gcc wrote: > BTW: My main practical issue with zero-sized arrays is that the > UB sanitizers triggers for zero-sized variable arrays. They are after all UB in standard C. (Note for example that the UB sanitizers cover all cases of shifts that are undefined

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

On Fri, 8 Nov 2024, Alejandro Colomar wrote: > Hi Thorsten, JeanHeyd, > > I've just checked that JeanHeyd opened a survey about the name. > It's here: . > Thanks for the survey, JeanHeyd; It's a fair one. (The only thing I > miss is anouncing i

Re: On pull request workflows for the GNU toolchain

On Mon, 23 Sep 2024, Richard Earnshaw (lists) via Gcc wrote: > One thing we must do, however, is break requirements into a number of > categories: must haves (red lines, we can't transition without this); should > haves (important, but we can likely find acceptable work-arounds); and would > like

Re: On pull request workflows for the GNU toolchain

On Mon, 23 Sep 2024, enh via Gcc wrote: > it doesn't make the patch _management_ problem better ("now i have two > problems"), but https://github.com/landley/toybox takes the "why not both?" > approach --- you can use pull requests if you grew up with/adapted to > git/github, or you can use the ma

RE: On pull request workflows for the GNU toolchain

On Tue, 24 Sep 2024, Jiang, Haochen via Gcc wrote: > I am running regression tests on x86_64 and sending the regressions to > gcc-regression mailing thread, will I need to send to another place or > using another API to do that? I don't expect use of pull requests to change anything about existin

Re: On pull request workflows for the GNU toolchain

On Fri, 20 Sep 2024, Carlos O'Donell via Gcc wrote: > > (e) All existing pre-commit checks from hooks should be kept in some > > form, to maintain existing invariants on both tree and commit contents > > (some hook checks make sure that commits don't have commit messages > > that would cause other

Re: On pull request workflows for the GNU toolchain

On Fri, 20 Sep 2024, Matt Rice via Gcc wrote: > To me though it is nice being able to edit the PR cover letter > directly in the editor, and do the pull-request using command line > tools. In the common case of a single-commit PR without dependencies, it seems reasonable to follow the practice t

On pull request workflows for the GNU toolchain

1. Introduction This message expands on my remarks at the Cauldron (especially the patch review and maintenance BoF, and the Sourceware infrastructure BoF) regarding desired features for a system providing pull request functionality (patch submission via creating branches that are then proposed us

RE: On pull request workflows for the GNU toolchain

On Wed, 25 Sep 2024, Jiang, Haochen via Gcc wrote: > The potential issue might be the PR will be closed after merging, which might > be flooded in history if the regression is not fixed with the PR forgotten to > be > reopened. I am not sure the reopen could be automatically done. If it could,

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

On Fri, 22 Nov 2024, Sam James wrote: > > Some estimate of the build failure would also be helpful. Is it the > > same as, e.g. the GCC 12 to GCC 13 update, or is it igher? > > It's pretty large so far. Between 12 and 13, the main issues were: > libstdc++ transitive include changes and a small n

Re: [PATCH v18 0/2] c: Add __countof__ operator

On Thu, 27 Feb 2025, Alejandro Colomar via Gcc wrote: > Can you please confirm if we should add a version of this operator that > need not be diagnosed under pedantic mode? If so, I'll propose this I'm doubtful of the need for a second variant, but in any case the starting point should be a pat

Re: message has lines too long for transport - Was: Fwd: Mail delivery failed: returning message to sender

On Mon, 24 Mar 2025, Richard Earnshaw (lists) via Gcc wrote: > https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1 > > So there's a 998 (sic) character limit on the length of any line. I'm > guessing your mail posting tool is not reformatting the message and trying to > pass it straigh