[llvm-commits] CVS: llvm/test/Feature/varargs_new.ll

[Chris Lattner]

On Sat, 18 Jun 2005, Reid Spencer wrote:

> I don't think my patch is incorrect. The test case needs to test va_arg,
> not vaarg. Since it doesn't exist in anyone's release tarball, only in
> CVS, it can't hurt since they'd only pick this test up if they also
> picked up Andrew's changes.

Ok.

> I have requested that Andrew add additional tests for mixing vaarg and
> vanext with va_arg. He's already committed changes to the assembly
> reader to check those combinations.

Ok, great.

> As Andrew pointed out, an old front end could not generate this file.

My mistake :)

> The change I made is needed to make that one test correct, as Andrew has
> confirmed.  However, I agree that the auto-upgrade, validation checking
> and the test cases are insufficient. Please talk to Andrew about
> completing those tasks.

Also, all of the new regressions on X86...

-Chris

> On Sat, 2005-06-18 at 22:17 -0500, Chris Lattner wrote:
>> On Sat, 18 Jun 2005, Reid Spencer wrote:
>>
>>> Andrew,
>>> I think I fixed this, but I'd like you to verify my patch, please:
>>> http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050613/026759.html
>>
>> Reid: I think this patch should be reverted.  This regression test failing
>> indicates a bug in the auto-upgrader for .ll files.  Imagine if an old
>> LLVM front-end generated this file: now llvm-as would crash on it.
>>
>> Not only is this not acceptable from a backwards compatibility
>> perspective, llvm-as should not crash on *any* input.
>>
>> Please revert it back to the old format.  If you'd like, you can check the
>> new version in as another test to provide a sanity check for the new-style
>> varargs.
>>
>> Andrew, please fix the .ll file reader :)
>>
>> -Chris
>>
>>>> I get this with your changes:
>>>>
>>>> Running /proj/llvm/build/../llvm/test/Feature/dg.exp ...
>>>> FAIL: /proj/llvm/build/../llvm/test/Feature/varargs_new.ll:
>>>> llvm-as: /proj/llvm/build/../llvm/lib/AsmParser/llvmAsmParser.y:740:
>>>> llvm::Module* RunParser(llvm::Module*): Assertion `F->arg.llvm-as
>>>> ((anonymous namespace)::PrintStackTrace()+0x1a)[0x82c4142]
>>>> llvm-as((anonymous namespace)::SignalHandler(int)+0xd3)[0x82c440b]
>>>> /lib/tls/libc.so.6[0xaef8c8]
>>>> /lib/ld-linux.so.2[0xa587a2]
>>>> /lib/tls/libc.so.6(gsignal+0x55)[0xaef7d5]
>>>> /lib/tls/libc.so.6(abort+0xe9)[0xaf1149]
>>>> /lib/tls/libc.so.6(__assert_fail+0x101)[0xae8db1]
>>>> llvm-as[0x81c0ee0]
>>>> llvm-as(llvm::RunVMAsmParser(std::basic_string<char,
>>>> std::char_traits<char>, std::allocator<char> > const&,
>>>> _IO_FILE*)+0x73)[0]llvm-as(llvm::ParseAssemblyFile
>>>> (std::basic_string<char, std::char_traits<char>, std::allocator<char> >
>>>> const&)+0x1c1)[0x81afa4]llvm-as(main+0x5a)[0x81ab16e]
>>>> /lib/tls/libc.so.6(__libc_start_main+0xd3)[0xadce23]
>>>> llvm-as(__gxx_personality_v0+0xd1)[0x81ab091]
>>>> llvm-dis: Standard Input empty!
>>>> 0a1,3
>>>> ; ModuleID = '<stdin>'
>>>> implementation   ; Functions:
>>>>
>>>> Reid
>>>>
>>>> On Sat, 2005-06-18 at 13:30 -0500, Andrew Lenharth wrote:
>>>>>
>>>>> Changes in directory llvm/test/Feature:
>>>>>
>>>>> varargs_new.ll added (r1.1)
>>>>> ---
>>>>> Log message:
>>>>>
>>>>> new vararg test
>>>>>
>>>>> ---
>>>>> Diffs of the changes:  (+33 -0)
>>>>>
>>>>>  varargs_new.ll |   33 +++++++++++++++++++++++++++++++++
>>>>>  1 files changed, 33 insertions(+)
>>>>>
>>>>>
>>>>> Index: llvm/test/Feature/varargs_new.ll
>>>>> diff -c /dev/null llvm/test/Feature/varargs_new.ll:1.1
>>>>> *** /dev/null	Sat Jun 18 13:30:47 2005
>>>>> --- llvm/test/Feature/varargs_new.ll	Sat Jun 18 13:30:37 2005
>>>>> ***************
>>>>> *** 0 ****
>>>>> --- 1,33 ----
>>>>> + ; RUN: llvm-as %s -o - | llvm-dis > %t1.ll
>>>>> + ; RUN: llvm-as %t1.ll -o - | llvm-dis > %t2.ll
>>>>> + ; RUN: diff %t1.ll %t2.ll
>>>>> +
>>>>> + ; Demonstrate all of the variable argument handling intrinsic functions plus
>>>>> + ; the va_arg instruction.
>>>>> +
>>>>> + implementation   ; Functions:
>>>>> + declare void %llvm.va_start(sbyte**)
>>>>> + declare void %llvm.va_copy(sbyte**, sbyte*)
>>>>> + declare void %llvm.va_end(sbyte**)
>>>>> +
>>>>> + int %test(int %X, ...) {
>>>>> +         ; Allocate two va_list items.  On this target, va_list is of type sbyte*
>>>>> +         %ap = alloca sbyte*             ; <sbyte**> [#uses=4]
>>>>> +         %aq = alloca sbyte*             ; <sbyte**> [#uses=2]
>>>>> +
>>>>> +         ; Initialize variable argument processing
>>>>> +         call void %llvm.va_start(sbyte** %ap)
>>>>> +
>>>>> +         ; Read a single integer argument
>>>>> +         %tmp = vaarg sbyte** %ap, int           ; <int> [#uses=1]
>>>>> +
>>>>> +         ; Demonstrate usage of llvm.va_copy and llvm_va_end
>>>>> +         %apv = load sbyte** %ap         ; <sbyte*> [#uses=1]
>>>>> +         call void %llvm.va_copy(sbyte** %aq, sbyte* %apv)
>>>>> +         call void %llvm.va_end(sbyte** %aq)
>>>>> +
>>>>> +         ; Stop processing of arguments.
>>>>> +         call void %llvm.va_end(sbyte** %ap)
>>>>> +         ret int %tmp
>>>>> +
>>>>> + }
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at cs.uiuc.edu
>>>>> http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>
>> -Chris
>>
>

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/