Hi!
Here is a small piece of C code what compiles with gcc but clang asserts during codegen.
I’ve used clang svn version: revision 51478
I’ve found this bug during compiling blender open source modeler (blender.org).
Cheers,
Csaba
Hi! (now i send the email with code 
)
Here is a small piece of C code what compiles with gcc but clang asserts during codegen.
I’ve used clang svn version: revision 51478
I’ve found this bug during compiling blender open source modeler (blender.org).
Cheers,
Csaba
buggy code:
extern double g ();
void f()
{
double t, g();
t = g();
}
I'm pretty sure it's an issue with merging function decls. The issue
is that t essentially disappears from the AST (try running this code
through -ast-dump to see what I mean), so CodeGen ends up seeing a
reference to an undeclared variable. Declaration merging and whatnot
is tricky code that I never really studied closely, though, so it's
not obvious why this is happening.
-Eli
One approach would be to have two predicates: one for "real i-c-e" and one for "gcc i-c-e". If it is a GCC ICE but not a standards one, accept but emit a diagnostic? In this case, it is pretty easy, in other cases (such as when dealing with ?: promotion rules) it is much harder.
I don't know if it is worth it though. The set of stuff accepted by GCC is, uh, "poorly defined".
-Chris
Wrong thread?
In reply to what you're saying though, I think it isn't worth it
unless it turns out to be a common construct, because it's difficult
to contain all the effects of deciding something is a "gcc i-c-e";
this case is easy, but stuff starts getting more complicated fast.
Besides, once/if we start properly supporting FP rounding modes, we
can actually end up with wrong code.
-Eli
One approach would be to have two predicates: one for "real i-c-e" and one
for "gcc i-c-e". If it is a GCC ICE but not a standards one, accept but
emit a diagnostic? In this case, it is pretty easy, in other cases (such as
when dealing with ?: promotion rules) it is much harder.I don't know if it is worth it though. The set of stuff accepted by GCC is,
uh, "poorly defined".-Chris
Wrong thread?
Hrm, yeah, how about that. Email is hard for me, very technical and stuff.
In reply to what you're saying though, I think it isn't worth it
unless it turns out to be a common construct, because it's difficult
to contain all the effects of deciding something is a "gcc i-c-e";
this case is easy, but stuff starts getting more complicated fast.
Besides, once/if we start properly supporting FP rounding modes, we
can actually end up with wrong code.
Ok.
-Chris