[llvm] r223193 - Emit the entry block first and the exit block second, then all the blocks in between afterwards. This is what gcc always does, and some out of tree tools depend on that.
mail at justinbogner.com
Mon Mar 16 15:34:11 PDT 2015
Justin Bogner <mail at justinbogner.com> writes:
> Nick Lewycky <nicholas at mxc.ca> writes:
>> Justin Bogner wrote:
>>> Nick Lewycky<nicholas at mxc.ca> writes:
>>>> Author: nicholas
>>>> Date: Tue Dec 2 20:45:01 2014
>>>> New Revision: 223193
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=223193&view=rev
>>>> Emit the entry block first and the exit block second, then all the
>>>> blocks in between afterwards. This is what gcc always does, and some
>>>> out of tree tools depend on that.
>>> Sorry I didn't notice this earlier, but there's something funny going on
>>> here. This makes llvm-cov choke on a simple hello world, as it assumes
>>> that "The last block is always reserved for exit block".
>>> Now, if gcc always emits the exit block second, this assumption makes no
>>> sense, in which case I'll fix up llvm-cov. However, it looks like this
>>> assumption did make sense back in the gcov-4.2 era, which warns that
>>> each function "has arcs from exit block" with this change. I'm guessing
>>> this behaviour changed (from "last" to "second") in some update of the
>>> format, and that we should not be doing this when emitting a format
>>> version of "402*".
>>> Do you have any insight into this?
>> I don't, besides noticing that it comes second instead of last in gcc
>> 4.7. If gcc 4.2 put is last, then we'll need a flag to switch between
>> the two behaviours.
> Yep, this behaviour is definitely incompatible with the 402* format. We
> need to put this behind a flag and emit a newer version (408*, I think -
> this behaviour doesn't seem to happen with 4.4 or 4.7) when we do this
> so that llvm-cov doesn't try to read it as the old format. We'll also
> want to leave the default on Darwin to emit the 402* format.
> Can you do this? I'm not sure what the appropriate name for the flag is
> and can't really validate that what we're outputting is correct for a
> 408* version.
Ping. We should really fix this soon, since we're generating gcov output
that our own llvm-cov can't even read. See also pr22436.
More information about the llvm-commits