Menu
▾
▴
Re: [avr-llvm-devel] Regression tests
|
From: Neil F. <inf...@gm...> - 2012-04-27 18:24:32
|
I'm up for helping with tests, so count me in. I'm a newbie at this, and haven't gotten the AVR target building yet. But I've got the code and have successfully applied the patches a few times, so I think I can get myself working and up to speed. -Neil On Mon, Apr 23, 2012 at 6:01 PM, <avr...@li...> wrote: > Send avr-llvm-devel mailing list submissions to > avr...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > or, via email, send a message with subject or body 'help' to > avr...@li... > > You can reach the person managing the list at > avr...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of avr-llvm-devel digest..." > > > Today's Topics: > > 1. Regression tests (Borja Ferrer) > 2. Re: Flash data (Borja Ferrer) > 3. Re: Regression tests (Nicklas Bo Jensen) > 4. Re: Fwd: Problem following Getting started with avr-llvm > (Borja Ferrer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 22 Apr 2012 19:26:05 +0200 > From: Borja Ferrer <bor...@gm...> > Subject: [avr-llvm-devel] Regression tests > To: avr...@li... > Message-ID: > <CAM...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > I think it's time to stop adding more features until we cover what is > currently implemented with regression tests. Otherwise the further we go > the harder will be to cover everything up, from now on it's going to be > easier to go in parallel. > In the past emails I've seen people interested in helping out with this, > it's a good way of starting with some development becuase it's an easy task > to do and it helps to understand how llvm works, so anybody interested > check in here so I know if I'm going to have any help at all or I have to > do it myself. > > So if there's some help available we can plan in this thread what needs to > get covered and how to do it, I'll wait a few days for any replies. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 2 > Date: Sun, 22 Apr 2012 19:26:38 +0200 > From: Borja Ferrer <bor...@gm...> > Subject: Re: [avr-llvm-devel] Flash data > To: John Myers <ato...@gm...> > Cc: avr...@li... > Message-ID: > <CAM...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > Ok, thanks John. > > 2012/4/20 John Myers <ato...@gm...> > >> I haven't had time to fix it. >> I'll probably be able to do it this weekend. >> >> >> On Fri, Apr 20, 2012 at 8:02 AM, Borja Ferrer <bor...@gm...>wrote: >> >>> John ping? >>> >>> >>> 2012/4/12 Borja Ferrer <bor...@gm...> >>> >>>> John I noticed that in your latest commit you removed a piece of valid >>>> code inside lib/CodeGen/TargetInfo.cpp, although this code is for flash >>>> variables, it goes under the code that handles interrupt attributes. >>>> >>>> + } else >>>> + // Global variables that do not belong to the generic address >>>> space and >>>> + // have common linkage are set to have external linkage. >>>> + if ((GV->getType()->getAddressSpace() != 0) >>>> + && (GV->getLinkage() == llvm::GlobalValue::CommonLinkage)) >>>> + GV->setLinkage(llvm::GlobalValue::ExternalLinkage); >>>> +} >>>> You may want to place this bit in the interrupt patch or something, I >>>> leave that up to you. >>>> >>>> Btw has anybody tried or tested the backend lately? I would like to hear >>>> some opinions. >>>> >>>> >>>> 2012/3/20 Borja Ferrer <bor...@gm...> >>>> >>>>> Ok I've just commited all patches and code related to this. Please try >>>>> them out and let me know any issues. John you'll notice some patches >>>>> duplicate some code compared to the interrupt.diff file because i added >>>>> some code to the same files like that patch, you may want to fix this, I >>>>> didnt know what to do. >>>>> >>>>> >>>>> 2012/3/19 Borja Ferrer <bor...@gm...> >>>>> >>>>>> Indeed __flash is a type qualifier just like const or volatile, the >>>>>> syntax you're all writing above is how it works. You can have an insane >>>>>> chain of pointers like __flash const int * const __flash * * const __flash >>>>>> * __flash ptr; and it's totally valid. The issue I'm talking about is, >>>>>> should __flash qualify a variable with a const aswell? As we discussed >>>>>> above i think it shouldn't. >>>>>> >>>>>> Anton, what you said in the last email is exactly what I think, as >>>>>> __flash is a type qualifier, check for constness and add errors if the user >>>>>> doesn't explicitly add them. But after all the usage is what you're all >>>>>> writing above. I like the idea of adding const because it really models how >>>>>> flash memory works, and as i said making __flash imply const is like >>>>>> cheating on the C language. But well, we're all here to discuss about it so >>>>>> it's not a closed decision in any sense. >>>>>> >>>>>> John thanks for the strings, I'll add them to my patch. If you want, >>>>>> once it is commited you can add further changes or add any additional >>>>>> hints. I still have to prepare the patch because I was waiting for this, I >>>>>> will split it in 2 parts, one for the clang side and another for llvm. >>>>>> >>>>>> Oh and if anybody else can think of any additional checks let me know, >>>>>> we should be here as robust as possible. >>>>>> >>>>>> >>>>>> 2012/3/19 John Myers <ato...@gm...> >>>>>> >>>>>>> >>>>>>> 1) Cannot write to flash memory. <-- emitted when trying to assign a >>>>>>>> value to a flash var >>>>>>>> >>>>>>> The error for a const being assigned a value is "error: read-only >>>>>>> variable is not assignable" so I would make the wording consistent and just >>>>>>> do... >>>>>>> >>>>>>> "error: Flash variable is not assignable" ...or... >>>>>>> "error: __flash qualified variable is not assignable" >>>>>>> >>>>>>> >>>>>>>> 2) Flash variables are read only and should be declared with a const >>>>>>>> qualifier. <-- emitted when doing something like __flash int, we want >>>>>>>> __flash const int >>>>>>>> >>>>>>> >>>>>>> Something like the below and then also have one of those clang fix-it >>>>>>> hints showing const being added. >>>>>>> >>>>>>> "error: Flash variable requires const qualifier" >>>>>>> >>>>>>> 3) The pointee type of a flash pointer should be declared with a >>>>>>>> const qualifier. <-- i cant think of a better way of saying it, this is >>>>>>>> emitted when doing __flash int* ptr, we want __flash const int *ptr. >>>>>>>> >>>>>>> >>>>>>> I think this can be the same as or similar to #2 and again use the >>>>>>> fix-it hint to show explicitly where the const needs to be placed. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 3 > Date: Mon, 23 Apr 2012 22:26:53 +0200 > From: Nicklas Bo Jensen <nbj...@gm...> > Subject: Re: [avr-llvm-devel] Regression tests > To: Borja Ferrer <bor...@gm...> > Cc: avr...@li... > Message-ID: > <CAM...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I'll be happy to contribute, after I have fixed my issues getting avr-llvm > to compile in the first place. > > BR, > Nicklas > > On Sun, Apr 22, 2012 at 7:26 PM, Borja Ferrer <bor...@gm...> wrote: > >> I think it's time to stop adding more features until we cover what is >> currently implemented with regression tests. Otherwise the further we go >> the harder will be to cover everything up, from now on it's going to be >> easier to go in parallel. >> In the past emails I've seen people interested in helping out with this, >> it's a good way of starting with some development becuase it's an easy task >> to do and it helps to understand how llvm works, so anybody interested >> check in here so I know if I'm going to have any help at all or I have to >> do it myself. >> >> So if there's some help available we can plan in this thread what needs to >> get covered and how to do it, I'll wait a few days for any replies. >> >> >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> avr-llvm-devel mailing list >> avr...@li... >> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 4 > Date: Mon, 23 Apr 2012 23:53:40 +0200 > From: Borja Ferrer <bor...@gm...> > Subject: Re: [avr-llvm-devel] Fwd: Problem following Getting started > with avr-llvm > To: Nicklas Bo Jensen <nbj...@gm...> > Cc: avr...@li... > Message-ID: > <CAMOECusZfLsNupRC+wHvwSk8xuHt-Rfx=0iq...@ma...> > Content-Type: text/plain; charset="iso-8859-1" > > Ahh ok I didn't receive the message from John, so i thought he never > replied to you. > > No, there's no special revision needed from llvm's repo, it should always > compile with the latest svn revision, I keep our code in sync with llvm's > trunk when any API change occurs, like during the past weekend. > > Remember to add --enable-targets=avr when configuring the build, probably > one of your files got corrupted after patching, try using a fresh configure > (or CMakelists.txt if you're using windows) file and build llvm without the > avr target. If that works then there's the problem, I would then patch the > configure file manually, just search the word msp430 and add avr the same > way it's done. Check other patch files that touch the building stuff like > CMake.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/CMake.diff?view=log>and > LLVMBuild.diff<http://avr-llvm.svn.sourceforge.net/viewvc/avr-llvm/llvm/trunk/patches/LLVMBuild.diff?view=log>. > I think the problem is related with one of those, not patches that touch > the sourcecode. > > 2012/4/23 Nicklas Bo Jensen <nbj...@gm...> > >> Hi, >> >> He did reply to my message: >> On Wed, Apr 11, 2012 at 7:30 PM, John Myers <ato...@gm...> >> wrote: >> >>> Hi Nicklas, >>> >>> Sorry, The getting started page needs to be updated. I've always just >>> applied the patch files one at a time, so I never checked to see if this >>> method works. But I get the same error when trying to apply the patches >>> with ../avr-llvm/patches/*.diff | patch -p0 >>> >>> You can try something like the below instead. >>> echo ../avr-llvm/llvm/trunk/patches/*.diff > patch -p0 >>> >>> >>> --John >> >> >> I ended up applying the patches one by one though, as patch returned >> "**** Only garbage was found in the patch input." when using echo and >> "malformed patch at line 16: Index: CMakeLists.txt" when using cat. >> >> Should any special revision of llvm be checked out? Right now the latest >> revision in the patches is 152169. >> >> I'm getting the following configure error (Regardless of chosen llvm >> revision): >> >> config.status: error: cannot find input file: tools/llvmc/src/Base.td.in >> >> Indeed the file is not there? >> >> I have followed the instructions in: avr-llvm/README and can normally >> compile llvm+clang directly from svn. >> >> BR, >> Nicklas >> >> On Fri, Apr 20, 2012 at 5:06 PM, Borja Ferrer <bor...@gm...>wrote: >> >>> Hello, >>> >>> Please wait for John to reply here about issues with patches since he's >>> the one that usually work with them. >>> >>> CCing John. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> For Developers, A Lot Can Happen In A Second. >>> Boundary is the first to Know...and Tell You. >>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> http://p.sf.net/sfu/Boundary-d2dvs2 >>> _______________________________________________ >>> avr-llvm-devel mailing list >>> avr...@li... >>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >>> >>> >> > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > > ------------------------------ > > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > > End of avr-llvm-devel Digest, Vol 16, Issue 3 > ********************************************* |
