https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117981
--- Comment #2 from Joseph S. Myers ---
The use of standard versions in the option names is deliberate. An option to
warn about any version incompatibilities would become like -Wtraditional, less
and less useful over time. If your code is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118106
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118112
--- Comment #9 from Joseph S. Myers ---
We do in fact track when () was interpreted as (void) for use by -Wtraditional,
but only in the c_arg_info, it doesn't get as far as the actual declarations
and types. If using this information in a way th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370
Joseph S. Myers changed:
What|Removed |Added
CC||aurelien at aurel32 dot net,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118016
--- Comment #3 from Joseph S. Myers ---
For C, see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1361.htm and the
minutes https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1380.pdf where it was
accepted (thus reverting an abortive attempt to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117727
--- Comment #8 from Joseph S. Myers ---
As nullptr_t is in C23, arguably psABIs ought to define the representation of
nullptr_t as part of defining the C ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112841
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|--- |15.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114816
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877
--- Comment #6 from Joseph S. Myers ---
I believe the test is valid: an unspecified (non-wobbly) value is stored, so,
for each call to frexp executed in the abstract machine, there must be a value
of type int (that compares equal to itself, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118592
--- Comment #2 from Joseph S. Myers ---
Actually, the _FloatN / _FloatNx functions are only reserved if the user
defines __STDC_WANT_IEC_60559_TYPES_EXT__ so maybe
DEF_EXT_LIB_FLOATN_NX_BUILTINS is right for them.
Excluding built-in functions w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118592
--- Comment #1 from Joseph S. Myers ---
That's just a small subset of the ones coming to C23 via TS 18661-4. There are
also all the functions (added to glibc some years ago) that came via TS 18661-1
(we have roundeven, but not most of the rest).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814
--- Comment #8 from Joseph S. Myers ---
See https://sourceware.org/legacy-ml/libc-alpha/2018-02/msg00440.html and
https://sourceware.org/bugzilla/show_bug.cgi?id=30973 regarding glibc fixes
that should preferably be done in sync with a GCC fix f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #14 from Joseph S. Myers ---
I think an object declared with a structure type with only const fields and no
padding can be considered const (no valid way to modify it), yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #11 from Joseph S. Myers ---
A struct with a const field is not a modifiable lvalue in C, so it's not valid
to assign to it. Modifying a const field with memcpy / byte accesses would
probably also violate "If an attempt is made to mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119684
--- Comment #21 from Joseph S. Myers ---
If we want such checking, it should be done in CI (similar to the CI that
verifies generated files that are checked in have been correctly regenerated),
not at .pot regeneration time or .po commit time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120059
Joseph S. Myers changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119855
--- Comment #9 from Joseph S. Myers ---
I don't think a glibc bug "assert should not allow C++ scoped enums" has
anything to do with the issue of making assert a variadic macro to allow an
argument with a comma in it. As far as I know that C23 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224
--- Comment #39 from Joseph S. Myers ---
Spelling is a sequence of characters - and a spelling where those characters
include \ and u is different from a spelling where a multibyte source character
appears directly, and also different from a spel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #6 from Joseph S. Myers ---
I don't think we should add this prematurely. We can wait for the specification
to mature in WG14, and I think it's a bad idea to split the discussion between
multiple places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #7 from Joseph S. Myers ---
In particular, the subtle issues around semantics for bit-field expression
operands (see N2958) are definitely something that should be discussed in a
single place (i.e. the standard committee) rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #11 from Joseph S. Myers ---
The ISO Code of Ethics and Conduct includes "We abide by the policies of ISO
and embrace the concepts of compromise and consensus building, and notably in
the development of ISO standards and other delive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #2 from Joseph S. Myers ---
If ABI support for _Float128 is added on an architecture that doesn't currently
have it, we can also add such support on that architecture in glibc - but that
will increase the minimum GCC version for buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
--- Comment #6 from Joseph S. Myers ---
If P3140 gets into standard C++ that will provide a more substantial reason for
extending ABIs / back-end / library support to handle 128-bit integers across
all targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #18 from Joseph S. Myers ---
bool is a keyword whose spelling inside # and ## is unspecified, and _Bool is
an alternative spelling for that keyword. It's permitted for implementations to
use a predefined macro, but that's not what GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97986
--- Comment #10 from Joseph S. Myers ---
I think my previous comment still applies: when an array type is passed to
va_arg, evaluate side effects of the arguments, warn and (except for non-VLAs
in C90 mode) generate a call to __builtin_trap that'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118991
--- Comment #3 from Joseph S. Myers ---
This sort of concatenation is not expected to work with gettext; except I think
for limited cases for standard PRI* etc. macros, translations are always for
literal strings, not ones concatenated with host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119624
--- Comment #3 from Joseph S. Myers ---
This raises a question of whether the interpretation of the type of the
controlling expression "as if it had undergone an lvalue conversion" (per the
resolution of issue 0481) also engages the (translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119624
--- Comment #6 from Joseph S. Myers ---
Please see the recent "discarded" papers, which attempt to establish a notion
of "discarded relative" which is what's actually wanted (for e.g. establishing
whether something is a constant expression).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112761
--- Comment #5 from Joseph S. Myers ---
The basic principle here was established in C90 DR#047: "there is nothing to
suggest that a not-strictly-conforming array type can magically be transformed
into a strictly conforming pointer parameter via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120304
--- Comment #5 from Joseph S. Myers ---
I agree that it's best not to support legacy __float128 for new architectures;
if there are any remaining issues with libgcobol using long double / _Float128,
those should be fixed instead.
float128-mul-u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381
--- Comment #2 from Joseph S. Myers ---
Nesting one definition of struct A inside another is never valid (and the
godbolt link shows the expected "nested redefinition" error that the PR doesn't
quote).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120326
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2025-05-19
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117025
Joseph S. Myers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
201 - 233 of 233 matches
Mail list logo
