https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117025
Joseph S. Myers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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=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=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=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=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=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=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=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=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=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 #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=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=67771
--- Comment #5 from Joseph S. Myers ---
Various glibc functions work around this using FIX_INT_FP_CONVERT_ZERO, I
suppose the new log10f implementation taken from CORE-MATH needs such a
workaround as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #5 from Joseph S. Myers ---
What do you mean by "doesn't work"? Please state both what you expect (based on
C23 with bug fixes that postdate the integration of the original proposal) and
what you see. As per CD1 comments GB-032 and F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
--- Comment #27 from Joseph S. Myers ---
That's not redundant, the previous calculation is in FE_TOWARDZERO mode, before
the call to libc_feupdateenv_test. But maybe that call needs to be followed by
"a1 = math_opt_barrier (a1);" or similar to e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
--- Comment #24 from Joseph S. Myers ---
See my previous comment about possible code movement / need for more usage of
math_opt_barrier. Maybe the a1 + u.d computation got moved before the rounding
mode was restored, or something like that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
--- Comment #23 from Joseph S. Myers ---
hppa is an after-rounding architecture and this test is only meant to produce
underflow on before-rounding architectures. You should investigate why the code
in question is entered at all. I'd have expect
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=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=118280
--- Comment #6 from Joseph S. Myers ---
Are you *actually using the code built by recent GCC versions on Microblaze
hardware running the Linux kernel* (as opposed to simply building software for
lots of different targets that GCC claims to suppo
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=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=118106
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
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=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=107980
--- Comment #20 from Joseph S. Myers ---
I think it's fine for such QoI diagnostics to happen during compilation.
Note that there is no requirement for [] or {} to be balanced in the additional
arguments, only ().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117162
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #18 from Joseph S. Myers ---
The final normative wording in C23 says "If any additional arguments expand to
include unbalanced parentheses, or a preprocessing token that does not convert
to a token, the
behavior is undefined." (and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100792
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100501
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Summary|[12/13/14/15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117752
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100501
Joseph S. Myers changed:
What|Removed |Added
CC||xieym3 at zohomail dot com
--- Commen
|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org
--- Comment #12 from Joseph S. Myers ---
Testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117757
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91193
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117750
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91193
Joseph S. Myers changed:
What|Removed |Added
CC||xieym3 at zohomail dot com
--- Comment
|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org
--- Comment #6 from Joseph S. Myers ---
Testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117781
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117755
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100624
Bug 100624 depends on bug 98195, which changed state.
Bug 98195 Summary: ICE after `void value not ignored as it ought to be` error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98195
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98195
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|--- |15.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117755
Joseph S. Myers changed:
What|Removed |Added
CC||141242068 at smail dot
nju.edu.cn
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111921
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98195
Joseph S. Myers changed:
What|Removed |Added
CC||141242068 at smail dot
nju.edu.cn
---
|1
Last reconfirmed||2024-11-25
Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org
--- Comment #1 from Joseph S. Myers ---
Testing a patch. (This is *not* the same as bug 98195, though both involve
invalid atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110737
Joseph S. Myers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98195
Joseph S. Myers changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112841
--- Comment #6 from Joseph S. Myers ---
Please file a new bug for this.
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=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=114816
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114266
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115515
Joseph S. Myers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117139
Joseph S. Myers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115515
Joseph S. Myers changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115515
Joseph S. Myers changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jsm28 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114869
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Summary|[13/14/15 Reg
Assignee|mpolacek at gcc dot gnu.org|jsm28 at gcc dot gnu.org
--- Comment #2 from Joseph S. Myers ---
Testing a fix. This is an rejects-valid regression in GCC 13 and later, not
specific to C23 mode; a valid program "int nullptr_t;" is wrongly rejected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059
--- Comment #11 from Joseph S. Myers ---
This does not currently warn about zero of enum, bool or _BitInt type except in
contexts where integer promotions result in bool being promoted to int before
the diagnostic applies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112556
--- Comment #7 from Joseph S. Myers ---
I don't object to a backport if someone wishes to backport it. (Technically
this is a regression between GCC 10 where false in had type int and
GCC 11 where it had type _Bool in C2X mode, so resulting in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112556
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117164
Joseph S. Myers changed:
What|Removed |Added
Known to work||15.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117164
--- Comment #5 from Joseph S. Myers ---
Slightly simplified test (note that only one nested function is needed, and
none of the calls to it actually use the return value - but all three calls are
needed to get the ICE). The special options from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117059
--- Comment #7 from Joseph S. Myers ---
How about the gnulib manywarnings module for a few years first, which would
cover various gnulib-using projects that like a high level of warnings, and
then consider -Wextra?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117020
--- Comment #4 from Joseph S. Myers ---
Yes, it's about the exec-charset / wide-exec-charset.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117289
--- Comment #3 from Joseph S. Myers ---
If deduplication is mainly meant to happen at link time, should we then add
-std=gnu17 to this test and leave this issue for a potential future
optimization of the CTF output in a single object in -std=gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117289
Joseph S. Myers changed:
What|Removed |Added
CC||david.faust at oracle dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117021
--- Comment #3 from Joseph S. Myers ---
That paragraph is there. As a Constraint, it needs a pedwarn or hard error (for
both the sign and overflow cases). The claim in the paper that it's already a
hard error in GCC is incorrect.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: uecker at gcc dot gnu.org
Target Milestone: ---
If the test gcc.dg/debug/ctf/ctf-function-pointers-2.c is built with -std=gnu23
(or a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117235
--- Comment #5 from Joseph S. Myers ---
I agree that we should consider -ftrapping-math to be misnamed and to be about
exception flags, not anything that would involve preserving the order in which
exceptions are raised (between function calls o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117197
--- Comment #4 from Joseph S. Myers ---
On the whole I'd expect vector initializers to work like structure ones: that a
vector can be initialized either with another vector of the same type, or with
brace-enclosed scalars, and that inside a brac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117183
Joseph S. Myers changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117162
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2024-10-16
Status|UNCONFI
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: uecker at gcc dot gnu.org
Target Milestone: ---
If I build gcc.dg/nested-func-12.c with -std=gnu23 (in addition to the other
options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117028
--- Comment #5 from Joseph S. Myers ---
Obsolescence is generally unhelpful when there is no non-obsolescent
alternative in previous standard versions, given that much code needs to work
with a range of implementation and standard versions; octa
-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Target: i?86-*-*
Created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117019
--- Comment #1 from Joseph S. Myers ---
Note that a switch declaration can have VM type without violating the rule
about switch not being allowed to jump over a declaration with VM type (the
previous rule was that the entire switch statement had
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
--- Comment #1 from Joseph S. Myers ---
Note that what was accepted omitted the [[unsequenced]] attributes (with a view
to having them added back in a later, separate paper), but that's probably not
relevant for the built-in functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117028
--- Comment #1 from Joseph S. Myers ---
My strong inclination is *not* to add any obsolescence diagnostics, just
support the new features (which should already be present for C++) for C23.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117024
--- Comment #1 from Joseph S. Myers ---
For GCC, this means built-in functions (this is also a library feature).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114816
--- Comment #2 from Joseph S. Myers ---
N3344 alternative 1 was accepted for C2Y. So we should make all these
questionable cases hard errors (no need for conditionals on standard version
since they were previously implicitly undefined behavior).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117027
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117026
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
--- Comment #1 from Joseph S. Myers ---
It's not clear what "implement" means here. See the thread
https://inbox.sourceware.org/gcc/375c5f62-dad4-4247-958c-57b230ae6...@oracle.com/T/#t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117020
--- Comment #2 from Joseph S. Myers ---
There is very little language content in this paper (only some predefined
macros).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #8 from Joseph S. Myers ---
Note that there are various places where translation happens without the
diagnostic machinery ever seeing an untranslated message. A representative
example is cp/typeck.cc:cp_build_unary_op, where message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46073
--- Comment #5 from Joseph S. Myers ---
It's doubtful that this is a bug. You could define __builtin_choose_expr so the
unselected operand only needs to be a balanced token sequence (with no commas
unless nested inside () [] {}), but it's less cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116631
--- Comment #2 from Joseph S. Myers ---
The specification for underspecified declarations (auto and constexpr) says "if
anywhere within the sequence of tokens making up the declaration identifiers
that are not ordinary are declared, the behavior
1 - 100 of 725 matches
Mail list logo
