https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #20 from Alejandro Colomar ---
(In reply to Kang-Che Sung from comment #19)
> I personally don't like when there is an "oligopoly" on the compilers (C and
> C++ should have a less centralized ecosystem than Java or Python), but this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #19 from Kang-Che Sung ---
(In reply to Alejandro Colomar from comment #17)
>
> There are less compilers than programs that use it, so there will be less
> points of failure if this is implemented in the compiler instead of in each
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=119170
--- Comment #17 from Alejandro Colomar ---
(In reply to Kang-Che Sung from comment #16)
> (In reply to Alejandro Colomar from comment #13)
> > Not really unimportant. Every time someone writes one of these in a
> > project, you need to make sur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #15 from Kang-Che Sung ---
(In reply to Alejandro Colomar from comment #13)
> >
> > Unimportant differences, I would say.
>
> Not really unimportant. Every time someone writes one of these in a
> project, you need to make sure it'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #16 from Kang-Che Sung ---
(In reply to Alejandro Colomar from comment #13)
> >
> > Unimportant differences, I would say.
>
> Not really unimportant. Every time someone writes one of these in a
> project, you need to make sure it'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #14 from Alejandro Colomar ---
(In reply to Joseph S. Myers from comment #11)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #13 from Alejandro Colomar ---
(In reply to Kang-Che Sung from comment #12)
> As the width of these types can be retrieved via the `sizeof(T) * CHAR_BIT`
> fallback, I said the `_Widthof` operator on these types is not a
> "necessity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #12 from Kang-Che Sung ---
Allow me to clarify some things.
(In reply to Alejandro Colomar from comment #10)>
> > The `_Widthof`
> > operator working with traditional integer types is a plus but not a
> > necessity.
>
> Here's an
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 #10 from Alejandro Colomar ---
(In reply to Kang-Che Sung from comment #9)
> Is there still room to make comments about the proposal?
Yes. This will not be voted for inclusion in the standard until around
2025-09, and the proposal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
Kang-Che Sung changed:
What|Removed |Added
CC||Explorer09 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #8 from Alejandro Colomar ---
(In reply to Joseph S. Myers from comment #7)
> In particular, the subtle issues around semantics for bit-field expression
> operands (see N2958) are definitely something that should be discussed in a
>
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=119170
--- Comment #5 from Alejandro Colomar ---
(In reply to Andrew Pinski from comment #1)
> Suspended until this is approved by the C committee for the names.
On the other hand, my experience with the C Committee is that they aren't the
best place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #4 from Alejandro Colomar ---
(In reply to Andrew Pinski from comment #3)
> No comments from me; but I suspect others will but they are more likely
> address it via WG14 rather than here.
Thanks! I've already requested an N number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #3 from Andrew Pinski ---
(In reply to Alejandro Colomar from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Suspended until this is approved by the C committee for the names.
>
> Any comments on the feature itself?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119170
--- Comment #2 from Alejandro Colomar ---
(In reply to Andrew Pinski from comment #1)
> Suspended until this is approved by the C committee for the names.
Any comments on the feature itself? It would be interesting to present a paper
that has
20 matches
Mail list logo
