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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id DACB8386102D for ; Mon, 28 Sep 2020 19:59:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DACB8386102D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-123-ZxJK2_V9P4mbA7N9IbU5xA-1; Mon, 28 Sep 2020 15:59:02 -0400 X-MC-Unique: ZxJK2_V9P4mbA7N9IbU5xA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4772A1084C89; Mon, 28 Sep 2020 19:59:01 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-37.ams2.redhat.com [10.36.112.37]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A3F4F55779; Mon, 28 Sep 2020 19:59:00 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 08SJwvDA007133; Mon, 28 Sep 2020 21:58:58 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 08SJwt25007132; Mon, 28 Sep 2020 21:58:55 +0200 Date: Mon, 28 Sep 2020 21:58:55 +0200 From: Jakub Jelinek To: Stefan Schulze Frielinghaus 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: <20200928195855.GT2176@tucnak> Reply-To: Jakub Jelinek References: <20200908084512.GH18149@tucnak> <20200911092952.GM18149@tucnak> <20200913082922.GF21814@tucnak> <20200928195000.GA6647@localhost.localdomain> MIME-Version: 1.0 In-Reply-To: <20200928195000.GA6647@localhost.localdomain> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, 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: Mon, 28 Sep 2020 19:59:08 -0000 On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus wrote: > 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. opts_set is always used as a booleans, cleaner would be to have a struct global_option_set that would contain just bool fields (or even bitfields) with the same names as in struct global_option, but unfortunately we didn't do that years ago and changing it now would be quite a lot of work. Anyway, opts_set records a boolean for each flag, whether it was set explicitly or not, for non-pointer vars that means values 0 and 1, for pointer vars NULL and "". I vaguely remember the s390 opts_set handling differed quite a lot from all the other targets. > 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've handled in the generic code handling of the opts_set only for whatever is handled there for opts too. Whether the vars that are handled in the save/restore options hooks need handling of opts_set at all or not depends on whether the backend ever cares about those or not (e.g. whether it every queries global_options_set.x_whatever). If yes, it can be handled e.g. by having an extra target variable that will store whether it was explicit or not and restore from there. If it is never used, then it doesn't need to be handled. Jakub