From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45875 invoked by alias); 28 Apr 2016 10:22:58 -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 45855 invoked by uid 89); 28 Apr 2016 10:22:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=ACATS, walking, HX-Envelope-From:sk:ebotcaz, H*F:U*ebotcazou X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 28 Apr 2016 10:22:53 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 39AD38132F; Thu, 28 Apr 2016 12:22:50 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoUIO8QCcvDH; Thu, 28 Apr 2016 12:22:50 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 0A43A8132A; Thu, 28 Apr 2016 12:22:49 +0200 (CEST) From: Eric Botcazou To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix type field walking in gimplifier unsharing Date: Thu, 28 Apr 2016 10:22:00 -0000 Message-ID: <3302327.fD05QFZoa0@polaris> User-Agent: KMail/4.14.10 (Linux/3.16.7-35-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: References: <1563866.3PAXIoXYk7@polaris> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2016-04/txt/msg01777.txt.bz2 > Aww, I was hoping for sth that would not require me to fix all > frontends ... I don't really see how this can work without DECL_EXPR though. You need to define when the variable-sized expressions are evaluated to lay out the type, otherwise it will be laid out on the first use, which may see a different value of the expressions than the definition point. The only way to do that for a locally-defined type is to add a DECL_EXPR in GENERIC, so that the gimplifier evaluates the expressions at the right spot. Of course in Ada we have the ACATS testsuite which tests for this kind of things, this explains why it already works. > It seems the C frontend does it correctly already - I hit the > ubsan issue for c-c++-common/ubsan/pr59667.c and only for the C++ FE > for example. Notice how only the pointed-to type is variable-size > here. > > C produces > > { > unsigned int len = 1; > typedef float [0:(sizetype) ((long int) SAVE_EXPR + > -1)][0:(sizetype) ((long int) SAVE_EXPR + -1)]; > float[0:(sizetype) ((long int) SAVE_EXPR + -1)][0:(sizetype) > ((long int) SAVE_EXPR + -1)] * P = 0B; > > unsigned int len = 1; > typedef float [0:(sizetype) ((long int) SAVE_EXPR + > -1)][0:(sizetype) ((long int) SAVE_EXPR + -1)]; > SAVE_EXPR ;, (void) SAVE_EXPR ;; > float[0:(sizetype) ((long int) SAVE_EXPR + -1)][0:(sizetype) > ((long int) SAVE_EXPR + -1)] * P = 0B; > (*P)[0][0] = 1.0e+0; > return 0; > } > > the decl-expr is the 'typedef' line. The C++ FE produces > > { > unsigned int len = 1; > float[0:(sizetype) (SAVE_EXPR <(ssizetype) len + -1>)][0:(sizetype) > (SAVE_EXPR <(ssizetype) len + -1>)] * P = 0B; > > <>; > < (void) (((bitsizetype) ((sizetype) (SAVE_EXPR <(ssizetype) len + -1>) + > 1) * (bitsizetype) ((sizetype) (SAVE_EXPR <(ssizetype) len + -1>) + 1)) * > 32) >>>>>; > < -1>)][0:(sizetype) (SAVE_EXPR <(ssizetype) len + -1>)] * P = 0B;>>; > < (void) ((*P)[0][0] = 1.0e+0) >>>>>; > return = 0; > } > > notice the lack of a decl-expr here. It has some weird expr_stmt > here covering the sizes though. Possibly because VLA arrays are a GNU > extension. Indeed. > Didn't look into the fortran FE issue but I expect it's similar > (it only occurs for pointers to VLAs as well). > > I'll try to come up with patches. > > Thanks for the hint, You're welcome. -- Eric Botcazou