Re: [PATCH,fortran] Reap dead code

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Wed, Oct 26, 2011 at 09:55:09PM +0200, Paul Richard Thomas wrote:
> Dear Steve,
> 
> Reaping implies that there is something about it that you want to keep
> :-)  Surely, weeding or herbicide spraying is better than reaping?

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

> 
> 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