From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 0F49A3851C33 for ; Mon, 9 Aug 2021 13:21:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F49A3851C33 Received: by mail-ej1-x633.google.com with SMTP id d11so4507585eja.8 for ; Mon, 09 Aug 2021 06:21:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HVjw52U6whTBHJEg9cm4ZaxJXHzl8fve5r0m3wTppG8=; b=mjp+XPjpimCmHfK4smrAvkm875XtNhexKaw3wdMJitenkE9lp1ouQRhmaPZyON5YTm QmXM0JgmpQAzDTDCaPJQ0yffU3Vvms9LkRmI2ojzwWaBEpH6soPFMhs15hEsuvO5ii/i 2hc6SqHnKbyazh8rpj5kB6F4spiQzni/QxH46/nAX/d0JJ/Qi3nBtyF1N3gDYIDfgGtr CCTkP8hzKYuN0agJHo6BfJptHEMOZEafi+ycRUXojFTJaOqPHZvCCBUUjjbah4WJtMjF v8IeH5L8ba/2vKzIZkvlgYLyxAFpVQAlUD/5SxYElMC8eYH4OtBNey1m46aKy6dOHCIW 0Kmw== X-Gm-Message-State: AOAM530wt7H9dEOMIv7f6xKwR6OXhQl3CqEUYrqMM/8fe9HWzxV2Ibq7 oZms7+wGAbAmp1xfD5cdyhnVCyMvM3PrkTMGWic= X-Google-Smtp-Source: ABdhPJwC1pYzS17d1n31qpOZ/sV2teYPLxHu1qDMIl5UhmCcarSeUC1QU2w/h213jemRk8ls7aKMxlErxMR1dZme7Is= X-Received: by 2002:a17:906:c085:: with SMTP id f5mr23141330ejz.250.1628515290038; Mon, 09 Aug 2021 06:21:30 -0700 (PDT) MIME-Version: 1.0 References: <7a60b732e62b342dd5bd89f9b67f0f493fd8c7e8.camel@gwdg.de> <422f57ce88597a75e0298ca5bdbaa6db06327026.camel@gwdg.de> In-Reply-To: <422f57ce88597a75e0298ca5bdbaa6db06327026.camel@gwdg.de> From: Richard Biener Date: Mon, 9 Aug 2021 15:21:19 +0200 Message-ID: Subject: Re: Re: [PATCH] Fix ICE when mixing VLAs and statement expressions [PR91038] To: Martin Uecker , Eric Botcazou Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 09 Aug 2021 13:21:33 -0000 On Tue, Aug 3, 2021 at 9:31 PM Martin Uecker wrote: > > Am Dienstag, den 03.08.2021, 11:26 +0200 schrieb Richard Biener: > > On Tue, Aug 3, 2021 at 10:28 AM Martin Uecker wrote: > > > > > > Does the same issue arise with writing the testcases as > > > > ({ ... }) + i; > > > > ? How can we fix it then if you also need to support > > > > i + ({ ...}); > > > > ? > > Here, the FE always moves the pointer to the right and > then produces something like: > > *((int *) TARGET_EXPR int n = 10; > ... > D.1952 = x; > }> + ((sizetype) SAVE_EXPR + 1) * 20); > > > So these are the cases which already work without > the path, although maybe it is wrong to have > the n in the SAVE_EXPR? > > It gets gimplified to something like this, > which works: > > int[0:D.1959][0:D.1955] * D.1952; > int n.0; > sizetype D.1955; > sizetype D.1959; > > { > int n; > int[0:D.1959][0:D.1955] * x; > > n = 10; > n.0 = n; > > ... > > _32 = (sizetype) n.0; > _33 = (sizetype) n.1; > _34 = _32 * _33; > _35 = _34 * 4; > x = __builtin_malloc (_35); > D.1952 = x; > } > _36 = (sizetype) n.0; > _37 = _36 + 1; > _38 = _37 * 20; > _39 = D.1952 + _38; > > > For the array ref, the FE produces: > > > (*TARGET_EXPR int n = 10; > ... > D.1951 = x; > }>)[5][5]; > > > With the patch, we get something like > the following in GIMPLE, which seems correct: > > int[0:D.1958][0:D.1954] * D.1951; > int n.0; > sizetype D.1954; > > { > int n; > int[0:D.1958][0:D.1954] * x; > > n = 10; > n.0 = n; > > _7 = (sizetype) n.0; > _8 = _7 * 4; > D.1956 = _8; > > n.1 = n > > _22 = (sizetype) n.0; > _23 = (sizetype) n.1; > _24 = _22 * _23; > _25 = _24 * 4; > x = __builtin_malloc (_25); > D.1951 = x; > } > _26 = D.1956 /[ex] 4; > c = (*D.1951)[5]{lb: 0 sz: _26 * 4}[5]; OK, thanks for the try to explaining. I think the patch makes sense but the comment says Java requires that we elaborated nodes in source order. That means we must gimplify the inner expression followed by each of the indices, in order. But we can't gimplify the inner expression until we deal with any variable bounds, sizes, or positions in order to deal with PLACEHOLDER_EXPRs. and I don't really understand that (not to say Java is no longer supported by GCC, but Ada does use PLACEHOLDER_EXPRs). In fact the comment suggests that we _should_ gimplify the inner expression first ... at least it seems to after your explanations ;) Eric - do you know anything about this? Martin - I think the patch is OK but please make sure to bootstrap & regtest with all languages enabled (--enable-languages=all) and make sure you have an Ada host compiler installed so you get Ada included as well. Thanks, Richard. > > MArtin >