From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id E6BA03857C55 for ; Mon, 28 Sep 2020 19:50:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E6BA03857C55 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08SJiExq059418; Mon, 28 Sep 2020 15:50:06 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 33up8g834a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Sep 2020 15:50:06 -0400 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 08SJkBFe067170; Mon, 28 Sep 2020 15:50:06 -0400 Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com with ESMTP id 33up8g832w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Sep 2020 15:50:06 -0400 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 08SJo3LD026922; Mon, 28 Sep 2020 19:50:03 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma03ams.nl.ibm.com with ESMTP id 33sw982fjt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Sep 2020 19:50:03 +0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 08SJo1ir25690504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Sep 2020 19:50:01 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 36F044C052; Mon, 28 Sep 2020 19:50:01 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C9A7F4C04E; Mon, 28 Sep 2020 19:50:00 +0000 (GMT) Received: from localhost.localdomain (unknown [9.145.90.15]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Mon, 28 Sep 2020 19:50:00 +0000 (GMT) Date: Mon, 28 Sep 2020 21:50:00 +0200 From: Stefan Schulze Frielinghaus To: Jakub Jelinek Cc: Richard Biener , "Joseph S. Myers" , Richard Earnshaw , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] options: Save and restore opts_set for Optimization and Target options Message-ID: <20200928195000.GA6647@localhost.localdomain> References: <20200908084512.GH18149@tucnak> <20200911092952.GM18149@tucnak> <20200913082922.GF21814@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200913082922.GF21814@tucnak> X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-28_20:2020-09-28, 2020-09-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=1 priorityscore=1501 spamscore=0 lowpriorityscore=0 adultscore=0 malwarescore=0 mlxscore=0 bulkscore=0 clxscore=1011 impostorscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009280142 X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Mon, 28 Sep 2020 19:50:10 -0000 On Sun, Sep 13, 2020 at 10:29:22AM +0200, Jakub Jelinek via Gcc-patches wrote: > On Fri, Sep 11, 2020 at 11:29:52AM +0200, Jakub Jelinek via Gcc-patches wrote: > > On Fri, Sep 11, 2020 at 09:46:37AM +0200, Christophe Lyon via Gcc-patches wrote: > > > I'm seeing an ICE with this new test on most of my arm configurations, > > > for instance: > > > --target arm-none-linux-gnueabi --with-cpu cortex-a9 > > > /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/gcc/xgcc > > > -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-ar > > > m-none-linux-gnueabi/gcc3/gcc/ c_lto_pr96939_0.o c_lto_pr96939_1.o > > > -fdiagnostics-plain-output -flto -O2 -o > > > gcc-target-arm-lto-pr96939-01.exe > > > > Seems a latent issue. > > Neither cl_optimization_{save,restore} nor cl_target_option_{save,restore} > > (nor any of the target hooks they call) saves or restores any opts_set > > values, so I think opts_set can be trusted only during option processing (if > > at all), but not later. > > So, short term a fix would be IMHO just stop using opts_set altogether in > > arm_configure_build_target, it doesn't make much sense to me, it should test > > if those strings are non-NULL instead, or at least do that when it is > > invoked from arm_option_restore (e.g. could be done by calling it with > > opts instead of &global_options_set ). > > Longer term, the question is if cl_optimization_{save,restore} and > > cl_target_option_{save,restore} shouldn't be changed not to only > > save/restore the options, but also save the opts_set flags. > > It could be done e.g. by adding a bool array or set of bool members > > to struct cl_optimization and struct cl_target_option , or even more compact > > by using bitmasks, pack each 64 adjacent option flags into a UHWI element > > of an array. > > So, I've tried under debugger how it behaves and seems global_options_set > is really an or of whether an option has been ever seen as explicit, either > on the command line or in any of the option pragmas or optimize/target > attributes seen so far, so it isn't something that can be relied on. > > The following patch implements the saving/restoring of the opts_set bits > (though only for the options/variables saved by the generic options-save.c > code, for the target specific stuff that isn't handled by the generic code > the opts_set argument is now passed to the hook and the backends can choose > e.g. to use a TargetSave variable to save the flags either individually or > together in some bitmask (or ignore it if they never need opts_set for the > options). > > Bootstrapped/regtested on x86_64-linux, i686-linux, armv7hl-linux-gnueabi, > aarch64-linux, powerpc64le-linux and lto bootstrapped on x86_64-linux, ok > for trunk? This patch breaks quite a view test cases (target-attribute/tattr-*) on IBM Z. Having a look at function cl_target_option_restore reveals that some members of opts_set are reduced to 1 or 0 depending on whether a member was set before or not, e.g. for target_flags we have opts_set->x_target_flags = (mask & 1) != 0; whereas previously those members where not touched by cl_target_option_restore. My intuition of this whole option evaluation is still pretty vague. Basically opts_set is a set of options enabled via command line and/or via pragmas/attributes whereas opts is the set of options which are implied by opts_set. What puzzles me right now is that in cl_target_option_save we save in ptr only options from opts but not from opts_set whereas in cl_target_option_restore we override some members of opts_set. Thus it is unclear to me how a backend should restore opts_set then. I'm probably missing something. Any hints on how to restore opts_set and especially target_flags? Cheers, Stefan