On Wed, Mar 17, 2010 at 6:40 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Wed, Mar 17, 2010 at 6:28 PM, Aldy Hernandez <al...@redhat.com> wrote: >>> > ? ? rtl = DECL_RTL (decl); >>> > ? ? /* Reset DECL_RTL back, as various parts of the compiler expects >>> > ? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/ >>> > ? ? SET_DECL_RTL (decl, NULL); >>> > >>> > ... why do this in the first place? ?Is this an issue for all decls or >>> > just >>> > for DEBUG_DECLs? ?For DEBUG_DECLs you could refuse to assign >>> > alias-sets in get_alias_set by returning 0 for them. >>> >>> It seems to me that code-path is from before we forced unit-at-a-time >>> compile and now should only trigger for statics we do not emit >>> (and debug-decls?). Why not simply remove it alltogether? >> >> The testcase I'm looking at is gfortran.dg/assign.f90. No, it's not a >> DEBUG_DECL, but a VAR_DECL named __BLNK__ which looks like the blank >> common block in Fortran (and of which I know nothing about). >> >> <var_decl 0x7ffff794d140 __BLNK__ >> type <record_type 0x7ffff79493f0 SI >> size <integer_cst 0x7ffff7854988 constant 32> >> unit size <integer_cst 0x7ffff7854690 constant 4> >> align 32 symtab 0 alias set -1 canonical type 0x7ffff79493f0 >> fields <field_decl 0x7ffff7946d10 i type <integer_type >> 0x7ffff7863498 integer(kind=4)> >> decl_2 SI file a.f90 line 4 col 0 size <integer_cst >> 0x7ffff7854988 32> unit size <integer_cst 0x7ffff7854690 4> >> align 32 offset_align 128 >> offset <integer_cst 0x7ffff78546b8 constant 0> >> bit offset <integer_cst 0x7ffff7854d98 constant 0> context >> <record_type 0x7ffff79493f0>>> >> public static ignored common decl_3 SI defer-output file a.f90 line >> 5 col 0 size <integer_cst 0x7ffff7854988 32> unit size <integer_cst >> 0x7ffff7854690 4> >> align 128 context <function_decl 0x7ffff794b300 test> chain >> <var_decl 0x7ffff794d0a0 i.1>> >> >> Are you suggesting we remove the entire code path here: >> >> /* Try harder to get a rtl. If this symbol ends up not being emitted >> in the current CU, resolve_addr will remove the expression referencing >> it. */ >> >> ?? > > Yes.
That said - it would be good to have ensurance that debug info for, say, cc1files doesn't change if we remove it. Richard. > Richard. > >> Aldy >> >