[LLVMbugs] [Bug 3448] New: clang does not match gcc/llvm-gcc in returning struct { < 2 x float> }

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Fri Jan 30 16:25:52 PST 2009


           Summary: clang does not match gcc/llvm-gcc in returning struct {
                    <2 x float> }
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu

gcc/llvm-gcc return T0 in the following code in memory 
ddunbar at 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 at 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 =
target triple = "x86_64-apple-darwin10.0"
        %struct.T0 = type { <2 x float> }
@T0_retval = common global %struct.T0 zeroinitializer           ; <%struct.T0*>

define void @fn183(%struct.T0* noalias sret %agg.result) nounwind {
        %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.

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list