Bug 65455 - typeof _Atomic fails
Summary: typeof _Atomic fails
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.9.2
: P3 normal
Target Milestone: ---
Assignee: Marek Polacek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-17 21:27 UTC by Jens Gustedt
Modified: 2019-03-01 13:04 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-09-01 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Gustedt 2015-03-17 21:27:50 UTC
The following declarations

_Atomic int a;
__typeof__(a) a;

result in compile errors:

> typeof_atomic.c:2:15: error: conflicting type qualifiers for 'a'
> __typeof__(a) a;
>               ^
> typeof_atomic.c:1:13: note: previous declaration of 'a' was here
> _Atomic int a;


This could be related to bug #65345.

Jens
Comment 1 joseph@codesourcery.com 2015-03-17 21:34:50 UTC
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.)  */
Comment 2 Jens Gustedt 2015-03-17 21:51:57 UTC
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.)
Comment 3 joseph@codesourcery.com 2015-03-17 22:02:32 UTC
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.
Comment 4 Jens Gustedt 2015-03-18 16:28:56 UTC
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.
Comment 5 joseph@codesourcery.com 2015-03-18 17:48:42 UTC
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.
Comment 6 joseph@codesourcery.com 2015-03-18 18:00:48 UTC
(_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.)
Comment 7 Jens Gustedt 2015-03-18 23:16:30 UTC
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.
Comment 8 Jens Gustedt 2015-03-18 23:25:53 UTC
(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.)
Comment 9 joseph@codesourcery.com 2015-03-19 00:20:42 UTC
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.
Comment 10 joseph@codesourcery.com 2015-03-19 00:29:47 UTC
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).
Comment 11 Jens Gustedt 2015-03-19 07:31:00 UTC
(In reply to joseph@codesourcery.com from comment #10)
> 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).

And now we are exactly in the situation that I was afraid of happening, compiler implementors interpret _Generic differently. Your interpretation and the one that clang applies differ and make it that code with _Generic isn't portable. That is just a disaster for an early (well not so early anymore) adoption of C11.
Comment 12 Marek Polacek 2015-03-19 07:59:48 UTC
What does clang differently wrt _Generic?
Comment 13 Jens Gustedt 2015-03-19 08:11:20 UTC
(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.
Comment 14 Jens Gustedt 2015-03-19 08:16:33 UTC
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.
Comment 15 Jakub Jelinek 2015-03-19 09:55:22 UTC
Usually such bugs are SUSPENDED with reference to the DR and when the DR is resolved, the bug is resolved accordingly.
Comment 16 Jens Gustedt 2015-03-19 10:37:52 UTC
(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?
Comment 17 Marek Polacek 2015-03-19 10:44:59 UTC
(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.
Comment 18 Marek Polacek 2015-08-13 15:22:10 UTC
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++?
Comment 19 joseph@codesourcery.com 2015-08-13 15:59:43 UTC
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).
Comment 20 Jens Gustedt 2015-08-13 23:37:34 UTC
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.
Comment 21 Jens Gustedt 2015-08-13 23:39:57 UTC
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.
Comment 22 pskocik 2019-03-01 13:04:44 UTC
(In reply to Marek Polacek from comment #18)
> 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++?

As a user, I can always force top-level-qualifier dropping by rvalue conversion (e.g., with , or ?:) but it(In reply to Jens Gustedt from comment #20)
> 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.

(In reply to Jens Gustedt from comment #20)
> 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.

I agree __typeof should keep all top level qualifs (clang's __typeof does). But I'd rather the unary + were not extended to non-numeric types. I frequently rely on it to throw comptime errors when applied to non-numerics. I think the comma should be able to accomplish the job (__typeof(0,X)) with similar brevity as that of the unary +.