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
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
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
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=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=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 t
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 "
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=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
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=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
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 t
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=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 enab
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
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=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=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
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=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
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, ap
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 d
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 archit
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 #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 #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
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 und
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 ---
&g
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
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
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
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
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=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=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 als
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=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 a
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017
--- Comment #2 from joseph at codesourcery dot com ---
If you want to support exceptions and rounding modes for double precision
on processors with hardware support for single-precision only
floating-point arithmetic, I suggest using soft-fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #13 from joseph at codesourcery dot com ---
For -fwrapv, the mathematical values of INT_MIN / -1 and INT_MIN % -1
should be reduced using modulo arithmetic, so both operations are
well-defined, and there is a bug then either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #25 from joseph at codesourcery dot com ---
The option to use to detect this is -fsanitize=float-cast-overflow (note:
I haven't tested if it detects this particular case). As per the manual:
"Unlike other similar options, @o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977
--- Comment #4 from joseph at codesourcery dot com ---
On Wed, 4 Aug 2021, jakub at gcc dot gnu.org via Gcc-bugs wrote:
> plus various changes in the check_nfc function.
> So, the first question is if the C11/N11/C99 etc. stuff shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101682
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 29 Jul 2021, eggert at gnu dot org via Gcc-bugs wrote:
> The grammar at the start of section 6.7 of the current C2x draft (N2596) says
> that attribute specifiers may appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101489
--- Comment #1 from joseph at codesourcery dot com ---
See the "For illustrative purposes, ..." in
<https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html> which explains the
conventions for how function prototypes are gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
--- Comment #8 from joseph at codesourcery dot com ---
I think this is a bug. Negative-size arrays are an unconditional error.
Zero-size arrays should be a pedwarn-if-pedantic, regardless of whether
the 0 is explicit or deduced from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101290
--- Comment #2 from joseph at codesourcery dot com ---
Anything constructing a constant-size type half the address space or
larger in size should be diagnosed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101265
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 30 Jun 2021, gcc at alanwu dot email via Gcc-bugs wrote:
> > [[attr1]] int [[attr2]] a[10] [[attr3]], b [[attr4]];
> > attr1 appertains to the variable declarat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101265
--- Comment #1 from joseph at codesourcery dot com ---
On Tue, 29 Jun 2021, gcc at alanwu dot email via Gcc-bugs wrote:
> [[maybe_unused]] int thisworks[1];
That attribute appertains to the declared entity.
> int thisdo
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=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=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
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-incomp
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 i
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
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
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=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 raise
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=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 hand
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 fun
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
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 ---
&g
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
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
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=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=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
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 == !=
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
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
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=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 #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
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 differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088
--- Comment #1 from joseph at codesourcery dot com ---
On Thu, 17 Sep 2020, clyon at gcc dot gnu.org wrote:
> This happens because the testcase does
> #define x (
> and "x" is used as parameter names in several function pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #25 from joseph at codesourcery dot com ---
On Mon, 14 Sep 2020, anlauf at gcc dot gnu.org wrote:
> Remember that Fortran needs a correspondence between a storage representation
> (in bytes / bits) and the kind type on the la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #22 from joseph at codesourcery dot com ---
On Fri, 11 Sep 2020, segher at gcc dot gnu.org wrote:
> > #ifndef RS6000_MODES_H
> > #define RS6000_MODES_H 1
> > #define FLOAT_PRECISION_IFmod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96788
--- Comment #5 from joseph at codesourcery dot com ---
The way GCC actually behaves is that this constant is unsigned in the
preprocessor but signed outside the preprocessor. I'm not sure that's
exactly intent (though the preprocessor having
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #4 from joseph at codesourcery dot com ---
IEEE 754 does not specify the choice of output NaN. None of the C
bindings to IEEE 754 specify the choice of output NaN. There are various
architecture differences in choice of output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96760
--- Comment #4 from joseph at codesourcery dot com ---
The increment is addition of 1 in type int (after integer promotions),
followed by conversion back to char. Converting an out-of-range integer
value to a narrower signed integer type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96526
--- Comment #1 from joseph at codesourcery dot com ---
You could define __builtin_totalorder functions, but watch out for the
change made to totalorder functions following a TS 18661-1 clarification
request, from floating-point argument types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #10 from joseph at codesourcery dot com ---
On Thu, 30 Jul 2020, rsandifo at gcc dot gnu.org wrote:
> IMO process_init_element shouldn't recurse into vector types
> if the initialisation value is also a vector type. We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96371
--- Comment #2 from joseph at codesourcery dot com ---
The target hook float_exceptions_rounding_supported_p can be used to
determine whether support for exceptions and rounding modes is available.
For any architectures with hardware floating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96371
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 29 Jul 2020, vries at gcc dot gnu.org wrote:
> Anyway, in absence of all this, without fenv.h support there's no way to set
> the rounding mode, meaning that we can assume d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96253
--- Comment #1 from joseph at codesourcery dot com ---
DFP is not supported for either AArch32 or AArch64; nor do the respective
ABI documents say what the ABI would be for it (though a GCC patch for the
AArch64 case was submitted in
<ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96173
--- Comment #5 from joseph at codesourcery dot com ---
I expect there's a speed/space trade-off here. You can use large tables
for the conversions with less computation, or small tables with more
computation (and the BID implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95763
--- Comment #3 from joseph at codesourcery dot com ---
FWIW, the Ada front end has some style checking support (I once broke
bootstrap by applying spelling corrections there, where fixing the
spelling in a comment made a line too long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95748
--- Comment #4 from joseph at codesourcery dot com ---
Note that __alignof__ is preferred alignment, whereas C11 _Alignof (which
only applies to types, not declarations) is the alignment required in all
contexts (so they differ for long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95722
--- Comment #3 from joseph at codesourcery dot com ---
See bugs 70490 and 84563 regarding atomic_load of const.
The atomic_load generic function takes a pointer-to-const-atomic argument
just like any other library function that takes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95697
--- Comment #2 from joseph at codesourcery dot com ---
See bug 60540, of which this is probably a duplicate, noting the issue
with losing "inexact" exceptions (and "overflow" for some types) and the
reference to bug 57371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #16 from joseph at codesourcery dot com ---
On Wed, 3 Jun 2020, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
>
> --- Comment #15 from Andrew Pinski ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
--- Comment #3 from joseph at codesourcery dot com ---
This is of course only valid because signed overflow is undefined; it
wouldn't be a valid optimization with -fwrapv (unless x were narrower than
int so no overflow could occur).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95423
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 29 May 2020, pinskia at gcc dot gnu.org wrote:
> Could there be overflows which don't happen originally?
Yes. Say a == INT_MIN, x == -1, b == 0, for exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95279
--- Comment #14 from joseph at codesourcery dot com ---
I think it's invalid to refer to element (size_t)-1 of an array; that the
actual integer value used has to be within the range of available array
elements.
It's entirely possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95139
--- Comment #1 from joseph at codesourcery dot com ---
Code using the GCC diagnostic functions should use %wd instead of
HOST_WIDE_INT_PRINT, both for translation and because HOST_WIDE_INT_PRINT
is a format for the host printf and may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #1 from joseph at codesourcery dot com ---
See bug 92292. The extra attribute isn't ignored, it simply means the
function has multiple format attributes, which is valid, but should
probably be special-cased for this case of built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94990
--- Comment #1 from joseph at codesourcery dot com ---
Note that ISO C references ISO 10646, not Unicode, so normalization forms
are not part of the C notion of identifier characters and differently
normalized forms are different identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--- Comment #44 from joseph at codesourcery dot com ---
This commit also introduces bug 94963 which breaks the glibc build (and is
*not* fixed by the commit that fixed bug 94949).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94842
--- Comment #3 from joseph at codesourcery dot com ---
Side-effects in the array sizes of variably modified parameters are valid
and occur on entry to the function. I don't think being a nested function
should make any difference
101 - 200 of 2017 matches
Mail list logo
