On 04/02/14 11:40, Joern Rennecke wrote:
On 2 April 2014 17:34, Joern Rennecke wrote:
Hmm, the sanity check in new_seginfo caused a boostrap failure
building libjava on x86.
There was a block with CODE_LABEL as basic block head, otherwise empty.
I've added the testcase - and a bit more detail
> I've added the testcase - and a bit more detail on this issue - in the PR.
>
> I've attached an updated patch, which skips past the CODE_LABEL.
> And this one bootstraps on i686-pc-linuc-gnu.
OK for stage 1 modulo the typo ("an" instead of "en") in a comment.
--
Eric Botcazou
On 2 April 2014 17:34, Joern Rennecke wrote:
> Hmm, the sanity check in new_seginfo caused a boostrap failure
> building libjava on x86.
> There was a block with CODE_LABEL as basic block head, otherwise empty.
I've added the testcase - and a bit more detail on this issue - in the PR.
I've attac
Hmm, the sanity check in new_seginfo caused a boostrap failure
building libjava on x86.
There was a block with CODE_LABEL as basic block head, otherwise empty.
On 28 March 2014 10:20, Eric Botcazou wrote:
>> However, the first call is for blocks with incoming abnormal edges.
>> If these are empty, the change as I wrote it yesterday is fine, but not
>> when they are non-empty; in that case, we should indeed insert before the
>> first instruction in that b
> However, the first call is for blocks with incoming abnormal edges.
> If these are empty, the change as I wrote it yesterday is fine, but not
> when they are non-empty; in that case, we should indeed insert before the
> first instruction in that block.
OK, so the issue is specific to empty basic
On 26 March 2014 12:35, Joern Rennecke wrote:
> bootstrapped on i686-pc-linux-gnu, regtest in progress.
Passed now.
On 26 March 2014 08:15, Eric Botcazou wrote:
>> As described in the PR, this patch fixes a wrong-code bug by making the
>> order of emitted mode switching instructions more consistet & predictable.
>
> I don't understand this change (but I'm not a specialist of mode switching):
> currently the mod
> As described in the PR, this patch fixes a wrong-code bug by making the
> order of emitted mode switching instructions more consistet & predictable.
I don't understand this change (but I'm not a specialist of mode switching):
currently the mode setting sequence is always emitted before the insn
