clang does not match gcc/llvm-gcc in returning struct { <2 x float> }

[llvmbot]

Bugzilla Link	3448
Resolution	WONTFIX
Resolved on	Jul 29, 2010 17:59
Version	unspecified
OS	All
Reporter	LLVM Bugzilla Contributor

Extended Description

gcc/llvm-gcc return T0 in the following code in memory

ddunbar@lordcrumb:return-types$ cat test.183.a.c
cat test.183.a.c
// ../ABITestGen.py --max-args 0 -o test.183.a.c -T test.183.b.c -D test.183.driver.c --min=183 --count=1
// Generated: 2009-01-30 16:12
// Cardinality of function generator: inf
// Cardinality of type generator: inf

#include <stdio.h>

typedef float T1 attribute ((vector_size (8)));
typedef struct T0 { T1 field0; } T0;
T0 T0_retval;
T0 fn183(void) {
return T0_retval;
}

ddunbar@lordcrumb:return-types$ llvm-gcc -m64 -S -emit-llvm -o - test.183.a.c
llvm-gcc -m64 -S -emit-llvm -o - test.183.a.c
; ModuleID = 'test.183.a.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"
target triple = "x86_64-apple-darwin10.0"
%struct.T0 = type { <2 x float> }
@​T0_retval = common global %struct.T0 zeroinitializer ; <%struct.T0*> [#uses=1]

define void @​fn183(%struct.T0* noalias sret %agg.result) nounwind {
entry:
%0 = getelementptr %struct.T0* %agg.result, i32 0, i32 0 ; <<2 x float>> [#uses=1]
%1 = load <2 x float> getelementptr (%struct.T0* @​T0_retval, i32 0, i32 0), align 8 ; <<2 x float>> [#uses=1]
store <2 x float> %1, <2 x float>* %0, align 8
br label %return

return: ; preds = %entry
ret void
}

while clang returns it in registers.

In my opinion this is clearly a bug in gcc/llvm-gcc and is both totally against the spirit of the ABI (if not technically incorrect) and something which could matter in practice.

icc doesn't support <2 x float>, so no help there.

My opinion is we should understand why gcc is classifying this this way to determine if there is a good reason, and see if this has been recognized as a gcc bug upstream.

Even if we decide to be bug compatible, we need to understand how gcc is computing this because I cannot figure out what gcc is actually doing to come up with this result. It correctly passes <2 x float> as a return type, so it is not just a matter of the classification being wrong.

[llvmbot]

Chris's belief is that no one uses <2 x float>, so we should be free to treat this as a gcc/llvm-gcc bug.

[llvmbot]

Bob, I believe you fixed a case with the same structure for ARM, any chance its related?

[lattner]

"Chris's belief is that no one uses <2 x float>, so we should be free to do whatever we want" :)

[llvmbot]

The ABI is what it is, and you can't just define it to be wrong because you don't like it. Compiler writers only get to control the ABI if they're the first implementation on a system, and nobody has come up with a document defining it.

Disabling this makes the gcc compatibility testsuite considerably less useful, since this is used in many of the tests. That's the best test we have for ABI compatibility and IMO it's worth some ugliness to keep it running cleanly. Your call, though.

It may well be true that there are no users other than this testsuite, but if there are, the right thing is to imitate gcc, not try to "fix" the ABI.