From: Stepan D. <stp...@na...> - 2013-07-29 18:58:20
|
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...>> > > 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...>>> > > 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...>>>> > > 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...>>>>> > > > 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>>>>>): > > > 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...>>__>__>__>__> > > 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...>>>>>> > > > > > > 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...>>__>__>__>__> > > > >> 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...>>__>__>__>__> > >> > >>> 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> > > > > > _________________________________________________ > avr-llvm-devel mailing list > 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> > > > |