Menu
▾
▴
avr-llvm-devel
|
From: Stepan D. <stp...@na...> - 2013-07-26 09:33:58
Attachments:
PatchAndConfigs.tar.gz
|
Hello Borja, Thanks for fixes! Especially my stupid pieces of code in AVRAsmPrinter.cpp Back to your post at 01.07.2013: You wrote: [quote] Yes but the first goal now is to have inline asm feature complete xD Then we can move into other places of the library. Taking a look at the previous emails this is what needs still to be done: 1) Implement the missed optimization above for the memory constraint. Also see if you can come with further cases. Remember to add a test case. 2) Implement the stuff in the "C names used in assembler code" section of the avrlibc manual. You mentioned some issues here in a previous email. 3) Implement the a0, a1, etc... constraints. [/quote] 1. Done. 2. I checked it again. It works, though way of IR generation differs from ARM back-end for example. 3. Done. Now, I suppose, we have to work more with clang. But it is difficult since our changes are presented as patches. I had tried to compile avr-libc again. I had found clang bug (generic one: mistreating with builtins): http://llvm.org/bugs/show_bug.cgi?id=16712 Also avr-clang emits wrong sequense for .S files. So I'm using CCAS=avr-gcc. Steps for avr-libc compilation: 0. I'm working with avr-libc, svn r2403. 1. We also need to apply several changes for it (see the patch in attachment). 2. Currently you should rename "clang" with "avr-clang". "ln -s" doesn't works. 'avr-gcc' name was hard-coded in configure.ac, so I did the same with 'avr-clang'. 3. Run configure script as below: $AVR_LIBC_DIR/configure CC=$LLVM_BIN_DIR/avr-clang --build= --host=avr CCAS=avr-gcc A have also attached my config.log file. Currently compilation stopped with unsupported movw instruction for avr2. -Stepan. Borja Ferrer wrote: > Ok, you can commit the patch now. > > > 2013/7/24 Stepan Dyatkovskiy <stp...@na... <mailto:stp...@na...>> > > Borja Ferrer wrote: > > 1) I agree. > > > 3) What happens when you use multibyte constraints with "e" or "b". > > Just had checked it. It works :-) Though I'll add test-cases for > them too. > > > 4) Hah ok, btw no need to check for i64? > > In one of our previous mails we decided to restrict i64 usage, since > avr-gcc doesn't support it properly. > > -Stepan > > > > 2013/7/24 Stepan Dyatkovskiy <stp...@na... > <mailto:stp...@na...> <mailto:stp...@na... > <mailto:stp...@na...>>> > > Hi Borja, > > > > 1) You implemented the "aN" constraint by also allowing > b,c,d > > constraints. I'm not sure if gcc implements this, my > guess is > that only > > "a" is needed. Please check to see what gcc does here. > > For b,c,d avr-gcc acts like it meet %a. I think its wrong and > untested behaviour, so I just restricted usage to single > 'a' character. > > > > 2) Make getAlternativeRegName return a char instead of a > string > since we > > only need to return one letter. > > Done > > > > 3) Related to the changes in AVRISelLowering.cpp, do we > need to care > > about more register constraints apart of the ones you > already > covered? > > What you mean? I think all constraints are covered now. If > no, we > can find out it during compilation (avr-libc, arduino, etc). > > > > 4) Now that wider types have been covered, please check > if the > assert I > > commented out in AVRISelLowering.cpp in the inline asm > code can be > > removed or what. > > I replaced this assertion with error message. Suppose its > better > than killing the compiler :-) > > New patch is attached. > > -Stepan. > > > Borja Ferrer wrote: > > Hello Stepan, > The patch looks good, but I have some questions/comments: > > 1) You implemented the "aN" constraint by also allowing > b,c,d > constraints. I'm not sure if gcc implements this, my > guess is > that only > "a" is needed. Please check to see what gcc does here. > 2) Make getAlternativeRegName return a char instead of > a string > since we > only need to return one letter. > 3) Related to the changes in AVRISelLowering.cpp, do we > need to care > about more register constraints apart of the ones you > already > covered? > 4) Now that wider types have been covered, please check > if the > assert I > commented out in AVRISelLowering.cpp in the inline asm > code can be > removed or what. > > > > 2013/7/24 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...>>>> > > > Hello Borja, > Here is the new patch for multibyte reference. > Please look > at new > tests to see what was implemented exactly. > To fix issue I described in previous letter I've > added new reg > classes that contains pairs of 8 bit registers: > If we pass i32 parameter that should be split onto > four 8 > bit regs, > we set i16 register class first, then it would be > replaced > with 8 > bit registers if needed. Currently I see it is the > only > solution > that doesn't touch vmcore. > > -Stepan. > > Stepan Dyatkovskiy wrote: > > Hello Borja, > Great. I have found out next inline-asm issue. > When you pass i32 bit type, it could be split > onto two > registers > only, > no matter which register class you set for it. > This > behaviour is > implemented in > SelectionDAGBuilder::______visitInlineAsm. > > I think I'll > > implement simplest version of ExpandInlineAsm > today, > that will fix > operand types properly. > > -Stepan > > Borja Ferrer wrote: > > I've been adding fixes to pass a ton of > regression > in the > Generic folder. > Currently there are two tests that fail with a > "cannot select > build_pair" related to adding 16bit reg > classes in the > inline asm code. > The rest of failing tests are related with not > being able to > run llc > with -O0. There's a serious codegen bug > that i spotted > yesterday while > doing the fixes that I need to work on. > > > 2013/7/22 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, > > 3) Yes, it's the second case. It's > explained in > http://www.nongnu.org/avr-______libc/user-manual/inline_asm.______html > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html> > > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html > <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html>> > > > > > <http://www.nongnu.org/avr-____libc/user-manual/inline_asm.____html > <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html> > > <http://www.nongnu.org/avr-__libc/user-manual/inline_asm.__html > <http://www.nongnu.org/avr-libc/user-manual/inline_asm.html>>> > but in case there are any doubts > basically it > works > the same way as > multibyte constraints except that > when you see an > "aN", where N is a > number, you should print the alternative > regname. Of > course this > should only work for X Y and Z, not > sure how gcc > complains when you > use another register, or maybe it > ignores it and > prints the normal > register name. > > > > > > > ------------------------------______--------------------------__--__--__------------------ > > > See everything from the browser to the > database with > AppDynamics > Get end-to-end visibility with application > monitoring from > AppDynamics > Isolate bottlenecks and diagnose root cause in > seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.______net/gampad/clk?id=48808831&__iu=____/4140/ostg.clktrk > > > <http://pubads.g.doubleclick.____net/gampad/clk?id=48808831&__iu=__/4140/ostg.clktrk > > <http://pubads.g.doubleclick.__net/gampad/clk?id=48808831&iu=__/4140/ostg.clktrk > <http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk>>> > > _____________________________________________________ > avr-llvm-devel mailing list > avr-llvm-devel@lists.__sourcef____orge.net > <http://sourcef__orge.net> > <http://sourceforge.net> > <mailto:avr-llvm-devel@lists. > <mailto:avr-llvm-devel@lists.>____sourceforge.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>> > > > <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>>> > > > > > > > |
|
From: Stepan D. <stp...@na...> - 2013-07-28 18:36:19
|
Exactly. You got assertion due to incorrect inlineasm instruction. I had also failed to reproduce this behavoiur for reduced case. This bug fired for big source only. Try compile that big source with -emit-llvm, and lookup inline asm (there is some variable with name, that ends with "m10", perhaps you recheck that name in .c file). I can attach result IR file with string number reference a bit later, currently I'm stucking in traffic jam :-(
-Stepan
> 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...>
>
>> 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" \
>>
>> "lpm" "\n\t" \
>> "mov %B0, r0" "\n\t" \
>> "adiw r30, 1" "\n\t" \
>> "lpm" "\n\t" \
>>
>> "mov %C0, r0" "\n\t" \
>> "adiw r30, 1" "\n\t" \
>> "lpm" "\n\t" \
>> "mov %D0, r0" "\n\t" \
>>
>> : "=r" (__result), "=z" (__addr16) \
>> : "1" (__addr16) \
>> : "r0" \
>>
>> ); \
>>
>> __result; \
>> }))
>> unsigned long inlineasm(unsigned int addr)
>> {
>> return __LPM_dword_classic__(addr);
>> }
>>
>> clang produces:
>>
>> define i32 @inlineasm(i16 %addr) #0 {
>>
>> entry:
>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov ${0:A}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16 %addr) #2, !srcloc !4
>>
>> %asmresult = extractvalue { i32, i16 } %0, 0
>> ret i32 %asmresult
>> }
>>
>> No truncations here as far i can tell. Try this code and see what you get.
--
Truly yours,
Stepan Dyatkovskiy
|
|
From: Stepan D. <stp...@na...> - 2013-07-28 19:16:54
|
> 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...>
>
>> 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...>
>>
>>> 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" \
>>>
>>> "lpm" "\n\t" \
>>> "mov %B0, r0" "\n\t" \
>>> "adiw r30, 1" "\n\t" \
>>> "lpm" "\n\t" \
>>>
>>> "mov %C0, r0" "\n\t" \
>>> "adiw r30, 1" "\n\t" \
>>> "lpm" "\n\t" \
>>> "mov %D0, r0" "\n\t" \
>>>
>>> : "=r" (__result), "=z" (__addr16) \
>>> : "1" (__addr16) \
>>> : "r0" \
>>>
>>> ); \
>>>
>>> __result; \
>>> }))
>>> unsigned long inlineasm(unsigned int addr)
>>> {
>>> return __LPM_dword_classic__(addr);
>>> }
>>>
>>> clang produces:
>>>
>>> define i32 @inlineasm(i16 %addr) #0 {
>>>
>>> entry:
>>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov ${0:A}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16 %addr) #2, !srcloc !4
>>>
>>> %asmresult = extractvalue { i32, i16 } %0, 0
>>> ret i32 %asmresult
>>> }
>>>
>>> No truncations here as far i can tell. Try this code and see what you get.
--
Truly yours,
Stepan Dyatkovskiy
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 19:46:57
|
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...>
>
>
> > 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...>
> >
> >> 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...>
> >>
> >>> 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" \
> >>>
> >>> "lpm" "\n\t" \
> >>> "mov %B0, r0" "\n\t" \
> >>> "adiw r30, 1" "\n\t" \
> >>> "lpm" "\n\t" \
> >>>
> >>> "mov %C0, r0" "\n\t" \
> >>> "adiw r30, 1" "\n\t" \
> >>> "lpm" "\n\t" \
> >>> "mov %D0, r0" "\n\t" \
> >>>
> >>> : "=r" (__result), "=z" (__addr16) \
> >>> : "1" (__addr16) \
> >>> : "r0" \
> >>>
> >>> ); \
> >>>
> >>> __result; \
> >>> }))
> >>> unsigned long inlineasm(unsigned int addr)
> >>> {
> >>> return __LPM_dword_classic__(addr);
> >>> }
> >>>
> >>> clang produces:
> >>>
> >>> define i32 @inlineasm(i16 %addr) #0 {
> >>>
> >>> entry:
> >>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov ${0:A},
> r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, r0\0A\09adiw r30,
> 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:D},
> r0\0A\09", "=r,=z,1,~{r0}"(i16 %addr) #2, !srcloc !4
> >>>
> >>> %asmresult = extractvalue { i32, i16 } %0, 0
> >>> ret i32 %asmresult
> >>> }
> >>>
> >>> No truncations here as far i can tell. Try this code and see what you
> get.
>
>
> --
> Truly yours,
> Stepan Dyatkovskiy
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-28 21:35:36
|
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...>
> 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...>
>
>>
>>
>> > 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...>
>> >
>> >> 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...>
>> >>
>> >>> 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" \
>> >>>
>> >>> "lpm" "\n\t" \
>> >>> "mov %B0, r0" "\n\t" \
>> >>> "adiw r30, 1" "\n\t" \
>> >>> "lpm" "\n\t" \
>> >>>
>> >>> "mov %C0, r0" "\n\t" \
>> >>> "adiw r30, 1" "\n\t" \
>> >>> "lpm" "\n\t" \
>> >>> "mov %D0, r0" "\n\t" \
>> >>>
>> >>> : "=r" (__result), "=z" (__addr16) \
>> >>> : "1" (__addr16) \
>> >>> : "r0" \
>> >>>
>> >>> ); \
>> >>>
>> >>> __result; \
>> >>> }))
>> >>> unsigned long inlineasm(unsigned int addr)
>> >>> {
>> >>> return __LPM_dword_classic__(addr);
>> >>> }
>> >>>
>> >>> clang produces:
>> >>>
>> >>> define i32 @inlineasm(i16 %addr) #0 {
>> >>>
>> >>> entry:
>> >>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov ${0:A},
>> r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, r0\0A\09adiw r30,
>> 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:D},
>> r0\0A\09", "=r,=z,1,~{r0}"(i16 %addr) #2, !srcloc !4
>> >>>
>> >>> %asmresult = extractvalue { i32, i16 } %0, 0
>> >>> ret i32 %asmresult
>> >>> }
>> >>>
>> >>> No truncations here as far i can tell. Try this code and see what you
>> get.
>>
>>
>> --
>> Truly yours,
>> Stepan Dyatkovskiy
>>
>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-29 13:39:31
|
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): 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...>> > > 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...>> > > > > > 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...>> > > > >> 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...>> > >> > >>> 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" \ > >>> > >>> "lpm" "\n\t" \ > >>> "mov %B0, r0" "\n\t" \ > >>> "adiw r30, 1" "\n\t" \ > >>> "lpm" "\n\t" \ > >>> > >>> "mov %C0, r0" "\n\t" \ > >>> "adiw r30, 1" "\n\t" \ > >>> "lpm" "\n\t" \ > >>> "mov %D0, r0" "\n\t" \ > >>> > >>> : "=r" (__result), "=z" (__addr16) \ > >>> : "1" (__addr16) \ > >>> : "r0" \ > >>> > >>> ); \ > >>> > >>> __result; \ > >>> })) > >>> unsigned long inlineasm(unsigned int addr) > >>> { > >>> return __LPM_dword_classic__(addr); > >>> } > >>> > >>> clang produces: > >>> > >>> define i32 @inlineasm(i16 %addr) #0 { > >>> > >>> entry: > >>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov > ${0:A}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, > r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, > 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16 > %addr) #2, !srcloc !4 > >>> > >>> %asmresult = extractvalue { i32, i16 } %0, 0 > >>> ret i32 %asmresult > >>> } > >>> > >>> No truncations here as far i can tell. Try this code and > see what you get. > > > -- > Truly yours, > Stepan Dyatkovskiy > > > |
|
From: Stepan D. <stp...@na...> - 2013-07-29 13:46:56
|
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):
>
> 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...>>
>>
>> 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...>>
>>
>>
>>
>> > 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...>>
>> >
>> >> 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...>>
>> >>
>> >>> 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" \
>> >>>
>> >>> "lpm" "\n\t" \
>> >>> "mov %B0, r0" "\n\t" \
>> >>> "adiw r30, 1" "\n\t" \
>> >>> "lpm" "\n\t" \
>> >>>
>> >>> "mov %C0, r0" "\n\t" \
>> >>> "adiw r30, 1" "\n\t" \
>> >>> "lpm" "\n\t" \
>> >>> "mov %D0, r0" "\n\t" \
>> >>>
>> >>> : "=r" (__result), "=z" (__addr16) \
>> >>> : "1" (__addr16) \
>> >>> : "r0" \
>> >>>
>> >>> ); \
>> >>>
>> >>> __result; \
>> >>> }))
>> >>> unsigned long inlineasm(unsigned int addr)
>> >>> {
>> >>> return __LPM_dword_classic__(addr);
>> >>> }
>> >>>
>> >>> clang produces:
>> >>>
>> >>> define i32 @inlineasm(i16 %addr) #0 {
>> >>>
>> >>> entry:
>> >>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov
>> ${0:A}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B},
>> r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30,
>> 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16
>> %addr) #2, !srcloc !4
>> >>>
>> >>> %asmresult = extractvalue { i32, i16 } %0, 0
>> >>> ret i32 %asmresult
>> >>> }
>> >>>
>> >>> No truncations here as far i can tell. Try this code and
>> see what you get.
>>
>>
>> --
>> Truly yours,
>> Stepan Dyatkovskiy
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-29 14:33:07
|
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...> > 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> >> ): >> >> 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...>**> >>> >>> 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...>> >>> >>> >>> >>> > 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...>**> >>> > >>> >> 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...>**> >>> >> >>> >>> 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" \ >>> >>> >>> >>> "lpm" "\n\t" \ >>> >>> "mov %B0, r0" "\n\t" \ >>> >>> "adiw r30, 1" "\n\t" \ >>> >>> "lpm" "\n\t" \ >>> >>> >>> >>> "mov %C0, r0" "\n\t" \ >>> >>> "adiw r30, 1" "\n\t" \ >>> >>> "lpm" "\n\t" \ >>> >>> "mov %D0, r0" "\n\t" \ >>> >>> >>> >>> : "=r" (__result), "=z" (__addr16) \ >>> >>> : "1" (__addr16) \ >>> >>> : "r0" \ >>> >>> >>> >>> ); \ >>> >>> >>> >>> __result; \ >>> >>> })) >>> >>> unsigned long inlineasm(unsigned int addr) >>> >>> { >>> >>> return __LPM_dword_classic__(addr); >>> >>> } >>> >>> >>> >>> clang produces: >>> >>> >>> >>> define i32 @inlineasm(i16 %addr) #0 { >>> >>> >>> >>> entry: >>> >>> %0 = tail call { i32, i16 } asm sideeffect "lpm\0A\09mov >>> ${0:A}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, >>> r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, r0\0A\09adiw r30, >>> 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", "=r,=z,1,~{r0}"(i16 >>> %addr) #2, !srcloc !4 >>> >>> >>> >>> %asmresult = extractvalue { i32, i16 } %0, 0 >>> >>> ret i32 %asmresult >>> >>> } >>> >>> >>> >>> No truncations here as far i can tell. Try this code and >>> see what you get. >>> >>> >>> -- >>> Truly yours, >>> Stepan Dyatkovskiy >>> >>> >>> >>> >> >> ------------------------------**------------------------------** >> ------------------ >> >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.**net/gampad/clk?id=48808831&iu=** >> /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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> >> >> > |
|
From: Stepan D. <stp...@na...> - 2013-07-29 16:17:07
|
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...>> > > 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>): > > 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...>>__> > > 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...>>> > > > > > 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...>>__> > > > >> 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...>>__> > >> > >>> 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" \ > >>> > >>> "lpm" "\n\t" \ > >>> "mov %B0, r0" "\n\t" \ > >>> "adiw r30, 1" "\n\t" \ > >>> "lpm" "\n\t" \ > >>> > >>> "mov %C0, r0" "\n\t" \ > >>> "adiw r30, 1" "\n\t" \ > >>> "lpm" "\n\t" \ > >>> "mov %D0, r0" "\n\t" \ > >>> > >>> : "=r" (__result), "=z" (__addr16) \ > >>> : "1" (__addr16) \ > >>> : "r0" \ > >>> > >>> ); \ > >>> > >>> __result; \ > >>> })) > >>> unsigned long inlineasm(unsigned int addr) > >>> { > >>> return __LPM_dword_classic__(addr); > >>> } > >>> > >>> clang produces: > >>> > >>> define i32 @inlineasm(i16 %addr) #0 { > >>> > >>> entry: > >>> %0 = tail call { i32, i16 } asm sideeffect > "lpm\0A\09mov > ${0:A}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:B}, > r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, > r0\0A\09adiw r30, > 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", > "=r,=z,1,~{r0}"(i16 > %addr) #2, !srcloc !4 > >>> > >>> %asmresult = extractvalue { i32, i16 } %0, 0 > >>> ret i32 %asmresult > >>> } > >>> > >>> No truncations here as far i can tell. Try > this code and > see what you get. > > > -- > Truly yours, > Stepan Dyatkovskiy > > > > > > ------------------------------__------------------------------__------------------ > > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from > AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.__net/gampad/clk?id=48808831&iu=__/4140/ostg.clktrk > <http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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> > > > |
|
From: Borja F. <bor...@gm...> - 2013-07-29 16:33:51
|
You mean in the header (top) of the .S file instead of the footer no? 2013/7/29 Stepan Dyatkovskiy <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... >> >> >> >> >> 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> >> >): >> >> >> 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...>* >> *>__> >> >> 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...>>> >> >> >> >> >> > 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...>**>__> >> > >> >> 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...>**>__> >> >> >> >>> 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" \ >> >>> >> >>> "lpm" "\n\t" \ >> >>> "mov %B0, r0" "\n\t" \ >> >>> "adiw r30, 1" "\n\t" \ >> >>> "lpm" "\n\t" \ >> >>> >> >>> "mov %C0, r0" "\n\t" \ >> >>> "adiw r30, 1" "\n\t" \ >> >>> "lpm" "\n\t" \ >> >>> "mov %D0, r0" "\n\t" \ >> >>> >> >>> : "=r" (__result), "=z" (__addr16) \ >> >>> : "1" (__addr16) \ >> >>> : "r0" \ >> >>> >> >>> ); \ >> >>> >> >>> __result; \ >> >>> })) >> >>> unsigned long inlineasm(unsigned int addr) >> >>> { >> >>> return __LPM_dword_classic__(addr); >> >>> } >> >>> >> >>> clang produces: >> >>> >> >>> define i32 @inlineasm(i16 %addr) #0 { >> >>> >> >>> entry: >> >>> %0 = tail call { i32, i16 } asm sideeffect >> "lpm\0A\09mov >> ${0:A}, r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov >> ${0:B}, >> r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, >> r0\0A\09adiw r30, >> 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", >> "=r,=z,1,~{r0}"(i16 >> %addr) #2, !srcloc !4 >> >>> >> >>> %asmresult = extractvalue { i32, i16 } %0, 0 >> >>> ret i32 %asmresult >> >>> } >> >>> >> >>> No truncations here as far i can tell. Try >> this code and >> see what you get. >> >> >> -- >> Truly yours, >> Stepan Dyatkovskiy >> >> >> >> >> >> ------------------------------**__----------------------------** >> --__------------------ >> >> >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from >> AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.__**net/gampad/clk?id=48808831&iu=** >> __/4140/ostg.clktrk >> <http://pubads.g.doubleclick.**net/gampad/clk?id=48808831&iu=** >> /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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<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> >> > >> >> >> >> > |
|
From: Stepan D. <stp...@na...> - 2013-07-29 16:39:01
Attachments:
avr-libc-1.s
avr-libc-1-good.s
|
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...>> > > 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...>>> > > > 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>>): > > > 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...>>__>__> > > 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...>>>> > > > > > > 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...>>__>__> > > > >> 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...>>__>__> > >> > >>> 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" \ > >>> > >>> "lpm" "\n\t" \ > >>> "mov %B0, r0" "\n\t" \ > >>> "adiw r30, 1" "\n\t" \ > >>> "lpm" "\n\t" \ > >>> > >>> "mov %C0, r0" "\n\t" \ > >>> "adiw r30, 1" "\n\t" \ > >>> "lpm" "\n\t" \ > >>> "mov %D0, r0" "\n\t" \ > >>> > >>> : "=r" (__result), "=z" (__addr16) \ > >>> : "1" (__addr16) \ > >>> : "r0" \ > >>> > >>> ); \ > >>> > >>> __result; \ > >>> })) > >>> unsigned long inlineasm(unsigned int > addr) > >>> { > >>> return __LPM_dword_classic__(addr); > >>> } > >>> > >>> clang produces: > >>> > >>> define i32 @inlineasm(i16 %addr) #0 { > >>> > >>> entry: > >>> %0 = tail call { i32, i16 } asm > sideeffect > "lpm\0A\09mov > ${0:A}, r0\0A\09adiw r30, > 1\0A\09lpm\0A\09mov ${0:B}, > r0\0A\09adiw r30, 1\0A\09lpm\0A\09mov ${0:C}, > r0\0A\09adiw r30, > 1\0A\09lpm\0A\09mov ${0:D}, r0\0A\09", > "=r,=z,1,~{r0}"(i16 > %addr) #2, !srcloc !4 > >>> > >>> %asmresult = extractvalue { i32, i16 > } %0, 0 > >>> ret i32 %asmresult > >>> } > >>> > >>> No truncations here as far i can > tell. Try > this code and > see what you get. > > > -- > Truly yours, > Stepan Dyatkovskiy > > > > > > > ------------------------------____----------------------------__--__------------------ > > > See everything from the browser to the database with > AppDynamics > Get end-to-end visibility with application monitoring from > AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.____net/gampad/clk?id=48808831&iu=____/4140/ostg.clktrk > > <http://pubads.g.doubleclick.__net/gampad/clk?id=48808831&iu=__/4140/ostg.clktrk > <http://pubads.g.doubleclick.net/gampad/clk?id=48808831&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>> > > > > > |
|
From: Borja F. <bor...@gm...> - 2013-07-29 16:48:12
|
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... >> >> >> >> 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...>>> >> >> >> 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> >> >>): >> >> >> 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...>>__>__> >> >> 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...>>>> >> >> >> >> >> > 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...>>__>__> >> > >> >> 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...>>__>__> >> >> >> >>> 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" \ >> > > |
|
From: Stepan D. <stp...@na...> - 2013-07-29 16:56:34
|
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...>>
>
> 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...>>>
>
>
> 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>>>):
>
>
> 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...>>__>__>
>
> 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...>>>>
>
>
>
>
> > 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...>>__>__>
> >
> >> 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...>>__>__>
> >>
> >>> 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" \
>
|
|
From: Borja F. <bor...@gm...> - 2013-07-29 17:04:10
|
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...>
> 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...>>
>>
>> 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...>>>
>>
>>
>> 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...>**>__>__>
>>
>> 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...>>>>
>>
>>
>>
>>
>> > 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...>**>__>__>
>> >
>> >> 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...>**>__>__>
>> >>
>> >>> 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" \
>>
>>
>
|
|
From: Stepan D. <stp...@na...> - 2013-07-29 18:22:18
Attachments:
avr-libc.patch
|
Gotcha!!!
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" \
>
>
>
|
|
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
>
|
|
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>
>>
>>
>
|
|
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>
>
>
>
|
|
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>> > > > > > |
|
From: John M. <ato...@gm...> - 2013-07-31 04:08:47
|
> 3) Commit this patch to SVN, and create a new directory for it, John any > suggestions about the dir structure for this? > I would just make a /branches/patches directory and place the avr-libc patch there. |
|
From: Borja F. <bor...@gm...> - 2013-08-06 10:55:26
|
Ok then, Stepan commit your patch for avrlibc when you can. Ping Eric? El miércoles, 31 de julio de 2013, John Myers escribió: > > 3) Commit this patch to SVN, and create a new directory for it, John any >> suggestions about the dir structure for this? >> > > I would just make a /branches/patches directory and place the avr-libc > patch there. > |
|
From: Weddington, E. <Eri...@at...> - 2013-08-06 11:47:27
|
Hi Borja, John, My apologies. I haven't been following this thread closely. What's the issue? Eric > -----Original Message----- > From: Borja Ferrer [mailto:bor...@gm...] > Sent: Tuesday, August 06, 2013 4:55 AM > To: John Myers > Cc: avr-llvm > Subject: Re: [avr-llvm-devel] Inline assembly. > > Ok then, Stepan commit your patch for avrlibc when you can. > > Ping Eric? > > El miércoles, 31 de julio de 2013, John Myers escribió: > > > > 3) Commit this patch to SVN, and create a new directory for > it, John any suggestions about the dir structure for this? > > > > > I would just make a /branches/patches directory and place the > avr-libc patch there. > |
|
From: Borja F. <bor...@gm...> - 2013-08-07 13:04:56
|
Hello Eric, Stepan managed to compile avrlibc with the llvm backend adding a few patches to the library source code. Now we would like to test if the generated code is correct, so are there any tests to check this? Also he mentioned getting a test board to run the tests if necessary, what do you think? 2013/8/6 Weddington, Eric <Eri...@at...> > Hi Borja, John, > > My apologies. I haven't been following this thread closely. > > What's the issue? > > Eric > > > -----Original Message----- > > From: Borja Ferrer [mailto:bor...@gm...] > > Sent: Tuesday, August 06, 2013 4:55 AM > > To: John Myers > > Cc: avr-llvm > > Subject: Re: [avr-llvm-devel] Inline assembly. > > > > Ok then, Stepan commit your patch for avrlibc when you can. > > > > Ping Eric? > > > > El miércoles, 31 de julio de 2013, John Myers escribió: > > > > > > > > 3) Commit this patch to SVN, and create a new directory for > > it, John any suggestions about the dir structure for this? > > > > > > > > > > I would just make a /branches/patches directory and place the > > avr-libc patch there. > > > > |
|
From: Borja F. <bor...@gm...> - 2013-08-09 10:42:42
|
Hello Stepan, Don't worry about it now, enjoy your vacation :) 2013/8/9 Stepan Dyatkovskiy <stp...@na...> > Sorry guys, I'm on vocation till 22nd of August. Currently I'm in > mountains and not able to compile anything. Though, if you want to commit > it ASAP, I can consult you by email. > > Sincerely, > Stepan Dyatkovskiy > > > 06.08.2013, 14:55, "Borja Ferrer" <bor...@gm...>: > > Ok then, Stepan commit your patch for avrlibc when you can. > > Ping Eric? > > El miércoles, 31 de julio de 2013, John Myers escribió: > > > > 3) Commit this patch to SVN, and create a new directory for it, John any > suggestions about the dir structure for this? > > > I would just make a /branches/patches directory and place the avr-libc > patch there. > > , > > > ------------------------------------------------------------------------------ > 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=48897031&iu=/4140/ostg.clktrk > > , > > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > |
|
From: Borja F. <bor...@gm...> - 2013-09-16 17:56:52
|
Stepan did your patch ever get commited to the clang repo?
El viernes, 9 de agosto de 2013, Borja Ferrer escribió:
> Hello Stepan,
>
> Don't worry about it now, enjoy your vacation :)
>
>
>
> 2013/8/9 Stepan Dyatkovskiy <stp...@na... <javascript:_e({}, 'cvml',
> 'stp...@na...');>>
>
>> Sorry guys, I'm on vocation till 22nd of August. Currently I'm in
>> mountains and not able to compile anything. Though, if you want to commit
>> it ASAP, I can consult you by email.
>>
>> Sincerely,
>> Stepan Dyatkovskiy
>>
>>
>> 06.08.2013, 14:55, "Borja Ferrer" <bor...@gm...<javascript:_e({}, 'cvml', 'bor...@gm...');>
>> >:
>>
>> Ok then, Stepan commit your patch for avrlibc when you can.
>>
>> Ping Eric?
>>
>> El miércoles, 31 de julio de 2013, John Myers escribió:
>>
>>
>>
>> 3) Commit this patch to SVN, and create a new directory for it, John any
>> suggestions about the dir structure for this?
>>
>>
>> I would just make a /branches/patches directory and place the avr-libc
>> patch there.
>>
>> ,
>>
>>
>> ------------------------------------------------------------------------------
>> 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=48897031&iu=/4140/ostg.clktrk
>>
>> ,
>>
>> _______________________________________________
>> avr-llvm-devel mailing list
>> avr...@li... <javascript:_e({}, 'cvml',
>> 'avr...@li...');>
>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>>
>>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X