Menu
▾
▴
Re: [avr-llvm-devel] Inline assembly.
|
From: Stepan D. <stp...@na...> - 2013-07-30 17:45:50
|
Borja Ferrer wrote: > 1) Hrmm no idea then. May be it is related with wrong 'mode' attribute implementation. I have posted bug + patch for 'mode' attr here. You could also add some reviews, that allows us to keep high activity for this bug and attract code owners: http://llvm.org/bugs/show_bug.cgi?id=16752 > 2) Ok we'll have to live with it then. > 3) In theory we're going to move on to a different place and probably > use a different vcs, but for the meantime we have to live with svn. The main issue is differences in tree structure. SVN doesn't considers possibility of 2 upstreams and more. So if you can't move everything you did into llvm subfolder, you have to use some tricks like storing .diff files and so on. Using GIT you just can add your own upstream into separated branch and merge it with llvm sometimes. I have even managed to merge it with two upstreams (yours and llvm) :-) > > I'm very surprised that we didn't get any codegen errors/asserts, all > issues so far have been in the frontend. Now the next thing to do is > confirm that the generated code is doing the right things. I see they > have some checking functions so try running it to see if it passes. Yup. We have to ask somebody for development boards (or set up emulator). I have board with mega8. On latest stages I can also use my ardupilot uav board, but not now :-) -Stepan. > > > > > 2013/7/29 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>> > > Borja Ferrer wrote: > > WOW!!! very nice :) > > 1) Is the issue with int16_t related to what we discovered > yesterday? So > is sizeof(int) == sizeof(int16_t) true? > > Yes its true. It is different issue. It just treats attributed int > and just-int as different types. > > > > 3) Commit this patch to SVN, and create a new directory for it, > John any > > suggestions about the dir structure for this? > My suggestion is still to use GIT. From moment I started to work on > inlineasm I kept everything in GIT on github, syncing with your svn > repo from time to time. > > > 2) What sort of errors do you get without setting the CCAS line? > Again, > avr-clang should call avr-as if it's in the $PATH. > > I wrote you few days ago (it is not for avr2, I found this fires for > avr5 as well): > > > > > About compiling avrlibc: > > > > >> Also avr-clang emits wrong sequense for .S files. So I'm using > > CCAS=avr-gcc. > > What do you mean with this? What is wrong? > Directory: > bash:$ cd $AVR_LIBC_OBJ/avr/lib/avr2/__at90s1200 > bash:$ avr-clang -DHAVE_CONFIG_H -I. > -I../../../../../avr-libc/avr/__lib/avr2/at90s1200 -I../../../.. > -I../../../../../avr-libc/__common > -I../../../../../avr-libc/__include -I../../../../include > -I../../../../../avr-libc/__common > -I../../../../../avr-libc/__include -I../../../../include -x > assembler-with-cpp -mmcu=at90s1200 > -DIOSYMFILE=\"iosym/at90s1200.__S\" -MT gcrt1.o -MD -MP -MF > .deps/gcrt1.Tpo -c -o gcrt1.o ../../../../../avr-libc/crt1/__gcrt1.S > > > tons of errors. > > I suppose thats because clang driver uses different tools for asm files. > > For the -### command avr-clang shows the next: > > "avr-clang" "-cc1" "-triple" "avr" "-E" "-disable-free" > "-main-file-name" "gcrt1.S" "-mrelocation-model" "static" > "-mdisable-fp-elim" "-fmath-errno" "-mconstructor-aliases" > "-target-linker-version" "2.22.90.20120924" "-coverage-file" > "/tmp/gcrt1-fecbe5.s" "-resource-dir" > "/media/stepan/workproj/llvm.__project/2-avr/builds/llvm.__debug-avr-arm-x86_64.build/__Debug+Asserts/bin/../lib/__clang/3.4" > "-dependency-file" ".deps/gcrt1.Tpo" "-sys-header-deps" "-MP" "-MT" > "gcrt1.o" "-D" "HAVE_CONFIG_H" "-D" > "IOSYMFILE=\"iosym/at90s1200.__S\"" "-I" "." "-I" > "../../../../../avr-libc/avr/__lib/avr2/at90s1200" "-I" > "../../../.." "-I" "../../../../../avr-libc/__common" "-I" > "../../../../../avr-libc/__include" "-I" "../../../../include" "-I" > "../../../../../avr-libc/__common" "-I" > "../../../../../avr-libc/__include" "-I" "../../../../include" > "-fno-dwarf-directory-asm" "-fdebug-compilation-dir" > "/media/stepan/workproj/llvm.__project/2-avr/avr-libc/trunk/__build.opt/avr/lib/avr2/__at90s1200" > "-ferror-limit" "19" "-fmessage-length" "147" "-mstackrealign" > "-fobjc-runtime=gcc" "-fobjc-default-synthesize-__properties" > "-fdiagnostics-show-option" "-fcolor-diagnostics" "-vectorize-loops" > "-o" "/tmp/gcrt1-fecbe5.s" "-x" "assembler-with-cpp" > "../../../../../avr-libc/crt1/__gcrt1.S" > > "/usr/bin/avr-gcc" "-D" "HAVE_CONFIG_H" "-I" "." "-I" > "../../../../../avr-libc/avr/__lib/avr2/at90s1200" "-I" > "../../../.." "-I" "../../../../../avr-libc/__common" "-I" > "../../../../../avr-libc/__include" "-I" "../../../../include" "-I" > "../../../../../avr-libc/__common" "-I" > "../../../../../avr-libc/__include" "-I" "../../../../include" > "-mmcu=at90s1200" "-D" "IOSYMFILE=\"iosym/at90s1200.__S\"" "-MT" > "gcrt1.o" "-MD" "-MP" "-MF" ".deps/gcrt1.Tpo" "-c" "-o" "gcrt1.o" > "-x" "assembler" "/tmp/gcrt1-fecbe5.s" > > > While avr-gcc uses next sequence: > > /usr/lib/gcc/avr/4.7.0/cc1 -E -lang-asm -quiet -I . -I > ../../../../../avr-libc/avr/__lib/avr2/at90s1200 -I ../../../.. -I > ../../../../../avr-libc/common -I ../../../../../avr-libc/__include > -I ../../../../include -I ../../../../../avr-libc/common -I > ../../../../../avr-libc/__include -I ../../../../include -MD gcrt1.d > -MF .deps/gcrt1.Tpo -MP -MT gcrt1.o -D HAVE_CONFIG_H -D > "IOSYMFILE=\"iosym/at90s1200.__S\"" > ../../../../../avr-libc/crt1/__gcrt1.S "-mmcu=at90s1200" > -fno-directives-only -o /tmp/ccK7jMC3.s > '-mmcu=at90s1200' '-D' 'IOSYMFILE="iosym/at90s1200.S"__' '-MT' > 'gcrt1.o' '-MD' '-MP' '-MF' '.deps/gcrt1.Tpo' '-c' '-o' 'gcrt1.o' > > /usr/lib/gcc/avr/4.7.0/../../.__./avr/bin/as "-mmcu=at90s1200" > -mno-skip-bug -o gcrt1.o /tmp/ccK7jMC3.s > > 3) Commit this patch to SVN, and create a new directory for it, > John any > suggestions about the dir structure for this? > > I will fix those two issues later, we still need to fix or > report the > mode thing though. > > > > 2013/7/29 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > > Stepan Dyatkovskiy wrote: > > Gotcha!!! > > I mean, I have compiled it successfully :-) > > > In output I send you patch for avr-libc. > Remained issues: > -- PR16712, > -- Bug with 'mode' attr in SemaDeclAttr, handleModeAttr > function > -- AVRTargetInfo, size of double > -- AVRAsmPrinter, emit asm header. > -- By some strange reason avr-clang treats differently with > 'int' and > int16_t (that is the same int, but with attribute > added), so the > next > one causes error: > int foo(); // header > int16_t foo() { return 0; } // .c file. > > -- But currently (you will see in patch) I fixed their > stdint.h. > -- I'm still using CCAS=avr-gcc > > Though I think we already have solution for TargetInfo and > AsmPrinter. > > Configure command: > $AVR_LIBC_SRC/configure CC=$AVR_CLANG_BIN/avr-clang > --build= > --host=avr > CCAS=avr-gcc > > -Stepan. > > > Borja Ferrer wrote: > > Yes, that's the way of doing it, thanks for the > code, I will > add it > later. > > So how many files have you successfully compiled so > far? > > > 2013/7/29 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>>> > > > Just in case, I have already added temporary > it in my > sources. To do > that you should implement > AVRAsmPrinter::______EmitStartOfAsmFile method > > (that is virtual for AsmPrinter). Currently it > looks like: > > void > AVRAsmPrinter::______EmitStartOfAsmFile(Module &M) { > > // FIXME: Perhaps do it somehow with > OutStreamer.EmitAssignment > OutStreamer.EmitRawText(______StringRef( > > "__SP_H__ = 0x3e\n\t" > "__SP_L__ = 0x3d\n\t" > "__SREG__ = 0x3f\n\t" > "__tmp_reg__ = 0\n\t" > "__zero_reg__ = 1\n\t" > )); > } > > > Borja Ferrer wrote: > > Ok yes I will add this tonight. > > El lunes, 29 de julio de 2013, Stepan > Dyatkovskiy > escribió: > > Yes. I mean just header for .s file, > so it > should be > equal to > avr-gcc. For set_system_time.c gcc > produces > next header: > > .file "set_system_time.c" > __SP_H__ = 0x3e > __SP_L__ = 0x3d > __SREG__ = 0x3f > __tmp_reg__ = 0 > __zero_reg__ = 1 > ... > > Just compare our output and one > generated by > gcc (in > attachment). > > > > Borja Ferrer wrote: > > You mean in the header (top) of > the .S > file instead > of the > footer no? > > > 2013/7/29 Stepan Dyatkovskiy > <stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>> <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>>>>> > > Currently I have found that > set_system_time.c > hardcodes > __SREG__ and > __tmp_reg__ names in > inlineasm. GCC > just puts the > footer > for all .s > files: > __SP_H__ = 0x3e > __SP_L__ = 0x3d > __SREG__ = 0x3f > __tmp_reg__ = 0 > __zero_reg__ = 1 > > Can we do the same? > > -Stepan. > > Borja Ferrer wrote: > > Hello Stepan, > > 1) Yes, I'm aware of our > double width > definition in > clang. I > have to do > some tests before > changing it in > clang and > other places > back to > 32bits, > so in the meantime it's > ok to > leave that > change locally > for you. > > 2) If I understand that code > correctly they > are setting > SI to an > integer > type which is 16bits for our > target. If > that's the > case, they > have to > take care of ints being > smaller > than 32 > bits. They > check in the > 64bit > case for the long type > width and > do it right > there. So > I would > say fill > in a bug report or send > them a > patch if you > have the fix. > > Btw, if you want, create > a branch > in svn and > add there > all the > avrlibc > patches and stuff instead of > getting them lost > here in the > mailing list. > > > > 2013/7/29 Stepan Dyatkovskiy > <stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > <mailto:stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>>>> <mailto:stp...@na... > <mailto:stp...@na...> > > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > <mailto:stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>>>>>> > > > Currently I'm > considering it > as clang > bug. In > handleModeAttr they > handle 'SI' as 32 > bit value > (that's ok > for us, but > instead > it should > be 4*QI), and what > is really > wrong for > AVR is how > 32 value > type is > handled here: > > case 32: > if (!IntegerMode) > NewTy = > S.Context.FloatTy; > else if > (OldTy->isSignedIntegerType()) > NewTy = > S.Context.IntTy; > else > NewTy = > S.Context.UnsignedIntTy; > > -Stepan. > > Stepan Dyatkovskiy > wrote: > > Hi Borja, > > In > clang/lib/Basic/Targets.cpp, > > > AVRTargetInfo::AVRTargetInfo()____________, I have > > > > changed > DoubleWidth to > 32 bit value. > Is it > legal? I > mean why it > was 64 > bits, doesn't > it has > some pitfalls? > Anyway I > allowed me to > compile that > large source. > > > > > typedef > unsigned int > uint32_t > __attribute__ > ((__mode__ > > > (__SI__))); > > I have found > the next > info about it > > > > > (http://www.delorie.com/gnu/____________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/__________docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/__________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html>> > > > <http://www.delorie.com/gnu/__________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>>> > > > > <http://www.delorie.com/gnu/__________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>> > > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>>>> > > > > <http://www.delorie.com/gnu/__________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>> > > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>>> > > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>> > > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>>>>> > > > > > > <http://www.delorie.com/gnu/__________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html>> > > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>>> > > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>> > > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>>>> > > > > <http://www.delorie.com/gnu/________docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html>> > > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>>> > > > <http://www.delorie.com/gnu/______docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html> > > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html>> > > <http://www.delorie.com/gnu/____docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html> > <http://www.delorie.com/gnu/__docs/gcc/gcc_80.html > <http://www.delorie.com/gnu/docs/gcc/gcc_80.html>>>>>>): > > > QI -- An > integer that > is as wide as > the smallest > addressable unit, > usually 8 bits. > HI -- An > integer, twice > as wide as a > QI mode > integer, > usually 16 > bits. > SI -- An > integer, four > times as wide > as a QI > mode integer, > usually 32 bits. > DI -- An > integer, eight > times as wide > as a QI > mode integer, > usually 64 > bits. > SF -- A > floating point > value, as wide > as a SI > mode integer, > usually 32 > bits. > DF -- A > floating point > value, as wide > as a DI > mode integer, > usually 64 bits. > > It is > implemented in > > clang/lib/Sema/SemaDeclAttr.____________cpp, in > > > > handleModeAttr > static function. > > Perhaps we just > have to > sort it out in > AVRTargetInfo... > > -Stepan. > > Borja Ferrer wrote: > > Found it, the > isfinite() function > takes in a > double, and > since our > backend > treats them > as 64bit > types this > fails in > inline asm. > Removing > the function > implementation and > just > leaving it as > an extern > compiles > successfully. > > > 2013/7/28 > Borja Ferrer > <bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__>__>__>__> > > > I've > tried > different > optimization > levels and > they all > fail for me. > The > interesting thing is > that i've > isolated > the strtod > function in a > > different file > and it > compiles fine, > so there's > something > in the > huge > file that > causes this. > > > 2013/7/28 > Stepan Dyatkovskiy > <stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>> <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>>> > <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>> <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>>>> > > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>> <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>>>>> > > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > <mailto:stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>>>> <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > <mailto:stp...@na... <mailto:stp...@na...> > <mailto:stp...@na... <mailto:stp...@na...>> > <mailto:stp...@na... > <mailto:stp...@na...> > <mailto:stp...@na... > <mailto:stp...@na...>>>>>>__> > > > > > > > Ok this > was a bit > insane to > reduce but > I've > found the > > offending > lines. > > > > > The > problem is how > uint32_t and > uint16_t are > defined: > > > typedef > unsigned int > uint16_t > __attribute__ > ((__mode__ > > (__HI__))); > > > > > typedef > unsigned int > uint32_t > __attribute__ > ((__mode__ > > (__SI__))); > > > > > I have > no idea > what this > syntax is, > but if you > refedefine > those > types to unsigned > int / > long the > problem > goes away. > > > Wow great. > Never > expected that wrong > definition. > > > > > > Now im > getting an > error in > llc: error: > couldn't > allocate > > input reg for > constraint 'r' > > > > > Hm.. May > be try with O2 > instead > of Os? > > > > 2013/7/28 Borja > Ferrer > <bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__>__>__>__> > > > > > >> I've > compiled the > file you > attached, > ignoring > all warnings i > > get from > clang about > the unknown > attributes like > progmem, i'm > > getting > the assertion > "multibyte > index is > out of > range." > >> > >> > 2013/7/28 Borja > Ferrer > <bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__> > > <mailto:bor...@gm... > <mailto:bor...@gm...> <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__> > > <mailto:bor...@gm... <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>> > <mailto:bor...@gm... > <mailto:bor...@gm...> > <mailto:bor...@gm... > <mailto:bor...@gm...>>__>__>__>__>__> > > >> > > >>> Hello > Stepan, > >>> > > >>> 1) It > seems clang > mangles > assembly > functions > names by > > prefixing > a \01 > character. I haven't > found yet the > code that > > does this > depending > on the > target used. > >>> > > >>> 2) > About the code > above, I'm > assuming you got > that inline > > asm code > from the > __LPM_dword_classic__ > macro. > This is > what I'm > > getting > for the > following C code: > >>> > typedef unsigned > int uint16_t; > >>> > typedef unsigned > long uint32_t; > >>> > > >>> #define > __LPM_dword_classic__(addr) \ > >>> > (__extension__({ \ > >>> > uint16_t __addr16 = > (uint16_t)(addr); \ > > >>> uint32_t > __result; \ > > >>> __asm__ > __volatile__ \ > >>> > > >>> ( \ > > >>> "lpm" > "\n\t" \ > > >>> "mov > %A0, r0" > "\n\t" \ > > >>> "adiw > r30, 1" > "\n\t" \ > > > > > > > > ------------------------------____----------------------------__--__------------------ > > Get your SQL database under version control now! > Version control is standard for application code, but > databases > havent > caught up. So what steps can you take to put your SQL > databases > under > version control? Why should you start doing it? Read > more to > find out. > http://pubads.g.doubleclick.____net/gampad/clk?id=49501711&iu=____/4140/ostg.clktrk > > <http://pubads.g.doubleclick.__net/gampad/clk?id=49501711&iu=__/4140/ostg.clktrk > <http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk>> > > > > > > ___________________________________________________ > avr-llvm-devel mailing list > avr-llvm-devel@lists.__sourcef__orge.net > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists.__sourceforge.net > <mailto:avr...@li...>> > https://lists.sourceforge.net/____lists/listinfo/avr-llvm-__devel <https://lists.sourceforge.net/__lists/listinfo/avr-llvm-devel> > > <https://lists.sourceforge.__net/lists/listinfo/avr-llvm-__devel > <https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel>> > > > > > |
