This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix *two* AVR backend bugs (PR19293 + PR19329)
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Giovanni Bajo <rasky at develer dot com>, denisc at overta dot ru, Stefano Fedrigo <aleph at develer dot com>,Marek Michalkiewicz <marekm at amelek dot gda dot pl>, gcc-patches at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 24 Jan 2005 01:39:23 +0100
- Subject: Re: [PATCH] Fix *two* AVR backend bugs (PR19293 + PR19329)
- References: <BE19331D.8BD6firstname.lastname@example.org>
Paul Schlie wrote:
Bernardo Innocenti wrote:
Not sure if they can be called regressions, as no one could test with an
older version of GCC. Both are quite critical: PR19293 is an ICE, PR19329
is wrong-code, both with valid trivial input.
As a result of newly applied optimizations in 4.0, GCC now occasionally
generates shift by 0 which exposed a latent bug in avr's back-end, therefore
arguably a regression from previous behavior.
The shift by 0 slips through also in 3.4.2/3.4.3 as reported
in PR19329. I never saw out of range shifts in 3.4, so this
may be a 4.0 regression.
PR19293 and PR19329 can both be closed by applying the following
combined patch (Marek, please review it again).
Arguably, the PR referenced above associated with the middle-end now
occasionally generating a shift 0 as a result of newly applied optimizations
should remain open, as it shouldn't; although likely re-classified.
With respect to the combined patches (assuming I've merged them as
intended), it seems that sometimes the default behavior for out-of range
shifts is to either return 0, or do nothing? Would guess that the default
behavior should be at least consistent across all of the shift variant's,
as well as be consistent with the variable operand based shift operand
behavior. (minimally, likely doing nothing for out-of-range shifts, as
generating code to implement an undefined behavior may not be necessarily
I agree. For all shift patterns, we should consistently:
- return the input operand unchanged for shifts by 0;
- do the right thing for shifts between 1 and N-1;
- return 0 for out-of-range shifts;
I will prepare an updated patch.
// Bernardo Innocenti - Develer S.r.l., R&D dept.