[Bug c++/107571] Missing fallthrough attribute diagnostics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107571 --- Comment #3 from joseph at codesourcery dot com --- On Tue, 8 Nov 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote: > And looking at the C wording in n2596.pdf, seems it is different again: That's a very old version. N3054 is the most rec

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480 --- Comment #10 from joseph at codesourcery dot com --- For scalar isnan see bug 66462. (The claim in bug 66462 comment 19 that there was ever a working version of that patch ready to go in is incorrect: November 2016 is older than June 2017.

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480 --- Comment #12 from joseph at codesourcery dot com --- __builtin_isnan must not raise "invalid" for signaling NaN arguments. __builtin_isunordered (i.e. UNORDERED / UNORDERED_EXPR; standard macro isunordered) must raise "invalid" for signalin

[Bug middle-end/107702] {,unsigned} __int128 to _Float16 conversion shouldn't use libgcc routines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702 --- Comment #1 from joseph at codesourcery dot com --- On Tue, 15 Nov 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote: > _Float16 f9 (__int128 x) { return x; } > _Float16 f10 (__int128 x) { return x; } I suppose one of those is meant to be u

[Bug middle-end/107702] {,unsigned} __int128 to _Float16 conversion shouldn't use libgcc routines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702 --- Comment #2 from joseph at codesourcery dot com --- (Where "check for any high bits being set" needs appropriate adjustment in the case of negative values for conversion from signed __int128, e.g. "the high 64 bits aren't the sign-extension

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #17 from joseph at codesourcery dot com --- On Sat, 19 Nov 2022, macro at orcam dot me.uk via Gcc-bugs wrote: > If in older C standard versions such enums are invalid, then I think > this should be a hard error rather than a silent

