From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 5C8D2388A41D for ; Wed, 2 Jun 2021 16:14:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C8D2388A41D Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-422-3BWVt9NEOYSiTh1ed0j32Q-1; Wed, 02 Jun 2021 12:14:53 -0400 X-MC-Unique: 3BWVt9NEOYSiTh1ed0j32Q-1 Received: by mail-qv1-f72.google.com with SMTP id w4-20020a0c8e440000b02901f0640ffdafso2032737qvb.13 for ; Wed, 02 Jun 2021 09:14:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3eJ8E9gZuNECwP+NokelBcTd2eYUQnxgRqQgHHHc8x0=; b=GmuTtOeYpsotdvOAXtiH9lr9ZKtPqPmf/N12byHCioX5jwvlyeZBdz84HoJZwwDxK2 Fisg+MgcQ8QqRxJ8+XdkAvO9GNEeMQ0rqnalrhNvTQ3Czq4PY4Qd5BQux5UINAasSifd JhUSGghttus08yX4rd0ddf/UekonKAMfrfMymKUJvMhhcUKxUoGIy9XHGwVsNM9w/0j7 TWuoDB9UispeeOzT1ttVPqc/bJVwcfg9l7MPdfbj5JWuGcc+Xa/jBUU29LxmEILOkZiU 7dlEVEJabu8S0zVVnNbqI4gzyk3XoXGYTMD1hYaJOK7MmX/oVPD02xUG9+gzmxWVj5yj ZKZg== X-Gm-Message-State: AOAM5302jA11vQkCkue3EGxthCPilsQGNzp3sDAzxpHkczcjjM0OT1Zp C+Iz2QNBLRQ1hxzo7UFdjdutqn3pxn2DBUVdqueK7e1olhG5QFNzPZf/O69kRw2dr7cHTE7b/Pn x4k7PC891j5xBA6x8Xw== X-Received: by 2002:ac8:4319:: with SMTP id z25mr25981809qtm.262.1622650492983; Wed, 02 Jun 2021 09:14:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqa7MbBlZa0SRIGvrlTOE1vzZEAz0pNYRTANh2CcyOIM9GNRn/yzUhd57DsorYiCYfoUTsxw== X-Received: by 2002:ac8:4319:: with SMTP id z25mr25981782qtm.262.1622650492584; Wed, 02 Jun 2021 09:14:52 -0700 (PDT) Received: from [192.168.1.148] ([130.44.159.43]) by smtp.gmail.com with ESMTPSA id 20sm64583qtz.97.2021.06.02.09.14.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 09:14:52 -0700 (PDT) Subject: Re: [PATCH] inline-asm: Fix ICE with bitfields in "m" operands [PR100785] To: Jakub Jelinek Cc: Richard Biener , "Joseph S. Myers" , gcc-patches@gcc.gnu.org, Eric Botcazou References: <20210602075931.GX7746@tucnak> <5a507f60-8dd9-1c52-c04f-0e2e3bbbb65a@redhat.com> <20210602152518.GZ7746@tucnak> From: Jason Merrill Message-ID: <2695cde9-daae-fee0-6500-75f55976d7c7@redhat.com> Date: Wed, 2 Jun 2021 12:14:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210602152518.GZ7746@tucnak> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 16:14:58 -0000 On 6/2/21 11:25 AM, Jakub Jelinek wrote: > On Wed, Jun 02, 2021 at 11:09:45AM -0400, Jason Merrill wrote: >> On 6/2/21 3:59 AM, Jakub Jelinek wrote: >>> if (!allows_reg && !cxx_mark_addressable (*op)) >>> operand = error_mark_node; >>> + else if (!allows_reg && bitfield_p (*op)) >>> + { >>> + error_at (loc, "attempt to take address of bit-field"); >> >> Hmm, why aren't we already catching this in cxx_mark_addressable? > > That is certainly possible, but it goes against Eric's patch > https://gcc.gnu.org/pipermail/gcc-patches/2015-June/421483.html Hmm, I wonder what his rationale was? > So, do you want to keep the > if (bitfield_p (arg)) > { > if (complain & tf_error) > error_at (loc, "attempt to take address of bit-field"); > return error_mark_node; > } > in cp_build_addr_expr_1 and duplicate such check in cxx_mark_addressable > (though, that one doesn't have complain, will it be ok to do it > unconditionally for SFINAE)? We would need to add complain; the existing diagnostics can't happen in SFINAE context, but this one can. Alternately, cxx_mark_addressable could abort on a bitfield to require the caller to handle it, but that seems less useful. Jason > Shall the C FE do the same (i.e. diagnose in both places)?