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,
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
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
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
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
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
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
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
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
__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
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
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
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
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 +
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);
> >
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
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
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.
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
>
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
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
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.
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
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
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
> @@
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
> >
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
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.
>
>
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.
>
>
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
>
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
> &
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
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,
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,
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
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
[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.
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
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
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
On Wed, 9 Nov 2022, Michael Matz via Gcc-patches wrote:
> I think everything that's on the web server (even the 2.95 docu) has to be
> reachable via a (reasonable) set of clicks from the main index.html. It
> doesn't need to be _directly_ from the main index.html, though.
>
> Also, you simply
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) =
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
On Tue, 8 Nov 2022, Xi Ruoyao via Gcc-patches wrote:
> I'm wondering if running xz -T0 on different machines (with different
> core numbers) may produce different compressed data. The difference can
> cause trouble distributing checksums.
gcc_release definitely doesn't use any options to make
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
I've committed this further fix for a syntax error as obvious.
libstdc++: Fix syntax error in old-glibc case in floating_from_chars.cc
[PR107562]
PR libstdc++/107562
* src/c++17/floating_from_chars.cc (from_chars_impl): Fix syntax
error.
diff --git
On Mon, 7 Nov 2022, Jonathan Wakely wrote:
> This seems to "fix" it (not sure if it's right though):
>
> #ifndef _GLIBCXX_HAVE_FLOAT128_MATH
> extern "C" _Float128 __strtof128(const char*, char**)
> __attribute__((__weak__));
> #endif
> extern "C" _Float128 __strtof128(const char*, char**)
>
On Wed, 2 Nov 2022, Jakub Jelinek via Gcc-patches wrote:
> APIs. So that one can build gcc against older glibc and then compile
> user programs on newer glibc, the patch uses weak references unless
> gcc is compiled against glibc 2.26+. strfromf128 unfortunately can't
This support for older
Implement C2x auto, a more restricted version of the C++ feature
(closer to GNU C __auto_type in terms of what's supported).
Since the feature is very close to GNU C __auto_type, much of the
implementation can be shared. The main differences are:
* Any prior declaration of the identifier in an
On Wed, 2 Nov 2022, Christophe Lyon via Gcc-patches wrote:
> +# Sanity check: make sure we have as many dirnames as options
> +if [ -n "${dirnames}" ]; then
> +options_arr=($options)
This is an sh script; arrays are a bash feature. Building GCC isn't
supposed to need bash (or to rely on
On Mon, 31 Oct 2022, FX via Gcc-patches wrote:
> - rounded conversions: converting, from an integer or floating point
> type, into another floating point type, with specific rounding mode
> passed as argument
These don't have standard C names. The way to do these in C would be
using the
On Fri, 28 Oct 2022, Jeff Law via Gcc-patches wrote:
> Joseph, do you have bits in this space that are going to be landing soon, or
> is your C2X work focused elsewhere? Are there other C2X routines we need to
> be proving builtins for?
I don't have any builtins work planned for GCC 13 (maybe
C2x adds support for enums with a fixed underlying type specified
("enum e : long long;" and similar). Implement this in the C front
end. The same representation is used for these types as in C++, with
two macros moved from cp-tree.h to c-common.h.
Such enums can have bool as the underlying
On Wed, 26 Oct 2022, Thomas Schwinge wrote:
> Hi!
>
> Ping. For convenience, I've re-attached
> "options: Clarify 'Init' option property usage for streaming optimization".
> (I've re-verified: "No functional change; no change in generated files.")
OK.
--
Joseph S. Myers
On Tue, 25 Oct 2022, Richard Biener wrote:
> You are missing to stream the new type flag in tree-streamer-{in,out}.cc
> and checking for tree merging in lto-common.cc:compare_tree_sccs_1
>
> Otherwise looks reasonable. Can you add a (multi TU) runtime testcase to the
> torture exercising the
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
>
C2x allows function prototypes to be given as (...), a prototype
meaning a variable-argument function with no named arguments. To
allow such functions to access their arguments, requirements for
va_start calls are relaxed so it ignores all but its first argument
(i.e. subsequent arguments, if
On Wed, 19 Oct 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> This patch stops reporting fails for Arm targets with single
> precision floating point unit for types wider than 32 bits (the width
> of float on arm-none-eabi).
>
> As reported in PR102017, fenv is reported as supported in recent
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
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
C2x adds printf and scanf wN and wfN length modifiers (wN for
int_leastN_t / uint_leastN_t, also usable for intN_t and uintN_t which
are now required to be the same type as the "least" versions when both
are supported; wfN for int_fastN_t / uint_fastN_t). Add corresponding
format checking support
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
On Wed, 19 Oct 2022, Jakub Jelinek wrote:
> Hi!
>
> On Wed, Oct 19, 2022 at 02:57:59PM +0000, Joseph Myers wrote:
> > I think the type checked for e5a should be conditional on __LONG_MAX__ >
> > __INT_MAX__; everything else there should be OK regardless.
>
> So
On Wed, 19 Oct 2022, Jakub Jelinek wrote:
> > +/* Likewise, for overflow from long to long long. */
> > +#if __LONG_LONG_MAX__ > __LONG_MAX__
> > +enum e5 { e5a = __LONG_MAX__,
> > + e5b, e5c, e5d = ((typeof (e5b)) -1) < 0,
> > + e5e = (unsigned long) -1,
> > + e5f, e5g = ((typeof
As noted in bug 101764, a declaration "enum tag;" is invalid in
standard C after a definition, as well as when no definition is
visible; we had a pedwarn-if-pedantic for the forward declaration
case, but were missing one for the other case. Add that missing
diagnostic (if pedantic only).
(These
C2x has two enhancements to enumerations: allowing enumerations whose
values do not all fit in int (similar to an existing extension), and
allowing an underlying type to be specified (as in C++). This patch
implements the first of those enhancements.
Apart from adjusting diagnostics to reflect
On Mon, 17 Oct 2022, Jonathan Wakely via Gcc-patches wrote:
> > And I/O etc. support is missing, not sure I'm able to handle that and if it
> > is e.g. possible to keep that support out of libstdc++.so.6, because what
> > extended floating point types one has on a particular arch could change
C2x has, like C++, adopted rules for identifiers based directly on an
unversioned normative reference to Unicode. Make libcpp follow those
rules for c2x / gnu2x standards (this involves bringing back a flag
separate from the C++ one for whether to use these identifier rules,
but this time enabled
Implement the C2x feature of storage class specifiers in compound
literals. Such storage class specifiers (static, register or
thread_local; also constexpr, but we don't yet have C2x constexpr
support implemented) can be used before the type name (not mixed with
type specifiers, unlike in
A late change for C2x (addressing comments from the second round of
editorial review before the CD ballot, postdating the most recent
public working draft) removed the value 2 for *_IS_IEC_60559 (a new
macro added in C2x). Adjust the implementation accordingly
not to use this value.
On Mon, 10 Oct 2022, Paul Iannetta via Gcc-patches wrote:
> I have a patch to bring this feature to the C front-end as well, and
> would like to hear your opinion on it, especially since it may affect
> the feature-set of the objc front-end as well.
> Currently, this is only a tentative patch
I'm seeing the following build failure for arc-linux-gnu after this
commit. (Note that this is for building GCC *after* glibc, not for an
initial inhibit_libc bootstrap build of GCC.)
In file included from
/scratch/jmyers/glibc-bot/src/gcc/libgcc/unwind-dw2.c:413:
./md-unwind-support.h: In
My reading of the bug given as a reason for not testing that FE_INVALID is
raised for (both quiet and signaling) NaN arguments is that it's
specifically about constant arguments. That is, it ought to be possible
to have a testcase that verifies FE_INVALID is raised when appropriate
(and not
[C++ maintainers / global reviewers, note that there is a C++
front-end change here needing review.]
C2x adds typeof as a standard feature. In general this follows
existing GNU C semantics very closely, but there are various ways in
which the implementation involves more than simply enabling the
On Wed, 5 Oct 2022, Qing Zhao via Gcc-patches wrote:
> + /* if not the last field, return false. */
Comments should start with an uppercase letter.
> + /* if not an array field, return false. */
> + /* if there is a strict_flex_array attribute attached to the field,
> + override the
On Wed, 5 Oct 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> -/* These should be defined if and only if signaling NaNs are supported
> - for the given types. If the testsuite gains effective-target
> - support for targets not supporting signaling NaNs, or not
> - supporting them for all
On Tue, 4 Oct 2022, Qing Zhao via Gcc-patches wrote:
> + { "strict_flex_array", 1, 1, false, false, false, false,
> + handle_strict_flex_array_attribute, NULL },
You're not requiring that the attribute be applied to a declaration here.
> +static tree
>
On Tue, 4 Oct 2022, Jakub Jelinek via Gcc-patches wrote:
> Yet another problem is because I've only enabled the bf16/BF16 suffixes in
> C++ because for C it might clash with some later extension. Am I right to
> fear about that, or do you think C will never standardize suffixes that
> would
C2x changes the definition of *_EPSILON to apply only to
normalized numbers. The effect is that LDBL_EPSILON for IBM long
double becomes 0x1p-105L instead of 0x1p-1074L.
There is a reasonable case for considering this a defect fix - it
originated from the issue reporting process (DR#467),
On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> What isn't in the patch but I think we'll need to also change are some
> minimal set of __builtin_*bf16 builtins. Seems for _Float16, GCC provides
> all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
> no glibc
C2x adds a standard [[noreturn]] attribute (which can also be spelt
[[_Noreturn]] for use with ), so allowing non-returning
functions to be declared in a manner compatible with C++; the
_Noreturn function specifier remains available but is marked
obsolescent.
Implement this attribute. It's more
This introduces an ICE building libgcc for ia64-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
https://sourceware.org/pipermail/libc-testresults/2022q3/010294.html
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 26 Sep 2022, Lulu Cheng wrote:
> +GTM_longjmp:
> +cfi_startproc
> +GPR_L $s0, $r5, 3*SZ_GPR
> +GPR_L $s1, $r5, 4*SZ_GPR
> +GPR_L $s2, $r5, 5*SZ_GPR
> +GPR_L $s3, $r5, 6*SZ_GPR
> +GPR_L $s4, $r5, 7*SZ_GPR
> +GPR_L $s5, $r5,
There are some new requirements in C2x where GCC already behaves as
required (for all standard versions), where previous standard versions
either had weaker requirements permitting the GCC behavior, or were
arguably defective in what they said in that area. Add tests that
specifically verify GCC
On Thu, 22 Sep 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> This patch stops reporting fails for Arm targets with single
> precision floating point unit for types wider than 32 bits (the width
> of float on arm-none-eabi).
>
> As reported in PR102017, fenv is reported as supported in recent
C2x has changed the rules for defining INFINITY in so it is
no longer defined when float does not support infinities, instead of
being defined to an expression that overflows at translation time.
Thus, make the definition conditional on __FLT_HAS_INFINITY__ (this is
already inside a
On Mon, 12 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> > We don't claim in glibc to support old snapshots from master, so checking
> > for __GNUC_PREREQ (13, 0) and failing for such older GCC 13 versions is
> > fine.
>
> Ok, makes sense, especially if it is applied on the glibc side a few
On Mon, 12 Sep 2022, Jakub Jelinek via Gcc-patches wrote:
> Now, I guess for the fixincludes it could also use
> # if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
> where earlier GCC 13 snapshots would not be doing the fixincludes,
> but the question is what to use
The macro ATOMIC_VAR_INIT, previously declared obsolete,
is removed completely in C2x; disable it for C2x in GCC's
implementation. (Although ATOMIC_* are reserved names for this
header, disabling the macro for C2x still seems appropriate.)
Bootstrapped with no regressions for
On Thu, 8 Sep 2022, Kwok Cheung Yeung wrote:
> The sin and cos instructions for some reason are scaled by 2*PI radians (i.e.
> 1.0 == 2*PI radians/360 degrees), so their inputs need to be scaled by
> 1/(2*PI) first. I've implemented this as an expander to two instructions - one
C2x has sinpi and
C2x adds a macro unreachable to stddef.h, with the same semantics as
__builtin_unreachable. Define this macro accordingly.
Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit?
gcc/
* ginclude/stddef.h [__STDC_VERSION__ > 201710L] (unreachable):
New macro.
C2x follows C++ in making alignas, alignof, bool, false,
static_assert, thread_local and true keywords; implement this
accordingly. This implementation makes them normal keywords in C2x
mode just like any other keyword (C2x leaves open the possibility of
implementation using predefined macros
ISO C2x removes trigraphs, so disable them accordingly for -std=c2x
(they can still be enabled using -trigraphs).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
libcpp/
* init.cc (lang_defaults): Disable trigraphs for C2x.
gcc/testsuite/
*
On Fri, 2 Sep 2022, Richard Biener via Gcc-patches wrote:
> To catch these cases with a diagnostic earlier is
> -Wstrict-prototypes -Wold-style-declaration enough to diagnose all cases
> that the new standard will reject?
I think so.
> I suppose -W*-c2x-compat are not the correct vehicle to
C2x has completely removed unprototyped functions, so that () now
means the same as (void) in both function declarations and
definitions, where previously that change had been made for
definitions only. Implement this accordingly.
This is a change where GNU/Linux distribution builders might wish
On Thu, 1 Sep 2022, Aldy Hernandez via Gcc-patches wrote:
> Now that we keep track of the signbit, we can use it to fold
> __builtin_signbit.
>
> I am assuming I don't have try too hard to get the actual signbit
> number and 1 will do. Especially, since we're inconsistent in trunk whether
> we
Implement some changes to the currently supported C2x standard
attributes that have been made to the specification since they were
first implemented in GCC, and some consequent changes:
* maybe_unused is now supported on labels. In fact that was already
accidentally supported in GCC as a
On Wed, 31 Aug 2022, Qing Zhao wrote:
> >> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
> >> [] is treated as a valid flexible array) present together,
> >
> > That seems reasonable enough without a warning. If people want a warning
> > for flexible array members in
On Wed, 31 Aug 2022, Qing Zhao wrote:
> Does the above mean that -std=gnu89 does not support C99 flexible array
> member, then
No.
Flexible array members are supported by GCC in all C standards modes. The
C90 standard doesn't support them, but that's irrelevant to what GCC
supports; it just
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > How is level 3 (thus -fstrict-flex-array) interpreted when you specify
> > -std=c89? How for -std=gnu89?
>
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible
> array? (Checked online, cannot find a concrete
301 - 400 of 2614 matches
Mail list logo
