From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17150 invoked by alias); 27 Mar 2014 17:37:25 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 16650 invoked by uid 48); 27 Mar 2014 17:37:19 -0000 From: "ramana at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/60606] [ARM] ICE with asm ("mov ...", pc) Date: Thu, 27 Mar 2014 17:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.3 X-Bugzilla-Keywords: ice-on-invalid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: ramana at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords priority bug_status cf_reconfirmed_on cc short_desc everconfirmed Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-03/txt/msg02523.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606 Ramana Radhakrishnan 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 --- (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.