http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-invalid-code
Priority|P3 |P5
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-03-27
CC| |ramana at gcc dot gnu.org
Summary|ICE [ARM] error: insn does |[ARM] ICE with asm ("mov
|not satisfy its constraints |...", pc)
Ever confirmed|0 |1
--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to D.Salikhov from comment #4)
> (In reply to Richard Earnshaw from comment #3)
> > > register unsigned long pc asm("pc");
> >
> > I think it's a mistake to permit this sort of construct.
> >
> > What does:
> >
> > a = pc;
> > b = a+pc;
> >
> > generate for b? Is it exactly twice a (the compiler doesn't see pc
> > changing, so is free to assume that it doesn't), just more than twice a (how
> > much more?) or just less than twice a (different scheduling)? What happens
> > if the user writes
> >
> > pc = 3; // ???
> >
> > The point is that while it might be valid to use pc in assembly
> > instructions, the constructs you get in high-level languages are essentially
> > meaningless.
>
> Well, even if I use PC incorrectly (actually I don't), it shouldn't lead to
> ICE. At least, there should be a sensible error message from compiler but
> not internal error.
>
True, the compiler shouldn't ICE, but writing an inline assembler statement of
that form, to read the value of the PC is just broken. The value of PC you read
may not be what you expect it to be and allowing such a form is just wrong. It
would be just any old PC. In a function asm ("mov ..., pc") will not give you
the same result relative to other statements in the function all the time.
>From your program it appears as though you want to check Thumbness - is a
static time answer not good enough ? You can get information that from
pre-processor macros.
Anyway, patches welcome if you want to fix it.
