Your change causing regressions

[Daniel Berlin]

On Tue, 25 Jun 2002, David S. Miller wrote:

>    From: "David S. Miller" <davem@redhat.com>
>    Date: Tue, 25 Jun 2002 17:48:24 -0700 (PDT)
> 
>       From: Daniel Berlin <dberlin@dberlin.org>
>       Date: Tue, 25 Jun 2002 19:07:05 -0400 (EDT)
>    
>       If it looks okay, i'll add a changelog entry and whatnot.
>    
>    Daniel, I'm doing a full regression test of your fix on sparc-linux,
>    I'll let everyone know how that goes.  It should only take an hour or
>    so with all languages (sans ADA) enabled.
>    
> The tests on sparc-linux ran OK and fixed the -Os endless compilation
> failure went away.
> 
> However, I ran an i686-linux bootstrap plus regression tests too, and
> gcc.dg/struct-by-value-1.c started to fail.  This is a new failure
> seemingly introduced by your patch.  The compiler takes a segfault
> when compiling this file with -O2.
Hmmmm.

It shouldn't, as none of the code I modified is even used at -O2.

I changed hoist_code(), which is only called from 
one_code_hoisting_pass().  one_code_hoisting_pass()  is only called from 
gcse_main, in the following block:

   /* It does not make sense to run code hoisting unless we optimizing
         for code size -- it rarely makes programs faster, and can make
         them bigger if we did partial redundancy elimination (when optimizing
         for space, we use a classic gcse algorithm instead of partial
         redundancy algorithms).  */
      if (optimize_size)
        {
          max_gcse_regno = max_reg_num ();
          alloc_gcse_mem (f);
          changed |= one_code_hoisting_pass ();
          free_gcse_mem ();

          if (max_pass_bytes < bytes_used)
            max_pass_bytes = bytes_used;
        }


So i'm at a real loss as to why it would have introduced a failure at -O2.
In fact, it provably shouldn't have.

I hope it's spurious, or else we've got misoptimization (or something) in 
stage2/3. 

I also ran it on struct-by-value-1.c, at -O2 (and -Os for good measure), 
with no such problem.

This is on a stage1 compiler (IE make cc1, not make bootstrap),  however, 
so bad code generation in stage2 and stage3 could be screwing us.

I reproduced the original f90-intrinsic-bit.f on a stage1 compiler, and i 
would expect any real bug in the change itself would show  
up on the stage1 compiler as well.
--Dan