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

Re: [PATCH] Reject pre/post inc/decrement in "m" input operands (PR middle-end/43690)


On Fri, Nov 05, 2010 at 06:55:00AM -0400, Paul Koning wrote:
> > On Thu, Nov 4, 2010 at 9:12 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> >> Hi!
> >> 
> >> We currently ICE in various ways when "m" operand has pre or post
> >> increment/decrement.  We reject "m" (x + 1) and & which is roughly
> >> what "m" does doesn't accept x++ or ++x either, so I think rejecting
> >> it is the best thing to do.  The ICEs are because the FEs
> >> don't mark the operand addressable, so we get invalid gimple.
> >> 
> >> In theory for POST increment/decrement we could instead just
> >> mark their operand addressable, but for PRE increment/decrement
> >> we still ICE with that badly.
> >> 
> >> What do you think about this?
> >> Bootstrapped/regtested on x86_64-linux and i686-linux as usual.
> > 
> > I think it's a reasonable thing to do.  We should have discovered
> > all code that does this by now (I guess it just worked pre-tree-ssa?)
> 
> I'm puzzled.  Does this change make "m" operands reject things like x++ as
> "not addressable even on targets that have such addressing modes?

"m" (x++) has nothing to do with incdec addressing modes.  It is not
the address that is being post incremented, it is the value.

"m" (*x++)
is of course accepted (but won't use incdec addressing mode in current gcc
either, you need for that "m<>" (*x++).

	Jakub


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