Displaying 6 results from an estimated 6 matches for "altrottstrass".
Did you mean:
altrottstrasse
2009 Oct 30
2
[LLVMdev] llvm-gcc-4.2 RELEASE_26 bootstrap failure on Solaris/SPARC - unhandled REAL_TYPE during compilation of '__powitf2'
...#39;,
so I wonder what needs to be done in order to get LLVM to produce
code for 'TREE_CODE(type) == REAL_TYPE' in the 'HandleArgument' function.
Does anyone have an idea? And why does this only happen on SPARC?
Regards,
Juergen
--
Sun Microsystems GmbH Juergen Zimmermann
Altrottstrasse 31 ISV Engineering EMEA, Technical Lead for SAP
69190 Walldorf Phone: +49 (0)6227 356 256
Germany Fax: +49 (0)6227 356 222
mailto:Juergen.Zimmermann at Sun.COM
Sun Microsystems GmbH
Altrottstrasse 31, 69190 Walldorf
Sitz der Gesellschaft: Sonnenallee 1, D-85...
2009 Oct 30
2
[LLVMdev] llvm-gcc-4.2 RELEASE_26 bootstrap failure on Solaris/SPARC - unhandled REAL_TYPE during compilation of '__powitf2'
...= REAL_TYPE' in the 'HandleArgument' function.
>>
>>
>> Does anyone have an idea? And why does this only happen on SPARC?
> What is the value of "Ty" in your case? Just do "call Ty->dump()".
>
--
Sun Microsystems GmbH Juergen Zimmermann
Altrottstrasse 31 ISV Engineering EMEA, Technical Lead for SAP
69190 Walldorf Phone: +49 (0)6227 356 256
Germany Fax: +49 (0)6227 356 222
mailto:Juergen.Zimmermann at Sun.COM
Sun Microsystems GmbH
Altrottstrasse 31, 69190 Walldorf
Sitz der Gesellschaft: Sonnenallee 1, D-85...
2009 Oct 30
0
[LLVMdev] llvm-gcc-4.2 RELEASE_26 bootstrap failure on Solaris/SPARC - unhandled REAL_TYPE during compilation of '__powitf2'
Hello, Juergen
> With the full patch, I get the assertion of the 'unhandled REAL_TYPE!',
> so I wonder what needs to be done in order to get LLVM to produce
> code for 'TREE_CODE(type) == REAL_TYPE' in the 'HandleArgument' function.
>
>
> Does anyone have an idea? And why does this only happen on SPARC?
What is the value of "Ty" in your case?
2009 Dec 10
2
[LLVMdev] How to check for "SPARC code generation" in MachineBasicBlock.cpp?
...ikely) the SPARC code generator.
For now, I'm looking for a way to determine within that function
if LLVM is supposed to generate code for SPARC and then
implement the logic that's needed.
Any 'quick' suggestions?
Regards,
Juergen
--
Sun Microsystems GmbH Juergen Zimmermann
Altrottstrasse 31 ISV Engineering EMEA, Technical Lead for SAP
69190 Walldorf Phone: +49 (0)6227 356 256
Germany Fax: +49 (0)6227 356 222
mailto:Juergen.Zimmermann at Sun.COM
Sun Microsystems GmbH
Altrottstrasse 31, 69190 Walldorf
Sitz der Gesellschaft: Sonnenallee 1, D-85...
2009 Nov 02
1
[LLVMdev] llvm-gcc-4.2 RELEASE_26 bootstrap failure on Solaris/SPARC - unhandled REAL_TYPE during compilation of '__powitf2'
...128bit fp into normal first-class type (grep for TARGET_ZARCH
> into llvm-types.cpp, where this mapping is done for s390x), but then
> you will need to implement all codegen for 128-bit fp, since sparc
> backend is currently really weak.
>
--
Sun Microsystems GmbH Juergen Zimmermann
Altrottstrasse 31 ISV Engineering EMEA, Technical Lead for SAP
69190 Walldorf Phone: +49 (0)6227 356 256
Germany Fax: +49 (0)6227 356 222
mailto:Juergen.Zimmermann at Sun.COM
Sun Microsystems GmbH
Altrottstrasse 31, 69190 Walldorf
Sitz der Gesellschaft: Sonnenallee 1, D-85...
2009 Oct 30
0
[LLVMdev] llvm-gcc-4.2 RELEASE_26 bootstrap failure on Solaris/SPARC - unhandled REAL_TYPE during compilation of '__powitf2'
Hello, Juergen
> Ty->dump() prints "{double, double}" in the failing case (just before my
> introduced assert).
The answer is simple. The code in question contains extended IEEE FP
argument / return type (aka 'long double'). By default it's lowered
into struct {double, double} as you already saw and sparc currently
does not provide any argument layout hooks.
There