[Bug c/65455] typeof _Atomic fails

[Bug c/65455] typeof _Atomic fails

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
By design, typeof removes qualifiers in certain cases.  Currently it only 
removes them from atomic types (as needed for use in <stdatomic.h>), but 
arguably it should do so more generally - this would be useful for certain 
macros when passed const arguments, and would reflect that qualifiers on 
rvalues are not meaningful in C standard terms (so rvalues should always 
be considered to have unqualified type) but GCC's internal representation 
may or may not have them.

      /* For use in macros such as those in <stdatomic.h>, remove all
         qualifiers from atomic types.  (const can be an issue for more macros
         using typeof than just the <stdatomic.h> ones.)  */

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #2 from Jens Gustedt <jens.gustedt at inria dot fr> ---
Since typeof is a gcc extension, there is not much arguing about it, but this
sounds wrong to me. Use cases I have, and that I seen used by others are for
example something like

_Atomic int a;
__typeof__(a) b __attribute__((weak,alias("a")));

This would systematically fail with that approach. When _Atomic will go into
wider use these difficulties will pop up more often.

Eliminating qualifiers in expressions is easy for arithmetic types at least,
something like

__typeof__((a)+0) b;

should always do the trick. In P99 I have implemented an equivalent to
stdatomic.h that seems to work well without assuming a drop of qualifiers.

(and BTW, the current version of stdatomic.h uses __auto_type, which makes it
incompatible with clang.)

[Bug c/65455] typeof _Atomic fails

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 17 Mar 2015, jens.gustedt at inria dot fr wrote:

> Eliminating qualifiers in expressions is easy for arithmetic types at least,
> something like
> 
> __typeof__((a)+0) b;

No, that would not work for the uses in stdatomic.h.  The temporary must 
have the unqualified, non-atomic type when a is, for example, _Atomic 
char; there can't be any promotions as otherwise the type would be wrong 
when the address of the temporary is taken.

> (and BTW, the current version of stdatomic.h uses __auto_type, which makes it
> incompatible with clang.)

Well, GCC's stdatomic.h only ever needs to be compatible with the same 
version of GCC it ships with.  __auto_type is to avoid duplicate 
evaluations of side-effects in operands with variably modified types (a 
variably modified argument to typeof is evaluated, unlike a non-VM 
argument); see gcc.dg/atomic/stdatomic-vm.c.

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #4 from Jens Gustedt <jens.gustedt at inria dot fr> ---
This is a surprising policy change that occurs a random point in time, namely
where _Atomic is introduced to the C language and in addition does that in a
very unituitive way. Why drop _Atomic, why keep the others.

Also it doesn't look very consistent to me: on one hand you claim that it is
necessary for the implementation of stdatomic.h, but that now uses __auto_type.
For __auto_type the drop of qualifiers comes quite naturally since the RHS is
evaluated anyhow.

So basically the drop of _Atomic qualifiers by __typeof__ is a historic
artefact that maybe has been needed in a short period of time for one internal
use case in  libatomic.

Please consider changing this to a more comprehensive behavior.

[Bug c/65455] typeof _Atomic fails

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
stdatomic.h uses both __auto_type and __typeof__.  In the cases where 
__typeof__ is used, (a) const and _Atomic (and maybe volatile) must be 
removed and (b) __auto_type would not be correct (the type in question is 
not the type of the initializer, and if the types are different then the 
conversions from the type of the initializer to the type given with 
__typeof__ are required).

The dropping of qualifiers only when _Atomic was present was the 
conservative minimal change that could not affect any existing code using 
typeof.  It may well be that __typeof__ should always treat its argument 
as being an rvalue and so as having no qualifiers, but it wasn't necessary 
to resolve that issue at that time.

__auto_type and __typeof__ should be consistent with each other to avoid 
making the language even more confusing.

