[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