[Bug other/64711] New: Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations

[Bug other/64711] New: Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations

[jbellon at bsc dot es]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

            Bug ID: 64711
           Summary: Unconsistency with -fnon-call-exceptions when used
                    along inline and ipa optimizations
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jbellon at bsc dot es

Created attachment 34517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34517&action=edit
Test program source code

Behavior of -fnon-call-exceptions mechanism (throwing an exception inside a
signal handler) is not consistent if optimization options change, that is, the
result of a given program can be different.

In order to make a comparison, I ran a test program several times, each with
different optimizations enabled. The test consists on copying a buffer (r/w
protected) content to another (will trigger a SIGSEGV signal). The program uses
two additional functions that make a call to another as shown below:
   main --> foo --> copy --> std::copy (raises SIGSEGV) --> handler

Each of the function calls are surounded by a try/catch block.

1) Compilation either with -O0 or without any flags (just
-fnon-call-exceptions):
 Exception is caught at the "copy" function (the one which calls
 std::copy). This is the expected behavior.

2) Compilation using -O1 -O2 or -O3 flag directly:
Exception is not being caught.

3) If both -fno-inline and -fno-ipa-pure-const are included before -OX, then
the program behaves as in (1): 
CXXFLAGS=-fnon-call-exceptions -fno-inline -fno-ipa-pure-const -O1

4) Compilation using both -finline -fipa-pure-const, but without any other
optimization:
Exception is caught in "foo" function.

5) Compilation using -fipa-pure-const only
Same as (3).

6) Compilation using -finline only
Same as (1).

7) Compilation using -fipa-pure-const -finline -finline-functions
Same as (3).

8) Compilation using -fno-inline -O1
Same as (2).

9) Compilation using -fno-ipa-pure-const -O1
Same as (3).

It seems that catch blocks are being optimized out or that, because of the
inlining, the generated code is not able to find any catch blocks inside its
scope.

The test program is attached. Compile command used is:
    g++ -fnon-call-exceptions [-fno-ipa-pure-const -fno-inline] -O{0,1,2,3}
file.cpp -o exec
or
   g++ -fnon-call-exceptions -fipa-pure-const -finline file.cpp -o exec

--------------------------
System info
GCC version:
   g++ (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]
Also reproduced with (default flags) public SVN versions:
   g++ (GCC) 4.8.1
   g++ (GCC) 5.0.0 20150109 (experimental)
Linux version (openSUSE 13.1)
Linux 3.11.10-25-desktop #1 SMP PREEMPT Wed Dec 17 17:57:03 UTC 2014 (8210f77)
x86_64 GNU/Linux

[Bug other/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations

[jbellon at bsc dot es]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

--- Comment #1 from Jorge Bellon <jbellon at bsc dot es> ---
There is a typo in the details:
5) Compilation using -fipa-pure-const only
Same as (4).

7) Compilation using -fipa-pure-const -finline -finline-functions
Same as (4).

9) Compilation using -fno-ipa-pure-const -O1
Same as (4).

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[laszlo.2.nemeth@continental-corporation.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

Leslie <laszlo.2.nemeth@continental-corporation.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laszlo.2.nemeth@continental
                   |                            |-corporation.com

--- Comment #3 from Leslie <laszlo.2.nemeth@continental-corporation.com> ---
I encountered the same problem, so I put +1 vote for fixing this :)

Following Comment 2, this looks like related to already reported bugs:
built-ins are always considers as "noexcept":
Bug 96985, Bug 39801 (from 2009) and maybe Bug 94357, too ?

Thanks Jorge for reporting this!

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-11-12
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
As Andrew says the reason is that C library builtins are marked nothrow which
currently implies "notrap" in the context of -fnon-call-exceptions.  There's
no separate attribute for not trapping (or IPA discovery of this) but a
simple enough workaround only pessimizing -fnon-call-exceptions would be sth
like the following

diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index c3314bbd78c..bcf6a7fb348 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -2902,6 +2902,12 @@ stmt_could_throw_p (function *fun, gimple *stmt)
       return true;

     case GIMPLE_CALL:
+      /* ???  We need to check whether the callee can throw non-call
+        exceptions or conservatively assume so if we cannot tell but
+        non-call exceptions are enabled.  */
+      if (fun && fun->can_throw_non_call_exceptions
+         || flag_non_call_exceptions)
+       return true;
       return !gimple_call_nothrow_p (as_a <gcall *> (stmt));

     case GIMPLE_COND:

as the comments says the check isn't correct but it might work for simple
non-LTO cases.  Anybody willing to try?

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> as the comments says the check isn't correct but it might work for simple
> non-LTO cases.  Anybody willing to try?

But isn't LTO towards being the default these days?  If so, what's the point of
punishing every function for something that doesn't really work with LTO?

Cannot we clear the nothrow flag on the functions selectively instead?

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 12 Nov 2020, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
> 
> --- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > as the comments says the check isn't correct but it might work for simple
> > non-LTO cases.  Anybody willing to try?
> 
> But isn't LTO towards being the default these days?  If so, what's the point of
> punishing every function for something that doesn't really work with LTO?
> 
> Cannot we clear the nothrow flag on the functions selectively instead?

Well, if this is the place to fix we can figure a way to check it
correctly.

The issue with clearing nothrow is that those pesky builtins have
that "sticky" while the per-stmt flag (gimple_call_nothrow ())
just amends it.  Guess we might want to fix that (in gimple_call_flags)
and then clear the flag always for -fnon-call-exceptions?

I suppose all/most noexcept specifications in libstdc++ are similarly
questionable.

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> The issue with clearing nothrow is that those pesky builtins have
> that "sticky" while the per-stmt flag (gimple_call_nothrow ())
> just amends it.  Guess we might want to fix that (in gimple_call_flags)
> and then clear the flag always for -fnon-call-exceptions?
> 
> I suppose all/most noexcept specifications in libstdc++ are similarly
> questionable.

Let's not use too big a hammer though, -fnon-call-exceptions works fine for
languages (Ada, Go) that enable it by default and I'm quite wary of C++ folks
who try it once in a while, want to pessimize it because it doesn't work on
their questionable testcase, and then forget about it.

Why not just extend what's done in build_common_builtin_nodes for
__builtin_alloca to the family of __builtin_mem* functions?

[Bug middle-end/64711] Unconsistency with -fnon-call-exceptions when used along inline and ipa optimizations and memmov

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 12 Nov 2020, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
> 
> --- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > The issue with clearing nothrow is that those pesky builtins have
> > that "sticky" while the per-stmt flag (gimple_call_nothrow ())
> > just amends it.  Guess we might want to fix that (in gimple_call_flags)
> > and then clear the flag always for -fnon-call-exceptions?
> > 
> > I suppose all/most noexcept specifications in libstdc++ are similarly
> > questionable.
> 
> Let's not use too big a hammer though, -fnon-call-exceptions works fine for
> languages (Ada, Go) that enable it by default and I'm quite wary of C++ folks
> who try it once in a while, want to pessimize it because it doesn't work on
> their questionable testcase, and then forget about it.
> 
> Why not just extend what's done in build_common_builtin_nodes for
> __builtin_alloca to the family of __builtin_mem* functions?

Ah, didn't remember this place.  Yes, I guess we could fix that place
but that wouldn't conver the C/C++ frontends since those have
the builtins already (wrongly) declared via the builtins.def machinery
which does mark them NOTHROW (the __builtin_alloca handling also
doesn't work for them).

That means that similar to ATTR_MATHFN_FPROUNDING we'd need a
variants of ATTR_NOTHROW_NONNULL_LEAF and some others that make
the NOTHROW part conditional on flag_non_call_exceptions.
Guess that's doable, double checking LTO behavior on merging
of builtins from different CUs with possibly different settings
of -fnon-call-exceptions needs to be done though.