From: Borja F. <bor...@gm...> - 2013-07-29 18:52:03
|
WOW!!! very nice :) 1) Is the issue with int16_t related to what we discovered yesterday? So is sizeof(int) == sizeof(int16_t) true? 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. 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...> > 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> >>> >>> >>> >>> >>> >>> <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<http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk> >> >> >> >> >> ______________________________**_________________ >> avr-llvm-devel mailing list >> avr-llvm-devel@lists.**sourceforge.net<avr...@li...> >> https://lists.sourceforge.net/**lists/listinfo/avr-llvm-devel<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> >> >> > |