[llvm-bugs] [Bug 40666] New: Clangs 4 through 7 panic on non-const expressions inside the ctrl-expr of _Generic's where only the final value needs to be constant

via llvm-bugs llvm-bugs at lists.llvm.org
Fri Feb 8 11:43:49 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=40666

            Bug ID: 40666
           Summary: Clangs 4 through 7 panic on non-const expressions
                    inside the ctrl-expr of _Generic's where only the
                    final value needs to be constant
           Product: clang
           Version: 4.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: pskocik at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

The code below demonstrates the problem:

#define MC_cexpr_eh_(X) _Generic((1? (void *) ((!!(X))*0ll) : (int *) 0), int*:
1, void*: 0)
extern int i;
#if 1 //FAILS:
_Bool const fail0 = MC_cexpr_eh_((int){i});
void fail() { enum { fail1 = MC_cexpr_eh_( (int){i}) }; }
#endif

//THESE WORK:
void ok()
{
        enum { ok0 = MC_cexpr_eh_( i ) };
        const _Bool ok1 = MC_cexpr_eh_( (int){i});
        static _Bool const ok2 = MC_cexpr_eh_((int){i});
}

I don't think the comptime (non)constness  of the controlling expression of a
_Generic should ever matter.

gcc and tinycc are doing this right.

-- 
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/20190208/47a87975/attachment.html>


More information about the llvm-bugs mailing list