From: Stepan D. <stp...@na...> - 2013-07-29 18:32:55
|
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...>> >> >> 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...>>> >> >> 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...>>>> >> >> >> 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>>>>): >> >> >> 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...>>__>__>__> >> >> 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...>>>>> >> >> >> >> >> > 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...>>__>__>__> >> > >> >> 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...>>__>__>__> >> >> >> >>> 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 > > > > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |