This is the mail archive of the gcc-bugs@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]

Re: Patch review - any way to expedite?


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


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