public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Uecker, Martin" <Martin.Uecker@med.uni-goettingen.de>
To: "joseph@codesourcery.com" <joseph@codesourcery.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [C PATCH] Do not drop qualifiers for _Atomic in typeof
Date: Wed, 25 Nov 2020 19:06:17 +0000	[thread overview]
Message-ID: <1606331176.16636.0.camel@med.uni-goettingen.de> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2011232012330.321778@digraph.polyomino.org.uk>

Am Montag, den 23.11.2020, 20:21 +0000 schrieb Joseph Myers:
> On Mon, 23 Nov 2020, Uecker, Martin wrote:
> 
> > Joseph,
> > 
> > here is the patch to not drop qualifiers for _Atomic in
> > typeof. I am not sure whether this is appropriate in
> > stage3, but I wanted to leave it here for you to comment
> > and so that it does not lost.
> > 
> > First, I noticed that the change to drop qualifiers
> > in lvalue conversion also implies that __auto_type now
> > always uses the non-qualified type. I think this is more
> > correct, and also what other compilers and C++'s auto do.
> > The first change here in c-parser would remove the now
> > redundant code to drop qualifiers for _Atomic types.
> > 
> > The second change would remove the code to drop qualifiers
> > for _Atomic types for typeof. I would then use the
> > comma operator for stdatomic to remove all qualifiers.
> > Here, the question is whether this may have same
> > unintended side effects.
> 
> This is OK, with references to bugs 65455 and 92935 as I think it fixes 
> those.
> 
> Any change to qualifiers for typeof risks breaking something relying on 
> the details of when the result is or is not qualified, but given that in 
> previous GCC versions that was poorly defined and inconsistent, making 
> these changes to make it more consistent seems reasonable.
> 
> It is probably still the case that _Typeof as proposed for ISO C would 
> need special handling of function and function pointer types for the same 
> reason as _Generic has such handling (_Noreturn not being part of the 
> function type as defined by ISO C).

So OK to apply with the following Changelog?



    C: Do not drop qualifiers in typeof for _Atomic types. [PR65455,PR92935]
    
    2020-11-25  Martin Uecker  <muecker@gwdg.de>

    gcc/c/
            * c-parsers.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/ginclude/
	    * ginclude/stdatomic.h: Use comma operator to drop qualifiers.
 
    gcc/testsuite/
	    * gcc.dg/typeof-2.c: Adapt test.


  reply	other threads:[~2020-11-25 19:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 20:02 Uecker, Martin
2020-11-23 20:21 ` Joseph Myers
2020-11-25 19:06   ` Uecker, Martin [this message]
2020-11-25 22:27     ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1606331176.16636.0.camel@med.uni-goettingen.de \
    --to=martin.uecker@med.uni-goettingen.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).