[Bug target/99900] feature request: 16-bit x86 C compiler / support compilation of (VirtualBox) BIOS

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99900

--- Comment #3 from joseph at codesourcery dot com  ---
I've no idea whether the (not merged) ia16 port can do this, or whether 
the person currently maintaining a version of that port for GCC 6 is 
covered by an FSF copyright assignment.

https://gcc.gnu.org/legacy-ml/gcc-patches/2017-04/msg9.html
https://gcc.gnu.org/legacy-ml/gcc/2018-06/msg00103.html
https://github.com/tkchia/gcc-ia16

[Bug c/99955] gcc.c-torture/execute/pr92618.c violates strict aliasing rules

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99955

--- Comment #4 from joseph at codesourcery dot com  ---
I think may_alias ought to work together with vector_size, whatever its 
position in the attribute list, i.e. there is a front-end bug here for 
which making that combination of attributes work properly together in any 
order is the right fix.

[Bug c/100064] False positive with -Wincompatible-pointer-types

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100064

--- Comment #1 from joseph at codesourcery dot com  ---
This conversion is required to be diagnosed by ISO C.  Some way of marking 
a particular cast as being an inheritance cast (thus, to be diagnosed if 
the types don't in fact match) would seem better than disabling it by 
default and assuming an implicit conversion is deliberate rather than a 
user mistake.

[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474

--- Comment #8 from joseph at codesourcery dot com  ---
p and p->p are two different pointer objects, the first restricted, so 
it's not valid to use p->p to access an object that's also accessed via p 
(and modified).

This is different from the case where there is one pointer object but 
multiple expressions, indirecting through multiple other pointer objects, 
that refer to it.  For that case, of multiple expressions that all end up 
referring to the same pointer object, see bug 14192 comment 8 where I 
discuss the rule about "restrict" when pointers to pointers are involved.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #1 from joseph at codesourcery dot com  ---
The C front end doesn't have any kind of general lvalue-to-rvalue 
conversion in the IR (other than for atomic lvalues where the code 
required for such a conversion is more than a simple load, as handled by 
convert_lvalue_to_rvalue) that tries to drop qualifiers; the DECL node is 
used directly to represent a load of a variable, even when the rvalue 
would have the unqualified type.  The circumstances in which typeof 
produces a qualified result type are underspecified.  When a C standard 
construct uses a type in a way that cares about qualifiers not being 
present on rvalues (which I think only applies to _Generic), the removal 
is handled at that point; see this code from c_parser_generic_selection:

  selector = default_function_array_conversion (selector_loc, selector);
[...]
  selector_type = TREE_TYPE (selector.value);
  /* In ISO C terms, rvalues (including the controlling expression of
 _Generic) do not have qualified types.  */
  if (TREE_CODE (selector_type) != ARRAY_TYPE)
selector_type = TYPE_MAIN_VARIANT (selector_type);
  /* In ISO C terms, _Noreturn is not part of the type of expressions
 such as &abort, but in GCC it is represented internally as a type
 qualifier.  */
  if (FUNCTION_POINTER_TYPE_P (selector_type)
  && TYPE_QUALS (TREE_TYPE (selector_type)) != TYPE_UNQUALIFIED)
selector_type
  = build_pointer_type (TYPE_MAIN_VARIANT (TREE_TYPE (selector_type)));

That said, the resolution of bug 45584 means casts always produce a result 
with explicitly unqualified type (including casts to a qualified type, see 
gcc.dg/pr13519-1.c).  It would seem reasonable to do the same for the 
comma operator.  There will be other places as well that do not remove 
qualifiers when constructing the internal representation for rvalues and 
would need adjusting to make the constness of the IR more consistent.  
One example is applying unary '+' to a const int variable; combine that 
with typeof and it shows the result to be const at present.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #3 from joseph at codesourcery dot com  ---
T5 in that list is an lvalue, so it seems right not to drop qualifiers 
there.

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702

--- Comment #5 from joseph at codesourcery dot com  ---
A standard version might well end up being handled slightly differently 
from the existing GNU version (cf. _Alignof and __alignof).

[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326

--- Comment #7 from joseph at codesourcery dot com  ---
I agree that match.pd is a sensible place for this (and the front end is 
not, we should be getting optimizations out of the front ends).

I'd encourage anyone looking at this also to look at convert_to_real_1, 
which has different, related optimizations (which also would be better off 
in match.pd rather than as part of convert).

The particular example test in this bug report would also need to pass 
that deals with fusing operations (when permitted by the fp-contract 
setting) to handle the case where promotions to a wider type (with the 
same radix) are involved; I don't know if it does handle that at present.

[Bug target/97865] libtool needs to be updated for Darwin20.

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865

--- Comment #12 from joseph at codesourcery dot com  ---
config.sub and config.guess are imported, unmodified, from upstream 
config.git.

libtool has lots of local changes, hopefully all of them submitted 
upstream but maybe not and maybe some not committed upstream (libtool has 
very few commits in recent years, but lots since the 2009 version used in 
GCC).  As well as checking all the local changes (relative to libtool 
commit 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622, apparently) and applying 
them to a new version as needed, updating libtool would also require 
reverting libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c to deal 
with a mismatch of --with-sysroot interpretations.

[Bug c++/97965] constexpr evaluation vs. NaNs inconsistency

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97965

--- Comment #1 from joseph at codesourcery dot com  ---
I don't think there should be any difference between quiet and signaling 
NaNs here, since < <= > >= comparisons with either kind of NaN raise 
"invalid"; it's == != (and the __builtin_is* comparisons) that only raise 
exceptions for signaling NaN but not quiet.

[Bug c/97986] ICE in force_constant_size when applying va_arg to VLA type

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97986

--- Comment #1 from joseph at codesourcery dot com  ---
I guess this should be handled like va_arg for float: give a warning about 
the type passed, then generate an abort (making sure that side-effects in 
both arguments take effect before the abort, in case a side-effect 
involves calling longjmp or exit).

(Technically a fixed-size array type argument to va_arg could be used in 
C90 mode to retrieve a non-lvalue array passed by value as a function 
argument, but the result would just be another non-lvalue array with no 
way to access the array elements, so just as useless as all other cases of 
non-lvalue arrays in C90.  So although specifying any array type as the 
second argument to va_arg is very dubious, maybe the case of a non-VLA in 
C90 mode should not generate an abort.)

[Bug preprocessor/97998] GCC should not complain about double definitions of macros whose names begin with __STDC_

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97998

--- Comment #2 from joseph at codesourcery dot com  ---
In bug 91451 I suggested changing this specifically for __STDC_WANT_*.

[Bug tree-optimization/98095] Optimize __builtin_unordered (...) || __builtin_is{less,greater}{,equal}

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98095

--- Comment #1 from joseph at codesourcery dot com  ---
There's no __builtin_isequal because == and != don't raise exceptions for 
quiet NaNs anyway.  (The lack of __builtin_iseqsig is bug 77928.)

[Bug c/98217] Prefer a warning for when VLAs declared on stack

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98217

--- Comment #11 from joseph at codesourcery dot com  ---
It would seem reasonable to have options both for the case of warning 
about all VLA declarations, and more specifically for the case of 
allocating a VLA on the stack.  The diagnostics for all VLA declarations, 
including [*], are needed in any case for -std=c90 -pedantic (as pedwarns, 
so they become errors with -pedantic-errors) and -Wc90-c99-compat / 
-Wc++-compat (as warnings).

[Bug bootstrap/98323] current trunk won't build with clang

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98323

--- Comment #9 from joseph at codesourcery dot com  ---
The original intent in the C standard was definitely to allow at least 
some cases of subobjects; the May 20, 1988 list of changes in the third 
public review draft of C89 has as item 10 "The offsetof macro has been 
generalized to allow more than just a simple identifier as its second 
argument.".

[Bug target/98549] [11 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:9938 on powerpc64le-linux-gnu

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549

--- Comment #15 from joseph at codesourcery dot com  ---
On Mon, 18 Jan 2021, segher at gcc dot gnu.org via Gcc-bugs wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
> 
> --- Comment #14 from Segher Boessenkool  ---
> (In reply to Jakub Jelinek from comment #13)
> > For UB at runtime, we can warn, but shouldn't error because the code might
> > never be invoked at runtime.
> 
> As far as I can see at least the C standard disagrees with this:
>   NOTE Possible undefined behavior ranges from ignoring the situation
>   completely with unpredictable results, to behaving during translation
>   or program execution in a documented manner characteristic of the
>   environment (with or without the issuance of a diagnostic message), to
>   terminating a translation or execution (with the issuance of a
>   diagnostic message).
> 
> So we are allowed to error.

Only if the undefined behavior is a property of the program, or of all 
possible executions of the program, as opposed to a property of a 
particular execution of the program.  See C90 DR#109.  "A conforming 
implementation must not fail to translate a strictly conforming program 
simply because *some* possible execution of that program would result in 
undefined behavior.".

[Bug c/98826] [gcc vs g++] qualified type of members of anonymous struct

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98826

--- Comment #1 from joseph at codesourcery dot com  ---
As I said on the WG14 reflector, I think the natural handling of anonymous 
structs and unions for C is that anonymity provides only a shorthand for 
name lookup (member access, designated initializers, offsetof) with 
everything else being exactly as if the anonymous member were named.

[Bug c/98945] gcc does not warn when assigning value of type int (*)() to variable of type int (*)(double)

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98945

--- Comment #3 from joseph at codesourcery dot com  ---
The relevant rule in ISO C is 6.7.6.3#15 (in C17): "For two function types 
to be compatible ... If one type has a parameter type list and the other 
type is specified by a function declarator that is not part of a function 
definition and that contains an empty identifier list, ... the type of 
each parameter shall be compatible with the type that results from the 
application of the default argument promotions".  Thus, a declaration with 
a float argument is incompatible with an unprototyped declaration.

*However* I see that when I implemented N2432 (removal of old-style 
function definitions) for C2x mode, I missed that that paper also removed 
that rule (keeping only the rule that an unprototyped declaration is 
incompatible with a variadic prototype).  It's not obvious to me that such 
a change was intentional and it doesn't appear to have been discussed (it 
wasn't the main point of that paper), and it's still the case that you 
can't actually call a function with (float) prototype if only an 
unprototyped declaration is in scope, without undefined behavior; I'll 
raise that question on the WG14 reflector.

[Bug driver/98943] [11 Regression] gcc driver does not fail on unknown files: tricks configure scripts to recognize /W4 and -diag-disable 1,2,3,4 options

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98943

--- Comment #7 from joseph at codesourcery dot com  ---
On Wed, 3 Feb 2021, nathan at gcc dot gnu.org via Gcc-bugs wrote:

> a) Reject any filename that is -STUFF (allow plain '-')

Any -STUFF that's not a known option should be handled as 
OPT_SPECIAL_unknown and should not go through OPT_SPECIAL_input_file code 
at all.

[Bug c/98965] assignment to a struct with an atomic member not atomic

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98965

--- Comment #4 from joseph at codesourcery dot com  ---
The difficulty with making such an assignment atomic is that atomic 
operations for different sizes of atomic access don't interoperate on the 
same memory; if the struct contains an _Atomic int, that's accessed 
atomically via appropriate int-sized atomic operations, while a larger 
structure may use locking for atomic access in libatomic, and if both 
mechanisms are used on the same memory the result doesn't properly follow 
the memory model.

So you'd need to split struct assignment up into assignment of members to 
access a member atomically.  But that couldn't work at all when you have a 
union with atomic members, because in the union case the compiler can't 
know which is the currently active member that would determine the size of 
the atomic access.

[Bug tree-optimization/98984] Failure to optimize out float conversion from long long->float->char conversion

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98984

--- Comment #2 from joseph at codesourcery dot com  ---
Under Annex F, conversion of an out-of-range floating-point value to an 
integer type other than _Bool produces an unspecified value with the 
"invalid" exception raised.  Losing that exception (and "inexact" for 
unsigned long long values not representable exactly in float) makes such a 
transformation questionable unless -fno-trapping-math is used.

[Bug middle-end/100595] ICE: output_operand with static const int of address of label + difference of label

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100595

--- Comment #3 from joseph at codesourcery dot com  ---
My old model of constant expressions for GNU extensions says that the 
difference of two label addresses is a "label difference constant 
expression", which is valid as a static initializer by itself but not when 
added to anything.

https://www.polyomino.org.uk/computer/c/const-exprs-gnu.txt

[Bug c/100854] TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854

--- Comment #1 from joseph at codesourcery dot com  ---
On Tue, 1 Jun 2021, acoplan at gcc dot gnu.org via Gcc-bugs wrote:

> This could be considered a bug in TS 18661-3 which stipulates that
> __FLT_EVAL_METHOD__ take backwards-incompatible values. Either way, it seems

TS 18661-3 only talks about FLT_EVAL_METHOD, not __FLT_EVAL_METHOD__.  
GCC's  then uses __FLT_EVAL_METHOD__, 
__FLT_EVAL_METHOD_TS_18661_3__ and __STDC_WANT_IEC_60559_TYPES_EXT__ to 
determine the value of FLT_EVAL_METHOD, taking account of any 
-fpermitted-flt-eval-methods option (or other options implying it) passed.

[Bug c/100993] ICE with -O2: Segmentation fault, cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100993

--- Comment #3 from joseph at codesourcery dot com  ---
Rejecting __builtin_* declarations was previously discussed in bug 32455.  
If we do, it would probably be worth testing building various software 
with the patched GCC to see what issues arise.

For many purposes, __sync_* and __atomic_* are built-in function 
namespaces just like __builtin_* (see builtins.c:is_builtin_name).  
However, functions with such names are definitely defined in libgcc and 
libatomic, and quite possibly might be defined elsewhere.

[Bug target/101128] DFP support for aarch64 is missing

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101128

--- Comment #3 from joseph at codesourcery dot com  ---
Bug 91985 was the bug that DFP constants were wrongly accepted by older 
GCC versions on architectures lacking DFP support.

[Bug middle-end/101170] [12 Regression] ICE in df_ref_record building libgomp for ColdFire

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101170

--- Comment #2 from joseph at codesourcery dot com  ---
No.  It's still broken as of commit 
f61e5d4d8b6d4cfa96863187fa61b8c6b057a491.

[Bug libgcc/108279] Improved speed for float128 routines

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108279

--- Comment #17 from joseph at codesourcery dot com  ---
It's not part of the ABI for the Arm 32-bit Architecture (AAPCS32).

https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst

You can file an issue there if you want, though I don't know how 
interested the maintainers will be in that optional language feature.

[Bug c/47781] warnings from custom printf format specifiers

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #29 from joseph at codesourcery dot com  ---
As I said before, the issue is still how to define something general 
enough to be useful but that doesn't expose too much of the details of 
GCC's internal data structures for format checking.

[Bug c/108531] Imaginary types are not supported, violating ISO C Annex G

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531

--- Comment #6 from joseph at codesourcery dot com  ---
My only real addition to my previous comments in the referenced glibc bug 
report is that, given we defined _Float32 which has the same "not promoted 
at language level in variable arguments" property as _Imaginary float and 
let it have the ABI arising naturally from the back ends in the absence of 
target maintainers / ABI maintainers choosing something different, it 
would probably be reasonable to do the same thing for imaginary types; 
this case is rather different from _BitInt where there are significant ABI 
choices to be made for each architecture (and I've filed bugs on various 
ABI repositories to request that such ABIs be defined).  It would be good 
if psABI maintainers kept up more with C standard features, however.

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84764

--- Comment #5 from joseph at codesourcery dot com  ---
Also, for it to become an extended integer type, it would be necessary to 
define integer constant suffixes and implement printf / scanf support in 
the library, because  is now required to provide intN_t / 
uintN_t when there is a matching standard or extended integer type, so 
would be required to provide int128_t / uint128_t, which in turn would 
require the corresponding  and  macros, so requiring 
constant suffixes and printf / scanf support.

[Bug middle-end/108623] We need to grow the precision field in tree_type_common for PowerPC

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623

--- Comment #8 from joseph at codesourcery dot com  ---
See also bug 102989 (C2x _BitInt) regarding another case for which growing 
TYPE_PRECISION would be useful.

[Bug target/108742] Incorrect constant folding with (or exposed by) -fexcess-precision=standard

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742

--- Comment #11 from joseph at codesourcery dot com  ---
As discussed, FLT_EVAL_METHOD applies to constants as well as to 
operations.  See the example in C17 F.8.5, for example; it shows

float y = 1.1e75f; // may raise exceptions

since 1.1e75f may be evaluated to a wider range and precision than those 
of float, in which case the conversion to the range and precision of float 
occurs at runtime (whereas if there is no excess range and precision for 
float, the constant is evaluated to positive infinity of type float at 
translation time).

[Bug c/108796] Can't intermix C2x and GNU style attributes

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796

--- Comment #6 from joseph at codesourcery dot com  ---
The logic is that GNU attributes are declaration specifiers (and can mix 
anywhere with other declaration specifiers), but standard attributes 
aren't declaration specifiers; rather, they come in specified positions 
relative to declaration specifiers (the semantics before and after the 
declaration specifiers are different), and in the middle isn't such a 
position.

[Bug c/108796] Can't intermix C2x and GNU style attributes

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796

--- Comment #8 from joseph at codesourcery dot com  ---
On Thu, 16 Feb 2023, aaron at aaronballman dot com via Gcc-bugs wrote:

> > The logic is that GNU attributes are declaration specifiers (and can mix 
> > anywhere with other declaration specifiers), but standard attributes 
> > aren't declaration specifiers; rather, they come in specified positions 
> > relative to declaration specifiers (the semantics before and after the 
> > declaration specifiers are different), and in the middle isn't such a 
> > position.
> 
> How does that square with:
> ```
> struct __attribute__((packed)) S { ... };
> void func(int *ip) __attribute__((nonnull(1)));
> ```
> where the GNU attribute is not written where a declaration specifier is
> allowed?

GNU attributes are declaration specifiers *in the previous examples given 
here*, not necessarily in all other cases.  The position in relation to 
other declaration specifiers does not matter in those examples.  Whereas a 
standard attribute at the start of declaration specifiers appertains to 
the entity declared, while a standard attribute at the end of declaration 
specifiers appertains to the type in those declaration specifiers.  That 
is

[[noreturn]] void f();

declares a non-returning function f, but

void [[noreturn]] f();

applies the attribute (invalidly) to the type void, not to the function f.  
While __attribute__((noreturn)) means exactly the same thing in both 
locations - it appertains to the function (and you could also have it in 
the middle of other declaration specifiers, with the same meaning).  So 
the two kinds of attributes are not interchangable, and the semantics for 
arbitrary mixtures would not be clear.

It might work to have arbitrary mixtures in the struct context.  But in 
the

void func(int *ip) __attribute__((nonnull(1)));

context you again have attributes appertaining to different things: a GNU 
attribute in that position is in a particular position *in a declaration* 
(after any asm ("identifier"), before an initializer), and appertains to 
the entity declared, whereas a standard attribute in such a position is 
part of the declarator (immediately following a function-declarator or 
array-declarator) and appertains to the function type - although they look 
superficially like the same case in simple examples such as this one, they 
aren't at all.  And so again it would be unclear what attributes in 
arbitrary mixtures should appertain to.

(There is then logic in GCC to handle __attribute__ that, according to the 
syntax, should appertain to a particular entity, so that it's instead 
applied to some other related entity; for example, moving an attribute 
from a declaration to its type.  This is deliberately *not* done for [[]] 
attribute syntax; those attributes are expected to be written in a correct 
location for the entity they appertain to.)

[Bug c/69960] "initializer element is not constant"

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960

--- Comment #21 from joseph at codesourcery dot com  ---
On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:

> First of all, it is questionable if gcc is still conforming after the change
> discussed here and implemented as per gcc 8.0. Yes "an implementation may
> accept other forms of constant expressions" but that doesn't mean that a
> compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the 
> definition
> of an integer constant expression. So this ought to explicitly be a compiler
> extension and we ought to have a way to reliably compile strictly conforming
> programs with gcc without constraint violations silently getting ignored. 

"integer constant expression" does not mean the same thing as "constant 
expression of integer type".  If you use this expression in a context 
requiring an integer constant expression (case label, bit-field width, 
array designator in initializer, enum value, array size at file scope, 
constexpr initializer for object of integer type, etc.), it's properly 
rejected as required; in contexts where both integer constant expressions 
and other expressions are valid but with different semantics (e.g. 
determining whether something is a null pointer constant, determining 
whether an array is a VLA in a context where both VLA and non-VLA arrays 
are valid), again it's treated as non-constant.

[Bug c/69960] "initializer element is not constant"

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960

--- Comment #22 from joseph at codesourcery dot com  ---
I do however expect there may be cases in GCC 13 where constexpr 
initializers of floating type are accepted that do not meet the definition 
of arithmetic constant expressions, since GCC is generally a lot more 
careful about ensuring things are integer constant expressions when 
required than it is about doing the same for arithmetic constant 
expressions (before C2x there weren't any cases that allowed arithmetic 
constant expressions without also allowing other kinds of constant 
expressions permitted in initializers).

[Bug c/69960] "initializer element is not constant"

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960

--- Comment #24 from joseph at codesourcery dot com  ---
On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:

> In this code 
> 
> static const int y = 1;
> static int x = y;
> 
> y is not an integer constant expression, nor is it an integer constant in the
> meaning that ISO 9899 defines it.

Correct, but irrelevant, since nothing in that code example is required by 
the standard to be an integer constant expression.

> Therefore an initializer was given which is
> not a constant expression.

No, it's an "other form of constant expression" accepted by GCC.

> "an implementation may accept other forms of constant expressions" does not
> mean that an implementation can throw out any constraints it pleases out the
> window.

Correct.  The Constraints on constant expressions say "Constant 
expressions shall not contain assignment, increment, decrement, 
function-call, or comma operators, except when they are contained within a 
subexpression that is not evaluated." and "Each constant expression shall 
evaluate to a constant that is in the range of representable values for 
its type.".  The initializer is entirely consistent with those 
Constraints, so it is within the bounds of what an implementation may 
accept as an "other form of constant expression".  Whereas it wouldn't be 
valid for an implementation to accept f() as a constant expression 
(contains a function call), for example.

Note also that only violations of Syntax and Constraints require 
diagnostics (and thus -pedantic doesn't claim to ensure diagnostics for 
code that's not strictly conforming for some other reason than violating 
Syntax or Constraints).

[Bug analyzer/109098] Encoding errors on SARIF output for non-UTF-8 source files

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098

--- Comment #6 from joseph at codesourcery dot com  ---
For diagnosis of non-UTF-8 in strings / comments, see commit 
0b8c57ed40f19086e30ce54faec3222ac21cc0df, "libcpp: Add -Winvalid-utf8 
warning [PR106655]" (implementing a new C++ requirement).

[Bug c/89408] No constant folding when dereferencing string literals

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89408

--- Comment #6 from joseph at codesourcery dot com  ---
Case labels are required to be integer constant expressions.  In most 
cases where an integer constant expression is required, something that 
isn't an integer constant expression but folds to an integer constant is 
accepted with a pedwarn-if-pedantic (see c-typeck.cc:do_case for this in 
the case of case labels, where the diagnostic is "case label is not an 
integer constant expression").  *But* note that this is mainly for 
compatibility with pre-GCC-4.5 code depending on folding that occurred 
before GCC 4.5; as I said in 
, it's not any 
sort of designed, documented extension with stable semantics that it would 
be a good idea to use.

[Bug d/104738] gdc.test/runnable_cxx/stdint.d FAILs on Solaris

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104738

--- Comment #3 from joseph at codesourcery dot com  ---
char having the same set of values as signed char is valid.

char is not however a "signed integer type" within the meaning of the 
standard, and so is never a valid definition of int8_t, despite Solaris 
using that definition.

https://gcc.gnu.org/legacy-ml/gcc/2009-04/msg00249.html

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829

--- Comment #6 from joseph at codesourcery dot com  ---
The compilation command is:

/scratch/jmyers/glibc/many12/build/compilers/powerpc-linux-gnu/gcc/./gcc/xgcc 
-B/scratch/jmyers/glibc/many12/build/compilers/powerpc-linux-gnu/gcc/./gcc/ 
-B/scratch/jmyers/glibc/many12/install/compilers/powerpc-linux-gnu/powerpc-glibc-linux-gnu/bin/
 
-B/scratch/jmyers/glibc/many12/install/compilers/powerpc-linux-gnu/powerpc-glibc-linux-gnu/lib/
 
-isystem 
/scratch/jmyers/glibc/many12/install/compilers/powerpc-linux-gnu/powerpc-glibc-linux-gnu/include
 
-isystem 
/scratch/jmyers/glibc/many12/install/compilers/powerpc-linux-gnu/powerpc-glibc-linux-gnu/sys-include
 
-g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall 
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC 
-mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc 
-fno-stack-protector   -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. 
-I../.././gcc -I/scratch/jmyers/glibc/many12/src/gcc/libgcc 
-I/scratch/jmyers/glibc/many12/src/gcc/libgcc/. 
-I/scratch/jmyers/glibc/many12/src/gcc/libgcc/../gcc 
-I/scratch/jmyers/glibc/many12/src/gcc/libgcc/../include 
-I/scratch/jmyers/glibc/many12/src/gcc/libgcc/../libdecnumber/dpd 
-I/scratch/jmyers/glibc/many12/src/gcc/libgcc/../libdecnumber 
-DHAVE_CC_TLS  -Wno-type-limits -mvsx -mfloat128 -mno-float128-hardware 
-mno-gnu-attribute -I/scratch/jmyers/glibc/many12/src/gcc/libgcc/soft-fp 
-I/scratch/jmyers/glibc/many12/src/gcc/libgcc/config/rs6000  
-mno-gnu-attribute -Wno-psabi -mabi=ieeelongdouble  -o _kf_to_sd.o -MT 
_kf_to_sd.o -MD -MP -MF _kf_to_sd.dep  -c 
/scratch/jmyers/glibc/many12/src/gcc/libgcc/config/rs6000/_kf_to_sd.c 
-fvisibility=hidden -DHIDE_EXPORTS

The generated .s file has ".machine ppc".  Maybe there is some 
inconsistency arising from the use of -mvsx -mfloat128 for this 32-bit 
configuration with no --with option to change the default CPU?  Should 
these KFmode functions really be being built for 32-bit libgcc at all?

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829

--- Comment #12 from joseph at codesourcery dot com  ---
I still get the same error (and the same ".machine ppc") with that patch 
applied.

[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829

--- Comment #15 from joseph at codesourcery dot com  ---
I confirm that the second patch does fix the problem I see.

[Bug target/104984] Use hard-fp for libgcc single-floating-point routines

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104984

--- Comment #2 from joseph at codesourcery dot com  ---
See libgcc/config/rs6000/t-e500v1-fp (which should have been removed along 
with associated configure logic when the powerpcspe port was removed, the 
cases using that file should no longer be reachable), for an example of a 
configuration using hardware floating point for single precision only.

[Bug other/105114] [12 regression] contrib/gcc_update hangs

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114

--- Comment #9 from joseph at codesourcery dot com  ---
The dependencies in gcc_update refer to 
gcc/config/loongarch/genopts/loongarch-string which doesn't exist (should 
be loongarch-strings not loongarch-string, I suppose).  Maybe that's 
causing the problem?

[Bug c/105149] [9/10/11/12 Regression] ICE in verify_ssa, at tree-ssa.cc:1211

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149

--- Comment #7 from joseph at codesourcery dot com  ---
I think it's valid to reject this at compile time (rather than just 
generating a runtime trap): the "such that the type of a pointer to an 
object that has the specified type can be obtained simply by postfixing a 
* to type" can never be satisfied for a function type, even if e.g. a 
typedef name is used so that postfixing '*' produces valid syntax for the 
corresponding pointer type, because it still wouldn't be "the type of a 
pointer to an object".

[Bug rtl-optimization/105376] ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105376

--- Comment #3 from joseph at codesourcery dot com  ---
For this transformation to be correct for DFP, you need a 2 with quantum 
exponent 0.  Converting from either integer or binary floating-point 2 
will work for that.  However, I note that decimal_to_decnumber has

case rvc_normal:
  if (!r->decimal)
{
  /* dconst{1,2,m1,half} are used in various places in
 the middle-end and optimizers, allow them here
 as an exception by converting them to decimal.  */

so the existing code ought to work as-is.  Maybe there is a problem with 
padding in REAL_VALUE_TYPE meaning the comparisons don't work as intended?

[Bug tree-optimization/105384] compilation never (?) finishes with __builtin_yn{,f,l} at -O and above

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384

--- Comment #7 from joseph at codesourcery dot com  ---
Using host libm routines is a bad idea, that would make the generated code 
depend on the host libm and processor.  Having a cut-off to avoid constant 
folding these functions for n >= 128 might make sense (that cut-off is 
chosen as the one beyond which the ISO 24747 versions of the functions, 
and the versions in the standard C++ library, have implementation-defined 
behavior).

[Bug target/103605] [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605

--- Comment #4 from joseph at codesourcery dot com  ---
On Tue, 26 Apr 2022, guihaoc at gcc dot gnu.org via Gcc-bugs wrote:

> C99/11 standard
> If just one argument is a NaN, the fmin functions return the other argument 
> (if
> both arguments are NaNs, the functions return a NaN).
> fmin(NaN, 3.0) = fmin(3.0, NaN) = 3.0

"NaN" here means quiet NaN.

> xsmindp
> The minimum of a QNaN and any value is that value. The minimum of any value 
> and
> an SNaN is that SNaN converted to a QNaN.
> xsmindp(NaN, 3.0) = 3.0 xsmindp(3.0, NaN) = NaN

That seems right for fmin, provided that (QNaN, SNaN) arguments in either 
order produce a QNaN result (with "invalid" raised).  Note that fmin and 
fmax follow the old operations from IEEE 754-2008 (that aren't associative 
in the presence of SNaN), not any of the new operations from IEEE 
754-2019.

[Bug target/105428] compilation never (?) finishes with __builtin_casinl() and __builtin_csqrtl() with -O -mlong-double-128

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105428

--- Comment #1 from joseph at codesourcery dot com  ---
What MPC version are you using?  There have been a few fixes for slowness 
in the MPC inverse trigonometric and hyperbolic functions over the years, 
though there may still be scope for substantial further improvements by 
choosing different algorithms for different ranges of inputs.  If you're 
using current MPC then this case should probably be reported to the MPC 
maintainers.

[Bug target/105428] compilation never (?) finishes with __builtin_casinl() and __builtin_csqrtl() with -O -mlong-double-128

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105428

--- Comment #4 from joseph at codesourcery dot com  ---
If you can identify specific arguments passed to mpc_asin for which it is 
excessively slow, that should be reported as an MPC bug.

Computing correctly rounded mpc_asin shouldn't need to be that slow - 
provided the algorithm used is appropriate to the input value.  See for 
example how glibc implements casin / casinh / cacos / cacosh.  Or 
https://dl.acm.org/doi/10.1145/275323.275324 (Hull et al, Implementing the 
complex arcsine and arccosine functions using exception handling, ACM TOMS 
vol. 23 no. 3 (Sep 1997) pp 299-335).  That may require several different 
algorithms to be implemented, but each such algorithm is straightforward.  
That's different from the case of Bessel functions of high order - for 
which there is some literature about computational techniques that 
shouldn't take time proportional to the order, but where the algorithms 
are certainly a lot more complicated.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574

--- Comment #5 from joseph at codesourcery dot com  ---
It's possible code is being moved across SET_RESTORE_ROUNDL, in which case 
maybe math_opt_barrier needs to be used in glibc code to prevent that 
movement.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574

--- Comment #7 from joseph at codesourcery dot com  ---
I'd suggest looking at the generated assembly.  I don't know exactly what 
you mean by "putting a math_opt_barrier on this line"; it would need to be 
used in a way that ensures a dependency for all the code after 
SET_RESTORE_ROUNDL (for example, "xx = math_opt_barrier (xx);").

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574

--- Comment #11 from joseph at codesourcery dot com  ---
On Wed, 10 Aug 2022, michael.hudson at canonical dot com via Gcc-bugs wrote:

> I just changed
> 
>   z = xx * xx;
> 
> to
> 
>   z = math_opt_barrier(xx * xx);
> 
> which perhaps isn't sufficient.

That wouldn't prevent the multiplication being moved before 
SET_RESTORE_ROUNDL, though it should suffice for the later computations as 
they all depend on z.

> But my reading of the assembly is that the issue is that some of the math code
> is being moved _after_ the restore of the fpu state implied by
> SET_RESTORE_ROUNDL (FE_TONEAREST).

To avoid code being moved after the restore, "math_force_eval (p);" just 
before the return would be appropriate.

[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652

--- Comment #4 from joseph at codesourcery dot com  ---
Regarding mangling: I expect this change should fix bug 85518.

General: I expect some glibc header changes might be appropriate, where 
they currently assume __FloatN keywords aren't supported in C++.  And 
where glibc headers handle type-generic operations for C++ by defining 
appropriate overloaded functions in the headers, make sure the overloads 
for _Float128 work with both _Float128 and __float128 where supported and 
distinct, or otherwise adjust the headers as needed to handle both types.

(Also, so far we don't have _Float16 support in glibc, and while it would 
be a sensible feature in principle, there would be issues to consider with 
the impact on minimum GCC versions for building glibc on relevant 
architectures, unless some kind of hack is used to allow _Float16 
functions to be built and to get the correct ABI even when built with an 
older compiler.  Requiring GCC 7 to build glibc for AArch64 and Arm might 
well be reasonable now; requiring GCC 12 for x86/x86_64 or GCC 13 for 
RISC-V probably not for a few years.)

[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831

--- Comment #12 from joseph at codesourcery dot com  ---
The difference with __ibm128 is that in that case there is no semantic 
significance to whether the low part is +0 or -0, or what the low part is 
at all when the high part is a NaN.  At the C level, such __ibm128 
representations should be considered different representations of the same 
value, not different values.  Whereas different DFP quantum exponents for 
the same real number correspond to different values that compare equal.  
(Noncanonical DFP encodings might be more closely analogous to the 
__ibm128 variants, except that most operations aren't supposed to return a 
noncanonical encoding even if inputs have such an encoding.)

[Bug bootstrap/107059] [13 regression] bootstrap failure after r13-2887-gb04208895fed34

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107059

--- Comment #22 from joseph at codesourcery dot com  ---
Even with the fixincluded headers properly being used, the powerpc64le 
issue still applies because of the issue I noted in 
https://sourceware.org/pipermail/libc-alpha/2022-September/142259.html 
with certain required changes to the powerpc version of bits/floatn.h not 
being covered by the fixincludes fixes added.  You get errors such as:

/scratch/jmyers/glibc-bot/build/compilers/powerpc64le-linux-gnu/gcc/gcc/include-fixed/bits/floatn.h:88:9:
error: multiple types in one declaration
   88 | typedef __float128 _Float128;
  | ^~

while building libstdc++.  (Whereas other architectures can build GCC OK 
but then run into failures building glibc that my glibc patch is intended 
to address.)

[Bug c/107314] [13 Regression] New -Wsign-compare since r13-3360-g3b3083a598ca3f4b

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107314

--- Comment #1 from joseph at codesourcery dot com  ---
This is a deliberate change: if any enumerators are outside the range of 
int, then all enumerators now have the enum type, rather than those 
outside the range of int having the enum type and those inside the range 
of int having type int.  (The logic to determine the integer type with 
which the enum type is compatible is unchanged.  In the case of this 
testcase, it produces unsigned int.)

While, as noted in the commit message, the change could be made 
conditional on C2x mode if necessary, I'm doubtful if that would actually 
help grub; presumably they'd rather change things so they work in C2x mode 
rather than keeping using an older mode after -std=gnu2x is the default, 
or postponing the fix until then.

[Bug c/103810] -fallow-parameterless-variadic-functions flag could use a testcase that covers its documentation better

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103810

--- Comment #1 from joseph at codesourcery dot com  ---
Note also that there is a proposal for C23 (N2854) to allow such 
functions, including changing the requirements on va_start to make it 
possible to read their arguments.

[Bug libfortran/103886] Use 64-bit time_t on 32-bit glibc targets

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886

--- Comment #5 from joseph at codesourcery dot com  ---
On Sat, 1 Jan 2022, jb at gcc dot gnu.org via Gcc-bugs wrote:

> I'm not super-familiar with glibc, but it seems that this changes the default
> (in ./bits/timesize.h) to 64 for targets not overriding it, however it
> adds/modifies a number of target-specific overrides to retain the previous
> behavior?

Exactly.  "Default" here means "default for architectures that don't 
provide their own bits/timesize.h header"; there is no change to the 
default for any existing architecture.  It was already required that new 
glibc ports must use 64-bit time_t; the effect of this change is that new 
glibc ports to 32-bit architectures no longer need to have a 
bits/timesize.h header of their own (in general, we want the defaults to 
be such that new ports need as few sysdeps files as possible).

[Bug c/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103980

--- Comment #2 from joseph at codesourcery dot com  ---
If it's specific to s390, I wonder if it's something to do with excess 
precision being enabled by -std=c89 (see commit 
a5dd6b69fcbe74c02d4821ac2daf2b8c9f819f6e regarding s390 excess precision, 
but even if that means it doesn't appear by default with newer GCC on 
s390, if it's an excess precision issue I'd expect it to appear also with 
x86 -mfpmath=387).

[Bug c/103980] -Wdouble-promotion triggers on s390x when it shouldn't.

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103980

--- Comment #4 from joseph at codesourcery dot com  ---
Possible the way x86 excess precision promotes to long double means this 
is only an issue for s390 excess precision (if it is an excess precision 
issue).

[Bug target/104045] [AArch64] combine related to insn fmaxnm

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045

--- Comment #5 from joseph at codesourcery dot com  ---
Folding the fmax operation should be valid in the absence of 
-fsignaling-nans (fmax (a, +Inf) should return +Inf without raising any 
exceptions, for any x not a signaling NaN).  However, replacing the 
division with the constant +Inf is only valid with -fno-trapping-math 
(though it would be OK by default to use the fact that the result is +Inf 
in optimizing the fmax call, as long as the division itself doesn't get 
removed so the divide-by-zero exception is preserved).

[Bug ipa/104187] Call site specific attribute to control inliner

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187

--- Comment #4 from joseph at codesourcery dot com  ---
Right now, all the C front end does with statement attributes is parses 
them and then passes them to c_warn_unused_attributes; it doesn't have any 
other handling for such attributes.

[Bug c/104205] Signed overflow in case label reports confusing warning with -Wpedantic

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104205

--- Comment #5 from joseph at codesourcery dot com  ---
Printing an expression within the diagnostic message is generally 
problematic, but it might be good to change the caret location to point to 
the expression rather than the keyword "case" (or to a range covering both 
the keyword and the expression).

[Bug libgcc/104253] libgcc missing __floatdiif

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #2 from joseph at codesourcery dot com  ---
I wouldn't expect any *if libgcc function names to be used, because "tf" 
libgcc names are supposed to refer to the ibm128 format and "kf" names are 
supposed to refer to the IEEE binary128 format, regardless of which format 
is actually TFmode inside the compiler.

Probably much the same issue as this bug: building

_Complex double ic __attribute__ ((mode (IC)));
void test_ic (void) { ic /= ic; ic *= ic; }

with -mabi=ieeelongdouble produces spurious __divic3 and __mulic3 
references (should be __divtc3 and __multc3).

[Bug sanitizer/104262] -fsanitize=address false alarm with aligned_alloc

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104262

--- Comment #3 from joseph at codesourcery dot com  ---
See DR#460.  
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_460

[Bug target/103008] poor inlined builtin_fmod on x86_64

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008

--- Comment #11 from joseph at codesourcery dot com  ---
An implementation using division like that definitely isn't valid without 
-funsafe-math-optimizations (it gives nonsense results when the exponent 
difference between the arguments is too large, inaccurate results whenever 
the multiplication is inexact unless you use fma, and spurious exceptions 
for operations that are never supposed to raise "inexact" on any 
arguments).

[Bug target/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103193

--- Comment #1 from joseph at codesourcery dot com  ---
See bug 52451 and bug 91323 for previous cases of unordered comparisons 
being wrongly used on x86.

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

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #10 from joseph at codesourcery dot com  ---
N2775 (hopefully to be considered at the Jan/Feb 2022 WG14 meeting) is the 
proposal for constant suffixes.

[Bug target/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103193

--- Comment #3 from joseph at codesourcery dot com  ---
Converting from >= to == is inappropriate (because >= should raise invalid 
for all NaN operands but == should do so only for signaling NaNs).  If 
that's happening in architecture-independent code, then this is an 
architecture-independent bug.

[Bug middle-end/103193] gcc for x86_64: wrong code generation: ucomiss instead of comiss

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103193

--- Comment #5 from joseph at codesourcery dot com  ---
On Fri, 12 Nov 2021, rguenth at gcc dot gnu.org via Gcc-bugs wrote:

> /* Simplify comparison of something with itself.  For IEEE
>floating-point, we can only do some of these simplifications.  */
> (for cmp (eq ge le)
>  (simplify
>   (cmp @0 @0)
>   (if (! FLOAT_TYPE_P (TREE_TYPE (@0))
>|| ! HONOR_NANS (@0))
>{ constant_boolean_node (true, type); }
>(if (cmp != EQ_EXPR)
> (eq @0 @0)
> 
> does this.  The folding to == happens unconditionally.  As I understand you
> the condition that applies to the constant folding should apply to the
> folding to EQ as well, which means we effectively need to remove the
> canonicalization to EQ (since when it would be valid we can fold to constant
> true)?

It's invalid with -ftrapping-math because it loses an exception.  With 
-fno-trapping-math, but NaNs supported, you can convert to EQ but can't 
fold to constant true.

[Bug c++/103238] c++ Feature: array-copy experimental extensions implementing P1997

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103238

--- Comment #1 from joseph at codesourcery dot com  ---
On Sun, 14 Nov 2021, wjwray at gmail dot com via Gcc-bugs wrote:

> An interesting suggestion is that these array extensions be incorporated into
> C and C++ standards as a DR, applying as they do to the C subset and all -std,
> with DR standing for Dennis Ritchie, great language designer in the sky.

This is a good example of what I said in today's WG14 meeting about C++ 
going overboard about applying changes to previous standard versions.  
Something should only be considered a DR for previous standard versions if 
what was in the previous standard version is unambiguously *wrong* - not 
simply if a new feature seems nice to have or more convenient to use.

[Bug middle-end/103248] [12 Regression] ICE in operation_could_trap_helper_p, at tree-eh.c:2479

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103248

--- Comment #11 from joseph at codesourcery dot com  ---
Division by zero is undefined behavior for fixed-point types the same way 
as it is for integer types (but not floating point, at least when 
infinities and NaN are supported).  Treating it like integer division in 
the compiler would seem reasonable.

[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406

--- Comment #11 from joseph at codesourcery dot com  ---
The sign of a NaN result is never specified in C except for fabs, 
copysign, negation, unary + (and assignment to the same format in the case 
where that's copy rather than convertFormat).

The result should of course be NaN (of any sign), not 0.

The reason soft-fp (and thus sfp-machine.h) has special support for 
choosing a NaN result based on NaN operands is because soft-fp is also 
used in the Linux kernel for emulating floating-point instructions, and in 
that context the aim is to follow the semantics of those instructions, 
which specifies things left unspecified in IEEE 754 and its C bindings.  
That isn't relevant at the level of C code or libgcc functions.

[Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406

--- Comment #14 from joseph at codesourcery dot com  ---
There is no reasonable definition of how operands of binary + map to 
particular operands of a particular instruction and so no -f or -m option 
could sensibly be defined for that.  When the result is a NaN, there is no 
requirement at all on what (quiet) NaN it is (beyond a preference for 
preservation of the payload of a NaN operand if there is at least one NaN 
operand).

[Bug tree-optimization/103491] nextafter does not raise "overflow" and "inexact" floating-point exceptions

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491

--- Comment #3 from joseph at codesourcery dot com  ---
This testcase is incorrect.  This call to nextafter has a finite result, 
so it's correct that no exceptions are raised and so an exit status of 1 
from the provided testcase is what should be expected.

A GCC bug could only be demonstrated if the call were elided for arguments 
for which overflow or underflow occurs (such as (DBL_MAX, INFINITY) or 
(DBL_MIN, 0) or (DBL_TRUE_MIN, 0)).  I haven't tested whether that is the 
case.

[Bug c/102291] [9/10/11/12 Regression] wrong overflow warning for compound expression conversion and bit_and expressions

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291

--- Comment #7 from joseph at codesourcery dot com  ---
I don't think TREE_OVERFLOW should be introduced in folding expressions 
that didn't have undefined behavior in the original source code.

[Bug c/47781] warnings from custom printf format specifiers

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

--- Comment #26 from joseph at codesourcery dot com  ---
It's hard to define something that is sufficiently general to be useful 
but doesn't expose too much of the details of GCC's internal data 
structures for describing standard formats.  %b for binary is now a 
standard C23 format and supported for GCC 12 and later.

[Bug tree-optimization/103683] Redundant !__builtin_isnan not removed with -fno-signaling-nans

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103683

--- Comment #1 from joseph at codesourcery dot com  ---
(x > 1) is expected to raise invalid for a quiet NaN, so the two functions 
are different in the absence of -fno-trapping-math, whether or not 
signaling NaNs are enabled.

((!__builtin_isnan (x)) && x > 1) is equivalent to __builtin_isgreater (x, 
1.0) and could be optimized accordingly for -fno-signaling-nans, however.  
(With signaling NaNs, you have the issue that the first expression doesn't 
raise invalid for a signaling NaN but the second does.)

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #5 from joseph at codesourcery dot com  ---
Exception traps (and thus exact underflow) are outside the scope of ISO C.  
(Some forms of alternate exception handling are described in TS 18661-5, 
which is *not* being integrated into C2x, but none of them are like 
feenableexcept; they involve lexically scoped, not dynamically scoped, 
alternate exception handling.)  Note "This specification does not require 
support for trap handlers that maintain information about the order or 
count of floating-point exceptions.", concerning a different case where 
trap handlers could observe transformations that are not otherwise 
visible.

Maybe we should split -ftrapping-math into the on-by-default flag 
concerned with the raising of exception flags, and an off-by-default flag 
concerned with actual changed-flow-of-control traps.  (That's apart from 
the question of splitting -ftrapping-math into the part concerned with 
local transformations keeping the correct set of exception flags raised by 
expressions whose results are used, and the part (largely not implemented, 
but see Marc Glisse's -ffenv-access patches from August 2020) concerned 
with treating flag raising as an actual side effect and preventing code 
movement or removal that would be valid if flag raising weren't handled as 
a side effect.)

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129

--- Comment #2 from joseph at codesourcery dot com  ---
On Mon, 30 Aug 2021, vincent-gcc at vinc17 dot net via Gcc-bugs wrote:

> In the generated code with -O1 and above, one can see that the multiplication
> is done after g is called, even if -ftrapping-math is used (which is the
> default). This is incorrect as x * 5.0 may trap, terminating the program with 
> a
> floating-point exception, in which case g must not be executed.

It's incorrect as the function g might call fetestexcept and examine the 
floating-point exception flags raised, or feclearexcept to clear them.  
That has nothing to do with trap enablement.  Since trap enablement is 
outside the scope of ISO C, and since various processors implement aspects 
of it differently making it inherently unportable, issues that appear 
without involving enabled traps are best considered without involving such 
traps at all.

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #6 from joseph at codesourcery dot com  ---
Issues relating to traps being enabled are still bugs (unlike e.g. any 
issues with changing x87 rounding precision, which are definitely "don't 
do that" when it invalidates assumptions made by the compiler) - e.g. we 
have tests in the testsuite for exact underflow being handled 
appropriately by soft-fp for __float128 - but correct semantics when traps 
are enabled can't usefully be read from ISO C or any part of TS 18661, 
since trap enablement is out of scope there.

[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126

--- Comment #8 from joseph at codesourcery dot com  ---
I think that documentation should be changed to say it's primarily about 
flags, not traps, with trapping being considered much more of a legacy 
feature rather than something it's normally a good idea to use (although 
the option should generally cover the case of traps as well, while still 
allowing variations in the nonzero number of times an exception is raised 
or the order in which different exceptions are raised).

[Bug c/54192] -fno-trapping-math by default?

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192

--- Comment #8 from joseph at codesourcery dot com  ---
On Tue, 21 Sep 2021, rguenther at suse dot de via Gcc-bugs wrote:

> Yes, as said in other contexts GCC happily _removes_ traps if trapping
> is the only side-effect.  _Unless_ you also have -fnon-call-exceptions
> enabled which is the only way to observe traps.  So we consider
> a trap invoking undefined behavior unless you make them well-defined
> via -fnon-call-exceptions.

That might be relevant to traps in the sense of changing control flow when 
a floating-point exception is signaled.  -fnon-call-exceptions doesn't 
seem very relevant to the -ftrapping-math effects on transformations that 
might affect the set of floating-point exception flags raised by some 
code.  As per my previous comment, -ftrapping-math currently affects (or 
might affect if fully implemented) several different things:

* Disallowing code transformations that cause some code to raise more 
exception flags than it would have before.

* Disallowing code transformations that cause some code to raise fewer 
exception flags than it would have before.

* Ensuring the code generated allows for possible non-local control flow 
from exception traps raised by floating-point operations (this is the part 
where -fnon-call-exceptions might be relevant).

* Disallowing code transformations that might affect whether an exact 
underflow exception occurs in some code (not observable through exception 
flags, is observable through trap handlers).

* Ensuring floating-point operations that might raise exception flags are 
not removed, or moved past code (asms or function calls) that might read 
or modify the exception flag state (not implemented, modulo Marc Glisse's 
-ffenv-access patches from August 2020)

[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464

--- Comment #4 from joseph at codesourcery dot com  ---
Note that for fma this would only be valid for 
-funsafe-math-optimizations.

[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630

--- Comment #2 from joseph at codesourcery dot com  ---
Since we concluded this was a GCC bug, rather than an unavoidable 
limitation of the warning, suppressing it in glibc seems inappropriate.

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934

--- Comment #16 from joseph at codesourcery dot com  ---
I don't think this bug is anything to do with -fsignaling-nans, for the 
same reason as applies to bug 58416 and bug 71460.

The option -fsignaling-nans is only about correctly handling programs 
that, in the abstract machine, interpret the bit pattern of a signaling 
NaN as a floating-point value (i.e. do lvalue-to-rvalue conversion on it 
in the relevant floating-point type).  Thus bug, and those other two, and 
maybe others, involves a different case: a bit pattern of a signaling NaN 
occurs somewhere, but is never converted to an rvalue in the abstract 
machine.

In such cases, the bit pattern should be handled correctly even without 
-fsignaling-nans (and, thus, on x87, it's incorrect to do single-precision 
or double-precision loads on any bit-pattern where an lvalue-to-rvalue 
conversion doesn't occur in the abstract machine, even without 
-fsignaling-nans).

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934

--- Comment #24 from joseph at codesourcery dot com  ---
On Thu, 14 Oct 2021, ubizjak at gmail dot com via Gcc-bugs wrote:

> The situation is hopeless from the beginning. Please consider this testcase:
> 
> --cut here--
> #include 
> #include 
> 
> double
> __attribute__((noinline,noipa))
> foo (double a, double b, char c)
> {
>   return c ? a : b;
> }
> 
> int main ()
> {
>   double a = __builtin_nans ("");
>   double b = 42.0;
> 
>   feclearexcept (FE_INVALID);
>   foo (a, b, 0);

This is a fundamentally different test, because it involves (in the 
abstract machine) lvalue-to-rvalue conversion of a sNaN representation.  
That means that, unlike the present bug, and the two others I referenced, 
(a) it's only valid with -fsignaling-nans, (b) it's at most a 
quality-of-implementation issue because of the rule that assignment to the 
same format may be a convertFormat operation rather a copy operation, and 
(c) the ABI means the exception can't be avoided when an sNaN is returned.  
Effectively, this test is bug 56831, whereas the present bug is more like 
bug 58416 and bug 71460.

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783

--- Comment #6 from joseph at codesourcery dot com  ---
Generically (and if the command-line options are such that floating-point 
control / status bits are to be respected by optimizations), *any* 
function call might access or modify floating-point control and status 
bits, subject to e.g. const functions not being able to access them, pure 
functions not being able to modify them, functions whose body is known 
having properties based on analysis of that body, built-in functions 
having semantics based on what the compiler knows about those functions.  
And then a subset of asms may similarly access or modify them (based on 
inputs / outputs / clobbers, but maybe on some architectures existing 
practice doesn't provide a register name that inputs / outputs / clobbers 
can use to refer to floating-point state).

Then you'd need something like Marc Glisse's -ffenv-access patches (August 
2020) to represent the other side of things, how floating-point operations 
also access / modify such bits.

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783

--- Comment #9 from joseph at codesourcery dot com  ---
On Tue, 19 Oct 2021, segher at gcc dot gnu.org via Gcc-bugs wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
> 
> --- Comment #8 from Segher Boessenkool  ---
> (In reply to jos...@codesourcery.com from comment #6)
> > Generically (and if the command-line options are such that floating-point 
> > control / status bits are to be respected by optimizations), *any* 
> > function call might access or modify floating-point control and status 
> > bits, subject to e.g. const functions not being able to access them, pure 
> > functions not being able to modify them, functions whose body is known 
> > having properties based on analysis of that body, built-in functions 
> > having semantics based on what the compiler knows about those functions.  
> 
> If FENV_ACCESS is OFF most of those things can be ignored as well.  But
> FENV_ACCESS is much too blunt a hammer for most of our uses.

My recent discussions with Roger Sayle 
, 
and bug 54192 as referenced therein, may be helpful for more details of 
how FENV_ACCESS could be split up.  (At present we have -ftrapping-math, 
on by default, and -frounding-math, off by default.  I suspect that if 
-ftrapping-math really restricted optimizations enough to avoid all 
problematic code reordering / removal in the presence of function calls 
possibly reading and writing exception flags, it would actually inhibit 
optimization more than a full implementation of -frounding-math would: a 
full -frounding-math only means that arithmetic *reads* the rounding mode, 
whereas a full -ftrapping-math means that arithmetic *writes* to the 
exception flags.)

[Bug middle-end/102930] equal values appear to be different due to missing correct rounding in libc

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930

--- Comment #4 from joseph at codesourcery dot com  ---
On Mon, 25 Oct 2021, vincent-gcc at vinc17 dot net via Gcc-bugs wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102930
> 
> --- Comment #3 from Vincent Lefèvre  ---
> (In reply to Jakub Jelinek from comment #2)
> > I think there is nothing that can be done about this, and something like
> > this has been there since forever.  While perhaps some double routines in
> > glibc used to be at some point correctly roundded, many others (e.g. float
> > or long double) never were, there is always a chance you get different
> > results from compile time folding vs. runtime evaluation.
> 
> In this case, for its optimizations, GCC shouldn't assume that these results
> are equal.

Indeed.  It's fine that different executions of a call to such a function 
*in the abstract machine* return different values.  But each execution of 
such a call in the abstract machine must return some particular value 
(possibly different for different executions); it's not valid to optimize 
the code in a way that's inconsistent with a single return value for each 
call to the function in the abstract machine.  (Likewise for other cases 
discussed in other bugs such as out-of-range floating-point-to-integer 
conversions.)

[Bug tree-optimization/84407] incorrect constant propagation with -frounding-math

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84407

--- Comment #5 from joseph at codesourcery dot com  ---
On Wed, 27 Oct 2021, rguenth at gcc dot gnu.org via Gcc-bugs wrote:

> Also a question is the behavior on overflow when converting a real to an
> integer (IIRC the behavior here is undefined, but we constant fold to the
> largest/smallest integer here).

We follow Annex F here (so unspecified value rather than undefined - as 
discussed in other bugs, any given execution of the conversion in the 
abstract machine needs to act as if it does return some value of the 
type).

> For integer to float conversions is the overflow considered before or after
> applying the rounding?  That is, are there integer values that invoke
> undefined behavior when converted to a real dependent on the rounding mode?

It's fully defined regardless of the value (the appropriately rounded 
result is returned, which might be an infinity in case of overflow, or the 
largest finite value depending on the rounding mode).

Whether the conversion overflows can indeed depend on the rounding mode 
(overflow occurs when a conversion in that rounding mode, with infinite 
exponent range, would produce a result with an exponent too large to 
represent in the floating-point format).  For the IEEE formats and integer 
types supported by GCC, the only cases where overflow is possible are for 
conversions to _Float16, and from unsigned __int128 to float.

[Bug c/102989] Add Clang's _ExtInt(N)

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #6 from joseph at codesourcery dot com  ---
It's _BitInt in C2X, see N2763 for the final wording.  The operator for 
computing the width of a type, present in earlier drafts, was removed to 
get a minimal version into C2X; I don't know if it will be re-proposed in 
time for C2X (as it's a previously proposed feature, the deadline would be 
the January meeting of WG14; the deadline two weeks ago was for *initial* 
proposal of new features).

Note the importance of agreeing the ABI with the relevant ABI working 
groups!  And that the ABI needs to be clear about whether padding bits 
have defined values (in the in-memory representation, and in argument 
passing and return).  A proposed x86_64 ABI is on a branch of the ABI 
repository (not yet on master).  I'm not aware of proposals for the ABI 
for other architectures.

As a required C2X feature, we'll need some default for the ABI for 
architectures that haven't made another choice (which might closely follow 
what x86_64 does, for example), but we should try to get architecture 
maintainers all to explicitly consider the ABI issue, and to work with ABI 
maintainers / other implementations where applicable to agree what the ABI 
should be on that architecture.  Anyone interested in this feature can 
work with ABI working groups for various architectures *now* to agree on 
what the ABI should be, they don't need to be working on an 
implementation.

(For GCC, we also need an ABI for _Complex _BitInt, unless we disallow 
that, though complex integers are outside the scope of C2X.)

There is a proposal (N2858) for printf/scanf support for _BitInt.  
Implementing that in glibc (or any other C library) will require 
architecture-specific code to read the values of arguments, given that (a) 
we can't call va_arg with a type of run-time-determined size, unless there 
is a pretty small limit on the sizes we support with _BitInt and (b) we 
might want to support that feature in glibc well before it's desirable to 
depend on a GCC with _BitInt support for building glibc.  ABIs like the 
x86_64 one (treating the argument like a standard integer type or a 
struct) should be OK for that purpose, since once the size gets 
sufficiently large (depending on the ABI), a repeated sequence of va_arg 
calls should suffice to read the structure elements (or a va_arg call for 
a pointer type, when passed by reference).

[Bug middle-end/107370] long double sqrtl constant folding is wrong

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107370

--- Comment #8 from joseph at codesourcery dot com  ---
On Mon, 24 Oct 2022, jacob at jacob dot remcomp.fr via Gcc-bugs wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107370
> 
> --- Comment #3 from jacob navia  ---
>   1 trunk gcc:
>   2 .LC1:
>   3.word   325511829  # 0x1366EA95 <<<--- SHOULD BE 325508205
>   4.word   -922176773 # 0xC908B2FB OK
>   5.word   -429395012 # 0xE667F3BC OK
>   6.word   1073703433 # 0x3FFF6A09 OK
> 
> This data is wrong, I repeat, the first number (line 3) should be 325508205 
> or 
> 0x1366DC6D.

Why do you think that number is wrong?  If I compute the square root of 
2**225 using GMP (so not involving MPFR at all, just integer square root 
in GMP), I get 1366ea95 as the low 32 bits (and the next bit is a 0, so 
rounding toward 0 is correct in this case).

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

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #13 from joseph at codesourcery dot com  ---
On Tue, 25 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:

> The x86-64 psABI has been changed for this:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/8ca45392570e96920f8a15d903d6122f6d263cd0
> but the state of the padding bits isn't mentioned there anywhere.

I think the words "The value of the unused bits beyond the width of the 
\texttt{_BitInt(N)} value but within the size of the \texttt{_BitInt(N)} 
are unspecified when stored in memory or register." are what deals with 
padding (both padding within sizeof(_BitInt(N)) bytes, and bytes within a 
register or stack slot used for argument passing / return but outside 
sizeof(_BitInt(N)) bytes).

(Of course different architectures might make different choices for how to 
handle padding.)

I filed https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/300 in 
July to request an ABI for _BitInt on RISC-V.  I've just now filed 
https://github.com/ARM-software/abi-aa/issues/175 to request such an ABI 
for both 32-bit and 64-bit Arm, and 
https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI 
for 32-bit x86.  I don't know if there are other psABIs with public issue 
trackers where such issues can be filed (but we'll need some sensible 
default anyway for architectures where we can't get an ABI properly 
specified in an upstream-maintained ABI document).

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

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #25 from joseph at codesourcery dot com  ---
On Wed, 26 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:

> Seems LLVM currently only supports _BitInt up to 128, which is kind of useless
> for users, those sizes can be easily handled as bitfields and performing 
> normal
> arithmetics on them.

Well, it would be useful for users of 32-bit targets who want 128-bit 
arithmetic, since we only support __int128 for 64-bit targets.

> As for implementation, I'd like to brainstorm about it a little bit.
> I'd say we want a new tree code for it, say BITINT_TYPE.

OK.  The signed and unsigned types of each precision do need to be 
distinguished from all the existing kinds of integer types (including the 
ones used for bit-fields: _BitInt types aren't subject to integer 
promotions, whereas bit-fields narrower than int are).

In general the types operate like integer types (in terms of allowed 
operations etc.) so INTEGRAL_TYPE_P would be true for them.  The main 
difference at front-end level is the lack of integer promotions, so that 
arithmetic can be carried out directly on narrower-than-int operands (but 
a bit-field declared with a _BitInt type gets promoted to that _BitInt 
type, e.g. unsigned _BitInt(7):2 acts as unsigned _BitInt(7) in 
arithmetic).

Unlike the bit-field types, there's no such thing as a signed _BitInt(1); 
signed bit-precise integer types must havet least two bits.

> TYPE_PRECISION unfortunately is only 10-bit, that is not enough, so it 
> would need the full precision to be specified somewhere else.

That may complicate things because of code expecting TYPE_PRECISION to be 
meaningful for all integer types.  But that could be addressed without 
needing to review every use of TYPE_PRECISION by e.g. changing 
TYPE_PRECISION to check wherever the _BitInt precision is specified, and 
instead using e.g. TYPE_RAW_PRECISION for direct access to the tree field 
(so only lvalue uses of TYPE_PRECISION would then need updating, other 
accesses would automatically get the full precision).

> And have targetm specify the ABI
> details (size of a limb (which would need to be exposed to libgcc with
> -fbuilding-libgcc), unless it is everywhere the same whether the limbs are
> least significant to most significant or vice versa, and whether the highest
> limb is sign/zero extended or unspecified beyond the precision.

I haven't seen an ABI specified for any architecture supporting big-endian 
yet, but I'd tend to expect such architectures to use big-endian ordering 
for the _BitInt representation to be consistent with existing integer 
types.

> What about the large ones?

I think we can at least slightly simplify things by assuming for now 
_BitInt multiplication / division / modulo are unlikely to be used much 
for arguments large enough that Karatsuba or asymptotically faster 
algorithms become relevant; that is, that naive quadratic-time algorithms 
are sufficient for those operations.

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

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405

--- Comment #13 from joseph at codesourcery dot com  ---
If the real issue in a particular place in the kernel is that a single 
(anonymous) enum type is being used for lots of different kinds of 
constants, then the appropriate fix in the kernel might be to split up the 
enum, so that large constants of one kind don't affect the types of small 
constants of a different kind.

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

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #31 from joseph at codesourcery dot com  ---
On Fri, 28 Oct 2022, rguenth at gcc dot gnu.org via Gcc-bugs wrote:

> I wouldn't go with a new tree code, given semantics are INTEGER_TYPE it should
> be an INTEGER_TYPE.

Implementation note in that case: bit-precise integer types aren't allowed 
as underlying types for enums, so the code in 
c-parser.cc:c_parser_enum_specifier checking underlying types:

  else if (TREE_CODE (specs->type) != INTEGER_TYPE
   && TREE_CODE (specs->type) != BOOLEAN_TYPE)
{
  error_at (enum_loc, "invalid % underlying type");

would then need to check that the type isn't a bit-precise type.

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

[joseph at codesourcery dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989

--- Comment #32 from joseph at codesourcery dot com  ---
On Fri, 28 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:

> > That said, if C allows us to limit to 128bits then let's do that for now.
> > 32bit targets will still see all the complication when we give that a stab.
> 
> I'm afraid once we define BITINT_MAXWIDTH, it will become part of the ABI, so
> we can't increase it afterwards.

I don't think it's part of the ABI; I think it's always OK to increase 
BITINT_MAXWIDTH, as long as the wider types don't need more alignment than 
the previous choice of max_align_t.

Thus, starting with a 128-bit limit (or indeed a 64-bit limit on 32-bit 
platforms, so that all the types fix within existing modes supported for 
arithmetic), and adding support for wider _BitInt later, would be a 
reasonable thing to do.

(You still have ABI considerations even with such a limit: apart from the 
padding question, on x86_64 the ABI says _BitInt(128) is 64-bit aligned 
but __int128 is 128-bit aligned.)

> Anyway, I'm afraid we probably don't have enough time to implement this
> properly in stage1, so might need to target GCC 14 with it.  Unless somebody
> spends on it
> the remaining 2 weeks full time.

I think https://gcc.gnu.org/pipermail/gcc/2022-October/239704.html is 
still current as a list of C2x language features likely not to make it 
into GCC 13.  (I hope to get auto and constexpr done in the next two 
weeks, and the other C2x language features not on that list are done.)