[llvm-commits] [llvm-gcc-4.2] r80850 - in /llvm-gcc-4.2/tags/Apple/llvmgcc42-2306/gcc: except.c llvm-convert.cpp

[Duncan Sands]

Hi Eric,

> Found one myself in the project I'm trying to get working. Assert in 
> debug mode with the catch blocks lost/added weren't equal. The generated 
> llvm looks fine in practice but the invoke goes to an empty block that 
> forwards to the unwind block.

you get this failure if the selectors are not in the landing pad, and
not in the successor of the landing pad.  Then codegen doesn't know
which invokes to associate them with.  To fix this, codegen needs to
start from each landing pad and look for all selector calls that use
its exception value (= result of eh.exception call), so it can associate
its catches with the invoke.  However because dwarf catches are ordered,
it is not enough to find the selector calls, you also have to order them
correctly, which in theory is hard because there might be all kinds of
control flow logic between the landing pad and the selector calls,
making it tricky to know which one comes first.  In practice however the
output of llvm-gcc is very regular, and probably most real cases can be
handled fairly easily.

For the moment, I think you should just turn off inlining through
invoke calls.

In the long term, I think lists of globals to catch should be attached
directly to the invoke using some kind of metadata, rather than using
eh.selector calls.  Then everything can be handled trivially (see later
email).

Ciao,

Duncan.