https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
--- Comment #5 from joseph at codesourcery dot com ---
I think it would be reasonable for glibc to require that audit modules
don't change errno, at least when acting for libc function calls where
glibc guarantees not changing errno. I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112762
--- Comment #5 from joseph at codesourcery dot com ---
The *-uclinux* targets are generally for systems without an MMU and a
corresponding ABI (FLAT, FDPIC, etc.), whereas *-linux-uclibc* targets are
for systems with an MMU and an associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #50 from joseph at codesourcery dot com ---
Qualifiers on function parameter types do not affect type compatibility or
composite type (see 6.7.6.3#14). I think they're only actually of
significance in the definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112614
--- Comment #2 from joseph at codesourcery dot com ---
The sign of a NaN isn't specified for conversions, only for a few
operations such as absolute value, negation, copysign.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112566
--- Comment #4 from joseph at codesourcery dot com ---
On Thu, 16 Nov 2023, jakub at gcc dot gnu.org via Gcc-bugs wrote:
> ctz(ext(x)) == ctz(x) if UB on zero,
In one direction, this should also be true for a narrowing conversion
(chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112556
--- Comment #2 from joseph at codesourcery dot com ---
Yes, this is a bug; null_pointer_constant_p gets this right, but
convert_for_assignment fails to handle enumerations and booleans as
possible null pointer constants. Other contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111811
--- Comment #4 from joseph at codesourcery dot com ---
The checks are in check_bitfield_type_and_width. I expect the attribute -
in this position a declaration attribute - gets applied after that (and
while applying it results in a change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #13 from joseph at codesourcery dot com ---
On Fri, 10 Nov 2023, rguenth at gcc dot gnu.org via Gcc-bugs wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
>
> --- Comment #11 from Richard Biener ---
> (In r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #9 from joseph at codesourcery dot com ---
To quote the C23 DIS, "This annex does not require the full support for
signaling NaNs specified in IEC 60559. This annex uses the term NaN,
unless explicitly qualified, to denote
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #10 from joseph at codesourcery dot com ---
The wording refers to "the size requested", which I consider to be the
product of two arguments in the case of calloc - not a particular argument
to calloc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112364
--- Comment #7 from joseph at codesourcery dot com ---
I believe "size requested" refers to the product nmemb * size in the case
of calloc, so getting the arguments the "wrong" way round does not affect
the required a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112296
--- Comment #12 from joseph at codesourcery dot com ---
I agree that the side effects of an argument to __builtin_constant_p must
be discarded, for the original macro use case to work properly.
There are various constructs with __builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
--- Comment #2 from joseph at codesourcery dot com ---
I'm going to guess this was introduced by the char8_t changes ("C:
Implement C2X N2653 char8_t and UTF-8 string literal changes", commit
703837b2cc8ac03c53ac7cc0fb1327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #9 from joseph at codesourcery dot com ---
A portability issue producing a compile failure is often better than one
where there is no error but the code misbehaves at runtime on some
platforms (a lot of code does not have good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #7 from joseph at codesourcery dot com ---
I think it's reasonable for such a portability issue to be detected only
when building for i386, much like a portability issue from code that
assumes long is 64-bit would only be detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808
--- Comment #5 from joseph at codesourcery dot com ---
We could add a "note: initializer represented with excess precision" or
similar for the case where the required error might be surprising because
the semantic types are the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
--- Comment #8 from joseph at codesourcery dot com ---
Typically these sorts of issues result from floating-point operations
being moved past environment manipulation (fesetround, feupdateenv,
feholdexcept, etc.) - in either direction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
--- Comment #6 from joseph at codesourcery dot com ---
On Mon, 2 Oct 2023, rdapp at gcc dot gnu.org via Gcc-bugs wrote:
> In our case the int64_t -> int32_t conversion is implementation defined when
> the source doesn't fit the tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
--- Comment #4 from joseph at codesourcery dot com ---
Conversion from 64-bit integers for _Float16 is fully defined, it produces
the correctly rounded result according to the current rounding direction
(round-to-nearest may be assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
--- Comment #22 from joseph at codesourcery dot com ---
On Mon, 2 Oct 2023, eggert at cs dot ucla.edu via Gcc-bugs wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
>
> --- Comment #20 from Paul Eggert ---
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421
--- Comment #4 from joseph at codesourcery dot com ---
The definition of constexpr in C2x is intentionally minimal, with
potential for future expansion in subsequent standard revisions.
Allowing array element accesses would run into needing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111421
--- Comment #1 from joseph at codesourcery dot com ---
See the definitions of "named constant" and "compound literal constant".
Array element accesses aren't allowed, and the example you have with "->"
shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111390
--- Comment #7 from joseph at codesourcery dot com ---
Stubbing out execution of tests can be done with a suitable board file (a
board file to stub out linking as well is a bit more complicated).
https://gcc.gnu.org/pipermail/gcc/2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
--- Comment #3 from joseph at codesourcery dot com ---
Defined values for 0 are marginally more convenient for implementing the
standard operations which have defined results for all
arguments, and I think it's appropriate for the type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
--- Comment #1 from joseph at codesourcery dot com ---
Yes, we should have APIs for building type-generic _BitInt interfaces
(also a width-of operation to give the width in bits of an integer type;
also type-generic versions of operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111058
--- Comment #7 from joseph at codesourcery dot com ---
There shouldn't be such a thing as an unsupported constant payload; both
__builtin_nan and __builtin_nans should rather be made consistent with
parsing of payloads by glibc's nan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111058
--- Comment #5 from joseph at codesourcery dot com ---
We should absolutely *not* generate calls to a non-existent function
"nans" based on a long-obsolescent standard proposal. The modern way to
generate a signaling NaN with giv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954
--- Comment #5 from joseph at codesourcery dot com ---
The straw poll at the June meeting said to keep calling it C23 (votes
4/12/2 for/against/abstain on the question of changing the informal name
to C24). Of course the actual standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110664
--- Comment #1 from joseph at codesourcery dot com ---
Yes, this would be a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
--- Comment #6 from joseph at codesourcery dot com ---
The latest version should be taken to be what's in the working draft
N3096, plus the editorial fixes from CD2 comments GB-081 through GB-084.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #7 from joseph at codesourcery dot com ---
I suppose the question is how to interpret "the longest array (with the
same element type) that would not make the structure larger than the
object being accessed". The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #6 from joseph at codesourcery dot com ---
For the standard, dynamically allocated case, you should only need to
allocate enough memory to contain the initial part of the struct and the
array members being accessed - not any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
--- Comment #25 from joseph at codesourcery dot com ---
Older versions of C++ - up to C++20 - would reject such characters (not
allowed in identifiers based on the list of allowed characters in that
standard version) even when not converted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622
--- Comment #31 from joseph at codesourcery dot com ---
It can be an extended integer type in C2x, but then stdint.h would be
required to have int128_t / uint128_t / int_least128_t / uint_least128_t
typedefs, and integer constant suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #37 from joseph at codesourcery dot com ---
If _BitInt constants aren't INTEGER_CST, then all places that expect that
any integer constant expression is folded to an INTEGER_CST will need
updating to handle whatever tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52339
--- Comment #8 from joseph at codesourcery dot com ---
I think it's valid C99, yes: the VLA size should be evaluated exactly
once, when the declaration is passed in the order of execution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412
--- Comment #2 from joseph at codesourcery dot com ---
May be related to bug 107682.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109355
--- Comment #5 from joseph at codesourcery dot com ---
As I mentioned in previous discussions of this idea: any implementation
should *not* involve simply editing the old generated files in place; it
needs to involve keeping an unmodified
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=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 c
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
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 imple
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
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
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
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=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
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 var
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
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=108068
--- Comment #5 from joseph at codesourcery dot com ---
For DFP it's not just zero for which you can't infer an equivalence of
values from an equality comparison; any finite value that can be
represented with more than one quantum exponent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194
--- Comment #3 from joseph at codesourcery dot com ---
If you use typeof instead of __typeof, and -std=c2x, these types are
treated as compatible. I deliberately kept the existing semantics for
__typeof, and for typeof in pre-C2x modes, when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043
--- Comment #3 from joseph at codesourcery dot com ---
Probably the same as bug 107682.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108054
--- Comment #2 from joseph at codesourcery dot com ---
The basic principle is that auto declarations should always be writable in
a form without auto, so they should never result in a type escaping to a
larger scope (but a rule expressed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #17 from joseph at codesourcery dot com ---
The details of not expanding in cases where it matters whether and how
many times something is expanded - such as arguments expanding to have
unbalanced parentheses - may be a non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108001
--- Comment #1 from joseph at codesourcery dot com ---
At least some cases of this are a standard C++ feature - which ones are
still an extension for C++ and so need documenting as such?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #12 from joseph at codesourcery dot com ---
The standard rule about not using extra arguments means that any warnings
would need to avoid even converting those arguments from pp-tokens to
tokens; it's OK for them to contain pp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954
--- Comment #3 from joseph at codesourcery dot com ---
Editorial review before the CD ballot slipped the schedule. Second-round
editorial review after a huge number of changes in the editorial review
slipped the schedule. Getting a final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899
--- Comment #3 from joseph at codesourcery dot com ---
C2x provides type-generic versions of various such operations,
in addition to type-specific versions (but the type-specific versions are
for unsigned char through unsigned long long, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 22 Nov 2022, macro at orcam dot me.uk via Gcc-bugs wrote:
> Well, according to the assertion triggered `typeof (EM_MAX_SLOTS)' will
> yield a data type of a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405
--- Comment #17 from joseph at codesourcery dot com ---
On Sat, 19 Nov 2022, macro at orcam dot me.uk via Gcc-bugs wrote:
> If in older C standard versions such enums are invalid, then I think
> this should be a hard error rather than a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702
--- Comment #2 from joseph at codesourcery dot com ---
(Where "check for any high bits being set" needs appropriate adjustment in
the case of negative values for conversion from signed __int128, e.g. "the
high 64 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702
--- Comment #1 from joseph at codesourcery dot com ---
On Tue, 15 Nov 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:
> _Float16 f9 (__int128 x) { return x; }
> _Float16 f10 (__int128 x) { return x; }
I suppose one of those is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #12 from joseph at codesourcery dot com ---
__builtin_isnan must not raise "invalid" for signaling NaN arguments.
__builtin_isunordered (i.e. UNORDERED / UNORDERED_EXPR; standard macro
isunordered) must rais
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #10 from joseph at codesourcery dot com ---
For scalar isnan see bug 66462. (The claim in bug 66462 comment 19 that
there was ever a working version of that patch ready to go in is
incorrect: November 2016 is older than June 2017.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107571
--- Comment #3 from joseph at codesourcery dot com ---
On Tue, 8 Nov 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:
> And looking at the C wording in n2596.pdf, seems it is different again:
That's a very old version. N3054 is the m
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 s
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.
Implemen
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
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
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/-/
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 ---
>
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
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
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
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
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
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 th
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=106117
--- Comment #7 from joseph at codesourcery dot com ---
FLT_EVAL_METHOD of 0 gives _Float16 excess precision ("evaluate all
operations and constants, whose semantic type comprises a set of values
that is a strict subset of the values of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117
--- Comment #5 from joseph at codesourcery dot com ---
The idea with "16" is to say that's the exact FLT_EVAL_METHOD value
(defined in C23 Annex H) whose semantics should be followed. It would
affect float/double promotion on i3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106117
--- Comment #2 from joseph at codesourcery dot com ---
"none" was something I mentioned as a possible future argument when
originally posting -fexcess-precision
<https://gcc.gnu.org/legacy-ml/gcc-patches/2008-11/msg00105.htm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969
--- Comment #3 from joseph at codesourcery dot com ---
Overlapping elements is simply a consequence of the zero-sized-objects
extension, I don't see anything invalid here to reject (though there might
be undefined behavior at runtime when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #24 from joseph at codesourcery dot com ---
On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> > For long double it's sysdeps/ieee754/soft-fp/s_fmal.c in glibc - some
> > adjustments wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #22 from joseph at codesourcery dot com ---
On Mon, 13 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> > The function should be sqrtf128 (present in glibc 2.26 and later on
> > x86_64, x86, powerpc64l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #20 from joseph at codesourcery dot com ---
On Sat, 11 Jun 2022, already5chosen at yahoo dot com via Gcc-bugs wrote:
> On MSYS2 _Float128 and __float128 appears to be mostly the same thing, mapped
> to the same library ro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
--- Comment #18 from joseph at codesourcery dot com ---
libquadmath is essentially legacy code. People working directly in C
should be using the C23 _Float128 interfaces and *f128 functions, as in
current glibc, rather than libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
--- Comment #9 from joseph at codesourcery dot com ---
N2963 is up for discussion in WG14 tomorrow, but there are still
significant issues with the wording to resolve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105510
--- Comment #4 from joseph at codesourcery dot com ---
We have a documented extension:
As a GNU extension, GCC allows initialization of objects with static
storage
duration by compound literals (which is not possible in ISO C99 because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
--- Comment #8 from joseph at codesourcery dot com ---
I expect you'd also see this issue with build-many-glibcs.py (from glibc)
if you remove the workaround code in that script:
# GCC uses paths such as lib/../lib64, so make sure lib
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
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
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
> bo
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 >=
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
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 typ
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
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=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=104829
--- Comment #12 from joseph at codesourcery dot com ---
I still get the same error (and the same ".machine ppc") with that patch
applied.
1 - 100 of 2017 matches
Mail list logo
