Re: RFA: Fix PR 20413

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 11 Apr 2005, Joern RENNECKE wrote:
> 2005-04-11  J"orn Rennecke <joern.rennecke@st.com>
>	    Stephen Clarke <stevec@superh.com>
>
>	* cfgrtl.c (redirect_edge_and_branch): Use Pmode instead of
>	VOIDmode for LABEL_REF.
>	* final.c (shorten_branches): Likewise.
>	* jump.c (mark_all_labels, redirect_exp_1): Likewise.
>	* loop.c (reg_dead_after_loop): Likewise.
>	* varasm.c (decode_addr_const): Likewise.

Unfortunately PR rtl-optimization/20413 doesn't give a testcase to
backup it's claims of being an ICE-on-valid or even it's missed
optimization status.  The reason why this is important is that the
current RTL documentation in rtl.texi implies that the mode of a
LABEL_REF should always be VOIDmode:

Compare:
>> @findex symbol_ref
>> @item (symbol_ref:@var{mode} @var{symbol})
>> Represents the value of an assembler label for data.
>>
>> @findex label_ref
>> @item (label_ref @var{label})
>> Represents the value of an assembler label for code.

Where the description of symbol_ref includes an explicit mode, and
the description of label_ref doesn't.  Even if it were decided that
LABEL_REFs should always be Pmode, the documentation would need to
be updated to reflect that.

The distinction is that symbol refs may refer to different types
of symbol, local/global, exported, static, different sections, etc...
which may require that they are accessed in different modes.  Labels
on the other hand are local to the current function and would always
be accessed with the same mode through control flow instructions.


However, far more likely is that there are bugs/misunderstandings
elsewhere in the compiler that are checking the mode of a LABEL_REF.
Just a wild guess, but I suspect one of these places is the SH
back-end?

Without a testcase, or a pointer to the source that expects modes
on LABEL_REFs, it's impossible to say which is at fault and whether
it would be reasonable to change the long time definition of the
RTX code (potentially breaking other targets that may rely on the
documented behaviour).


Finally, I agree completely with Giovanni Bajo's comments that
whatever the outcome, we should consider removing the mode argument
from gen_rtx_LABEL_REF, if appropriate, to prevent these misunderstandings
in the future.

Note: that this blocks merging of the sh-elf-4_1-branch, which has
had this potentially incorrect patch applied, until the issue is
resolved.

Roger
--