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
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.) */
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.)
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.
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.
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.
(_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.)
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.
(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.)
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.
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).
(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.
What does clang differently wrt _Generic?
(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.
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.
Usually such bugs are SUSPENDED with reference to the DR and when the DR is resolved, the bug is resolved accordingly.
(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?
(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.
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++?
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).
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 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 +.
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.
This can be closed.
Fixed for GCC 11 by the referenced revision in comment #23.