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: -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: 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: 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

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

N2653 char8_t and UTF-8 string literal changes > and as only partially implemented > N2341 - IEEE 754 decimal floating-point types Various -pedantic and fixes done to reflect these being standard e.g. commit 04a9b8d2f38573d0527edeea9e4fd9b7dfdc7983 Author: Joseph Myers Date: Thu Oct

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: 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: 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 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 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 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

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

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: 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: 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: 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 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: -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: 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: 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: 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: [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 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: 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 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: 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: 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: 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: [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_NOT

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: 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: Unjustified optimization due to restricted struct members?

On Thu, 30 Nov 2023, Ties Klappe via Gcc wrote: > When reading section 6.7.3.1 of the C standard (quoted below) about > the *restrict > *type qualifier, the first section talks about *ordinary identifiers*. > These are defined in section 6.2.3, and exclude members of structures. > > Let D be a de

Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz

On Thu, 2 Nov 2023, Richard Biener via Gcc wrote: > Note the semantic of __builtin_clz is _not_ altered by > CLZ_DEFINED_VALUE_AT_ZERO, the behavior > of __builtin_clz (x) is that is has undefined result for x == 0. Note also the discussion in bug 111309 of possible future type-generic versions

Re: Suboptimal warning formatting with `bool` type in C

On Wed, 1 Nov 2023, peter0x44 via Gcc wrote: > Why is #define used instead of typedef? I can't imagine how this could > possibly break any existing code. That's how stdbool.h is specified up to C17. In C23, bool is a keyword instead. -- Joseph S. Myers jos...@codesourcery.com

Re: C89 question: Do we need to accept -Wint-conversion warnings

On Tue, 10 Oct 2023, Florian Weimer via Gcc wrote: > Are these code fragments valid C89 code? > > int i1 = 1; > char *p1 = i; > > char c; > char *p2 = &c; > int i2 = p2; Implicit conversions between pointers and integers are not valid C89. ANSI C89, as adopted as FIPS PUB 160, is ava

Re: Complex numbers support: discussions summary

On Mon, 25 Sep 2023, Sylvain Noiry via Gcc wrote: > --> Idea: Add an attribute to the Tree complex type which specify pure real / > pure >    imaginary / full complex ? If you start from the implementation approach of lowering imaginary type operations in the front end, a flag on a REAL_TYPE wou

Re: Concerns regarding the -ffp-contract=fast default

On Mon, 18 Sep 2023, Alexander Monakov wrote: > > On Mon, 18 Sep 2023, Florian Weimer wrote: > > > Okay, you meant “changing the result” as in “changing the result in a > > permitted way”. Sorry, was confused. So this is a bad example all > > around. Are there better ones (that don't involve

Re: m68k Coldfire and PC-relative addressing distances

On Tue, 11 Jul 2023, Florian Weimer via Gcc wrote: > * Richard Biener: > > > On Tue, Jul 11, 2023 at 11:36 AM Florian Weimer via Gcc > > wrote: > >> > >> How does the Coldfire m68k subtarget and sure that displacements in PIC > >> code are within the addressable range? > > > > There is usually

Re: Passing the complex args in the GPR's

On Tue, 6 Jun 2023, Andrew Pinski via Gcc wrote: > You are looking at the wrong ABI document. > That is for the 64bit ABI. > The 32bit ABI document is located at: > http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf > > Plus the 32bit ABI document does not document Complex argument passing

Re: More C type errors by default for GCC 14

On Fri, 12 May 2023, Florian Weimer wrote: > This sone seems to be a good candidate for additional errors, though: > > warned_here = pedwarn > (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0, > "% with no value, in function returning non-void"); > > It's a clear type volation that

Re: [wish] Flexible array members in unions

On Thu, 11 May 2023, Kees Cook via Gcc wrote: > Okay, understood. If this is a C-only thing, we can ignore the C++ > impact. We're a lot more careful lately in WG14 about checking for C++ compatibility issues and expecting approval from the liaison group for anything with possible compatibility

Re: [wish] Flexible array members in unions

On Thu, 11 May 2023, Kees Cook via Gcc wrote: > Why are zero-sized objects missing in Standard C? Or, perhaps, the better > question is: what's needed to support the idea of a zero-sized object? Zero-sized objects break the principle that different objects have different addresses, and the princ

Re: [wish] Flexible array members in unions

On Thu, 11 May 2023, Kees Cook via Gcc wrote: > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote: > > On 5/11/23 18:07, Alejandro Colomar wrote: > > [...] > > > Would you allow flexible array members in unions? Is there any > > > strong reason to disallow them? > > Yes please!!

Re: More C type errors by default for GCC 14

On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote: > That is not the case we are discussing, AFAIU. Or at least no one has > yet explained why accepting those old K&R programs will adversely > affect the ability of GCC to compile C2x programs. At block scope, auto x = 1.5; declares x to have

Re: MIN/MAX and trapping math and NANs

On Tue, 11 Apr 2023, Michael Matz via Gcc wrote: > Note that this makes minNum/maxNum (and friends) not associative. Also, > different languages and different hardware implement fmin/fmax different > and sometimes in conflict with 754-2008 (e.g. on SSE2 maxsd isn't > commutative but maxNum is!

Re: Git 'hooks/post_receive.py': UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 2766: invalid start byte

On Thu, 16 Feb 2023, Martin Liška wrote: > Well, the https://github.com/AdaCore/git-hooks were ported to Python 3 > some time ago and I thought we've been using the updated version. But it > seems we're still on python2.7 :(( > > Joseph, can we update it, please? If someone wishes to update th

Re: Renaming git master?

On Sun, 15 Jan 2023, Gerald Pfeifer wrote: >(If someone tells me what to use instead of "master" I can propose a >patch.) If you wish to add additional symbolic-refs / make master into a symbolic-ref, please make sure to change hooks-bin, refs/meta/config:project.config and anything el

Re: stdc_bit_ceil(3) and wrapping

On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote: > For the C standard, shifts have wrap around semantics for unsigned types: Only if the shift count is nonnegative and strictly less than the width of the type. This is about shifting by an amount equal to the width of the type, which has u

Re: stdc_bit_ceil(3) and wrapping

On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote: > I was wondering if there was any reason to make that UB in the standard, when > unsigned wrapping has always been well-defined, and this is a case that is > likely to be implemented with some operation that wraps around, right? I It's likel

Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition

On Mon, 5 Dec 2022, Gavin Ray via Gcc wrote: > union [[may_alias]] broken2 {}; With [[]] syntax it's [[gnu::may_alias]], since it's not a standard attribute. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Sat, 3 Dec 2022, Alejandro Colomar via Gcc wrote: > What do you think about it? I'm not asking for your opinion about adding it > to GCC, but rather for replacing the current '.' in the man-pages before I > release later this month. Do you think I should apply that change? I think man pages

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Tue, 29 Nov 2022, Michael Matz via Gcc wrote: > like. But I'm generally doubtful of this whole feature within C itself. > It serves a purpose in documentation, so in man-pages it seems fine enough > (but then still could use a different puncuator to not be confusable with > C syntax). In

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote: > I guess asking the compiler to do two passes on the param list isn't as bad as > asking to do unbound lookahead. In this case it's bound: look ahead till the > end of the param list; get as much info as possible, and then do it again to > comple

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote: > > To quote the convenor in WG14 reflector message 18575 (17 Nov > > 2020) when I asked about its status, "The author asked me not to put those > > on the agenda. He will supply updated versions later.". > > Since his email is not in the pap

Re: [BUG] README: Reference to non-existent path?

On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote: > Okay, let's see the online readable version of the manual: > > $ ls gcc/doc/gcc.info* > ls: cannot access 'gcc/doc/gcc.info*': No such file or directory That reference is for releases - those files are in release tarballs, but not

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote: > SYNOPSIS: > > unary-operator: . identifier That's not what you mean. See the standard syntax. unary-expression: [other alternatives] unary-operator cast-expression unary-operator: one of & * + - ~ ! > - It is not an lvalue. > >

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote: > Maybe allowing integral types and pointers would be enough. However, > foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will > succeed, and combining it with this one, _Lengthof(pointer) would ideally give > the length of

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote: > > > No, assigning to a function parameter from within another parameter > > > declaration wouldn't make sense. They should be readonly. Side effects > > > should be forbidden, I think. > > > > Such assignments are already allowed. In a fu

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote: > Since it's to be used as an rvalue, not as a lvalue, I guess a > postfix-expression wouldn't be the right one. Several forms of postfix-expression are only rvalues. > > (with a special rule about how the identifier is interpreted, different

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote: > > struct s { int a; }; > > void f(int a, int b[((struct s) { .a = 1 }).a]); > > Is it really ambiguous? Let's show some currently-valid code: Well, I still don't know what the syntax addition you propose is. Is it postfix-expression : .

Re: How can Autoconf help with the transition to stricter compilation defaults?

On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote: > These are also a trip hazard for novices, and the only way to turn them > off is with -std=cXX, which also turns another trip hazard (trigraphs) > *on*… so yeah, anything you can do to help speed up their removal, I > think it’d be worthwhile. A

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote: > > Even a compiler extension requires the level of detail of specification > > that you get with a WG14 paper (and the level of work on finding bugs in > > that specification), to avoid the problem we've had before with too many > > features ad

Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations?

On Thu, 10 Nov 2022, Florian Weimer via Gcc wrote: > I assumed that there was a rule similar to the the rule for #error for > any kind of diagnostic, which would mean that GCC errors are diagnostic > messages in the sense of the standard, but GCC warnings are not. The rule (for C) is that any dia

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote: > One problem with WG14 papers is that people put in too much, > because the overhead is so high and the standard is not updated > very often. It would be better to build such feature more > incrementally, which could be done more easily with a co

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Thu, 10 Nov 2022, Joseph Myers wrote: > On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote: > > > I've shown the three kinds of prototypes that have been changed: > > > > - Normal VLA; nothing fancy except for the '.'. > > - Complex size ex

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote: > I've shown the three kinds of prototypes that have been changed: > > - Normal VLA; nothing fancy except for the '.'. > - Complex size expressions. > - 'void *' VLAs (assuming GNU conventions: sizeof(void *)==1). That doesn't cover any of

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Wed, 9 Nov 2022, Martin Liška wrote: > 1) not synchronized content among lib*/Makefile.in and lib*/Makefile.am. > Apparently, I modified the generated Makefile.in file with the rules like: > > doc/info/texinfo/libitm.info: $(SPHINX_FILES) > + if [ x$(HAS_SPHINX_BUILD) = xhas-sphinx-build

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On Wed, 9 Nov 2022, Richard Biener via Gcc wrote: > I'd say that doing a trunk snapshot build every day as CI would be nice, we > can then publish one once a week, skipping days where the build failed. Note that each snapshot should have diffs relative to the previous published snapshot. Not re

Re: Announcement: Porting the Docs to Sphinx - tomorrow

On Tue, 8 Nov 2022, Sam James via Gcc wrote: > Yes, please (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899) > even for snapshots? Pretty please? :) I think we want snapshots to come out weekly even if the compiler or documentation build fails, which makes anything involving a build as part

Re: Local type inference with auto is in C2X

On Thu, 3 Nov 2022, Florian Weimer via Gcc wrote: > My main worry is that both Clang and GCC still enable implicit ints by > default. This means that auto variables have type int always, and that > can subtly alter the meaning of programs. The only indication that this > has happened in a code b

Re: C2x features status

On Fri, 21 Oct 2022, Florian Weimer wrote: > > while typeof was enabled by default for -std=gnu* anyway > > in previous releases so is a lower risk. > > Do the semantics of typeof change to align with C++, so that typeof > (int) becomes invalid? No. Both typeof (expr) and typeof (type) are val

Re: C2x features status

On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote: > Do you have a list of C2X features that are likely to impact autoconf > tests? Or planned changes in the GCC 13 and 14 default language modes > that reject constructs previous accepted as an extension? I think by far the biggest risk - for bui

Re: Ping (c,c++): Handling of main() function for freestanding

On Fri, 21 Oct 2022, Arsen Arsenović via Gcc wrote: > Ping on this patch. > > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603574.html > > For context, see the rest of this thread. TL;DR is that `int main' > should implicitly return 0 on freestanding, without the other burdens of >

Re: C89isms in the test suite

On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote: > Is this really possible? For function pointers, it's an ABI change. > int (*) () and int (*) (void) have different calling conventions on some > ABIs (e.g., powerpc64le-linux-gnu). The ABI difference goes away once > the callees are rebuilt, a

Re: C89isms in the test suite

On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote: > What should we do about these when they are not relevant to what's being > tested? For example, gcc/testsuite/gcc.c-torture/execute/ieee/mzero6.c > has this: > > int main () > { > if (__builtin_copysign (1.0, func (0.0 / -5.0, 10)) !=

Re: C89isms in the test suite

On Fri, 21 Oct 2022, Florian Weimer via Gcc wrote: > What's the expected default behavior for GCC 14 regarding old-style > function definitions (function definitions which do not have a > prototype)? I assume if GCC 14 defaults to C2x mode, these no longer > valid constructs would be rejected by

C2x features status

I'm working on adding various C2x features to the C front end (and elsewhere in GCC as applicable). I suspect I won't get all the C2x features done for GCC 13. If anyone else is interested in adding C2x features, I'd encourage looking at some of the following, which I may well not get to for G

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Thu, 20 Oct 2022, Martin Liška wrote: > > Also, but not strictly part of the release issue: > > > > (d) Builds with missing or old Sphinx should work regardless of whether > > such files are in the source directory - but if they aren't in the source > > directory, the effect of missing or ol

Re: No-named-argument variadic functions

On Thu, 20 Oct 2022, Richard Biener via Gcc wrote: > > 1. How should (...) be represented differently from unprototyped functions > > so that stdarg_p and prototype_p handle it properly? Should I add a new > > language-independent type flag (there are plenty spare) to use for this? > > I'd say u

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Thu, 20 Oct 2022, Martin Liška wrote: > > Could generated man and info pages be provided as a tarball on > > gcc.gnu.org or ftp.gnu.org? > > Not planning doing that. Release tarballs (but not snapshots) currently include the info files and man pages, via gcc_release running a build with --e

No-named-argument variadic functions

C2x allows variable-argument functions declared with (...) as parameters - no named arguments - as in C++. It *also* allows such functions to access their parameters, unlike C++, by relaxing the requirements on va_start so it no longer needs to be passed the name of the last named parameter. M

Re: Announcement: Porting the Docs to Sphinx - 9. November 2022

On Wed, 19 Oct 2022, Martin Liška wrote: > > Currently, there is a tarball with texinfo sources for all the manuals > > for each version. > > Well, then equivalent would be packaging all .rst files together with the > corresponding > conf.py, logo.* and other files. But I don't see it much usefu

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > The next thing I need to tackle for Fortran is the implementation of > functions that perform maxNum, maxNumMag, minNum, and minNumMag. Am I > correct in assuming that maxNum and minNum correspond to fmin and fmax? Yes (note that maxNum and minNum were r

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > I have a Fortran patch ready to submit, but before I do so I’d like to > know: do you support or oppose a __builtin_iseqsig()? I support having such a built-in function. -- Joseph S. Myers jos...@codesourcery.com

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > Do you want me to file a bug report? Yes. -- Joseph S. Myers jos...@codesourcery.com

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, Marc Glisse via Gcc wrote: > On Thu, 1 Sep 2022, Joseph Myers wrote: > > > On Thu, 1 Sep 2022, FX via Gcc wrote: > > > > > A tentative patch is attached, it seems to work well on simple examples, > > > but for test coverage the hard part

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > A tentative patch is attached, it seems to work well on simple examples, > but for test coverage the hard part is going to be that the comparisons > seem to be optimised away very easily into their non-signaling versions. > Basically, if I do: Presumably

Re: Floating-point comparisons in the middle-end

On Thu, 1 Sep 2022, FX via Gcc wrote: > 1. Is this list normative, and was it modified later (I have only found > a 2012 draft)? See N3047 Annex F for the current bindings (there have been a lot of changes to the C2x working draft after N3047 in the course of editorial review, but I don't thin

Re: Reproducible builds - supporting relative paths in *-prefix-map

On Mon, 15 Aug 2022, Richard Purdie via Gcc wrote: > Currently it works well for absolute paths but if a file uses a > relative path or a path with a symlink in, or a non-absolute path, it > will miss those cases. For relative paths in particular it is > problematic as you can't easily construct a

Re: [PATCH] static analysis support for posix file desccriptor APIs

On Tue, 21 Jun 2022, David Malcolm via Gcc wrote: > Joseph: is the target hook the way to go with this? Would it look > something like: > > DEFHOOK (fd_access_mode, "FIXME", int (int)) > > taking the build configuration's O_ access mode, and returning the > target configurations's access mode (

Re: [PATCH] static analysis support for posix file desccriptor APIs

On Tue, 21 Jun 2022, David Malcolm via Gcc wrote: > So ultimately that's something we want to fix, though exactly how, I'm > not quite sure; we presumably want to look up the target's definitions > of those macros - but I don't think the analyzer has access to the > cpp_reader instance from the fr

Re: [C2x] Disallow function attributes after function identifier

On Fri, 10 Jun 2022, Alejandro Colomar via Gcc wrote: > I'd like to suggest a change in C2x regarding attributes. The attribute syntax is supposed to accept attributes in exactly the places they are accepted in C++ (and appertaining to the same entity, for each such place), for constructs prese

Re: AW: [RFC] Adding division/modulo on arbitrary precision integers to libgcc

On Fri, 6 May 2022, Matthias Gehre via Gcc wrote: > > This proposed interface doesn't say anything about what aliasing is or > > isn't permitted among the four arrays pointed to. > Good catch. I would lean into saying that none of the four arrays must alias > because allowing them to alias would r

  1   2   3   4   5   6   7   8   >