Re: Generating RTL for function call sequences from GIMPLE

2 msg	Best of luck for GSoC 2007 participants!
4 msg	anyone using svk?
2 msg	FW: [M16C] : 20 bit data pointer
3 msg	Re: Toolchain for Maverick Crunch FPU
5 msg	Re : Problem with gcc 3.4.0 & 3.4.6 in ARM ...
4 msg	peephole patterns are not matching
2 msg	Problem with gcc 3.4.0 & 3.4.6 in ARM thumb...
5 msg	adding dependence from prefetch to load
8 msg	Recent dataflow branch SPEC2000 benchmarking
1 msg	PHI_NODE memory reduction, WAS: Re: RFC: GIMPLE...
4 msg	A microoptimization of isnegative or greatertha...
68 msg	RFC: GIMPLE tuples. Design and implementation p...
1 msg	gcc-4.1-20070409 is now available
2 msg	Re: Integer overflow in operator new. Solved? E...
14 msg	Inclusion in an official release of a new throw...

Generating RTL for function call sequences from...
\ Dave Korn (9 Apr 2007)
. \ Richard Guenther (9 Apr 2007)
. \ Richard Henderson (9 Apr 2007)
. . \ Dave Korn (9 Apr 2007)
. . . \ Richard Henderson (10 Apr 2007)

11 msg	Re: Integer overflow in operator new. Solved?
2 msg	static symbol occurs twice in the executable.
4 msg	Miscompilation...
1 msg	VCG viewer...

Subject:	Re: Generating RTL for function call sequences from GIMPLE
Group:	Gcc
From:	Richard Henderson
Date:	10 Apr 2007

On Mon, Apr 09, 2007 at 11:55:14PM +0100, Dave Korn wrote:
> Thanks, I think you're right on there. The comments on PR31136 make it
> fairly clear what's wrong; perhaps the best solution might be for
> STRIP_SIGN_NOPS to mask out the high bits when it's discarding a size-reducing
> NOP_EXPR? Or perhaps fold_unary should simplify it before passing to
> STRIP_SIGN_NOPS for minimal peturbation?

I think STRIP_NOPS, and STRIP_SIGN_NOPS, should not consider the
mode to be the same when the precision doesn't match. Indeed,
perhaps the mode is largely irrelevant, and it should only be
checking the precision....

r~