This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: error found in get_ivts_expr() function.


Uttam Pawar wrote:
> Hi All,
> 
> I found following code snippet in file, trunk/gcc/loop-unroll.c
> 
>    1814 /* Locate in EXPR the expression corresponding to the location
>    recorded 1815    in IVTS, and return a pointer to the RTX for this
>    location.  */ 1816
>    1817 static rtx *
>    1818 get_ivts_expr (rtx expr, struct iv_to_split *ivts)
>    1819 {
>    1820   unsigned i;
>    1821   rtx *ret = &expr;
>    1822
>    1823   for (i = 0; i < ivts->n_loc; i++)
>    1824     ret = &XEXP (*ret, ivts->loc[i]);
>    1825
>    1826   return ret;
>    1827 }
> 
> at line 1821, what is the point of taking address of a stack variable?
> and returning it, if the 'condition' in for loop fails. Is this done
> intentionally or is it an error? 

  The point is that it's only taking that pointer as the start of a linkedlist
chain down which it intends to run.  As long as the loop runs at least once,
ret will point to a real rtx somewhere in heap memory.  It would be a bug to
call get_ivts_expr if ivts->n_loc was zero, and it certainly wouldn't hurt to
add a gcc_assert() to that effect, but have you actually seen this routine
called with zero n_loc, or is it adequately guarded by the logic of the call
sites?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]