[PATCH,fortran] Reap dead code

[Paul Richard Thomas]

Steve,

> Surely, you have Halloween across the Pond, ie., the Grim Reaper. :-)

And what, pray, does the Grim Reaper hold???

The patch is OK.

Thanks

Paul

>
>>
>> On Wed, Oct 26, 2011 at 7:53 PM, Steve Kargl
>> <sgk@troutmask.apl.washington.edu> wrote:
>> > On Sat, Oct 22, 2011 at 01:16:14PM -0700, Steve Kargl wrote:
>> >> The attach patch reaps some code that is now dead
>>
>> I am sure that you are right but could you confirm that is is because
>> of previous patches?
>
> The tests in simplify.c can never be triggered because these
> are already caught in check.c.  Consider,
>
>  program a
>  integer i
>  i = 12234
>  print *, ibclr(i, 123)
>  end program a
>
> laptop:kargl[207] gfc4x -o z a.f90
> a.f90:4.20:
>
>  print *, ibclr(i, 123)
>                    1
> Error: 'pos' at (1) must be less than BIT_SIZE('i')
>
> This error message comes from check.c(gfc_check_bitfcn), and
> it is the error message I get with 4.5.x without my dead.diff
> patch.  The relevant lines of code in gfc_check_bitfcn are
>
>  if (nonnegative_check ("pos", pos) == FAILURE)
>    return FAILURE;
>
>  if (less_than_bitsize1 ("i", i, "pos", pos, false) == FAILURE)
>    return FAILURE;
>
> This is the chunk of code I removed from simplify.c(gfc_simplify_ibclr)
>
> -  if (gfc_extract_int (y, &pos) != NULL || pos < 0)
> -    {
> -      gfc_error ("Invalid second argument of IBCLR at %L", &y->where);
> -      return &gfc_bad_expr;
> -    }
> +  gfc_extract_int (y, &pos);
>
> The if-statement can never be true.  In fact, for the above Fortran
> code, gfc_simplify_ibclr is never executed beyonds its first line:
>
>  if (x->expr_type != EXPR_CONSTANT || y->expr_type != EXPR_CONSTANT)
>    return NULL;
>
> Here, x is 'i' from the program and y is 'pos'.  So, both arguments
> to ibclr must be constant for the code that I removed to even have
> a chance to execute.
>
> The other chunks of code I removed are similar in nature.  The
> checking done by code in check.c makes the checking done in
> simplify.c useless bloat.  I'm just cleaning up the mess left
> behind the person, who introduced gfc_check_bitfcn.
>
> laptop:kargl[217] svn log -r 160492 check.c |more
> ------------------------------------------------------------------------
> r160492 | kargl | 2010-06-09 09:24:59 -0700 (Wed, 09 Jun 2010) | 23 lines
>
> 2010-06-09  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>        * fortran/intrinsic.c (add_functions): Change gfc_check_btest,
>        gfc_check_ibclr, and gfc_check_ibset to gfc_check_bitfcn.
>        * fortran/intrinsic.h: Remove prototypes for gfc_check_btest,
>        gfc_check_ibclr, and gfc_check_ibset.  Add prototype for
>        gfc_check_bitfcn.
>        * fortran/check.c (nonnegative_check, less_than_bitsize1,
>        less_than_bitsize2): New functions.
>        (gfc_check_btest): Renamed to gfc_check_bitfcn.  Use
>        nonnegative_check and less_than_bitsize1.
>        (gfc_check_ibclr, gfc_check_ibset): Removed.
>        (gfc_check_ibits,gfc_check_mvbits): Use nonnegative_check and
>        less_than_bitsize1.
>
>> >> due to my recent changes for ishftc in check.c.
>> >> Regression tested on i686-*-freebsd.
>>
>> It looks to be OK, subject to the above, and is, I would guess,
>> "obvious" in any case.
>>
>> Thanks for the patch
>
> My regression test on i686-*-freebsd.
>
>                === gfortran Summary ===
>
> # of expected passes            39552
> # of unexpected failures        8
> # of unexpected successes       16
> # of expected failures          41
> # of unsupported tests          212
>
> The 8 failures are due to entry_4.f90 and select_type_12.f03.
>
> --
> Steve
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy