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:/
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 wo
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 see
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
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 loa
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.
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).
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
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 no
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* co
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 ab
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_*.
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.)
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
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
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 Jaku
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 in
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 declarato
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_SP
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
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 excepti
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
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 val
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 ar
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.
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.
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
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 checki
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
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 p
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.
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
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 co
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 spec
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
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
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, n
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).
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 t
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, de
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/sc
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.
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.
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
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
caus
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 obtaine
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 de
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 m
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 a
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 subs
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
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.
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
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 i
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 suppor
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 th
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/14225
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 a
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.
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
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 precis
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).
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, r
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.
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" (
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
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
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
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.
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.
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-independe
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 simplifica
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 t
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
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).
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 th
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
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.
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 fo
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_isna
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 C2
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 -
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 mad
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
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
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.
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.
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 prog
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
>
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-p
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.
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 Jak
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,
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 kno
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
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/8ca45392570e96920f8a15d9
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 ha
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
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 n
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 com
1 - 100 of 175 matches
Mail list logo
