aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/validation/backend/call-variadic.c
AgeCommit message (Collapse)AuthorFilesLines
2024-01-29llvm: fix LLVM 15 deprecation warningsLuc Van Oostenryck1-12/+4
LLVM 15 switched to opaque pointers by default and no longer supports typed pointers. Remove deprecated LLVM calls and update test. Original-patch-by: Vladimir Petko <vladimir.petko@canonical.com> Signed-off-by: Luc Van Oostenryck <lucvoo@kernel.org>
2017-11-17llvm: give names easier to debugLuc Van Oostenryck1-3/+3
LLVM automatically add an numeric suffix for names automatically created. So, if intermediate names must be created for a pseudo whose name was, for example, "%R4", these new names will be "%R41", "%R42". This is quite annoying because we can't make the distinction between these names and the original names, (maybe of some other pseudos whose names were "%R41" & "%R42). Change this by adding a "." at the end of each name, as this will then allow to see what the original name was. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-17llvm: fix variadic calls with constantsLuc Van Oostenryck1-1/+0
The linearized code, sparse's IR, have no use of C's complex type system. Those types are checked in previous phases and the pseudos doesn't have a type directly attached to them as all the needed typing info info are conveyed by the instructions. In particular, PSEUDO_VAL (used for integer and address constants) are completely typeless. There is a problem with this when calling a variadic function with a constant argument as in this case there is no type in the function prototype (for the variadic part, of course) and there is no defining instructions holding the type of the argument. Fiw this by using the type of the arguments explicitly given in the OP_CALL instructions. Reported-by: Dibyendu Majumdar <mobile@majumdar.org.uk> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
2017-11-17llvm: add testcase for calling variadic functionsLuc Van Oostenryck1-0/+28
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>