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

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

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 programs will adversely > affect the ability of GCC to compile C2x programs. At block scope, auto x = 1.5; declares x to have

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

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

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 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org

Re: [C PATCH] Detect all variably modified types [PR108375]

On Fri, 17 Feb 2023, Martin Uecker via Gcc-patches wrote: > Here is a patch for PR108375. This patch is OK. > and another C FE patch for PR105660: > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611817.html This one is also OK. -- Joseph S. Myers jos...@codesourcery.com

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

[committed] c: Allow conversions of null pointer constants to nullptr_t

WG14 has agreed to allow conversions (explicit and implicit) from null pointer constants to nullptr_t; update GCC's nullptr_t implementation to match. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-convert.cc (c_convert): Allow conversion of a null pointer

[committed] c: Update checks on constexpr pointer initializers

WG14 has agreed a change of the rules on constexpr pointer initializers, so that a (constant) null value that is not a null pointer constant is accepted in that context, rather than only accepting null pointer constants. (In particular, this means that a constexpr variable of pointer type can be

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

On Wed, 8 Feb 2023, Siddhesh Poyarekar wrote: > On 2023-02-08 14:09, Joseph Myers wrote: > > What must be avoided is -pedantic diagnostics for > > > > struct flex1 { int n; int data[1]; }; > > struct out_flex_end1 { int m; struct flex1 flex_data; }; > > >

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

On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote: > But I noticed that “flexible_array_type_p” later was moved from FE to > middle-end and put into tree.cc, tree.h as a general utility routine, and to > > /* Determine whether TYPE is a structure with a flexible array member, >or a union

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

On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote: > Then, this routine (flexible_array_type_p) is mainly for diagnostic purpose. > It cannot be used to determine whether the structure/union type recursively > include a flexible array member at the end. > > Is my understanding correct? My

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

On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote: > 1. Structure with flexible array member embedded into other structures > recursively, for example: > > struct A { > int n; > char data[]; > }; > > struct B { > int m; > struct A a; > }; > > struct C { > int q; > struct B b; >

Re: [pushed] wwwdocs: projects/tree-ssa: Use our own copy of GCC Summit 2007 proceedings

On Mon, 6 Feb 2023, Gerald Pfeifer wrote: > gccsummit.org is gone with the wind; luckily we have our own copy of the > 2006 proceedings. > > If any of you has copies of 2007 and later, can you please drop me a > copy and I'll put them on gcc.gnu.org as well? Aren't they all on the wiki?

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

On Mon, 6 Feb 2023, Qing Zhao via Gcc-patches wrote: > In GCC14: > > 1. Include this new warning -Wgnu-varaible-sized-type-not-at-end to -Wall > 2. Deprecate this extension from GCC. (Or delay this to next release?). Any deprecation, or inclusion in -Wall, would best come with evidence about

Re: [PATCH 2/2] Documentation Update.

On Thu, 2 Feb 2023, Siddhesh Poyarekar wrote: > I dug into this on the glibc end and it looks like this commit: > > commit 63fb8f9aa9d19f85599afe4b849b567aefd70a36 > Author: Zack Weinberg > Date: Mon Feb 5 14:13:41 2018 -0500 > > Post-cleanup 2: minimize _G_config.h. > > ripped all of

[committed] c: Update nullptr_t comparison checks

WG14 has agreed to allow equality comparisons between pointers and nullptr_t values that are not null pointer constants (this was previously an exceptional case where such nullptr_t values were handled differently from null pointer constants; other places in the standard allowed nullptr_t values,

[committed] c: Update checks on constexpr floating-point initializers

WG14 has agreed some changes (detailed at the end of N3082) to the rules on constexpr initializers for floating types. Update GCC's implementation to match: binary initializers are now allowed for decimal types, and real initializers for complex types, but signaling NaN initializers can't be used

[committed] c: Disallow braces around C2x auto initializers

WG14 agreed at this week's meeting to remove support for braces around auto scalar initializers, as incompatible with C++ auto handling of braced initializers; thus remove that support in GCC. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-parser.cc

Re: [PATCH] driver: fix -gz=none error message with missing zstd

On Fri, 27 Jan 2023, Martin Liška wrote: > We wrongly report: > > $ echo "int main () {}" | gcc -xc -gz=none - > gcc: error: -gz=zstd is not supported in this configuration > > if zstd compression is not supported by binutils. We should emit the > error message only if -gz=zstd. > > PR

Re: [committed] C-SKY: Define SYSROOT_SUFFIX_SPEC.

On Fri, 13 Jan 2023, Xianmiao Qu via Gcc-patches wrote: > The earlier patch > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575418.html > refine the way to generate sysroot suffix, but it can't find the > right path for all CPUs. The SYSROOT_SUFFIX_SPEC should be defined > to fix it. I

Re: [PATCH] c: ICE with nullptr as case expression [PR108424]

On Wed, 18 Jan 2023, Marek Polacek via Gcc-patches wrote: > In this ICE-on-invalid, we crash on > > gcc_assert (INTEGRAL_TYPE_P (type)); > > in perform_integral_promotions, because a nullptr is an INTEGER_CST, > but not INTEGRAL_TYPE_P, and check_case_value is only checking the > former. In

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

Re: [PATCH] c: Don't emit DEBUG_BEGIN_STMTs for K function argument declarations [PR105972]

On Wed, 11 Jan 2023, Jakub Jelinek via Gcc-patches wrote: > The following patch ensures we don't emit any such DEBUG_BEGIN_STMTs for the > K function parameter declarations even in nested functions. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > 2023-01-11 Jakub

Re: [PATCH] longlong.h: Do no use asm input cast for clang

On Tue, 10 Jan 2023, Adhemerval Zanella Netto via Gcc-patches wrote: > That's my original intention [1], but Joseph stated that GCC is the upstream > source of this file. Joseph, would you be ok for a similar patch to glibc > since gcc is reluctant to accept it? I don't think it's a good idea

[committed] c: Check for modifiable static compound literals in inline definitions

The C rule against modifiable objects with static storage duration in inline definitions should apply to compound literals (using the C2x feature of storage-class specifiers for compound literals) just as to variables. Add a call to record_inline_static for compound literals to make sure this

[committed] c: C2x semantics for __builtin_tgmath

__builtin_tgmath implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for macros with such types, which should also be considered defect fixes (although

Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

On Tue, 3 Jan 2023, Iain Sandoe wrote: > 1. Modula-2 should not forward the builtins unless the target supports them, > either by expansion or the relevant lib functions. So that would need > some >configury and conditional build code. Note that such configure tests could only readily

Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

On Sat, 31 Dec 2022, Iain Sandoe wrote: > builtins.def unconditionally defines these builtins to be DEF_EXT_LIB_BUILTIN > which expands to the libcall, this is currently hard-wired to FALLBACK_P = > true. > > but, AFAIU the builtins.def descriptions: > > FALLBACK_P should be false if the libc

Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

On Fri, 30 Dec 2022, Iain Sandoe via Gcc-patches wrote: > This patch is providing functions used by the modula-2 implementation. > > At present, I've used a crt rather than adding symbols to libgcc, since > it is not clear if the modula-2 might alter the use of scalb to scalbn > (although that

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

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

Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]

On Thu, 22 Dec 2022, Segher Boessenkool wrote: > Hi! > > On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote: > > On Wed, 21 Dec 2022, Segher Boessenkool wrote: > > > > --- a/gcc/tree.cc > > > > +++ b/gcc/tree.cc > > > > @@ -9442,15 +

Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]

On Wed, 21 Dec 2022, Segher Boessenkool wrote: > > --- a/gcc/tree.cc > > +++ b/gcc/tree.cc > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char) > >if (!targetm.floatn_mode (n, extended).exists ()) > > continue; > >int precision = GET_MODE_PRECISION (mode); > >

Re: [C PATCH] remove same_translation_unit_p

On Tue, 20 Dec 2022, Martin Uecker via Gcc-patches wrote: > Here is a patch to remove the unused function > same_translation_unit_p and related code. The > code to check for structural equivalency of > structs / unions is kept (with some fixes) > because it will be needed for C2X. Could you

Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299

On Thu, 15 Dec 2022, Kewen.Lin via Gcc-patches wrote: > By investigating the exposed NaN failures, I found it's due to that it wants > to convert _Float128 type constant to long double type constant, it goes > through function real_convert which clears the signalling bit in the context > of

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

On Tue, 13 Dec 2022, Martin Liška wrote: > If the Rust folks are willing to use Sphinx, then yes, I'm going to > prepare a common infrastructure (baseconf.py, common license files and a > common Makefile). So something similar to what I prepared for the Sphinx > conversion that didn't make it.

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

On Fri, 9 Dec 2022, Martin Liška wrote: > On 12/6/22 11:14, arthur.co...@embecosm.com wrote: > > |We still need to write out a documentation section, but these READMEs will > > help in the meantime.| > > Hello. > > Just a quick comment: The Sphinx conversion didn't make it for all GCC >

Re: [PATCH Rust front-end v4 46/46] gccrs: Add README, CONTRIBUTING and compiler logo

On Fri, 9 Dec 2022, Martin Liška wrote: > On 12/6/22 11:14, arthur.co...@embecosm.com wrote: > > |We still need to write out a documentation section, but these READMEs will > > help in the meantime.| > > Hello. > > Just a quick comment: The Sphinx conversion didn't make it for all GCC >

[committed] c: Diagnose auto constexpr used with a type

The constraints on auto in C2x disallow use with other storage-class specifiers unless the type is inferred from an initializer. That includes constexpr; add the missing checks for this case (the combination of auto, constexpr and a type specifier). Bootstrapped with no regressions for

[committed] testsuite: Add test for C90 auto with implicit int

Add a test for the case of auto with implicit int in C90 mode, which is incompatible with C2x semantics (I missed adding such a test when implementing C2x auto). Tested for x86_64-pc-linux-gnu. * gcc.dg/c90-auto-1.c: New test. diff --git a/gcc/testsuite/gcc.dg/c90-auto-1.c

[committed] preprocessor: Enable __VA_OPT__ for C2x

C2x supports __VA_OPT__, so adjust libcpp not to pedwarn for uses of it (or of not passing any variable arguments to a variable-arguments macro) in standard C2x mode. I didn't try to duplicate existing tests for the details of the feature, just verified -pedantic-errors handling is as expected.

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] libcpp: suppress builtin macro redefined warnings for __LINE__

On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote: > They are ./gcc/testsuite/gcc.dg/cpp/warn-redefined.c and > ./gcc/testsuite/gcc.dg/cpp/warn-redefined-2.c > > These two cases redefine the __TIME__ macro when using the option > '-Wbuiltin-macro-redefined'. > > I think I shoud add a test

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

On Fri, 2 Dec 2022, Longjun Luo via Gcc-patches wrote: > > On 12/2/2022 1:01 AM, Joseph Myers wrote: > > On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote: > > > > > diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c > > > b/gcc/testsuite/gcc.dg/builti

Re: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__

On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote: > diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c > b/gcc/testsuite/gcc.dg/builtin-redefine.c > index 882b2210992..9d5b42252ee 100644 > --- a/gcc/testsuite/gcc.dg/builtin-redefine.c > +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c > @@

Re: Java front-end and library patches.

On Wed, 30 Nov 2022, Zopolis0 via Gcc-patches wrote: > > * Each patch should have its own explanation of what it is doing and why, > > in the message body (not in an attachment). Just the commit summary line > > and ChangeLog entries aren't enough, we need the actual substantive commit > >

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 >

Re: Java front-end and library patches.

On Fri, 25 Nov 2022, Zopolis0 via Gcc-patches wrote: > Firstly, to get feedback and reviews on the 56 already existing > patches, even though most are just re-adding code or making idiomatic > changes, so that when the final issue is solved everything has already > been approved (hopefully) and

Re: [PATCH] c: Fix compile time hog in c_genericize [PR107127]

On Wed, 23 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The complex multiplications result in deeply nested set of many SAVE_EXPRs, > which takes even on fast machines over 5 minutes to walk. > This patch fixes that by using walk_tree_without_duplicates where it is > instant. > >

Re: [PATCH] c: Propagate erroneous types to declaration specifiers [PR107805]

On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote: > Without this change, finish_declspecs cannot tell that whether there > was an erroneous type specified, or no type at all. This may result > in additional diagnostics for implicit ints, or missing diagnostics > for multiple types. > >

Re: [PATCH] range-op: Implement floating point division fold_range [PR107569]

On Tue, 22 Nov 2022, Jan-Benedict Glaw wrote: > I'm running a slightly hacked [glibc]/scripts/build-many-glibcs.py to > to CI builds for glibc as well by now (hacked to allow for GCC master > being used) and this GCC commit > (2d5c4a16dd833aa083f13dd3e78e3ef38afe6ebb) triggers glibc's >

Re: [PATCH] [range-ops] Implement sqrt.

On Thu, 17 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > On Thu, Nov 17, 2022 at 06:59:45PM +0000, Joseph Myers wrote: > > On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote: > > > > > So... is the optimization wrong? Are we not allowed to substitute > &

Re: [PATCH] [range-ops] Implement sqrt.

On Thu, 17 Nov 2022, Aldy Hernandez via Gcc-patches wrote: > So... is the optimization wrong? Are we not allowed to substitute > that NAN if we know it's gonna happen? Should we also allow F F F F F > in the test? Or something else? This seems like the usual ambiguity about what

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

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 41d07e57..d033628b 100644 --- a/htdocs/gcc-13/changes.html +++ b/htdocs/gcc-13/changes.html @@ -112,9 +112,41 @@ a work-in-progress. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm;>N3042,

Re: [PATCH] [range-ops] Implement sqrt.

On Sun, 13 Nov 2022, Jakub Jelinek via Gcc-patches wrote: > So, I wonder if we don't need to add a target hook where targets will be > able to provide upper bound on error for floating point functions for > different floating point modes and some way to signal unknown accuracy/can't > be trusted,

Re: [PATCH 1/5] c: Set the locus of the function result decl

On Sun, 13 Nov 2022, Bernhard Reutner-Fischer via Gcc-patches wrote: > Bootstrapped and regtested on x86_86-unknown-linux with no regressions. > Ok for trunk? > > Cc: Joseph Myers > --- > gcc/c/ChangeLog: > > * c-decl.cc (start_function): Set the result decl

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

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

ginclude: C2x header version macros

C2x adds __STDC_VERSION_*_H__ macros to individual headers with interface changes compared to C17. All the new header features in headers provided by GCC have now been implemented, so define those macros to the value given in the current working draft. Bootstrapped with no regressions for

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

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,

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

c: C2x constexpr

[Global / middle-end reviewers, note there is a dfp.cc change here that needs review.] Implement C2x constexpr (a feature based on the C++ one but much more minimal, with only constexpr variables, not functions). I believe this implementation is fully functional for use of this feature.

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.

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

Re: old install to a different folder

On Fri, 11 Nov 2022, Tobias Burnus wrote: > For /onlinedocs/, I concur that we want to have the old doc there as there are > many > deep links. Still, we should consider adding a disclaimer box to all former > mainline > documentation stating that this data is no longer updated + point to the new

Re: [PATCH v2 2/4] LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions

On Thu, 10 Nov 2022, Xi Ruoyao via Gcc-patches wrote: > Joseph: can you confirm that -ftrapping-math allows floor and ceil to > raise inexact exception? The man page currently says: > > The default is -ffp-int-builtin-inexact, allowing the exception to be > raised, unless C2X or a later C

Re: [PATCH] c-family: Support #pragma region/endregion [PR85487]

On Thu, 10 Nov 2022, Jonathan Wakely via Gcc-patches wrote: > Something similar has been proposed before, but didn't get approval. > Jeff wanted a more general framework for ignoring pragmas. It might make > sense to do that, and reuse it for the Darwin-specific 'mark' pragmas. > But as I said in

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

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