aaron.ballman added a comment.
In https://reviews.llvm.org/D36208#828955, @sdardis wrote:
> I think for the interrupt attribute, it should be an error. Currently it's an
> implementation detail that it errors out in the backend but in principal it
> can be supported (I haven't gotten around to addressing it.)
For the interrupt attribute, I think it should behave the same as the other
target-specific interrupt attributes unless there's a very good reason to be
inconsistent.
> For the micromips attribute, I believe it should be an error. My rational
> there is that the user has requested something that the compiler cannot
> perform.
That's not really sufficient rationale, because the same logic can be said of
any ignored attribute. As best I can tell from the docs on this attribute, this
controls code generation to turn on or off micromips code generation, which
sounds like the code otherwise generated may still work just fine. e.g., `void
f(void) __attribute__((micromips)) {}` -- if you compile that code on a
non-MIPS target, why should it produce an error instead of merely warning the
user that the attribute is ignored?
Repository:
rL LLVM
https://reviews.llvm.org/D36208
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
