[Bug c/105863] RFE: C23 #embed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863 --- Comment #11 from Joseph S. Myers --- It makes the changes more complicated (everything that handles CONSTRUCTORs, whether to output them to assembly or to extract values for optimization etc., needs to handle the new tree), but yes, having a new tree would allow more efficient handling of additional cases that wouldn't be so efficient with STRING_CST.
[Bug c/115109] Incorrect type of enumeration constant in redeclaration of enumeration constant (C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115109 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||uecker at gcc dot gnu.org Last reconfirmed||2024-05-16 Ever confirmed|0 |1 --- Comment #1 from Joseph S. Myers --- Adding Martin as an issue related to redefinitions of tagged types.
[Bug c/105863] RFE: C23 #embed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863 --- Comment #9 from Joseph S. Myers --- The most straightforward and most important case to optimize is the one where the #embed expansion lies entirely inside a single character array initializer (possibly with some integer constants before or after it in the initializer - whether coming from the prefix and suffix parameters to #embed or otherwise) - in which case the initializer can be converted internally to a STRING_CST. Cases that aren't within a character array initializer like that are harder to optimize (might require additional internal representation beyond the front end), and probably also less important to optimize initially.
[Bug c/81756] type attributes silently ignored on type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81756
--- Comment #3 from Joseph S. Myers ---
This sort of "???" comment about existing practice means that some past change
(in this case, the one adding support for [[]] attributes) was aiming to avoid
perturbing how the compiler behaved for constructs that were not the subject of
the change (in this case, __attribute__).
Silently ignoring attributes is not good, but it would be important to diagnose
cases where they cannot be respected, such as when the attributes appear after
the type was defined and are not consistent with the attributes in effect when
it was defined.
The documentation you refer to is intended to mean that "struct
__attribute__((...)) foo { ... }" is preferred to "struct foo { ... }
__attribute__((...))", not to suggest that the attributes should be used in a
declaration that does not define the tagged type.
[Bug c/114873] Incorrect warning generated for [*] array when in atomic or typeof type specifier for a parameter declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114873 --- Comment #4 from Joseph S. Myers --- These are not meant to be valid C (although the relevant requirement isn't a Constraint, so a diagnostic isn't required); see the discussion in DR#341.
[Bug c/114869] GCC says nullptr_t is a C built in but it should be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869 Joseph S. Myers changed: What|Removed |Added Last reconfirmed||2024-04-29 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Joseph S. Myers --- I suspect /* C-specific nullptr initialization. */ record_builtin_type (RID_MAX, "nullptr_t", nullptr_type_node); in c-decl.cc, from the original nullptr support for C.
[Bug c/114816] Non-standard behavior with void arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114816
--- Comment #1 from Joseph S. Myers ---
Note that it's not possible to define a function with such parameters ("After
adjustment, the parameters in a parameter type list in a function declarator
that is part of a definition of that function shall not have incomplete
type.").
"register void" and "const void" (single unnamed parameter) are in the list of
undefined behavior in Annex J ("A storage-class specifier or type qualifier
modifies the keyword void as a function parameter type list") - presumably
implicitly undefined for lack of definition. As for named void parameters (or
more than one void parameter, etc.), the response to C99 DR#295 says "The
Committee agrees that there do not appear to be any constraints forbidding
constructions like void func(void parm); nor are any semantics provided for
this construction." (which would also be implicitly undefined behavior).
Given the desire to reduce undefined behavior in C2y it would be reasonable to
submit a paper tightening this up by making all the problem cases (any case of
a void parameter except for the special case of a single unnamed parameter of
type void, no storage class specifier, no ellipsis following) into constraint
violations for function declarators - or indeed to raise this through the issue
tracking process once we have the new issue tracker set up, with a view to
inviting WG14 to consider this a defect applicable to older standard versions.
[Bug c/114808] Qualified void return type is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114808 --- Comment #7 from Joseph S. Myers --- Yes, this is deliberate following the resolution of DR#423 which means qualifiers are ignored on function return types (it's still diagnosed in pre-C11 modes).
[Bug c/114746] With FLT_EVAL_METHOD = 2, -fexcess-precision=fast reduces the precision of floating-point constants and floating-point constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746 --- Comment #3 from Joseph S. Myers --- The actual effect of -fexcess-precision=fast is more like "outside the back end, pretend excess precision doesn't exist, but the back end might use it anyway" (complicated a bit by having genuine excess precision logic for _Float16 still in operation when otherwise pretending excess precision doesn't exist). Pretending excess precision doesn't exist includes not having its effects on constants. Maybe that's confusing, but the effects of excess precision on constants also confuse people, as do all forms of excess precision for operations, so it's not clear that an alternative would be any better.
[Bug c/114730] should enum types be vector types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114730 --- Comment #3 from Joseph S. Myers --- When implementing C23 enums with fixed underlying types I tried to ensure that enums with underlying type bool were handled consistently with bool (cf. bug 96496 where they're not always handled consistently for C++) but it seems I missed this vector_size check.
[Bug c/114657] Invalid type conversion from some _BitInt bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114657 --- Comment #3 from Joseph S. Myers --- https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2958.htm has my analysis of the various notions of "type" used in relation to bit-fields and the questions of what expressions are considered to have special properties associated with referring to a bit-field.
[Bug c/114526] ISO C does not prohibit extensions: fix misconception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 --- Comment #15 from Joseph S. Myers --- There are several statements such as "Any pointer type may be converted to an integer type." and "A pointer to an object type may be converted to a pointer to a different object type.", that allow certain conversions to occur in a translation unit and are associated with some properties of those conversions if they are executed. There are also statements disallowing certain conversions from occurring in a translation unit (for example, conversions between pointer and floating types are constraint violations). In the cases where there is no statement either way, the behavior is undefined as a property of the translation unit (not just of the execution): it is not defined whether such a conversion may occur in a translation unit, and not defined what the semantics would be on execution if an implementation permits the translation of such a conversion. Being undefined through omission of definition has, as per clause 4, not difference in meaning or emphasis from being explicitly undefined. I'd suggest working with the Undefined Behavior Study Group on making it more explicit for each instance of undefined behavior whether it is a property of the program or of an execution thereof, but if any case seems particularly unclear, filing an issue once the new C standard issue tracker is up and running would probably be reasonable (but it seems likely that such issues would be referred to the UB study group to recommend a resolution just as floating-point issues would likely be referred to the CFP group). It's *not* the case that the same rules apply everywhere, because there are two different kinds of UB depending on whether what's undefined is a property of the program or an execution thereof. Division by zero is obviously UB as a property of an execution, because whether a value is zero is a property of the execution. Different types for the same identifier with external linkage in different translation units is obviously UB as a property of the program (and not widely diagnosed without LTO), as the whole concept of an identifier corresponding to an object with a particular value depends on a globally consistent notion of its type and the UB is about presence of declarations rather than a particular path of execution. In some cases, as here, it may be less obvious how to read the wording as referring to properties of an execution or of a program.
[Bug c/114526] ISO C does not prohibit extensions: fix misconception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 --- Comment #11 from Joseph S. Myers --- I think that simply failing to say whether a value of type X may be converted to type Y is clearly enough for it at least to be unspecified whether or when such conversions are possible in a cast at all (which is enough for rejecting the translation unit). And since no requirements are imposed relating to such conversions at either translation time or runtime, the definition of undefined behavior is met. If you try to cast from a struct to a union (for example), you violate a constraint. If you try to do a conversion between a pointer and another scalar type that's not one of the "may be converted" cases listed as allowing such a conversion, you have undefined behavior through the lack of definition (if it's an implicit conversion rather than a cast, doing it as an implicit conversion violates a constraint unless it follows the requirements for assignment expressions.)
[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533 --- Comment #7 from Joseph S. Myers --- Note also that in glibc, _Float128 support in printf code can only be used in limited circumstances: either on powerpc64le, as one of the multiple supported long double formats there, or through the sharing of the printf code with the implementation of strfromf128. In particular, there are no glibc printf formats corresponding directly to _FloatN / _FloatNx types. There was support in principle at the WG14 meeting in Strasbourg in January for having some form of printf/scanf support for such types in C2y, but major work is still needed on the wording that was proposed in N3184.
[Bug c/114526] ISO C does not prohibit extensions: fix misconception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 --- Comment #8 from Joseph S. Myers --- "rejects", in the ISO C sense, only applies to errors and pedwarns in GCC; not to warnings conditional on -pedantic (of which there are also some, but which don't turn into errors with -pedantic). If you have cases where something that is only *undefined as a property of a particular execution of the program* (as opposed to undefined as a property of a translation unit or of the collection of translation units making up a program, or violating a Constraint or syntax rule) but that are errors or pedwarns, those should be reported as separate bugs. There are various cases where we make sure to only warn at compilation time and generate code that aborts at precisely the point in execution where undefined behavior would occur, precisely because the undefined behavior in those cases is a property of a program execution. I believe conversions between function and object pointers are undefined as a property of the translation unit - not of a particular execution. Whereas e.g. calling a function pointer converted to an incompatible type is undefined as a property of a particular execution (the undefinedness only occurring when the call itself is executed, after all side effects from the function designator and arguments have taken place).
[Bug c/114526] ISO C does not prohibit extensions: fix misconception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #5 from Joseph S. Myers ---
The -pedantic documentation was updated to reflect reality - that the option is
about more than just when diagnostics are required by ISO C ("forbidden
extensions" can be taken, in the C case, as meaning those that involve
constraint violations or are outside the standard C syntax) but covers some
other programs doing things not defined in ISO C as well - in commit
074e95e34275d72664f997ed949d9c91e37cd6ee (July 2000). I don't think any
possible narrower intent there may have been long before then is particularly
relevant now.
It may well be the case that for certain diagnostics for things that do not
violate constraints or syntax rules, "ISO C does not define" or "is a GNU
extension" or similar would be better wording.
[Bug c/112571] [13 Regression] ICE with nested redefinition of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Joseph S. Myers --- Fix now backported to GCC 13 branch, so fixed in 13.3 as well.
[Bug tree-optimization/114469] gcc.dg/torture/bitint-64.c failure with -O2 -flto -std=c23 -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114469 --- Comment #1 from Joseph S. Myers --- I'd expect _Atomic _BitInt(5) to follow the same ABI (regarding upper bits being defined or not) as plain _BitInt(5), and any simplification needs to deal with that. (In principle for atomics with _BitInt with padding bits there are the same concerns as for any types with padding bits - any compare-and-exchange loop needs to succeed eventually when the underlying memory isn't being modified, rather than failing in comparison of padding bits that might not have been consistently loaded / preserved. My guess is this is unlikely to be a concern in practice for _BitInt the way it is e.g. for x86 long double where the padding bits only exist in memory and not in registers.)
[Bug tree-optimization/114465] "x % const1 % const2" should be optimized if const1 % const2 == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114465 --- Comment #1 from Joseph S. Myers --- Note that transforming x % 1 % -1 to x % -1 wouldn't strictly be valid (because of undefined behavior from INT_MIN % -1), though hopefully cases with constant 1 or -1 get optimized to 0 anyway and the undefined behavior is only a problem with a -1 that's not a constant.
[Bug middle-end/114347] wrong constant folding when casting __bf16 to int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114347 --- Comment #4 from Joseph S. Myers --- I think it's correct that conversions (explicit or implicit) from a value with excess precision convert only once; they don't first remove excess range and precision and then convert to the target type. This is not an assertion about whether we should implement __bf16 with excess precision, though it probably makes sense to do so in general for formats for which processors don't provide direct arithmetic support.
[Bug c/114266] No -pedantic diagnostic for zero-sized array in compound literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114266 Joseph S. Myers changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-07 --- Comment #2 from Joseph S. Myers --- The relevant constraint here is "An array of unknown size shall not be initialized by an empty initializer.".
[Bug middle-end/94083] inefficient soft-float x!=Inf code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083 --- Comment #6 from Joseph S. Myers --- Contrary to what was claimed in bug 66462, I don't think there ever was a fixed patch. Note that in bug 66462 comment 19, "June" is June 2017 but "November" is November 2016 - the "November" one is the *older* one.
[Bug libquadmath/114140] quadmath fminq/fmaxq with signaling_NaN not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #2 from Joseph S. Myers ---
Returning a quiet NaN when either argument is a signaling NaN is correct at
least for C (fmin/fmax correspond to IEEE 754-2008 operations, *not* the new
IEEE 754-2019 operations which are
fminimum/fmaximum/fminimum_num/fmaximum_num).
This is not a self-contained bug report ("not work" doesn't say what was
expected or why). But the output reported from the godbolt link is
std::float128_t
inf
inf
inf
inf
__float128
inf
inf
nan
nan
which looks correct for __float128 and incorrect for float128_t (suggesting
that, in the float128_t case, something might have wrongly converted the
signaling NaN to a quiet NaN before calling the underlying function).
[Bug tree-optimization/111770] predicated loads inactive lane values not modelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770 --- Comment #6 from Joseph S. Myers --- X + 0. -> X is invalid for FP with signed zero or signaling NaN, and also gets the wrong quantum exponent for decimal FP unless the zero has the maximum possible quantum exponent (which is not what you get from all bits of the representation zero, which is a zero with the minimum possible quantum exponent, or from converting integer 0 to DFP, which has quantum exponent 0). (If you add -0. (with maximum quantum exponent, in the DFP case) instead of +0., that does produce X for X not a signaling NaN - except in FE_DOWNWARD mode. Whereas adding +0. is only correct in FE_DOWNWARD mode, since 0. - 0. has positive sign in all other modes.)
[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #16 from Joseph S. Myers --- I think it's clear that __has_c_attribute(gnu::unused) should only return 1 if the [[gnu::unused]] syntax is actually parsed. (An unavoidable limitation if it might return 1 in pre-C23 modes is that if it's used with -pedantic / -pedantic-errors, such a usage of [[gnu::unused]] would then be diagnosed - since another principle is that -pedantic / -pedantic-errors should not affect semantics, in particular not change the return value of __has_c_attribute.) I also think that __has_c_attribute(gnu::unused) should always parse successfully in #if, even if it returns 0 in some cases. It's probably reasonable to accept :: in [[]] attributes in pre-C23 standard modes where those are two consecutive : tokens (the use of the [[]] syntax at all would result in a pedwarn-if-pedantic). Ideally there might be a marker on the tokens as suggested to indicate whether two such tokens would have been :: if in C23 mode, to avoid accepting other variants where the two tokens are separated in the sources. (The only reason it's not valid to produce a single preprocessing token in pre-C23 mode is to deal with corner cases such as ##-concatenating < :: > where the concatenations are valid in pre-C23 mode, producing digraphs equivalent to [], but invalid in C23 mode. Once the preprocessing tokens are converted to tokens, pre-C23 doesn't have any valid cases of two consecutive : tokens.)
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #17 from Joseph S. Myers --- The tests that GCC's internal notion of the types agrees with the headers are in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint-6.c.
[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #4 from Joseph S. Myers --- I don't know what's expected for C++, but for C, TS 18661-3 and C23 don't have versions of nexttoward for _FloatN or _FloatNx (recall that the second argument of nexttoward has type long double independent of the first argument, which is using long double as a common superset type for all the standard floating types - but no such common superset type is guaranteed to exist for all the _FloatN and _FloatNx types, and long double certainly need not be such a type, so nexttoward doesn't make sense for _FloatN or _FloatNx). Instead, those types have nextafter, nextup and nextdown functions.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #11 from Joseph S. Myers --- As I said in comment#2, I prefer a constant suffix for __int128 to the wb/uwb hack - I think it's cleaner, as well as allowing int128_t to work properly on all the targets that support __int128 but have not so far had an ABI for _BitInt defined, or not had such an ABI implemented in GCC. (I also think it's time to chase up target maintainers for all the architectures that don't yet have _BitInt support, which is almost all of them, inviting them to sort out an ABI definition either locally in GCC, in conjunction with other implementations or in an actual ABI document, as appropriate depending on the extent to which GCC for that target tries to interoperate with other implementations or externally defined ABIs, and then add the support, but that's a separate matter.)
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #5 from Joseph S. Myers --- Compiler and library are not in practice independent for this issue. GCC typically provides for freestanding compilations and forwards to a libc version for hosted compilations, and in both cases it needs to know what the types are for correct format checking (for example, whether int64_t is long or long long) - and it needs to know that even in files that didn't include , and preferably the types should be the same for hosted and freestanding. In fact it needs to know the types even when not compiling C or C++ - Fortran ISO_C_BINDING supports those types (though the Fortran standard has a specific list, not mentioning int128_t or general intN_t). And to properly support implementation - whether in GCC's or one provided by libc - any int128_t support should come with all the associated predefined macros - including __INT128_C and __UINT128_C defined to use an appropriate constant suffix.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #2 from Joseph S. Myers --- https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643237.html has my notes on things that need supporting, in , and by implication in printf and scanf, to support __int128 as an extended integer type for C23 and thus support int128_t, uint128_t, int_least128_t and uint_least128_t in . I think we *should* add such support in GCC (thus, including GCC's for the freestanding case - header changes appropriately conditional on C23 mode) and glibc. Not of course in GCC 14 at the current development stage, as it's clearly a new feature. I think it should be done with an integer constant suffix (say i128 / I128 - potentially confusing if used together with 'i' for complex integers, but not ambiguous), rather than using wb/uwb together with the hack of making macros expand to e.g. ((__int128) +123wb) to get the right type (the '+' together with the cast, to a type name that's interpreted as 0 in the preprocessor, allows such an expression to work in #if expressions as long as the value is within the range of intmax_t which is all that's allowed there). When adding such a feature to glibc we'd need to consider what user-visible features are appropriate beyond the header changes and printf/scanf support. That probably includes functions such as strotoi128 / wcstoi128 and the unsigned and _l versions thereof (using C23 semantics unconditionally for 0b, I suppose), maybe also i128abs, i128div. The type-generic macros in stdbit.h mean we don't need extra type-specific functions there. The default printf/scanf format checking in GCC is effectively for things that are either standard or in glibc - and w128 is only standard when you have support for int128_t and all the pieces that go along with that, at least on the compiler side. (I'm supposing you don't want separate musl_printf format checking support - although such a thing is possible, we do have separate ms_printf support for Windows target.)
[Bug c/113825] missing warning for omitted parameter names in function definitions (c23 extension)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113825 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Joseph S. Myers --- This is diagnosed as expected with -pedantic (given a standard older than C23) or -Wc11-c23-compat (even in C23 mode); I see no reason for this to be different from any other extension that doesn't affect the semantics of code valid in an older standard version.
[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Joseph S. Myers --- Fixed for GCC 14.
[Bug c/113776] [14 regression] postgresql-16.1 build failure with -Werror=vla in configure test since r14-8641
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113776 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org Last reconfirmed||2024-02-07 Ever confirmed|0 |1 --- Comment #3 from Joseph S. Myers --- Testing a patch.
[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455 --- Comment #6 from Joseph S. Myers --- -frounding-math is only relevant for arithmetic that occurs as-if at runtime in the abstract machine. Conversion of constants to their type (or a type with excess range and precision as indicated by DEC_EVAL_METHOD, but (a) that doesn't apply here and (b) none of the excess precision support in GCC is hooked up for decimal floating point, I think) occurs at translation time, not at runtime, so is never affected by -frounding-math or fe_dec_setround (and GCC doesn't implement the FENV_DEC_ROUND pragma to set a constant rounding mode in a particular scope).
[Bug target/113720] [14 Regression] internal compiler error: in extract_insn, at recog.cc:2812 targeting alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113720 Joseph S. Myers changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||sayle at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |14.0 Last reconfirmed||2024-02-02 Ever confirmed|0 |1 --- Comment #2 from Joseph S. Myers --- Introduced by: commit 2f14c0dbb789852947cb58fdf7d3162413f053fa Author: Roger Sayle Date: Thu Feb 1 06:10:42 2024 + PR target/113560: Enhance is_widening_mult_rhs_p.
[Bug c/112571] [13/14 Regression] ICE with nested redefinition of enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112571 Joseph S. Myers changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org Known to work||14.0 Status|NEW |ASSIGNED --- Comment #4 from Joseph S. Myers --- Fixed for GCC 14 so far.
[Bug c++/113674] [11/12/13/14 Regression] [[____attr____]] causes internal compiler error: in decl_attributes, at attribs.cc:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113674 --- Comment #5 from Joseph S. Myers --- C supports _Noreturn (and thus ___Noreturn__) as an attribute name, so that code with "#define noreturn _Noreturn" (probably from stdnoreturn.h) works with C23 [[noreturn]].
[Bug c/111911] [11/12/13 Regression] ICE with integer overflow converting to _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911 Joseph S. Myers changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE |ICE with integer overflow |with integer overflow |converting to _Bool |converting to _Bool --- Comment #8 from Joseph S. Myers --- Fixed so far for GCC 14.
[Bug c/111059] [11/12/13 Regression] ICE: in gimplify_expr, at gimplify.cc:17253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059 Joseph S. Myers changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE: |ICE: in gimplify_expr, at |in gimplify_expr, at |gimplify.cc:17253 |gimplify.cc:17253 --- Comment #7 from Joseph S. Myers --- Fixed so far for GCC 14.
[Bug c/111911] [11/12/13/14 Regression] ICE with integer overflow converting to _Bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111911 Joseph S. Myers changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Joseph S. Myers --- Testing a patch.
[Bug c/111059] [11/12/13/14 Regression] ICE: in gimplify_expr, at gimplify.cc:17253
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111059 Joseph S. Myers changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Joseph S. Myers --- Testing a patch.
[Bug target/113578] Incorrect sign printed for -nan on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578 --- Comment #2 from Joseph S. Myers --- If a conversion from float to double (for passing in variable arguments) occurs at runtime on RISC-V, that will produce a positive-signed NaN (that's what the RISC-V floating-point instructions do). Cf. https://sourceware.org/bugzilla/show_bug.cgi?id=29501 (for strfrom functions).
[Bug other/111287] doc: "strict ISO mode" definition is not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287 --- Comment #3 from Joseph S. Myers --- "even in strict ISO C90 mode" is used, correctly, when referring to C90 mode as the one with the fewest built-in functions; it's talking about __builtin_*, which are valid in all standards modes. "except in strict ISO C90 mode" is used, correctly, when talking about built-in versions of C99 functions (accepted in all modes other than strict C90). __STRICT_ANSI__ is properly defined for strict ISO C modes (any version). The "Outside strict ISO C mode" paragraph mostly lists functions not in any version of the C standard, but a few of them (exp10, roundeven, strdup, etc.) are in C23 and thus defined using DEF_C23_BUILTIN, and arguably should be moved to a separate paragraph to reflect that they are defined in strict ISO C23 mode.
[Bug target/113484] Add support for _Float16 type on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113484 --- Comment #1 from Joseph S. Myers --- It would of course be necessary to define the ABI used for _Float16 (and _Complex _Float16) argument passing and return (in each PowerPC ABI for which we support use of this feature).
[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455 --- Comment #3 from Joseph S. Myers --- If you're linking with the version of the DFP arithmetic functions (__bid_a3 etc.) in libdfp rather than the libgcc version - check the link order carefully to make sure the right version is linked in - and they're not respecting the rounding mode, that would be a libdfp issue, not a GCC one. If you're doing arithmetic with constant operands, it might be folded at compile time; make sure you're using -frounding-math to avoid that.
[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455 --- Comment #1 from Joseph S. Myers --- The decimal rounding mode is set with fe_dec_setround. libdfp provides that function and an fenv.h wrapper with constant definitions including FE_DEC_TONEARESTFROMZERO. Providing that library is outside the scope of GCC; see https://sourceware.org/pipermail/libc-alpha/2019-September/106579.html for a discussion of considerations for any integration of such support directly in glibc (which would certainly be a lot of work). libdfp is at https://github.com/libdfp/libdfp but doesn't have that much activity.
[Bug tree-optimization/113379] `MIN == MAX` should be optimzed to `a == b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113379 --- Comment #2 from Joseph S. Myers --- Note that some of these aren't valid for floating point in the presence of NaNs.
[Bug rtl-optimization/113098] [14 Regression] LRA ICE building glibc for mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113098 Joseph S. Myers changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2024-01-12 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from Joseph S. Myers --- This ICE building glibc has come back with the new fix for bug 112918 (not bisected, just presuming that commit is the cause, but it seems very likely). Note: the arc ICE observed with the previous reverted fix for bug 112918 (bug 113097) has *not* come back.
[Bug rtl-optimization/113234] missing folding to builtin_isunordered if manual nan comparison is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113234 --- Comment #1 from Joseph S. Myers --- Note that if flag_signaling_nans, __builtin_isnan should not raise exceptions for signaling NaN argument (bug 66462), but ==, != and __builtin_isunordered should raise exceptions for signaling NaN argument.
[Bug tree-optimization/113189] `(-X * Y) * -X` can be optimized to `(X * Y) * X`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113189 --- Comment #2 from Joseph S. Myers --- If Y is INT_MIN and X is -1, removing the negations introduces undefined behavior in the first example (-(-1) * INT_MIN * -(-1) is valid, -1 * INT_MIN * -1 has undefined behavior). For floating types, removing the negations isn't valid if flag_rounding_math.
[Bug middle-end/113130] `abs(a) == b` could be expanded as `(a == b || a == -b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130 --- Comment #1 from Joseph S. Myers --- Note that the first example (and the suggested one with ABS_EXPR) has undefined behavior for a == INT_MIN, while the second has undefined behavior for c == INT_MIN (and is also not equivalent to the first for negative c).
[Bug rtl-optimization/113098] New: [14 Regression] LRA ICE building glibc for mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113098
Bug ID: 113098
Summary: [14 Regression] LRA ICE building glibc for mips
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
Target Milestone: ---
Target: mips*-*-*
Created attachment 56912
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56912=edit
preprocessed source
Compile the attached code, from glibc, with -mabi=32 -O2 for MIPS (I used a
mips64-linux-gnu compiler configured --with-mips-plt --with-nan=2008
--with-arch-64=mips64r2 --with-arch-32=mips32r2; the --with-arch-32 part may
well be required to reproduce the issue).
offtime.c: In function '__offtime':
offtime.c:86:1: error: unable to find a register to spill
offtime.c:86:1: error: this is the insn:
(insn 1015 3973 3974 24 (parallel [
(set (reg:SI 2971)
(plus:SI (mult:SI (reg:SI 2367)
(reg:SI 898))
(reg:SI 2972)))
(clobber (reg:SI 2881 [2814]))
(clobber (reg:SI 2815))
]) "offtime.c":67:84 42 {*mul_acc_si}
(expr_list:REG_UNUSED (reg:SI 2815)
(expr_list:REG_UNUSED (reg:SI 2881 [2814])
(expr_list:REG_DEAD (reg:SI 2972)
(expr_list:REG_DEAD (reg:SI 2367)
(expr_list:REG_DEAD (reg:SI 898)
(nil)))
during RTL pass: reload
offtime.c:86:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.cc:1862
0x6f3f05 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/jmyers/glibc/many14/src/gcc/gcc/rtl-error.cc:108
0xd53048 lra_split_hard_reg_for()
/scratch/jmyers/glibc/many14/src/gcc/gcc/lra-assigns.cc:1862
0xd4c9c9 lra(_IO_FILE*, int)
/scratch/jmyers/glibc/many14/src/gcc/gcc/lra.cc:2518
0xd00d97 do_reload
/scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:5973
0xd00d97 execute
/scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:6161
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
ICE introduced by
commit 989e67f827b74b76e58abe137ce12d948af2290c
Author: Vladimir N. Makarov
Date: Mon Dec 18 17:12:23 2023 -0500
[PR112918][LRA]: Fixing IRA ICE on m68k
Some GCC tests on m68K port of LRA is failed on `maximum number of
generated reload insns per insn achieved`. The problem is in that for
subreg reload LRA can not narrow reg class more from ALL_REGS to
GENERAL_REGS and then to data regs or address regs. The patch permits
narowing reg class from reload insns if this results in succesful
matching of reg operand.
[Bug rtl-optimization/113097] New: [14 Regression] LRA ICE building glibc for arc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113097 Bug ID: 113097 Summary: [14 Regression] LRA ICE building glibc for arc Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: vmakarov at gcc dot gnu.org Target Milestone: --- Target: arc*-*-* Created attachment 56911 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56911=edit preprocessed source Compile the attached code, from glibc, with -O2 for arc-linux-gnu. during RTL pass: reload In file included from gconv_simple.c:587: ../iconv/skeleton.c: In function '__gconv_transform_ascii_internal': ../iconv/skeleton.c:663:1: internal compiler error: maximum number of LRA assignment passes is achieved (30) 0xd2b202 lra_assign(bool&) /scratch/jmyers/glibc/many14/src/gcc/gcc/lra-assigns.cc:1696 0xd25164 lra(_IO_FILE*, int) /scratch/jmyers/glibc/many14/src/gcc/gcc/lra.cc:2493 0xcdb80f do_reload /scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:5973 0xcdb80f execute /scratch/jmyers/glibc/many14/src/gcc/gcc/ira.cc:6161 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. ICE introduced by commit 989e67f827b74b76e58abe137ce12d948af2290c Author: Vladimir N. Makarov Date: Mon Dec 18 17:12:23 2023 -0500 [PR112918][LRA]: Fixing IRA ICE on m68k Some GCC tests on m68K port of LRA is failed on `maximum number of generated reload insns per insn achieved`. The problem is in that for subreg reload LRA can not narrow reg class more from ALL_REGS to GENERAL_REGS and then to data regs or address regs. The patch permits narowing reg class from reload insns if this results in succesful matching of reg operand.
[Bug middle-end/112909] New: [14 Regression] glibc -Wuninitialized build failure for i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112909 Bug ID: 112909 Summary: [14 Regression] glibc -Wuninitialized build failure for i686-gnu Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Target: i?86-*-* Created attachment 56829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56829=edit preprocessed source What look like spurious -Wuninitialized errors were introduced building glibc for i686-gnu (Hurd) by: commit 602e824eec30a7c6792b8b27d61c40f1c1a2714c Author: Aldy Hernandez AuthorDate: Thu Jun 29 11:27:49 2023 +0200 Commit: Aldy Hernandez CommitDate: Wed Jul 12 18:21:29 2023 +0200 [range-op] Enable value/mask propagation in range-op. Compile the attached test for i686-gnu with -O2 -Wall -Werror (likely the issue appears also as a regression for other targets, the source file in glibc that this came from is Hurd-specific so it wouldn't have broken the glibc build for other targets). ../sysdeps/mach/hurd/x86/trampoline.c: In function '_hurd_setup_sighandler': ../sysdeps/mach/hurd/x86/trampoline.c:108:22: error: 'scp' may be used uninitialized [-Werror=maybe-uninitialized] 108 | struct sigcontext *scp; | ^~~ ../sysdeps/mach/hurd/x86/trampoline.c:353:34: error: 'args' may be used uninitialized [-Werror=maybe-uninitialized] 353 | struct mach_msg_trap_args *args = (void *) state->basic.esp; | ^~~~ cc1: all warnings being treated as errors I don't see any way these variables can be used uninitialized, even taking into account the use of setjmp in this function which could well be confusing things.
[Bug target/112753] New: [14 Regression] unrecognizable insn building glibc for s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112753 Bug ID: 112753 Summary: [14 Regression] unrecognizable insn building glibc for s390x Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: jchrist at linux dot ibm.com Target Milestone: --- Target: s390*-*-* Created attachment 56709 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56709=edit preprocessed source An ICE building glibc for s390x-linux-gnu was introduced by the commit commit 466b100e5fee808d77598e0f294654deec281150 Author: Juergen Christ Date: Mon Nov 20 09:13:10 2023 +0100 s390: implement flags output Compile the attached test with -O2. In file included from ../sysdeps/ieee754/ldbl-64-128/strtold_l.c:58: ./strtod_l.c: In function 'round_and_return': ./strtod_l.c:356:1: error: unrecognizable insn: (insn 252 251 253 30 (set (reg:FPRX2 187) (subreg:FPRX2 (reg:TF 186) 0)) "./strtod_l.c":309:218 discrim 1 -1 (nil)) during RTL pass: vregs ./strtod_l.c:356:1: internal compiler error: in extract_insn, at recog.cc:2804 0x6f8bb8 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /scratch/jmyers/glibc/many14/src/gcc/gcc/rtl-error.cc:108 0x6f8bda _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /scratch/jmyers/glibc/many14/src/gcc/gcc/rtl-error.cc:116 0x6f759b extract_insn(rtx_insn*) /scratch/jmyers/glibc/many14/src/gcc/gcc/recog.cc:2804 0xb85405 instantiate_virtual_regs_in_insn /scratch/jmyers/glibc/many14/src/gcc/gcc/function.cc:1610 0xb85405 instantiate_virtual_regs /scratch/jmyers/glibc/many14/src/gcc/gcc/function.cc:1993 0xb85405 execute /scratch/jmyers/glibc/many14/src/gcc/gcc/function.cc:2040 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Joseph S. Myers --- These option names have now been implemented, and all references to the old names updated in the source tree except for documentation and tests specifically for the old names, given the preference in WG14 to keep C23 as the informal name despite the 2024 publication date, and the view at the Cauldron that it's thus now time to add these options to GCC.
[Bug tree-optimization/112358] New: [14 Regression] glibc -Wstringop-overflow= build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112358 Bug ID: 112358 Summary: [14 Regression] glibc -Wstringop-overflow= build failure Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: hppa-linux-gnu Created attachment 56497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56497=edit preprocessed source Building glibc for hppa-linux-gnu has been failing since 18 September: In file included from ../include/atomic.h:49, from dl-find_object.c:20: In function '_dlfo_update_init_seg', inlined from '_dl_find_object_update_1' at dl-find_object.c:689:30, inlined from '_dl_find_object_update' at dl-find_object.c:805:13: ../sysdeps/unix/sysv/linux/hppa/atomic-machine.h:44:4: error: '__atomic_store_4' writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 44 |__atomic_store_n ((mem), (val), __ATOMIC_RELAXED); \ |^ dl-find_object.c:644:3: note: in expansion of macro 'atomic_store_relaxed' 644 | atomic_store_relaxed (>size, new_seg_size); | ^~~~ In function '_dl_find_object_update': cc1: note: destination object is likely at address zero Compile the attached test with -O2 -Wall: In function '_dlfo_update_init_seg', inlined from '_dl_find_object_update_1' at dl-find_object.c:689:30, inlined from '_dl_find_object_update' at dl-find_object.c:805:12: dl-find_object.c:644:132: warning: '__atomic_store_4' writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] In function '_dl_find_object_update': cc1: note: destination object is likely at address zero I don't know why the compiler thinks "destination object is likely at address zero", so maybe there is actually an issue in the glibc sources, but I didn't see an obvious reason for the warning/error. Introduced by the commit: commit d45ddc2c04e471d0dcee016b6edacc00b8341b16 Author: Richard Biener AuthorDate: Thu Sep 14 13:06:51 2023 +0200 Commit: Richard Biener CommitDate: Mon Sep 18 10:56:18 2023 +0200 tree-optimization/111294 - backwards threader PHI costing
[Bug target/87281] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 --- Comment #15 from Joseph S. Myers --- Created attachment 56496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56496=edit Test that started failing on 20 July 2023 Another instance of this ICE appeared in my glibc bot on 20 July; compile ibm1008_420.i with -O2. This failure was introduced by commit ef28aadad6e5cff3d7494f3c97d435a6579a2e2d Author: Jan Hubicka Date: Thu Jul 20 15:41:39 2023 +0200 loop-ch improvements, part 3 although I fully expect it's really the same bug as for the other testcases discussed here and it was just some perturbation to the processing of this test that resulted in the appearance for that test with that commit.
[Bug target/87281] [14 Regression] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 Joseph S. Myers changed: What|Removed |Added Last reconfirmed|2019-06-14 00:00:00 |2023-11-2 Target Milestone|--- |14.0 Summary|qsort checking ICE in |[14 Regression] qsort |ia64_reorg building libgo |checking ICE in ia64_reorg ||building libgo
[Bug c/110664] -std=c2x -pedantic-errors pedwarns on _Float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110664
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #3 from Joseph S. Myers ---
Fixed by
commit r14-3731-g80acabb6dd05090db67805cdd358fe974b45e2ed
Author: Jakub Jelinek
Date: Wed Sep 6 08:51:00 2023 +0200
c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X
[Bug middle-end/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 65213, which changed state. Bug 65213 Summary: Extend -Wmissing-declarations to variables [i.e. add -Wmissing-variable-declarations] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c/65213] Extend -Wmissing-declarations to variables [i.e. add -Wmissing-variable-declarations]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65213 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |14.0 --- Comment #5 from Joseph S. Myers --- Implemented for GCC 14.
[Bug target/106282] [10/11/12/13 Regression] m68k: Problem with thread-local storage and -mcpu=5206 since r9-2326-gede9446c26a929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106282 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |10.5 Summary|m68k: Problem with |[10/11/12/13 Regression] |thread-local storage and|m68k: Problem with |-mcpu=5206 since|thread-local storage and |r9-2326-gede9446c26a929 |-mcpu=5206 since ||r9-2326-gede9446c26a929 CC||jsm28 at gcc dot gnu.org --- Comment #2 from Joseph S. Myers --- My glibc bot has been failing for ColdFire since some time between commits 79d38dd46e6b07e5a90ab25df1438eb0918eb475 and f56d48b2471c388401174029324e1f4c4b84fcdb, with an assembler error building libgomp (affinity-fmt.c) that looks just like the one in this bug. affinity-fmt.s: Assembler messages: affinity-fmt.s:4062: Error: syntax error -- statement `lea (gomp_tls_data@TLSLE+8,%a0),%a0' ignored https://sourceware.org/pipermail/libc-testresults/2022q4/010394.html Although that's from October 2022, I expect it's the same underlying issue, and just was latent building libgomp until some other change exposed it there. Note: soft-float ColdFire now fails earlier in my bot, failing to build glibc with bug 103370 (also an assembler error, also probably latent for some time before being exposed by an unrelated change).
[Bug target/103370] [12/13 Regression] Assembler error building glibc for ColdFire soft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370 --- Comment #9 from Joseph S. Myers --- The glibc build failure has done away and come back at least once since my previous comment. It came back (I think the most recent time) with commit 4fa25a7eb322f0a003c1eb15680c71ece345e01e Author: Martin Liska AuthorDate: Mon Jan 24 15:45:38 2022 +0100 Commit: Martin Liska CommitDate: Wed Nov 30 14:03:43 2022 +0100 Improve profile handling in switch lowering. PR tree-optimization/101301 PR tree-optimization/103680 though that's almost surely just exposing a back-end bug. However, the reduced test here gave a different assembler error /tmp/cc40cNSh.s: Assembler messages: /tmp/cc40cNSh.s:320: Error: syntax error -- statement `lea (.LC0@GOT+3,%a5),%a0' ignored /tmp/cc40cNSh.s:328: Error: syntax error -- statement `lea (.LC1@GOT+3,%a5),%a2' ignored both before and after that commit (different register numbers and .s line numbers before versus after). Despite the different error messages from the reduced test and building glibc, they are still likely to be the same bug in the m68k back end.
[Bug debug/106746] [13 Regression] '-fcompare-debug' failure (length) with -O2 -fsched2-use-superblocks since r13-2041-g6624ad73064de241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746 --- Comment #22 from Joseph S. Myers --- The fix introduced a regression building glibc for ia64-linux-gnu, see bug 108484.
[Bug target/108484] New: [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484 Bug ID: 108484 Summary: [13 Regression] ICE building glibc for ia64 in cselib_subst_to_values, at cselib.cc:2148 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: aoliva at gcc dot gnu.org Target Milestone: --- Target: ia64*-*-* Created attachment 54319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54319=edit preprocessed source Compile the attached file (from glibc) with -g -O2 for ia64-linux-gnu. This produces the following ICE: during RTL pass: mach In file included from ../sysdeps/ia64/unwind-resume.c:18: ../sysdeps/generic/unwind-resume.c: In function '_Unwind_Resume': ../sysdeps/generic/unwind-resume.c:38:1: internal compiler error: in cselib_subst_to_values, at cselib.cc:2148 0x5fd409 cselib_subst_to_values(rtx_def*, machine_mode) /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2148 0x98c873 cselib_subst_to_values(rtx_def*, machine_mode) /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2193 0x98f761 cselib_subst_to_values_from_insn(rtx_def*, machine_mode, rtx_insn*) /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2264 0x18172aa add_insn_mem_dependence /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:1741 0x181b230 sched_analyze_2 /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2688 0x181b267 sched_analyze_2 /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2806 0x181b9eb sched_analyze_insn /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:2960 0x181ddb0 deps_analyze_insn(deps_desc*, rtx_insn*) /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:3683 0x181e40e sched_analyze(deps_desc*, rtx_insn*, rtx_insn*) /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-deps.cc:3836 0x1821870 schedule_ebb(rtx_insn*, rtx_insn*, bool) /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-ebb.cc:505 0x1821da2 schedule_ebbs() /scratch/jmyers/glibc/many13/src/gcc/gcc/sched-ebb.cc:655 0x11b3346 ia64_reorg /scratch/jmyers/glibc/many13/src/gcc/gcc/config/ia64/ia64.cc:9862 0xdb527d execute /scratch/jmyers/glibc/many13/src/gcc/gcc/reorg.cc:3927 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Introduced by g:3c99493bf39a7fef9213e6f5af94b78bb15fcfdc commit 3c99493bf39a7fef9213e6f5af94b78bb15fcfdc Author: Alexandre Oliva Date: Thu Jan 19 01:09:15 2023 -0300 [PR106746] drop cselib addr lookup in debug insn mem The testcase used to get scheduled differently depending on the presence of debug insns with MEMs. It's not clear to me why those MEMs affected scheduling, but the cselib pre-canonicalization of the MEM address is not used at all when analyzing debug insns, so the memory allocation and lookup are pure waste. Somehow, avoiding that waste fixes the problem, or makes it go latent. for gcc/ChangeLog PR debug/106746 * sched-deps.cc (sched_analyze_2): Skip cselib address lookup within debug insns. for gcc/testsuite/ChangeLog PR debug/106746 * gcc.target/i386/pr106746.c: New.
[Bug c/108375] New: [10/11/12/13 Regression] Some variably modified types not detected as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375
Bug ID: 108375
Summary: [10/11/12/13 Regression] Some variably modified types
not detected as such
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
Target Milestone: ---
variably_modified_type_p fails to detect an array type as variably modified if
the array and its element type are of constant size but the element type is
variably modified. For example, the following code should be diagnosed as
invalid, but is not (similar rejects-valid or wrong-code examples could no
doubt be constructed as well).
void
f (int a)
{
typedef int A[a];
goto x;
A *p[2];
x : ;
}
This is a regression in 4.2 and later relative to older versions, I think
introduced by g:2e3b8fe7b5405a94d86bfa323c0e80e83c58d784 .
commit 2e3b8fe7b5405a94d86bfa323c0e80e83c58d784
Author: Eric Botcazou
Date: Wed May 17 13:11:09 2006 +
tree.c (variably_modified_type_p): Return true if the element type is
variably modified without recursing.
* tree.c (variably_modified_type_p) : Return true
if the element type is variably modified without recursing.
From-SVN: r113858
[Bug c++/107148] [10/11/12/13 Regression] ICE in bot_manip, at cp/tree.cc:3252
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107148
Joseph S. Myers changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #2 from Joseph S. Myers ---
The following test produces the same ICE without any prior errors. I'm not sure
if a statement expression should be considered valid in this context, or if
that indicates that an earlier error is needed. Compile this test with
-fimplicit-constexpr (thus, needs GCC 12 or later, so this test does not show a
regression, unlike the ICE-on-invalid regression in the original bug report).
int f(int);
class A {
public:
A(int);
};
class C {
C() : m(f(({ int x = 1; x; }))) {}
A m;
};
Alternatively, not needing -fimplicit-constexpr (rejected by GCC 10 and before;
GCC 11 and later ICE; so again not showing a regression):
int f(int);
class A {
public:
A(int);
};
class C {
constexpr C() : m(f(({ int x = 1; x; }))) {}
A m;
};
The failing assertion is
gcc_assert (VAR_P (*p) && DECL_ARTIFICIAL (*p) && !TREE_STATIC (*p));
where *p is the variable x in the statement expression, so fails
DECL_ARTIFICIAL. If this test is valid, I don't know if it should reach the
code with this assertion (or what additional issues might arise if the variable
in the statement expression were declared static).
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #12 from Joseph S. Myers --- Implemented for GCC 13.
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 Joseph S. Myers changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org --- Comment #10 from Joseph S. Myers --- I'm working on implementing this C2x feature for GCC 13.
[Bug c/107314] [13 Regression] New -Wsign-compare since r13-3360-g3b3083a598ca3f4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107314 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Joseph S. Myers --- Closing this bug, since the new behavior is as intended.
[Bug c/107164] No pedantic warning for declaration just referring to a previously-declared enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107164 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Joseph S. Myers --- Fixed for GCC 13.
[Bug c/36113] fix C enumerators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36113 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Joseph S. Myers --- Fixed for GCC 13. (Where unsigned long is 64-bit, GCC may choose that instead of unsigned long long for the underlying type of the enum, so you'll get a format checking warning in that case, but all the enum constants now have the enum type if any of them don't fit in int, in accordance with C2X.)
[Bug middle-end/107088] New: [13 Regression] cselib ICE building __trunctfxf2 on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088 Bug ID: 107088 Summary: [13 Regression] cselib ICE building __trunctfxf2 on ia64 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: stefansf at linux dot ibm.com Target Milestone: --- Target: ia64-*-* Created attachment 53641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53641=edit preprocessed source commit d0b00b63a39108311f2e6f9cbe9072579f57df7c, "cselib: Keep track of further subvalue relations", introduced an ICE building libgcc for ia64-linux-gnu. Compile with attached testcase with -O2. /scratch/jmyers/glibc/many13/src/gcc/libgcc/soft-fp/trunctfxf2.c: In function '__trunctfxf2': /scratch/jmyers/glibc/many13/src/gcc/libgcc/soft-fp/trunctfxf2.c:52:1: internal compiler error: in require, at machmode.h:297 52 | } | ^ 0x876576 opt_mode::require() const /scratch/jmyers/glibc/many13/src/gcc/gcc/machmode.h:297 0x876576 void mode_iterator::get_known_wider(scalar_int_mode*) /scratch/jmyers/glibc/many13/src/gcc/gcc/machmode.h:1124 0x876576 new_cselib_val /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1579 0x873e4e cselib_lookup_1 /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2315 0x873e4e cselib_lookup(rtx_def*, machine_mode, int, machine_mode) /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2431 0x876aff cselib_hash_rtx /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1308 0x876e69 cselib_hash_rtx /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:1505 0x873c5f cselib_lookup_1 /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2375 0x873c5f cselib_lookup(rtx_def*, machine_mode, int, machine_mode) /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2431 0x877a6a cselib_record_sets /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:2932 0x87867d cselib_process_insn(rtx_insn*) /scratch/jmyers/glibc/many13/src/gcc/gcc/cselib.cc:3159 0x1661d1c dse_step1 /scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:2771 0x1661d1c rest_of_handle_dse /scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:3687 0x1661d1c execute /scratch/jmyers/glibc/many13/src/gcc/gcc/dse.cc:3803 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c++/107080] New: ICE in verify_symtab_nodes using _Float64x with long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107080
Bug ID: 107080
Summary: ICE in verify_symtab_nodes using _Float64x with long
double
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-* i?86-* ia64-*
Compiling the following C++ test for x86_64 (or i686 or ia64) produces an ICE,
no optimization or other options required (presumably introduced by the _FloatN
/ _FloatNx support for C++).
template struct S;
template<> struct S
{
static int call (long double x, long double y) throw ()
{
return 3;
}
};
template<> struct S<_Float64x>
{
static int call (_Float64x x, _Float64x y) throw ()
{
return 3;
}
};
template
inline int
g (T1 x, T2 y) throw ()
{
typedef decltype (x + y) T3;
return S::call (x, y);
}
int
f ()
{
return g (0.0f64x, 0.0f64x) + g (0.0f64x, 0.0L);
}
t.cc:31:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
31 | }
| ^
_Z1gIeeEiT_T0_/4 (int g(T1, T2) [with T1 = _Float64x; T2 = long double])
Type: function definition analyzed
Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
previous sharing asm name: 3
References: __gxx_personality_v0/5 (addr)
Referring:
Function flags: body
Called by: _Z1fv/2
Calls: _ZN1SIeE4callEee/1
_Z1gIeeEiT_T0_/3 (int g(T1, T2) [with T1 = _Float64x; T2 = _Float64x])
Type: function definition analyzed
Visibility: semantic_interposition no_reorder public weak comdat
comdat_group:_Z1gIeeEiT_T0_ one_only
next sharing asm name: 4
References: __gxx_personality_v0/5 (addr)
Referring:
Function flags: body
Called by: _Z1fv/2
Calls: _ZN1SIeE4callEee/1
t.cc:31:1: internal compiler error: symtab_node::verify failed
0xc9ba69 symtab_node::verify_symtab_nodes()
/scratch/jmyers/glibc/many13/src/gcc/gcc/symtab.cc:1410
0xcb4ab3 symtab_node::checking_verify_symtab_nodes()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraph.h:682
0xcb4ab3 symbol_table::compile()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2264
0xcb80cd symbol_table::compile()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2261
0xcb80cd symbol_table::finalize_compilation_unit()
/scratch/jmyers/glibc/many13/src/gcc/gcc/cgraphunit.cc:2529
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c/106797] Improvement: diagnose undefined behavior: not all declarations that refer to the same object or function have compatible type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106797 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Joseph S. Myers --- See bug 21343. *** This bug has been marked as a duplicate of bug 21343 ***
[Bug c/21343] [10/11/12/13 Regression] incompatible internal linkage declarations in different scopes not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21343 Joseph S. Myers changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #25 from Joseph S. Myers --- *** Bug 106797 has been marked as a duplicate of this bug. ***
[Bug target/103370] [12/13 Regression] Assembler error building glibc for ColdFire soft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370 --- Comment #8 from Joseph S. Myers --- This build failure has come back on GCC mainline, some time between commit 3cab897a67af120aa18efa7ddd7ee49b9a29e5dd and 7f5ec900e53f6c7f7c06c641b4fb303ebdc83785.
[Bug c++/106646] [C++23] P2437R1 - Support for #warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646 --- Comment #1 from Joseph S. Myers --- Enabled for C2x (i.e. stopped -pedantic diagnosing it) with commit d7c3000147c1d8090f66a2baf4623d2c0dfe8eb6 - C++ will presumably want to adjust the diagnostics as well as enabling for relevant C++ versions and adding associated tests.
[Bug target/103722] [12 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Joseph S. Myers --- Now also applied to GCC 12 branch, so fixed for GCC 12.2.
[Bug lto/106129] [12 Regression] LTO option merging broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106129 Joseph S. Myers changed: What|Removed |Added Last reconfirmed||2022-06-30 Ever confirmed|0 |1 Summary|[12/13 Regression] LTO |[12 Regression] LTO option |option merging broken |merging broken Status|UNCONFIRMED |NEW --- Comment #2 from Joseph S. Myers --- Fixed so far for GCC 13.
[Bug lto/106129] New: [12/13 Regression] LTO option merging broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106129 Bug ID: 106129 Summary: [12/13 Regression] LTO option merging broken Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- The LTO merging of options from different input files was broken by: commit 227a2ecf663d69972b851f51f1934d18927b62cd Author: Martin Liska Date: Fri Mar 12 11:53:47 2021 +0100 lto-wrapper: Use vec data type. Previously, find_and_merge_options would merge options it read into those in *opts. After this commit, options in *opts on entry to find_and_merge_options are ignored; the only merging that takes place is between multiple sets of options in the same input file that are read in the same call to this function (not sure how that case can occur at all). The effects include, for example, that if some objects are built with PIC enabled and others with it disabled, and the last LTO object processed has PIC enabled, the choice of PIC for the last object will result in the whole program being built as PIC, when the merging logic is intended to ensure that a mixture of PIC and non-PIC objects results in the whole program being built as non-PIC. I'm testing a patch for this bug.
[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105866 Joseph S. Myers changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Joseph S. Myers --- Yes, it's now working again. https://sourceware.org/pipermail/libc-testresults/2022q2/009793.html
[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105866 Joseph S. Myers changed: What|Removed |Added Version|12.0|13.0 Target Milestone|--- |13.0
[Bug middle-end/105866] New: [13 Regression] ICE in emit_move_insn building glibc for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105866 Bug ID: 105866 Summary: [13 Regression] ICE in emit_move_insn building glibc for MIPS Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: roger at nextmovesoftware dot com Target Milestone: --- Target: mips*-*-* Created attachment 53093 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53093=edit preprocessed source Commit ed6fd2aed58f2cca99f15331bf68999c0e6df370, "PR middle-end/95126: Expand small const structs as immediate constants.", introduces an ICE for the attached test case (from glibc) on mips64-linux-gnu. Compile with: -mabi=n32 -O2 during RTL pass: expand key_call.c: In function 'key_gendes': key_call.c:224:12: internal compiler error: in emit_move_insn, at expr.cc:4012 0x95754f emit_move_insn(rtx_def*, rtx_def*) /scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:4011 0x7eb57e load_register_parameters /scratch/jmyers/glibc/many13/src/gcc/gcc/calls.cc:2192 0x7f31ad expand_call(tree_node*, rtx_def*, int) /scratch/jmyers/glibc/many13/src/gcc/gcc/calls.cc:3594 0x951d45 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:11621 0x95ee95 store_expr(tree_node*, rtx_def*, int, bool, bool) /scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:6106 0x960a47 expand_assignment(tree_node*, tree_node*, bool) /scratch/jmyers/glibc/many13/src/gcc/gcc/expr.cc:5835 0x80e7ae expand_call_stmt /scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:2829 0x80e7ae expand_gimple_stmt_1 /scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:3869 0x80e7ae expand_gimple_stmt /scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:4033 0x815a22 expand_gimple_basic_block /scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:6085 0x8180d2 execute /scratch/jmyers/glibc/many13/src/gcc/gcc/cfgexpand.cc:6811 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug libstdc++/105671] [11/12/13 Regression] Unexplained "undefined reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671 Joseph S. Myers changed: What|Removed |Added Summary|Unexplained "undefined |[11/12/13 Regression] |reference" error|Unexplained "undefined ||reference" error CC| |jsm28 at gcc dot gnu.org Component|c++ |libstdc++ Target Milestone|--- |11.4 --- Comment #2 from Joseph S. Myers --- I'm seeing the same undefined reference on a customer test case. I haven't reduced it to a self-contained test case either, but as far as I can see this is a libstdc++ issue (rather than a front-end or LTO bug). _M_high_mark (which is new in libstdc++ in GCC 11) isn't exported from libstdc++.so (it's present in libstdc++.a), presumably because the symbol version maps don't include it, so if the compiler decides to inline one of the functions from the header that calls _M_high_mark, without inlining _M_high_mark itself, there is an undefined reference to _M_high_mark. (This selective inlining is what I haven't reproduced in a self-contained test, even when adjusting various inlining parameters, but it would explain the undefined reference.)
[Bug libgcc/105669] DFP to HF (_Float16) conversions use incorrect rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105669
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2022-05-20
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Joseph S. Myers ---
Example test illustrating this bug, at least on x86_64 (the DFP input is very
close to half way between two consecutive _Float16 values):
extern void exit (int);
extern void abort (void);
#define DCONST 7.340312e-5DF
static const _Float16 f1 = DCONST;
volatile _Decimal32 d = DCONST;
int
main (void)
{
volatile _Float16 f2;
f2 = d;
if (f1 == f2)
exit (0);
else
abort ();
}
[Bug preprocessor/105412] New: [10/11/12 Regression] Missing phony target with -MP for first include when compiling from stdin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105412 Bug ID: 105412 Summary: [10/11/12 Regression] Missing phony target with -MP for first include when compiling from stdin Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org Target Milestone: --- When generating dependencies with -M -MP, the phony target for the first included header (typically stdc-predef.h) is missing if compiling from stdin, with GCC 10 and later but not with GCC 9. For example: $ echo "#include " | ./many9/install/compilers/x86_64-linux-gnu/bin/x86_64-glibc-linux-gnu-g++ -M -MP -x c++ - | grep stdc-predef /scratch/jmyers/glibc/many9/install/compilers/x86_64-linux-gnu/sysroot/usr/include/stdc-predef.h \ /scratch/jmyers/glibc/many9/install/compilers/x86_64-linux-gnu/sysroot/usr/include/stdc-predef.h: shows the expected phony target (the second line of output) with a GCC 9 compiler, but $ echo "#include " | ./many10/install/compilers/x86_64-linux-gnu/bin/x86_64-glibc-linux-gnu-g++ -M -MP -x c++ - | grep stdc-predef /scratch/jmyers/glibc/many10/install/compilers/x86_64-linux-gnu/sysroot/usr/include/stdc-predef.h \ shows that line of output is missing with GCC 10 and later. (This example is adapted from code in glibc's configure script, but the bug only actually causes problems with glibc when the compiler is used with an old sysroot lacking stdc-predef.h and so the missing phony target is that for itself.)
[Bug c/105180] [9/10/11/12 Regression] K style definition does not evaluate array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180 Joseph S. Myers changed: What|Removed |Added Summary|K style definition does |[9/10/11/12 Regression] K |not evaluate array size |style definition does not ||evaluate array size Status|UNCONFIRMED |NEW Target Milestone|--- |9.5 Ever confirmed|0 |1 Last reconfirmed||2022-04-21
[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829 --- Comment #9 from Joseph S. Myers --- Created attachment 52598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52598=edit generated assembly Assembly output attached.
[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829 --- Comment #8 from Joseph S. Myers --- Created attachment 52597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52597=edit preprocessed source Preprocessed source attached.
[Bug preprocessor/104147] [9/10/11/12 Regression] C preprocessor may remove the standard required whitespace between the preprocessing tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104147 Joseph S. Myers changed: What|Removed |Added Known to fail||3.2.3 Known to work||3.0.4 Target Milestone|--- |9.5 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-20 Ever confirmed|0 |1 Summary|C preprocessor may remove |[9/10/11/12 Regression] C |the standard required |preprocessor may remove the |whitespace between the |standard required |preprocessing tokens|whitespace between the ||preprocessing tokens --- Comment #1 from Joseph S. Myers --- This appears to be a regression between GCC 3.0 and 3.2.
[Bug target/103722] New: [12 Regression] ICE in extract_constrain_insn building glibc for SH4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103722
Bug ID: 103722
Summary: [12 Regression] ICE in extract_constrain_insn building
glibc for SH4
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
Target: sh4*-*-*
Created attachment 52003
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52003=edit
preprocessed source
Build the attached code (from glibc) with -O2 for sh4-linux-gnu. This produces
an ICE:
malloc-debug.c: In function '__debug_realloc':
malloc-debug.c:267:1: error: insn does not satisfy its constraints:
(insn 955 1863 2 2 (set (reg:SI 76 fr12 [314])
(reg:SI 146 pr)) 189 {movsi_ie}
(nil))
during RTL pass: postreload
malloc-debug.c:267:1: internal compiler error: in extract_constrain_insn, at
recog.c:2670
0x5eec04 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/rtl-error.c:108
0x5eec2a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/rtl-error.c:119
0xcab367 extract_constrain_insn(rtx_insn*)
/scratch/jmyers/glibc/many12/src/gcc/gcc/recog.c:2670
0xc71acd reload_cse_simplify_operands
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:407
0xc732bc reload_cse_simplify
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:190
0xc732bc reload_cse_regs_1
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:238
0xc7584b reload_cse_regs
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:66
0xc7584b execute
/scratch/jmyers/glibc/many12/src/gcc/gcc/postreload.c:2355
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
This was introduced (exposed?) by:
commit a7acb6dca941db2b1c135107dac3a34a20650d5c
Author: Vladimir N. Makarov
Date: Mon Dec 13 13:48:12 2021 -0500
[PR99531] Modify pseudo class cost calculation when processing move
involving the pseudo and a hard register
[Bug c++/19992] -fhosted/-ffreestanding for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19992 Joseph S. Myers changed: What|Removed |Added Known to fail||4.2.0 Target Milestone|--- |4.3.0 Known to work||4.3.0 Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Joseph S. Myers --- Fixed for GCC 4.3 by: Author: Dirk Mueller Date: Fri May 4 00:46:02 2007 + c.opt (Wmain,ffreestanding): Enable for C++,ObjC++. 2007-05-04 Dirk Mueller * c.opt(Wmain,ffreestanding): Enable for C++,ObjC++. * cp-tree.h (DECL_MAIN_P): only if -ffreestanding is not in effect. From-SVN: r124404
[Bug target/103370] [12 Regression] Assembler error building glibc for ColdFire soft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370 --- Comment #4 from Joseph S. Myers --- It seems this glibc build failure disappeared between commit b880d1514c1e3dd75a6ea311a5cc956742bd713c and commit 8e836af61b7027c0819da62c12a8d18b7c46f3fc. (Not verified that the GCC change was what's relevant - my bot updated other components as well - but it looks plausible.)
[Bug target/103370] New: [12 Regression] Assembler error building glibc for ColdFire soft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370 Bug ID: 103370 Summary: [12 Regression] Assembler error building glibc for ColdFire soft-float Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: assemble-failure Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: m68k*-*-* Created attachment 51849 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51849=edit preprocessed source Compile and assemble the attached preprocessed source (from glibc) with -O2 -fPIC -c, using a compiler configured for m68k-linux-gnu --with-arch=cf --with-cpu=54455 --disable-multilib (this is m68k-linux-gnu-coldfire-soft in build-many-glibcs.py). This produces an assembler error: /tmp/cctaeK7A.s: Assembler messages: /tmp/cctaeK7A.s: Fatal error: Tried to convert PC relative branch to absolute jump This appeared with commit 045206450386bcd774db3bde0c696828402361c6 Author: Richard Biener Date: Fri Nov 12 10:21:22 2021 +0100 tree-optimization/102880 - improve CD-DCE though I'm guessing it was most likely to have been latent before then.
[Bug c/103031] [12 Regression] Missing static initializer folding with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103031 Joseph S. Myers changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Joseph S. Myers --- Fixed for GCC 12.
[Bug middle-end/103031] New: [12 Regression] Missing static initializer folding with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103031 Bug ID: 103031 Summary: [12 Regression] Missing static initializer folding with -frounding-math Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- One of the recent fixes to avoid inappropriate constant folding with -frounding-math caused the following test to produce an error when building with -frounding-math. Static initializers in C are evaluated at translation time, in the default rounding mode and with exceptions discarded; -frounding-math should not affect this. Indeed, fold-const.c has START_FOLD_INIT and END_FOLD_INIT that are supposed to be used for static initializer folding to implement this, but apparently aren't being effective in this case. Test case: double x = -1ULL; Errors: t.c:1:12: error: initializer element is not computable at load time 1 | double x = -1ULL; |^ Note: if the initializer is cast to double, things work fine; it's only the case of implicit conversion that has the problem, so maybe something is handled differently for folding an implicit conversion of a static initializer. This breaks building glibc tests for some platforms: https://sourceware.org/pipermail/libc-alpha/2021-October/132475.html
[Bug c/88727] Diagnostics improvement: Detection of undefined behaviour. Incomplete type in tenative definition with internal linkage. [-Wtentative-definition-incomplete-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88727 Joseph S. Myers changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #3 from Joseph S. Myers --- *** Bug 102821 has been marked as a duplicate of this bug. ***
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 Joseph S. Myers changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Joseph S. Myers --- This is in a Semantics section of the standard, not Constraints, so no diagnostic is required, but as a quality-of-implementation matter we should diagnose it. *** This bug has been marked as a duplicate of bug 88727 ***
