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]
Other format: [Raw text]

[Bug middle-end/29519] [4.2 Regression] Bad code on MIPS with -fnon-call-exceptions



------- Comment #5 from rsandifo at gcc dot gnu dot org  2006-10-21 18:44 -------
The wrapping check was added by:

    http://gcc.gnu.org/ml/gcc-patches/2002-10/msg00360.html

I think this check is wrong for exactly the reason seen here;
without type information, and without context, there's no
guarantee that the PLUS itself is a pointer, or indeed that
the constant was originally positive.  We could only do
something like this if we know the address is being
dereferenced -- but in that case, we generally care about
whether the value might trap, not whether it's zero
(and rtlanal.c rightly says that (plus reg (const_int ...))
can trap).

For example, something like:

    (uintptr_t) foo == 0x90000000

could legitimately be implemented as:

    (eq (plus foo (const_int 0x70000000)) (const_int 0))

And AIUI, gcc allows things like:

    (uintptr_t) foo - 0x90000000

and allows the result to be zero (assuming the result is not
dereferenced).

All uses of nonzero_address_p appear to using it for
general rtx simplification, i.e. in cases where the value
is not known to be a pointer.  So I think this check should
just be removed.

Hopefully the check is less important now than it was when
it was originally committed.  This sort of optimisation can
be done at the tree level instead.

Richard


-- 

rsandifo at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29519


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