[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #15 from jwjagersma at gmail dot com ---
Created attachment 47970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47970=edit
alternative patch v3

Alternative to last patch. Inserts the debug stmt across the fallthrough edge.
Let me know which patch would be preferable, and I'll submit it.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

jwjagersma at gmail dot com changed:

   What|Removed |Added

  Attachment #47941|0   |1
is obsolete||

--- Comment #14 from jwjagersma at gmail dot com ---
Created attachment 47951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47951=edit
proposed patch v3

I went with the option to ignore these debug statements. This works for
me now, I am able to build target libraries and some of my own code
with -fnon-call-exceptions. However I still think it's strange that
this used to work for other throwing or control statements. I feel like
I'm missing something here.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #13 from jwjagersma at gmail dot com ---
Is there some point at which debug statements are supposed to be copied
over to the next BBs? That appears to be what
maybe_move_debug_stmts_to_successors (tree-inline.c:2799) does, but it
is only called for inlined functions.

Or alternatively, should mark_reachable_handlers and
verify_gimple_in_cfg be made to ignore the debug statement, by using
gsi_last_nondebug_bb?

[Bug inline-asm/93981] No EH information generated for asm statements

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to jwjagersma from comment #11)
> (In reply to Richard Biener from comment #10)
> > Some stmt-ends-BB predicates are probably off for asms.
> 
> For stmt_ends_bb_p (tree-cfg.c:2763) the call chain looks like this:
> 
> stmt_ends_bb_p -> is_ctrl_altering_stmt -> stmt_can_throw_internal ->
> stmt_could_throw_p -> gimple_asm_volatile_p
> 
> So volatile asms are considered bb-enders, now that they have a landing
> pad, which stmt_can_throw_internal checks for. I am not sure how
> that works actually, do all throwing statements get a landing pad at
> first, even if there is no try block? Because that looks to be the
> case, I assume these are eliminated in some later pass.
> 
> Using gdb I found that the DEBUG stmt is added in rewrite_stmt
> (tree-into-ssa.c:1417) which does so without considering if the bb has
> an EH edge or not. How does this work for other throwing statements?

I guess it's a "first" for this case...  I'd say it should be reproducible
with call exceptions and a register LHS?!

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #11 from jwjagersma at gmail dot com ---
(In reply to Richard Biener from comment #10)
> Some stmt-ends-BB predicates are probably off for asms.

For stmt_ends_bb_p (tree-cfg.c:2763) the call chain looks like this:

stmt_ends_bb_p -> is_ctrl_altering_stmt -> stmt_can_throw_internal ->
stmt_could_throw_p -> gimple_asm_volatile_p

So volatile asms are considered bb-enders, now that they have a landing
pad, which stmt_can_throw_internal checks for. I am not sure how
that works actually, do all throwing statements get a landing pad at
first, even if there is no try block? Because that looks to be the
case, I assume these are eliminated in some later pass.

Using gdb I found that the DEBUG stmt is added in rewrite_stmt
(tree-into-ssa.c:1417) which does so without considering if the bb has
an EH edge or not. How does this work for other throwing statements?

[Bug inline-asm/93981] No EH information generated for asm statements

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Some stmt-ends-BB predicates are probably off for asms.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #9 from jwjagersma at gmail dot com ---
ICE can be replicated with:

```
$ ./cc1plus -O -g -fnon-call-exceptions -I../../gcc/libgcc
../../gcc/libgcc/config/i386/sfp-exceptions.c
 void __sfp_handle_exceptions(int)
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>  
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
  107 | }
  | ^
# VUSE <.MEM_31>
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
# VUSE <.MEM_46>
__asm__ __volatile__("fdivs %1" : "=t" f_47 : "m" g, "0" f_45);
during GIMPLE pass: ssa
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: internal compiler error:
verify_gimple failed
```

The error message is different but it's the same problem.
When I break there in gdb:

```
(gdb) break tree-cfg.c:5439
Breakpoint 5 at 0xf93816: file ../../gcc/gcc/tree-cfg.c, line 5439.
(gdb) r
Starting program: D:\vmshare\gcc-build\gcc\cc1plus.exe -O -g
-fnon-call-exceptions -I../../gcc/libgcc
../../gcc/libgcc/config/i386/sfp-exceptions.c
 void __sfp_handle_exceptions(int)
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>  
Breakpoint 5, verify_gimple_in_cfg (fn=0x3b9e10b8,
verify_nothrow=verify_nothrow@entry=true) at ../../gcc/gcc/tree-cfg.c:5439
warning: Source file is more recent than executable.
5439  error ("statement marked for throw in middle of
block");
=> 0x00f93816 : 48 8d
0d 83 44 1c 01learcx,[rip+0x11c4483]#0x2157ca0 <(anonymous
namespace)::pass_data_call_cdce+14848>
   0x00f9381d : e8 86
00 de 00  call   0x1d738a8 
(gdb) pp bb
 :
# DEBUG BEGIN_STMT
f_30 = 1.0e+0;
# DEBUG f => f_30
g = 0.0;
# DEBUG BEGIN_STMT
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);
# DEBUG f => f_32

(gdb) c
Continuing.

../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
  107 | }
  | ^
# VUSE <.MEM_31>
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);

Breakpoint 5, verify_gimple_in_cfg (fn=0x3b9e10b8,
verify_nothrow=verify_nothrow@entry=true) at ../../gcc/gcc/tree-cfg.c:5439
5439  error ("statement marked for throw in middle of
block");
=> 0x00f93816 : 48 8d
0d 83 44 1c 01learcx,[rip+0x11c4483]#0x2157ca0 <(anonymous
namespace)::pass_data_call_cdce+14848>
   0x00f9381d : e8 86
00 de 00  call   0x1d738a8 
(gdb) pp bb
 :
# DEBUG BEGIN_STMT
f_45 = 1.0e+0;
# DEBUG f => f_45
g = 3.0e+0;
# DEBUG BEGIN_STMT
__asm__ __volatile__("fdivs %1" : "=t" f_47 : "m" g, "0" f_45);
# DEBUG f => f_47
```

So the problem is that DEBUG stmts are inserted after a throwing asm.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #8 from jwjagersma at gmail dot com ---
(In reply to Segher Boessenkool from comment #7)
> Ah right, only for -fnon-call-exceptions, I missed that; that is implied
> by stmt_can_throw_internal.
> 
> Why only volatile memory operands, btw?  Can't *all* memory accesses throw?

Memory access from a known valid pointer (eg. stack variables) can
reasonably be expected not to throw. So I didn't mean 'volatile' in the
literal sense but more in general, pointers that cannot be know to be
valid at compile-time.

> Is that handled somewhere else, or does it need special-casing for asm?

For general memory access I think this is checked in tree_could_trap_p.
The case for ASM_EXPR there would need to be expanded to check if any
of its operands could trap.

> Please use trunk ("master") for development, not an older release?

I was having trouble building a native (mingw-w64) compiler from git,
so I tried using 9.2.0 sources. I'm working on trunk now using an
Ubuntu VM.

> I would think the problem here is caused by your modifications to tree-eh.c,
> but that is not based on understanding this code at all ;-)

To me it seems that some part of the code does not realize that a
throwing asm must be kept at a bb boundary, and inserts statements
after it. That would need to be patched too, if I could find where that
happens.

[Bug inline-asm/93981] No EH information generated for asm statements

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to jwjagersma from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > Pretending any asm can throw would be a pretty serious code degradation.
> > 
> > Any asm that is not volatile cannot throw (and be correct code).  But
> > most volatile asm in the wild can never throw, either.
> 
> The intention is to only produce EH info for volatile asms, and only if
> -fnon-call-exceptions is given. Asms that take volatile memory operands
> should be covered too.

Ah right, only for -fnon-call-exceptions, I missed that; that is implied
by stmt_can_throw_internal.

Why only volatile memory operands, btw?  Can't *all* memory accesses throw?

Is that handled somewhere else, or does it need special-casing for asm?

> Do note that the proposed patch is still incomplete, I ran into an ICE
> while building libgcc with -fnon-call-exceptions:
> 
> ```
> during GIMPLE pass: ehcleanup
> ../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c: In function
> '__sfp_handle_exceptions':
> ../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c:107:1: internal
> compiler error: in mark_reachable_handlers, at tree-eh.c:3929
>   107 | }
>   | ^
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> ```
> 
> However I am not knowledgable enough about gcc's inner workings to know
> what exactly is missing. I'm hoping someone can help me out with this.

Please use trunk ("master") for development, not an older release?

I would think the problem here is caused by your modifications to tree-eh.c,
but that is not based on understanding this code at all ;-)

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

jwjagersma at gmail dot com changed:

   What|Removed |Added

  Attachment #47936|0   |1
is obsolete||

--- Comment #6 from jwjagersma at gmail dot com ---
Created attachment 47941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47941=edit
patch v2

Small change; only call make_eh_edges for asm statements if the asm
could throw (is volatile).
This does not solve the ICE however, which is caused by a throwing
statement that appears before the end of a basic block. It seems that,
at some point, extra statements are added after the asm in a bb? But I
can't find where that happens.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #5 from jwjagersma at gmail dot com ---
(In reply to Segher Boessenkool from comment #4)
> Pretending any asm can throw would be a pretty serious code degradation.
> 
> Any asm that is not volatile cannot throw (and be correct code).  But
> most volatile asm in the wild can never throw, either.

The intention is to only produce EH info for volatile asms, and only if
-fnon-call-exceptions is given. Asms that take volatile memory operands
should be covered too. There are multiple instances in the gcc code
that suggest this should be possible, but it seems it was never
implemented fully. For example this comment in stmt_could_throw_p:

```
/* The only statements that can throw an exception are assignments,
 conditionals, calls, resx, and asms.  */
```

And the fact that tree_could_trap_p, stmt_could_throw_p, may_trap_p_1
have cases that return true for asm.

Do note that the proposed patch is still incomplete, I ran into an ICE
while building libgcc with -fnon-call-exceptions:

```
during GIMPLE pass: ehcleanup
../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c:107:1: internal
compiler error: in mark_reachable_handlers, at tree-eh.c:3929
  107 | }
  | ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

However I am not knowledgable enough about gcc's inner workings to know
what exactly is missing. I'm hoping someone can help me out with this.

[Bug inline-asm/93981] No EH information generated for asm statements

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Pretending any asm can throw would be a pretty serious code degradation.

Any asm that is not volatile cannot throw (and be correct code).  But
most volatile asm in the wild can never throw, either.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #3 from jwjagersma at gmail dot com ---
I don't think it needs to. The user can do this manually with .cfi directives.

[Bug inline-asm/93981] No EH information generated for asm statements

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
How do you propose the compiler can generate accurate asynchronous unwind
info for random inline assembler?  (Answer: that is impossible).

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #1 from jwjagersma at gmail dot com ---
Created attachment 47936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47936=edit
proposed patch