[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 --- Comment #19 from joseph at codesourcery dot com --- On Tue, 22 Nov 2022, macro at orcam dot me.uk via Gcc-bugs wrote: > Well, according to the assertion triggered `typeof (EM_MAX_SLOTS)' will > yield a data type of a different width dependi

[Bug other/55899] GCC should provide built-ins in data types flavor/version/variation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899 --- Comment #3 from joseph at codesourcery dot com --- C2x provides type-generic versions of various such operations, in addition to type-specific versions (but the type-specific versions are for unsigned char through unsigned long long, so do

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 --- Comment #3 from joseph at codesourcery dot com --- Editorial review before the CD ballot slipped the schedule. Second-round editorial review after a huge number of changes in the editorial review slipped the schedule. Getting a final dra

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980 --- Comment #12 from joseph at codesourcery dot com --- The standard rule about not using extra arguments means that any warnings would need to avoid even converting those arguments from pp-tokens to tokens; it's OK for them to contain pp-toke

[Bug c++/108001] unamed struct extension is documented for C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108001 --- Comment #1 from joseph at codesourcery dot com --- At least some cases of this are a standard C++ feature - which ones are still an extension for C++ and so need documenting as such?

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980 --- Comment #17 from joseph at codesourcery dot com --- The details of not expanding in cases where it matters whether and how many times something is expanded - such as arguments expanding to have unbalanced parentheses - may be a non-obvious

[Bug c/108054] C2X auto with struct defined in statement expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108054 --- Comment #2 from joseph at codesourcery dot com --- The basic principle is that auto declarations should always be writable in a form without auto, so they should never result in a type escaping to a larger scope (but a rule expressed in th

[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer since r13-2205-g14cfa01755a66afb

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043 --- Comment #3 from joseph at codesourcery dot com --- Probably the same as bug 107682.

[Bug c/108194] GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194 --- Comment #3 from joseph at codesourcery dot com --- If you use typeof instead of __typeof, and -std=c2x, these types are treated as compatible. I deliberately kept the existing semantics for __typeof, and for typeof in pre-C2x modes, when

[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #5 from joseph at codesourcery dot com --- For DFP it's not just zero for which you can't infer an equivalence of values from an equality comparison; any finite value that can be represented with more than one quantum exponent (any

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #8 from joseph at codesourcery dot com --- I expect you'd also see this issue with build-many-glibcs.py (from glibc) if you remove the workaround code in that script: # GCC uses paths such as lib/../lib64, so make sure lib

[Bug c/105510] error: initializer element is not constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105510 --- Comment #4 from joseph at codesourcery dot com --- We have a documented extension: As a GNU extension, GCC allows initialization of objects with static storage duration by compound literals (which is not possible in ISO C99 because

[Bug c/61469] language feature: Support for enum underlying type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 --- Comment #9 from joseph at codesourcery dot com --- N2963 is up for discussion in WG14 tomorrow, but there are still significant issues with the wording to resolve.

[Bug libquadmath/105101] incorrect rounding for sqrtq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #18 from joseph at codesourcery dot com --- libquadmath is essentially legacy code. People working directly in C should be using the C23 _Float128 interfaces and *f128 functions, as in current glibc, rather than libquadmath interf

[Bug libquadmath/105101] incorrect rounding for sqrtq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #20 from joseph at codesourcery dot com --- On Sat, 11 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote: > On MSYS2 _Float128 and __float128 appears to be mostly the same thing, mapped > to the same library routines with

[Bug libquadmath/105101] incorrect rounding for sqrtq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #22 from joseph at codesourcery dot com --- On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote: > > The function should be sqrtf128 (present in glibc 2.26 and later on > > x86_64, x86, powerpc64le, ia64). I do

[Bug libquadmath/105101] incorrect rounding for sqrtq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #24 from joseph at codesourcery dot com --- On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote: > > For long double it's sysdeps/ieee754/soft-fp/s_fmal.c in glibc - some > > adjustments would be needed to be ab

[Bug c/105969] [12 Regression] ICE in Floating point exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969 --- Comment #3 from joseph at codesourcery dot com --- Overlapping elements is simply a consequence of the zero-sized-objects extension, I don't see anything invalid here to reject (though there might be undefined behavior at runtime when spri

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117 --- Comment #2 from joseph at codesourcery dot com --- "none" was something I mentioned as a possible future argument when originally posting -fexcess-precision . I still think

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117 --- Comment #5 from joseph at codesourcery dot com --- The idea with "16" is to say that's the exact FLT_EVAL_METHOD value (defined in C23 Annex H) whose semantics should be followed. It would affect float/double promotion on i386 as well (th

[Bug c/106117] Use of option -fexcess-precision for operation-by-operation emulation for _Float16 arithmetics.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117 --- Comment #7 from joseph at codesourcery dot com --- FLT_EVAL_METHOD of 0 gives _Float16 excess precision ("evaluate all operations and constants, whose semantic type comprises a set of values that is a strict subset of the values of float,

[Bug c/101265] C2X [[maybe_unused]] ignored when placed after array declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101265 --- Comment #1 from joseph at codesourcery dot com --- On Tue, 29 Jun 2021, gcc at alanwu dot email via Gcc-bugs wrote: > [[maybe_unused]] int thisworks[1]; That attribute appertains to the declared entity. > int thisdoesnt[1]

[Bug c/101265] C2X [[maybe_unused]] ignored when placed after array declaration

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101265 --- Comment #3 from joseph at codesourcery dot com --- On Wed, 30 Jun 2021, gcc at alanwu dot email via Gcc-bugs wrote: > > [[attr1]] int [[attr2]] a[10] [[attr3]], b [[attr4]]; > > attr1 appertains to the variable declarations a and b, att

[Bug middle-end/101290] ICE with -O1 on valid code: in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:5976

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101290 --- Comment #2 from joseph at codesourcery dot com --- Anything constructing a constant-size type half the address space or larger in size should be diagnosed.

[Bug c/101446] -Wpedantic causes an error with zero size array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446 --- Comment #8 from joseph at codesourcery dot com --- I think this is a bug. Negative-size arrays are an unconditional error. Zero-size arrays should be a pedwarn-if-pedantic, regardless of whether the 0 is explicit or deduced from an initi

[Bug libgcc/101489] Documentation gives wrong signatures for libgcc float128 routines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101489 --- Comment #1 from joseph at codesourcery dot com --- See the "For illustrative purposes, ..." in which explains the conventions for how function prototypes are given in that part of the ma

[Bug c/101682] gcc incorrectly rejects C2x attributes after declaration-specifiers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101682 --- Comment #4 from joseph at codesourcery dot com --- On Thu, 29 Jul 2021, eggert at gnu dot org via Gcc-bugs wrote: > The grammar at the start of section 6.7 of the current C2x draft (N2596) says > that attribute specifiers may appear either

[Bug c++/100977] [C++23] Implement C++ Identifier Syntax using Unicode Standard Annex 31

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977 --- Comment #4 from joseph at codesourcery dot com --- On Wed, 4 Aug 2021, jakub at gcc dot gnu.org via Gcc-bugs wrote: > plus various changes in the check_nfc function. > So, the first question is if the C11/N11/C99 etc. stuff should use Unico

[Bug c/101953] bug on the default cast operator from double to unsigned short

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953 --- Comment #25 from joseph at codesourcery dot com --- The option to use to detect this is -fsanitize=float-cast-overflow (note: I haven't tested if it detects this particular case). As per the manual: "Unlike other similar options, @option{

[Bug target/30484] INT_MIN % -1 is well defined for -fwrapv

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484 --- Comment #13 from joseph at codesourcery dot com --- For -fwrapv, the mathematical values of INT_MIN / -1 and INT_MIN % -1 should be reduced using modulo arithmetic, so both operations are well-defined, and there is a bug then either operati

[Bug libgcc/102017] libgcc ieee754-df.S for arm does not support exceptions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017 --- Comment #2 from joseph at codesourcery dot com --- If you want to support exceptions and rounding modes for double precision on processors with hardware support for single-precision only floating-point arithmetic, I suggest using soft-fp i

[Bug c/110664] -std=c2x -pedantic-errors pedwarns on _Float128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110664 --- Comment #1 from joseph at codesourcery dot com --- Yes, this would be a bug.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 --- Comment #5 from joseph at codesourcery dot com --- The straw poll at the June meeting said to keep calling it C23 (votes 4/12/2 for/against/abstain on the question of changing the informal name to C24). Of course the actual standard will

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111058 --- Comment #5 from joseph at codesourcery dot com --- We should absolutely *not* generate calls to a non-existent function "nans" based on a long-obsolescent standard proposal. The modern way to generate a signaling NaN with given payload, a

[Bug c/111058] __builtin_nans (and its friends for other floating-point types) compiles to an external call to __builtin_nans for unsupported tag

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111058 --- Comment #7 from joseph at codesourcery dot com --- There shouldn't be such a thing as an unsupported constant payload; both __builtin_nan and __builtin_nans should rather be made consistent with parsing of payloads by glibc's nan functions

[Bug c/111309] va_arg alternative for _BitInt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #1 from joseph at codesourcery dot com --- Yes, we should have APIs for building type-generic _BitInt interfaces (also a width-of operation to give the width in bits of an integer type; also type-generic versions of operations such

[Bug c/111309] va_arg alternative for _BitInt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #3 from joseph at codesourcery dot com --- Defined values for 0 are marginally more convenient for implementing the standard operations which have defined results for all arguments, and I think it's appropriate for the type-generi

[Bug libstdc++/111390] libstdc++-v3/scripts/check_compile script is not useful

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390 --- Comment #7 from joseph at codesourcery dot com --- Stubbing out execution of tests can be done with a suitable board file (a board file to stub out linking as well is a bit more complicated). https://gcc.gnu.org/pipermail/gcc/2017-Septembe

[Bug c/111421] constexpr not working with array subscript

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421 --- Comment #1 from joseph at codesourcery dot com --- See the definitions of "named constant" and "compound literal constant". Array element accesses aren't allowed, and the example you have with "->" shouldn't be accepted either (although t

[Bug c/111421] constexpr not working with array subscript

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421 --- Comment #4 from joseph at codesourcery dot com --- The definition of constexpr in C2x is intentionally minimal, with potential for future expansion in subsequent standard revisions. Allowing array element accesses would run into needing a

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #22 from joseph at codesourcery dot com --- On Mon, 2 Oct 2023, eggert at cs dot ucla.edu via Gcc-bugs wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 > > --- Comment #20 from Paul Eggert --- > (In reply to jos...@codes

[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506 --- Comment #4 from joseph at codesourcery dot com --- Conversion from 64-bit integers for _Float16 is fully defined, it produces the correctly rounded result according to the current rounding direction (round-to-nearest may be assumed in the

[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506 --- Comment #6 from joseph at codesourcery dot com --- On Mon, 2 Oct 2023, rdapp at gcc dot gnu.org via Gcc-bugs wrote: > In our case the int64_t -> int32_t conversion is implementation defined when > the source doesn't fit the target. GCC doc

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709 --- Comment #8 from joseph at codesourcery dot com --- Typically these sorts of issues result from floating-point operations being moved past environment manipulation (fesetround, feupdateenv, feholdexcept, etc.) - in either direction. This m

[Bug web/109355] Add a text warning to old gcc online manual stating it is out of date

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355 --- Comment #5 from joseph at codesourcery dot com --- As I mentioned in previous discussions of this idea: any implementation should *not* involve simply editing the old generated files in place; it needs to involve keeping an unmodified copy

[Bug c/109412] [13 Regression] ICE in fold_convert_loc, at fold-const.cc:2627

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412 --- Comment #2 from joseph at codesourcery dot com --- May be related to bug 107682.

[Bug c++/52339] using delete ptr1->ptr2 where ptr2 destructor deletes a const ptr1 fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52339 --- Comment #8 from joseph at codesourcery dot com --- I think it's valid C99, yes: the VLA size should be evaluated exactly once, when the declaration is passed in the order of execution.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #37 from joseph at codesourcery dot com --- If _BitInt constants aren't INTEGER_CST, then all places that expect that any integer constant expression is folded to an INTEGER_CST will need updating to handle whatever tree code is us

[Bug libstdc++/43622] Incomplete C++ library support for __float128

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622 --- Comment #31 from joseph at codesourcery dot com --- It can be an extended integer type in C2x, but then stdint.h would be required to have int128_t / uint128_t / int_least128_t / uint_least128_t typedefs, and integer constant suffixes would

[Bug c/111808] [C23] constexpr with excess precision

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808 --- Comment #5 from joseph at codesourcery dot com --- We could add a "note: initializer represented with excess precision" or similar for the case where the required error might be surprising because the semantic types are the same.

[Bug c/111808] [C23] constexpr with excess precision

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808 --- Comment #7 from joseph at codesourcery dot com --- I think it's reasonable for such a portability issue to be detected only when building for i386, much like a portability issue from code that assumes long is 64-bit would only be detected

[Bug c/111808] [C23] constexpr with excess precision

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808 --- Comment #9 from joseph at codesourcery dot com --- A portability issue producing a compile failure is often better than one where there is no error but the code misbehaves at runtime on some platforms (a lot of code does not have good test

[Bug c/111884] unsigned char no longer aliases anything under -std=c2x

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884 --- Comment #2 from joseph at codesourcery dot com --- I'm going to guess this was introduced by the char8_t changes ("C: Implement C2X N2653 char8_t and UTF-8 string literal changes", commit 703837b2cc8ac03c53ac7cc0fb1327055acaebd2). /* Un

[Bug tree-optimization/112296] __builtin_constant_p doesn't propagate through member functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296 --- Comment #12 from joseph at codesourcery dot com --- I agree that the side effects of an argument to __builtin_constant_p must be discarded, for the original macro use case to work properly. There are various constructs with __builtin_* nam

[Bug libfortran/112364] calloc used incorrectly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #7 from joseph at codesourcery dot com --- I believe "size requested" refers to the product nmemb * size in the case of calloc, so getting the arguments the "wrong" way round does not affect the required alignment. The point of th

[Bug libfortran/112364] calloc used incorrectly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364 --- Comment #10 from joseph at codesourcery dot com --- The wording refers to "the size requested", which I consider to be the product of two arguments in the case of calloc - not a particular argument to calloc.

[Bug c/112449] Arithmetic operations can produce signaling NaNs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449 --- Comment #9 from joseph at codesourcery dot com --- To quote the C23 DIS, "This annex does not require the full support for signaling NaNs specified in IEC 60559. This annex uses the term NaN, unless explicitly qualified, to denote quiet Na

[Bug c/112449] Arithmetic operations can produce signaling NaNs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449 --- Comment #13 from joseph at codesourcery dot com --- On Fri, 10 Nov 2023, rguenth at gcc dot gnu.org via Gcc-bugs wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449 > > --- Comment #11 from Richard Biener --- > (In reply to post+

[Bug c/111811] [14 Regression] ICE with vector float bitfield after error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811 --- Comment #4 from joseph at codesourcery dot com --- The checks are in check_bitfield_type_and_width. I expect the attribute - in this position a declaration attribute - gets applied after that (and while applying it results in a change to

[Bug c/112556] Null pointer constants with enumeration type are not accepted

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112556 --- Comment #2 from joseph at codesourcery dot com --- Yes, this is a bug; null_pointer_constant_p gets this right, but convert_for_assignment fails to handle enumerations and booleans as possible null pointer constants. Other contexts such a

[Bug tree-optimization/112566] Some ctz/popcount/parity/ffs optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112566 --- Comment #4 from joseph at codesourcery dot com --- On Thu, 16 Nov 2023, jakub at gcc dot gnu.org via Gcc-bugs wrote: > ctz(ext(x)) == ctz(x) if UB on zero, In one direction, this should also be true for a narrowing conversion (changing ct

[Bug middle-end/112614] Compile-time float-to-_Decimal64 fails for -NAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112614 --- Comment #2 from joseph at codesourcery dot com --- The sign of a NaN isn't specified for conversions, only for a few operations such as absolute value, negation, copysign.

[Bug middle-end/32667] block copy with exact overlap is expanded as memcpy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667 --- Comment #50 from joseph at codesourcery dot com --- Qualifiers on function parameter types do not affect type compatibility or composite type (see 6.7.6.3#14). I think they're only actually of significance in the definition; in a declarati

[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112762 --- Comment #5 from joseph at codesourcery dot com --- The *-uclinux* targets are generally for systems without an MMU and a corresponding ABI (FLAT, FDPIC, etc.), whereas *-linux-uclibc* targets are for systems with an MMU and an associated c

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936 --- Comment #25 from joseph at codesourcery dot com --- Older versions of C++ - up to C++20 - would reject such characters (not allowed in identifiers based on the list of allowed characters in that standard version) even when not converted to

[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #6 from joseph at codesourcery dot com --- For the standard, dynamically allocated case, you should only need to allocate enough memory to contain the initial part of the struct and the array members being accessed - not any paddin

[Bug c/109956] GCC reserves 9 bytes for struct s { int a; char b; char t[]; } x = {1, 2, 3};

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956 --- Comment #7 from joseph at codesourcery dot com --- I suppose the question is how to interpret "the longest array (with the same element type) that would not make the structure larger than the object being accessed". The difficulty of inte

[Bug c/105863] RFE: C23 #embed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863 --- Comment #6 from joseph at codesourcery dot com --- The latest version should be taken to be what's in the working draft N3096, plus the editorial fixes from CD2 comments GB-081 through GB-084.

[Bug middle-end/113082] builtin transforms do not honor errno

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082 --- Comment #5 from joseph at codesourcery dot com --- I think it would be reasonable for glibc to require that audit modules don't change errno, at least when acting for libc function calls where glibc guarantees not changing errno. I think

<    1   2