This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR30338, ICE in fold_comparison
On 12/31/06, Roger Sayle <roger@eyesopen.com> wrote:
Hi Richard,
On Sun, 31 Dec 2006, Richard Guenther wrote:
> /* Convert -1 - A to ~A. */
> if (INTEGRAL_TYPE_P (type)
> && integer_all_onesp (arg0))
> return fold_build1 (BIT_NOT_EXPR, type, arg1);
Historically, the better fix and prevalent idiom in fold-const.c would
be to use "fold_convert (type, arg1)" instead of "op1". There was a time
when "op1" couldn't be guaranteed to be of type "type" (but things are
improving), and the utility of stripping NON_LVALUE_EXPR and other junk
nodes is becoming less significant with my plans to obsolete/deprecate
that tree code (once the C front-end is actively maintained). So in the
near future, the benefits of avoiding allocating a new tree node and
leaking the old one, will probably outweigh traditional usage.
What do you think?
I think we should not introduce calls to fold_convert that, if everything
is right, is a noop. If we would want to go down that route we could
as well put fold_converts into the [fold_]buildN routines ;)
Another reason is that putting in fold_convert there may actually hide bugs.
But if we want to establish a convention inside fold for fold_converting
every argument to calls to [fold_]buildN I'm fine with that, Just we
should do it _everywhere_ then - using 'argN' in any [fold_]buildN call
is as non-obvious as using 'opN'.
Of course I'd prefer just using 'opN' or 'argN' whenever we know it
should have the correct type. (Maybe we can put asserts in fold or
enhance fold checking to verify we're not creating mismatched types
in fold)
As for stripping NON_LVALUE_EXPR, should we do so if fold is called
from the frontend? Shouldn't those nodes be removed after gimplification?
Richard.