[llvm-bugs] [Bug 32595] New: gcc-compat check wrongly complains about differing behaviour

[via llvm-bugs]

http://bugs.llvm.org/show_bug.cgi?id=32595

            Bug ID: 32595
           Summary: gcc-compat check wrongly complains about differing
                    behaviour
           Product: clang
           Version: 4.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: royger at freebsd.org
                CC: llvm-bugs at lists.llvm.org

Created attachment 18260
  --> http://bugs.llvm.org/attachment.cgi?id=18260&action=edit
Sample test case

Hello,

The attached code triggers the following clang warning:

test.c:25:16: warning: 'break' is bound to loop, GCC binds it to switch
[-Wgcc-compat]
        while (foo(++i)) {
               ^
test.c:14:9: note: expanded from macro 'foo'
        break;          \
        ^

I haven't been able to spot what this different behaviour is, I've compiled the
attached test with clang 3.8, gcc 4.6 and gcc 5.4 and the output is always the
same:

D
i: 1
D
i: 2
D
i: 3
E
END

Also, I'm not sure what clang complains about, I don't think there's any
ambiguity here, and the "break" should apply to the inner switch. Could someone
clarify what's wrong with this, and how this should be fixed?

Note that the attached test.c is a simplification of an issue seen while
building Xen, in which case using a macro makes sense [0][1].

Roger.

[0]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/dm.c;h=d72b7bd8357e9d7f37be4f3ea0d1e6eac1ab4540;hb=refs/heads/staging#l411
[1]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/asm-x86/atomic.h;h=2fbe70551898bf4e8a866d9339eaf20d91991f9b;hb=refs/heads/staging#l46

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170410/14c20a7e/attachment.html>