[Bug c/65455] typeof _Atomic fails

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
(_Generic does make sure to treat its controlling expression as an rvalue, 
removing qualifiers including _Atomic as well as ensuring GCC's internal 
representation of _Noreturn as a qualifier does not affect the type 
resulting for expressions such as &abort.)

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #7 from Jens Gustedt <jens.gustedt at inria dot fr> ---
This bugzilla really sucks. There is my second comment that I place here gone
to the void. Obviously you did see it, since you replied to my mention of
_Generic, but now its gone.

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #8 from Jens Gustedt <jens.gustedt at inria dot fr> ---
(Perhaps gcc interprets _Generic as you say, but even the standard committee
doesn't agree on that interpretation, and other compiler implementors don't
agree either. Nothing in the standard says that it is an rvalue, nor that it
has to undergo any conversion. Conversion for non-evaluated expressions simply
doesn't exist in the standard. The standard explicitly asks for compatible type
of the expression itself, it says nothing about unqualified type.)

[Bug c/65455] typeof _Atomic fails

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote:

> This bugzilla really sucks. There is my second comment that I place here gone
> to the void. Obviously you did see it, since you replied to my mention of
> _Generic, but now its gone.

I did not reply to a mention of _Generic; I described the handling of 
_Generic as a follow-up to my discussion of __typeof__ and __auto_type, as 
something it would be natural to make __typeof__ and __auto_type 
consistent with.

[Bug c/65455] typeof _Atomic fails

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote:

> (Perhaps gcc interprets _Generic as you say, but even the standard committee
> doesn't agree on that interpretation, and other compiler implementors don't
> agree either. Nothing in the standard says that it is an rvalue, nor that it
> has to undergo any conversion. Conversion for non-evaluated expressions simply
> doesn't exist in the standard. The standard explicitly asks for compatible type
> of the expression itself, it says nothing about unqualified type.)

There isn't yet a conclusion to DR#423, but the committee discussion in 
N1892 says 'Specifically, the controlling expression of a generic 
selection "was very carefully not added" to the list of cases where lvalue 
conversion is not done.' (i.e. that conversion happens to all expressions 
unless excluded from happening).  There is no indication of a committee 
direction contradicting the approach I chose for GCC (even if the 
committee isn't quite sure of how to handle atomics there, and has 
suggested making qualifiers on function return types not part of the 
type).

