From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15052 invoked by alias); 4 Nov 2013 18:05:47 -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 15042 invoked by uid 89); 4 Nov 2013 18:05:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ee0-f42.google.com Received: from Unknown (HELO mail-ee0-f42.google.com) (74.125.83.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 04 Nov 2013 18:05:45 +0000 Received: by mail-ee0-f42.google.com with SMTP id c1so913965eek.1 for ; Mon, 04 Nov 2013 10:05:36 -0800 (PST) X-Received: by 10.14.224.132 with SMTP id x4mr19822365eep.5.1383588336727; Mon, 04 Nov 2013 10:05:36 -0800 (PST) Received: from [192.168.178.20] (p5495B719.dip0.t-ipconnect.de. [84.149.183.25]) by mx.google.com with ESMTPSA id z12sm49564679eev.6.2013.11.04.10.05.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Nov 2013 10:05:36 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: Patch RFA: With -fnon-call-exceptions sync builtins may throw From: Richard Biener Date: Mon, 04 Nov 2013 18:13:00 -0000 To: Ian Lance Taylor CC: GCC Patches Message-ID: X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00259.txt.bz2 Ian Lance Taylor wrote: >On Mon, Nov 4, 2013 at 3:52 AM, Richard Biener > wrote: >> On Mon, Nov 4, 2013 at 7:01 AM, Ian Lance Taylor >wrote: >>> The middle-end currently marks all the sync builtins as nothrow. >That >>> is incorrect for most of them when using -fnon-call-exceptions. The >>> -fnon-call-exceptions option means that instructions that trap may >throw >>> exceptions. Most of the sync builtins access memory via pointers >passed >>> by user code. Therefore, they may trap. (I noticed this because Go >>> uses -fnon-call-exceptions.) >>> >>> This patch fixes the problem by introducing a new internal function >>> attribute "nothrow call". The new attribute is exactly like >"nothrow", >>> except that it is ignored when using -fnon-call-exceptions. >>> >>> It is an internal attribute because there is no reason for a user to >use >>> this. The problem only arises when the middle-end sees a function >call >>> that the backend turns into an instruction sequence that directly >>> references memory. That can only happen for functions that are >built in >>> to the compiler. >>> >>> This requires changes to the C family, LTO, and Ada frontends. I >think >>> I'm handling the option correctly for LTO, but it would be good if >>> somebody could check the logic for me. >>> >>> Bootstrapped and ran tests on x86_64-unknown-linux-gnu. OK for >>> mainline? >> >> Hmm. I think you can handle this in a simpler way by just >> doing sth similar to >> >> #define ATTR_MATHFN_FPROUNDING_ERRNO (flag_errno_math ? \ >> ATTR_NOTHROW_LEAF_LIST : ATTR_MATHFN_FPROUNDING) >> >> that is, conditionally drop the _NOTHROW part. > >Good point. > >> Btw, I also think >> that if it can throw then it isn't LEAF (it may return exceptionally >> into another function in the unit). > >According to the docs, a "leaf" function is permitted to return by >throwing an exception. > >> Also this whole conditional-on-a-flag thing doesn't work well with >> using -fnon-call-exceptions in the optimize attribute or with >> different -fnon-call-exceptions settings in different TUs we LTO >> together. Because we only have a single builtin decl (so for >> "proper" operation you'd have to clone builtin decls based on >> the matrix of flags that generate different attributes and use the >> correct one depending on context). > >Yes, but as you know this problem already exists with -fexceptions. >I'm not really making it worse. > >> That said, I'd prefer a simpler approach for now, mimicing >flag_errno_math >> handling. > >Done. Attached. Bootstrapped on x86_64-unknown-linux-gnu, running >tests now. OK for mainline if the tests pass? Ok Thanks, Richard >Ian > > >gcc/ChangeLog: > >2013-11-04 Ian Lance Taylor > > * builtins.def (ATTR_NOTHROWCALL_LEAF_LIST): Define. > * sync-builtins.def: Use ATTR_NOTHROWCALL_LEAF_LIST for all sync > builtins that take pointers. > * lto-opts.c (lto_write_options): Write -fnon-call-exceptions > if set. > * lto-wrapper.c (merge_and_complain): Collect > OPT_fnon_call_exceptions. > (run_gcc): Pass -fnon-call-exceptions. > >gcc/testsuite/ChangeLog: > >2013-11-03 Ian Lance Taylor > > * g++.dg/ext/sync-4.C: New test.