From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15688 invoked by alias); 10 Jan 2018 15:46:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 15679 invoked by uid 89); 10 Jan 2018 15:46:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=highlight, hatch, Apparently, door X-HELO: mail-it0-f68.google.com Received: from mail-it0-f68.google.com (HELO mail-it0-f68.google.com) (209.85.214.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Jan 2018 15:46:29 +0000 Received: by mail-it0-f68.google.com with SMTP id m11so16905219iti.1 for ; Wed, 10 Jan 2018 07:46:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r0UHBp6Eu53ahaou+vZwIgwZL9QFvyxhpSMc69UPjgE=; b=EcaGRevK93EUyfqKkp1UA8BfEIEAWfgO5961UJsV7jHGtEF76j/ec9d14OLfwITIZS 2xyCXG0aDXhZ7LGLPtaQbRwtDsp99gZQp233pEgJ5r8g7Ju5A1hFgh3t6CaL1zXrKZPp U4ha/qZQiDcvYogjfofmJ+xYPcGhXsHdGHJ6gjq/CrBnMTXrrDTHVm3Mo8v2zZQ3ASk1 UHJDIdmVcNvni6OaMB7mNlIvOqpmAlDRJGTuosNilfBUYMwxhcTjVIT7CBXSfhnDyyAP 81cOMC5sNRJcFrkrc+ax+pOoc6PZKPOg3RSOWiGFldPgTtodROUWI09KwJ3sWiYEr3FF 0Lhg== X-Gm-Message-State: AKwxytccTxYmkyLSL2NVO7klOfd7FPFleWhScAzMslpfPR+XQemG3m/l oYYqnML1DB/wT1PqUxy3RSyiifadbwSXKCiC0XS3Dg== X-Google-Smtp-Source: ACJfBospdSEU7yxMyBsyOVjAIGVIbJ4Lt2EaqABM4IUuwkvF9Ld3YQHkjmZHpQMmIUCKAM8lD8loN6rrceip7jMN4c4= X-Received: by 10.36.228.79 with SMTP id o76mr14197939ith.85.1515599187428; Wed, 10 Jan 2018 07:46:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.147.193 with HTTP; Wed, 10 Jan 2018 07:46:06 -0800 (PST) In-Reply-To: <5ee91b70-1513-17c2-896d-d33d7129f14d@gmail.com> References: <20180105220231.GH1833@tucnak> <5ee91b70-1513-17c2-896d-d33d7129f14d@gmail.com> From: Jason Merrill Date: Wed, 10 Jan 2018 16:25:00 -0000 Message-ID: Subject: Re: [C++ PATCH] -Wclass-memaccess fixes and improvements (PR c++/81327) To: Martin Sebor Cc: Jakub Jelinek , Nathan Sidwell , gcc-patches List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00771.txt.bz2 On Fri, Jan 5, 2018 at 6:37 PM, Martin Sebor wrote: > On 01/05/2018 03:02 PM, Jakub Jelinek wrote: >> >> Hi! >> >> Apparently LLVM allows similar warning to -Wclass-memaccess (is it just >> similar or same?; if the latter, perhaps we should use the same option for >> that) to be disabled not just by casting the destination pointer to >> e.g. (char *) or some other pointer to non-class, but also to (void *), >> which is something that Qt uses or wants to use. > > Clang has an option/warning called -Wdynamic-class-memaccess. > It detects a limited subset of the problems -Wclass-memaccess > detects: AFAIK, just calling raw memory functions like memcpy > on objects of polymorphic types, which the standard says is > undefined. > > I didn't know about the Clang option when I wrote the GCC code. > Had I found out about it sooner I would have probably considered > splitting up -Wclass-memaccess and providing the same option as > Clang for compatibility, and another for the rest of the checks. > But there might still be time to split it up before the release > if that's important. > > Some Qt code apparently uses memcpy to copy polymorphic objects > but gets around the Clang warning by casting the pointers to > void*, which doesn't suppress the GCC warning. I had considered > allowing the void* cast as a possible suppression mechanism but > ultimately decided against it. IIRC, partly because it would > have complicated the implementation and partly because I wasn't > convinced that it was a good idea (and I also didn't know about > the Clang escape hatch). > >> The problem is that the warning is diagnosed too late and whether we had >> explicit or implicit conversion to void * is lost at that point. >> >> This patch moves the warning tiny bit earlier (from build_cxx_call to the >> caller) where we still have information about the original parsed >> arguments before conversions to the builtin argument types. OK. > I'm still not convinced that letting programs get away with > byte-wise copying polymorphic objects is a good thing, but I > agree that supporting the void* cast suppression will be useful > for portability with Clang (presumably both C-style cast and > C++-style static_cast work). IMO It's good to have a way to suppress any warning by being more verbose. Warnings are to highlight inadventent mistakes, not deliberate ones. > If we want to make it a feature then we should document it in > the manual. Otherwise, if it's supposed to be a back door for > poorly written code, then I think it would be helpful to mention > it in comments in the implementation and above the assertion in > the test. I don't like undocumented back doors so I'm leaning > toward documenting it in the manual. I'm happy to add some > text to the manual if/when this is approved and decided. I agree that this should be documented. Jason