This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/52381] asm goto output operands diagnostics
- From: "marc.glisse at normalesup dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 27 Feb 2012 21:08:44 +0000
- Subject: [Bug c/52381] asm goto output operands diagnostics
- Auto-submitted: auto-generated
- References: <bug-52381-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381
--- Comment #2 from Marc Glisse <marc.glisse at normalesup dot org> 2012-02-27 21:08:44 UTC ---
(In reply to comment #1)
> I don't think asm goto was designed to contain more than a computed jump
> instruction. And I don't know how reliably we could allocate registers
> for outputs on the multiple outgoing edges.
>
> So, it's definitely by design.
Note that if output was only reliable on the fall-through path, it would
already be useful. It may not have to be all-edges-or-nothing (or it may have
to, I don't know enough). Although that could be confusing...
> Confirmed for the diagnostic issue.
Thanks. While I am asking, I guess that since asm goto involves control flow it
never gets reordered (as opposed to regular asm), but if someone feels like
adding a sentence with this guarantee to the doc it would be helpful too.