[Bug c/65455] typeof _Atomic fails

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
What does clang differently wrt _Generic?

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #13 from Jens Gustedt <jens.gustedt at inria dot fr> ---
(In reply to Marek Polacek from comment #12)
> What does clang differently wrt _Generic?

Arrays. I don't recall which way around, but one of gcc and clang converts
array types to pointers and the other not. Something like

_Generic("bla", ...)

has different outcome according to the compiler.

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #14 from Jens Gustedt <jens.gustedt at inria dot fr> ---
Perhaps we should end the discussion here, this goes too far for a bug report,
and we should push for a solution of this type of questions by the C committee.

Perhaps you could leave this "bug" open, even if you don't agree that it is a
bug in gcc itself. It certainly is an "issue" that users of that feature in gcc
should be aware of.

I think that this should be resolved in one way or another, best by having a
clear policy in the C standard itself what to do in such situations.

[Bug c/65455] typeof _Atomic fails

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Usually such bugs are SUSPENDED with reference to the DR and when the DR is
resolved, the bug is resolved accordingly.

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #16 from Jens Gustedt <jens.gustedt at inria dot fr> ---
(In reply to Jakub Jelinek from comment #15)
> Usually such bugs are SUSPENDED with reference to the DR and when the DR is
> resolved, the bug is resolved accordingly.

Here the situation is a bit more complicated, since __typeof__ is an extension
to C, so no DR will directly say something about this.

Do you want me to open a new bug for the observation that _Generic leads to
compiler specific results?

[Bug c/65455] typeof _Atomic fails

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #17 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Jens Gustedt from comment #16)
> Here the situation is a bit more complicated, since __typeof__ is an
> extension to C, so no DR will directly say something about this.

I can look into this, but I think it's a GCC 6 material.

> Do you want me to open a new bug for the observation that _Generic leads to
> compiler specific results?

Please do.  I think we should have a bug specifically to address DR#423.

[Bug c/65455] typeof _Atomic fails

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #18 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
So this looks like a dup of PR39985.  It seems that, if anything, we should
modify __typeof to drop all qualifiers.  I.e. that all of the following
__typeofs yield "int":

const int a;
volatile int b;
const volatile c;
_Atomic int d;
int *restrict e;
__typeof (a) x;
__typeof (b) y;
__typeof (c) q;
__typeof (d) r;
__typeof (const int) z;
__typeof (volatile const int) w;
__typeof (volatile int) v;
__typeof (_Atomic volatile int) t;
__typeof (*e) *s;

Or is that not so?

What should we do for C++?

[Bug c/65455] typeof _Atomic fails

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #19 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Thu, 13 Aug 2015, mpolacek at gcc dot gnu.org wrote:

> So this looks like a dup of PR39985.  It seems that, if anything, we should
> modify __typeof to drop all qualifiers.  I.e. that all of the following
> __typeofs yield "int":

Yes, I think so as a matter of language design, but there is a risk to 
existing code (that declares aliases, for example) and there may be a use 
for a new typeof variant that always returns the declared type when passed 
an lvalue.

Minimally and probably more safely, __typeof should drop all qualifiers on 
rvalues (including those returned by functions returning qualified type, 
or resulting from cast to qualified type; note that the proposed 
resolution to DR#423 would require changes to remove the qualifiers from 
function return types so that "const int foo(int);" and "int foo(int);" 
are compatible declarations, which would probably be safest if only done 
for C11 and above).

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #20 from Jens Gustedt <jens.gustedt at inria dot fr> ---
I would be much happier with a generic operator that makes any object into an
rvalue. One way that comes close would be `1 ? (X) : (X)`. This is an
expression that transforms any expression `X` that is not a narrow integer type
into an rvalue. 

Unfortunately it is too ugly that anybody ever will systematically write
`__typeof__(1?(X):(X))`. But a macro

#define __typeof_unqual__(X) __typeof__(1?(X):(X))

could do. (And one could fix the finite number of cases that are not covered
with `_Generic`.)

I'd like to have prefix `+` for that. This could be useful in `__typeof__` but
also in `_Generic`. Maybe gcc could extend that operator to be applicable to
all types.

[Bug c/65455] typeof _Atomic fails

[jens.gustedt at inria dot fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #21 from Jens Gustedt <jens.gustedt at inria dot fr> ---
I would be much happier with a generic operator that makes any object into an
rvalue. One way that comes close would be `1 ? (X) : (X)`. This is an
expression that transforms any expression `X` that is not a narrow integer type
into an rvalue. 

Unfortunately it is too ugly that anybody ever will systematically write
`__typeof__(1?(X):(X))`. But a macro

#define __typeof_unqual__(X) __typeof__(1?(X):(X))

could do. (And one could fix the finite number of cases that are not covered
with `_Generic`.)

I'd like to have prefix `+` for that. This could be useful in `__typeof__` but
also in `_Generic`. Maybe gcc could extend that operator to be applicable to
all types.

[Bug c/65455] typeof _Atomic fails

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Uecker <uecker@gcc.gnu.org>:

https://gcc.gnu.org/g:768ce4f0ceb030e38427e85e483ed44330cd5da7

commit r11-5397-g768ce4f0ceb030e38427e85e483ed44330cd5da7
Author: Martin Uecker <muecker@gwdg.de>
Date:   Thu Nov 26 08:12:12 2020 +0100

    C: Do not drop qualifiers in typeof for _Atomic types. [PR65455,PR92935]

    2020-11-25  Martin Uecker  <muecker@gwdg.de>

    gcc/c/
            PR c/65455
            PR c/92935
            * c-parser.c (c_parser_declaration_or_fndef): Remove
            redundant code to drop qualifiers of _Atomic types for __auto_type.
            (c_parser_typeof_specifier): Do not drop qualifiers of _Atomic
            types for __typeof__.

    gcc/
            PR c/65455
            PR c/92935
            * ginclude/stdatomic.h: Use comma operator to drop qualifiers.

    gcc/testsuite/
            PR c/65455
            PR c/92935
            * gcc.dg/typeof-2.c: Adapt test.

[Bug c/65455] typeof _Atomic fails

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|mpolacek at gcc dot gnu.org        |unassigned at gcc dot gnu.org
             Status|ASSIGNED                    |NEW

[Bug c/65455] typeof _Atomic fails

[muecker at gwdg dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

--- Comment #24 from Martin Uecker <muecker at gwdg dot de> ---
This can be closed.

[Bug c/65455] typeof _Atomic fails

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |11.0
           Keywords|                            |rejects-valid

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed for GCC 11 by the referenced revision in comment #23.