On Sat, Aug 18, 2012 at 12:46 AM, Eli Friedman <[email protected]> wrote: > > It looks like the call to getFirstFieldInTransparentUnion isn't in the > right place on x86-32. >
Well spotted, attached is a an updated patch with the call to
getFirstFieldInTransparentUnion moved into
X86_32ABIInfo::classifyArgumentTypeWithReg.
> I'm suspicious that ABIArgInfo::getDirect() isn't going to do the
> "right" thing in all cases (say, for example, a union with a "void*"
> and a "double"); that said, it probably doesn't in practice, given the
> expected usage of transparent_union.
>
I can't say that I'm able to think out the possible cases where it
might go wrong, I'm willing to take a look at anything you throw
at me though (if it's worth bending over backwards to handle all kinds of
possible and impossible non-real use-cases, that's another story ;)).
The void*, double union example looks like this:
$ cat transparent-union.c
typedef union {
void *a;
double b;
} ARG __attribute__ ((__transparent_union__));
void f0(ARG u);
void f1(void *a)
{
f0(a);
}
void f2(double b)
{
f0(b);
}
$ clang -O2 -c -S transparent-union.c -emit-llvm -o -
; ModuleID = 'transparent-union.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define void @f1(i8* %a) nounwind uwtable {
entry:
tail call void @f0(i8* %a) nounwind
ret void
}
declare void @f0(i8*)
define void @f2(double %b) nounwind uwtable {
entry:
%0 = bitcast double %b to i64
%1 = inttoptr i64 %0 to i8*
tail call void @f0(i8* %1) nounwind
ret void
}
Which seems OK to me.
Stefan
CodeGen_support_for_transparent_union.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
