PATCH: error on code that redeclares with an __asm__ label after the first ODR use

[Nick Lewycky via cfe-commits]

On 10 December 2015 at 17:42, Gao, Yunzhong <
yunzhong_gao at playstation.sony.com> wrote:

> Out of curiosity, is the following test case possible too?
>
>
>
> void f();
>
> void g() __asm__(“real_g”); // rename g into real_g.
>
>
>
> void f() {
>
>   g(); // this would actually be calling real_g()
>
> }
>
> void real_g() __asm__("gold");  // re-declaring real_g() into gold <--
> should this be an error too?
>

I can't see any reason why not. Both clang and gcc will emit "real_g" here
instead of "gold", but changing the asm label in a program is highly
dubious. I added an error for this too.

Thanks!


> *From:* cfe-commits [mailto:cfe-commits-bounces at lists.llvm.org] *On
> Behalf Of *Nick Lewycky via cfe-commits
> *Sent:* Thursday, December 10, 2015 3:15 PM
> *To:* Clang Commits
> *Subject:* PATCH: error on code that redeclares with an __asm__ label
> after the first ODR use
>
>
>
> PR22830 shows a case where some code was adding an __asm__ label after the
> first use of a function. GCC and Clang diverged on this code, GCC emitting
> the name in the last __asm__ label for all uses while clang would switch in
> the middle of the TU as the redeclaration was parsed. The attached patch
> detects this case and issues an error on such a redeclaration. If this
> breaks real code, we can turn it down to a warning.
>
>
>
> Please review!
>
>
>
> Nick
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151211/107ca064/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr22830-2.patch
Type: application/octet-stream
Size: 2826 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151211/107ca064/attachment-0001.obj>