This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Patch review - any way to expedite?
- To: geoffk at geoffk dot org (Geoff Keating)
- Subject: Re: Patch review - any way to expedite?
- From: Toshi Morita <tm2 at best dot com>
- Date: Tue, 6 Mar 2001 12:24:56 -0800 (PST)
- Cc: gcc-bugs at gcc dot gnu dot org
Geoffrey Keating <geoffk@geoffk.org> wrote:
> Toshi Morita <tm2@best.com> writes:
>
> > Is there any additional information I can supply to expediate the
> > acceptance of the patch I mentioned in these messages?
> >
> > http://gcc.gnu.org/ml/gcc-bugs/2001-02/msg00658.html
> > http://gcc.gnu.org/ml/gcc-bugs/2001-02/msg00648.html
> >
> > The patch seems fairly simple, and I'd like to see it included
> > in both gcc-2.95.3 and gcc-3.0 as it's causing severe problems
> > for some of our developers.
>
> I've looked at this patch, and it has these problems:
...
> - I don't see why the patch is correct. It seems that this is exactly
> the situation where force_to_mode should be called. Are you sure
> the bug isn't somewhere else (like in force_to_mode, or in the next
> line of code)?
I'm guessing there's a historical problem here.
It sounds as though force_to_mode was originally written to simplify
an SImode rtx that's evaluated at QImode and HImode. Over the years,
people have gradually hacked it to handle arbitrary bitmasks, but the
hacks have not been complete, so there are a few corner cases for
which it fails.
I looked around in combine for other uses of force_to_mode, and it
is called in several other places with arbitrary bitmasks which
are not a mode mask. So, it appears this usage is now accepted,
and therefore I need to fix the failure modes of force_to_mode.
I will submit another patch shortly which addresses the other
cases as well.
Toshi