Menu
▾
▴
Re: [avr-llvm-devel] Regression tests
|
From: Nicklas Bo J. <nbj...@gm...> - 2012-05-25 08:23:36
|
Is it more clear now? I think those tests have become too complicated and
we should delete them for now.
Also I'm seeing some wierd code for calling. I've attached a short piece of
code showing what I think could be a bug. After call foo, we are for
example doing "adiw r25:r24, 8", but the result from the call is stored in
these registers. That is not optimal. Also the addition with 5 never
happens. Is this because the function(calli64_stack) only returns void?
On Fri, May 25, 2012 at 12:06 AM, Nicklas Bo Jensen <nbj...@gm...>wrote:
> Ah i see. I had only implemented correct behaviour in return void, as we
> had not decided on a test style yet, meaning that those tests for returning
> the first argument were not testing anything. I have included a new version
> implementing the check at all cases.
>
> The regex is not needed in other tests, where we are not using CHECK-NEXT,
> as the comments are simply ignored here. When only using CHECK, there can
> be all kind of things between two CHECK's.
>
> On Thu, May 24, 2012 at 11:51 PM, Borja Ferrer <bor...@gm...>wrote:
>
>> Yes I understood it xD
>> What confuses me is that the first CHECK which checks the function name
>> label has a regex (the return_void: line), while the rest of tests don't
>> have it, meaning that the comment in the functionname label is not present
>> OR that when you only check for ret_void: (done in the rest of tests) and
>> then you use CHECK-NEXT it is still in the same line which doesn't make
>> sense to me at all, but who knows.
>>
>> I see that the BB#0 comment is always printed, so it has to be consumed
>> before you get into the real instructions.
>>
>> Basically if what i wrote is confusing, why is the first regexp needed
>> and not needed in the rest of cases?
>>
>>
>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>
>>> Sorry for my bad explanations :)
>>>
>>> For returning void and returning the first parameter directly the
>>> assembly looks like:
>>> return_void: # @return_void
>>> # BB#0:
>>> ret
>>>
>>> What I'm thinking is important to test in these cases is that there is
>>> no code between the label "return_void:" and "ret", only comments.
>>>
>>> Here CHECK-NEXT is a good choice, but the two comments makes it much
>>> harder to use CHECK-NEXT. Therefore the first regexp consumes the comment
>>> after the label and the second the comment on the next line, if not
>>> including the first regexp the second will match on the same line as the
>>> label.
>>>
>>> Does that make sense? Essentially it would be much easier to test if
>>> FileCheck had the option for ignoring comments.
>>>
>>>
>>>
>>> On Thu, May 24, 2012 at 11:03 PM, Borja Ferrer <bor...@gm...>wrote:
>>>
>>>> I'm a bit confused now, why is this comment only appearing in this test
>>>> then? I mean, for the rest of tests you didn't need to add that regex.
>>>>
>>>>
>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>
>>>>> The asm looks something like:
>>>>> return_void: # @return_void
>>>>> # BB#0:
>>>>> ret
>>>>>
>>>>> So the two regex's handle one comment each. It's far from perfect,
>>>>> should we just delete these testcases for now?
>>>>>
>>>>> On Thu, May 24, 2012 at 6:40 PM, Borja Ferrer <bor...@gm...>wrote:
>>>>>
>>>>>> I prefer the second, although it's a bit nasty it doesn't use an
>>>>>> external tool. For what is this regex used in CHECK:
>>>>>> return_void:{{[a-zA-Z0-9 #@]*}} ?
>>>>>>
>>>>>>
>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>
>>>>>>> I agree. FileCheck should be able to ignore comments(at least as a
>>>>>>> parameter) like it ignores whitespaces.
>>>>>>>
>>>>>>> However I do have a few suggestions for how to do it, if you like
>>>>>>> one of them we can use it.
>>>>>>>
>>>>>>> 1. Previous suggestion with "hardcoded" comment.
>>>>>>> 2. Accept any comment after label:
>>>>>>> define void @return_void() {
>>>>>>> ; CHECK: return_void:{{[a-zA-Z0-9 #@]*}}
>>>>>>> ; CHECK-NEXT: #{{[a-zA-Z0-9 #@]*}}
>>>>>>> ; CHECK-NEXT: ret
>>>>>>> ret void
>>>>>>> }
>>>>>>>
>>>>>>> 3. Strip the assembler for comments and blank lines(here using sed)
>>>>>>> before checking.
>>>>>>> ; RUN: llc < %s -march=avr | sed "s/#.*//" | sed "/^$/d" | FileCheck
>>>>>>> %s
>>>>>>>
>>>>>>> define void @return_void() {
>>>>>>> ; CHECK: return_void:
>>>>>>> ; CHECK-NEXT: ret
>>>>>>> ret void
>>>>>>> }
>>>>>>>
>>>>>>> 2. is a bit complex and if we later choose to not print comments
>>>>>>> before blocks the test will fail.
>>>>>>> 3. is simpler, but requires a third party tool.
>>>>>>>
>>>>>>> What do you think Borja? I haven't found another backend dealing
>>>>>>> with this issue.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 24, 2012 at 12:33 PM, Borja Ferrer <
>>>>>>> bor...@gm...> wrote:
>>>>>>>
>>>>>>>> I like it but checking for BB#0 is a bit nasty because it's a
>>>>>>>> comment and not an instruction, also that could change in the future
>>>>>>>> breaking the test.
>>>>>>>>
>>>>>>>> I've checked the other backends and we're testing things further
>>>>>>>> than what others do so I think there's no need for more tests there.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/5/24 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>
>>>>>>>>> One idea could be to use CHECK-NEXT that checks if the string is
>>>>>>>>> on a consecutive line, then we could do something like:
>>>>>>>>>
>>>>>>>>> define void @return_void() {
>>>>>>>>> ; CHECK: return_void:
>>>>>>>>> ; CHECK-NEXT: # BB#0:
>>>>>>>>> ; CHECK-NEXT: ret
>>>>>>>>> ret void
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The solution with the comment is not the best. What do you think?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, May 24, 2012 at 1:48 AM, Borja Ferrer <
>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>
>>>>>>>>>> Maybe you could check using CHECKNOT or whatever to make sure
>>>>>>>>>> that no moves are emitted, that would cover it.
>>>>>>>>>>
>>>>>>>>>> I'll check what other backends do regarding these tests and see
>>>>>>>>>> if I can come up with further things.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>
>>>>>>>>>>> Are the following tests obsolete, as there in my opinion is no
>>>>>>>>>>> really good way to test them using FileCheck(with my current return
>>>>>>>>>>> tests(included) we could return the wrong argument)?
>>>>>>>>>>>
>>>>>>>>>>> - Returning void.
>>>>>>>>>>> - Returning the first parameter, which is already in the
>>>>>>>>>>> correct place.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Do we need additional tests for returning, besides
>>>>>>>>>>> returning immediate and argument, like returning a value from register or
>>>>>>>>>>> is it already covered in returning a argument?
>>>>>>>>>>>
>>>>>>>>>>> On Wed, May 23, 2012 at 12:51 AM, Borja Ferrer <
>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yes, that's something handled by llvm, not the backend so we
>>>>>>>>>>>> can't do too much there, although it would be a nice optimization to do.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2012/5/23 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the explanation. It's clear :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Out of curiosity, why are the pushes and pops in the example
>>>>>>>>>>>>> below? movw leaves r17:r14 unchanged. Do we simply push and pop all
>>>>>>>>>>>>> registers to be on the safe side and limited static analysis?
>>>>>>>>>>>>>
>>>>>>>>>>>>> llvm:
>>>>>>>>>>>>> define i32 @return32_arg2(i32 %x, i32 %y, i32 %z) {
>>>>>>>>>>>>> ret i32 %z
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> asm:
>>>>>>>>>>>>> return32_arg2:
>>>>>>>>>>>>> push r14
>>>>>>>>>>>>> push r15
>>>>>>>>>>>>> push r16
>>>>>>>>>>>>> push r17
>>>>>>>>>>>>> movw r23:r22, r15:r14
>>>>>>>>>>>>> movw r25:r24, r17:r16
>>>>>>>>>>>>> pop r17
>>>>>>>>>>>>> pop r16
>>>>>>>>>>>>> pop r15
>>>>>>>>>>>>> pop r14
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 22, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here you have a link that explains how registers are used:
>>>>>>>>>>>>>> www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
>>>>>>>>>>>>>> Testing a calling convention without knowing how it actually
>>>>>>>>>>>>>> works is going to be an insane task to do xD
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> About your question, when you read that link all will become
>>>>>>>>>>>>>> clear but basically here is what's going on. Arguments are passed from r25
>>>>>>>>>>>>>> down to r8, since in this case three 64bit args can't fit in those
>>>>>>>>>>>>>> registers the last argument is passed through the stack, so you get:
>>>>>>>>>>>>>> arg1 is in: r25-r18
>>>>>>>>>>>>>> arg2 is in: r17-r10
>>>>>>>>>>>>>> arg3 obviously doesn't fit in 2 register so it's all passed
>>>>>>>>>>>>>> through the stack, thats why you get those loads. Notice that the lowest
>>>>>>>>>>>>>> part of the argument is in Y+5 because in +4 and +3 is r29:r28 you just
>>>>>>>>>>>>>> pushed and in +2 +1 is the the return address that was pushed into the
>>>>>>>>>>>>>> stack after the call was performed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Another thing, you should add checks on the pushes and pops
>>>>>>>>>>>>>> for the callee saved registers so we're sure that they're being saved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2012/5/22 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Perfect :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm moving on to calling convention and have started with
>>>>>>>>>>>>>>> return values. However I'm a bit unsure what the calling convention
>>>>>>>>>>>>>>> actually is. For example with my last test, called "return64_arg2" in the
>>>>>>>>>>>>>>> attached .ll file and the generated assembly in the .s file, is the correct
>>>>>>>>>>>>>>> thing happening and how it should be tested? Couldn't we have passed the
>>>>>>>>>>>>>>> arguments in the normal registers? I.e. r25:r2.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If the arguments don't fit in the registers, do we always
>>>>>>>>>>>>>>> store the result in the same place in ram?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 11:38 PM, Borja Ferrer <
>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nice, so now you have the same test failures as me, they
>>>>>>>>>>>>>>>> are caused because we're using custom address space stuff in clang, dont
>>>>>>>>>>>>>>>> worry about those. Basically they fail because these tests are writing into
>>>>>>>>>>>>>>>> address space 1 which is flash data and that is forbidden in our target
>>>>>>>>>>>>>>>> (remember flash memory is readonly).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The test cases you just commited look great :) To which
>>>>>>>>>>>>>>>> ones are you going to move on next?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, that code looks correct, where is the problem?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2012/5/21 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is the following generated code correct:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> LLVM:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> define i8 @return8_arg(i8 %x) {
>>>>>>>>>>>>>>>>> ret i8 %x
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Generated:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> return8_arg:
>>>>>>>>>>>>>>>>> ret
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Something similar in .c compiling with avr-gcc gives a few
>>>>>>>>>>>>>>>>> pushes, loads and pops.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, May 21, 2012 at 10:48 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> When adding those targets I only have 10 unexpected
>>>>>>>>>>>>>>>>>> failures:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-compound-literal.c
>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space-field1.c
>>>>>>>>>>>>>>>>>> Clang :: CodeGen/address-space.c
>>>>>>>>>>>>>>>>>> Clang :: CodeGenCXX/mangle-address-space.cpp
>>>>>>>>>>>>>>>>>> Clang :: PCH/types.c
>>>>>>>>>>>>>>>>>> Clang :: Sema/address_spaces.c
>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-conversion.cpp
>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-newdelete.cpp
>>>>>>>>>>>>>>>>>> Clang :: SemaCXX/address-space-references.cpp
>>>>>>>>>>>>>>>>>> Clang :: SemaTemplate/address-spaces.cpp
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I will try to run each test separately and try to figure
>>>>>>>>>>>>>>>>>> out why they are failing. I have also attached the test output.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'm also committing tests for and, or and xor in a
>>>>>>>>>>>>>>>>>> minute. They are really simple and similar to the add and sub tests. Please
>>>>>>>>>>>>>>>>>> review these :)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 11:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Did you try adding the x86 and x64 targets with the avr
>>>>>>>>>>>>>>>>>>> one? It's something related with an unsopported target.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Good question, I think there's no need to do reg+imm for
>>>>>>>>>>>>>>>>>>> xor.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Btw remember to add the SF mailing list so we can have a
>>>>>>>>>>>>>>>>>>> record ;)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 2012/5/14 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sorry, that is the llvm+clang trunk gives me 13
>>>>>>>>>>>>>>>>>>>> unsupported tests, i.e. no failures versus the avr-llvm giving me 280
>>>>>>>>>>>>>>>>>>>> unexpected failures.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Mon, May 14, 2012 at 9:08 PM, Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> BTW, the newest llvm and clang trunk only gives me 13
>>>>>>>>>>>>>>>>>>>>> unexpected failures compared to the the newest trunk with avr-llvm where i
>>>>>>>>>>>>>>>>>>>>> get 280 unexpected failures.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Considering the regression tests for xor, does it make
>>>>>>>>>>>>>>>>>>>>> sense to test reg+imm, as the avr assembler does not have xor for immediate?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 9:12 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I don't think so, but I configured llvm to support
>>>>>>>>>>>>>>>>>>>>>> both x86 and x64, so maybe that could help, in fact I can't build clang if
>>>>>>>>>>>>>>>>>>>>>> I don't add support for x86.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Target: x86_64-unknown-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> But I only configured for avr... Did I do something
>>>>>>>>>>>>>>>>>>>>>>> wrong?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Thu, May 10, 2012 at 5:32 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> This is what I'm getting:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 9914
>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 66
>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 569
>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 11
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I've seen in that file you attached that you're
>>>>>>>>>>>>>>>>>>>>>>>> getting errors because of the target triple, errors like:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> error auto-selecting target for module 'No available targets are compatible with this triple, see -version for the available targets
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> so I guess that's the reason, so what is your
>>>>>>>>>>>>>>>>>>>>>>>> target triple? do clang -v to get it, mine is i386-pc-linux-gnu
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/10 Borja Ferrer <bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Interesting, I'll check it out tomorrow to see if
>>>>>>>>>>>>>>>>>>>>>>>>> I can find some reason behind this, because we're getting very different
>>>>>>>>>>>>>>>>>>>>>>>>> results here.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/9 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry for my slow response.Got i working again
>>>>>>>>>>>>>>>>>>>>>>>>>> now, thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Building with optimization disabled and
>>>>>>>>>>>>>>>>>>>>>>>>>> assertions turned on i get:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Avr llvm+clang:
>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Passes : 6978
>>>>>>>>>>>>>>>>>>>>>>>>>> Expected Failures : 39
>>>>>>>>>>>>>>>>>>>>>>>>>> Unsupported Tests : 3281
>>>>>>>>>>>>>>>>>>>>>>>>>> Unexpected Failures: 279
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> In the 279 unexpected failures for example 143 of
>>>>>>>>>>>>>>>>>>>>>>>>>> them are test/CodeGen/Generic. I'm not really sure how these tests are
>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to work? None of them seems to be using FileCheck.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> However building for msp430 seems to be giving me
>>>>>>>>>>>>>>>>>>>>>>>>>> similar results, indicating that it is not a avr-llvm specific problem.
>>>>>>>>>>>>>>>>>>>>>>>>>> Please see the attached output "make check-all" from avr-llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 11:30 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm asking because last week you said that you
>>>>>>>>>>>>>>>>>>>>>>>>>>> were getting +200 fails, and since I'm getting 11 I wanted to know what's
>>>>>>>>>>>>>>>>>>>>>>>>>>> going on.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> faluco is me btw, I updated a patch today
>>>>>>>>>>>>>>>>>>>>>>>>>>> because I got a conflict when updating my clang repo. These variables are
>>>>>>>>>>>>>>>>>>>>>>>>>>> defined in DiagnosticSemaKinds.td so check that you have them, they come
>>>>>>>>>>>>>>>>>>>>>>>>>>> from the flash.diff patch.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> The new tests should pass. I cannot check other
>>>>>>>>>>>>>>>>>>>>>>>>>>>> tests now, I'm having some issues after applying the newest patches that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> came in today by faluco:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4374:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_variable_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_variable_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:4383:38:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NewVD->getLocation(),
>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>> /home/nicklas/install/avr-llvm/llvm/tools/clang/lib/Sema/SemaDecl.cpp:7208:25:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> error:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> no member named
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'err_flash_pointer_requires_const' in namespace
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'clang::diag'
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Diag(NameLoc,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> diag::err_flash_pointer_requires_const);
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ~~~~~~^
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have i done something wrong?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:50 PM, Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How many tests failures are you getting now?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'm getting 11, 10 from clang due to address
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> space stuff (you'll need to patch clang to get those) and 1 from llvm.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <nbj...@gm...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ah, perfect.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would actually guess that you need to run
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "make check-all" before being able to test new tests individually. Sorry :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 8:17 PM, Borja Ferrer
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nevermind, got it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <bor...@gm...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> One thing, i dont have llvm-lit in that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dir, am I supposed to build llvm with an addtional param or something in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> order to get it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok, I've committed now. To only run the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVR specific tests run something like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ./build/Debug+Asserts/bin/llvm-lit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> llvm/test/CodeGen/AVR/
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, May 4, 2012 at 1:47 PM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Oh a small one I've just noticed, leave
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only 1 newline between tests not 2.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ok they look great now, I don't have any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> other objections. Please commit this test to SVN, post your SF username
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> here so that Eric or John can give you commit permissions. Once it gets
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> commited I'll check if I need to add any pattern specific tests to it,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> these tests are corner cases of some instructions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Before commiting it, remove the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> testcases dir with all the files there, and create a new one called
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test/CodeGen/AVR, and place your file there, just to keep the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> structure like in llvm's repo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> About the rest of tests to do, from that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> list remove mul and division for now, mul isn't yet implemented and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> division can come later. Sub tests should be very similar to add, then add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> binary ops (or, and, xor). Add calling convention tests (argument passing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> through regs and stack, return values for each value type, calls). Memory
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operations, etc...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are quite a few tests to add, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for now do the sub and binary op tests and we'll discuss the others by then.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/4 Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) Sure
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Yes, I've followed the msp430
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> backend that does include it. I've removed it now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Again, I've moved the CHECK lines,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> but it differs from backend to backend.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6) Done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will continue working other tests,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which do we need? Something like(and please add/comment):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Sub
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -division(Only working for multiples of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2?)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -mult
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -Return argument(In a few variants)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -xor
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -increment
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -branching?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any ideas?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, May 2, 2012 at 12:29 AM, Borja
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ferrer <bor...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Obviously in the last line I meant
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adiw or subi/sbci pair, add for immediates doesn't exist for imms greater
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> than 63
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/2 Borja Ferrer <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bor...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> They look good, very nice :)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Some small details and nitpicks:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) I think it's not necessary to add
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the reg_reg_imm variant because you covered it with the other two tests.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) Do the tests work if you remove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the target triple line? I've seen other backends don't include it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3) Move the CHECK lines after the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> function prototype like other backends do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4) In every CHECK line, can you
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> remove the tabs between the instr mnemonic and the first operand and add a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> single space? (I'm unsure about this because i dont know if CHECK eats
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> spaces). Also for the future, the llvm coding standards says to config your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> editor to replace tabs with spaces, so it's a good moment time to do it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5) Oh and the most important one,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please add this in only one file, add.ll or something like that, so we can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> keep this convention in the future, otherwise we'll end having too many
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> test files.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Something that should be covered is,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when doing 16 bit additions we can use adiw or add depending on the imm
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> value, can you cover this aswell?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2012/5/1 John Myers <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ato...@gm...>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, Apr 29, 2012 at 10:46 AM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Nicklas Bo Jensen <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nbj...@gm...> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have successfully been able to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compile your testcases (/avr-llvm/testcases/*.ll) to something looking like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> valid avr assembler.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> How should I test/simulate the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assembler? I get errors when trying to simulate the generated assembler in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AVRStudio. Perhaps they use a different assembler?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> avr-llvm produces GNU assembler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> syntax, which is different then the Atmel assembler syntax.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eventually we could support multiple
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> asm syntax's like the X86 target does.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
