Menu
▾
▴
avr-llvm-devel — Developers mailing list.
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(26) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(14) |
Oct
(16) |
Nov
(36) |
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(17) |
May
(9) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(4) |
| 2012 |
Jan
(22) |
Feb
(12) |
Mar
(39) |
Apr
(31) |
May
(42) |
Jun
(35) |
Jul
(32) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(9) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(121) |
Jul
(61) |
Aug
(7) |
Sep
(8) |
Oct
(6) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Dylan M. <dyl...@gm...> - 2015-01-31 09:36:13
|
I am working on a fork of this repository (located here <https://github.com/dylanmckay/avr-llvm>), which I am adding features, fixing bugs, and implementing missing functionality. I have run into a bug which causes compilation to fail if all optimisations are turned off (see issue #15 <https://github.com/dylanmckay/avr-llvm/issues/15> on GitHub). You can work around the bug by setting the register allocator to 'fast'. I have found a mailing list <https://groups.google.com/d/msg/llvm-dev/UeIaa0Z74lw/w4EAY1HGWgMJ> mentioning the problem, but I can't find any real documentation on it. Does anybody remember any details about it, or is there anywhere that I'm missing where it may be documented? |
|
From: Urs F. <ur...@bi...> - 2014-07-02 21:03:45
|
Hi all, I am trying this backend since I really like to use llvm for avr. But it seems not very active, so I'd like to ask what the plans for this projects are. Is it planed to go llvm-mainline? Is it planed to maintain the code or otherwise, why not? Thanks Urs |
|
From: John M. <ato...@gm...> - 2013-12-12 06:58:28
|
Hi Anton, Great work! What are your build steps? I believe clang should just pass unknown arguments to GCC tools and -mmcu hasn't been added to avr-llvm (clang). The target specific parts we had in were stripped out during the re-write of the back-end. It hasn't been added back in yet, but it wasn't complete anyways. But now that I've read your link I suppose you're not worried that much about the back-end. I don't know much about Arduino but this should help with understanding the different folders (avr/avr-3/avr-4) and -mmcu. http://www.nongnu.org/avr-libc/user-manual/using_tools.html avr-gcc defines these macros based on -mmcu which then allows avr-libc (io.h) to pick the correct header files. On Wed, Dec 11, 2013 at 2:13 AM, Anton Smirnov <de...@an...>wrote: > Hello. > > I was able to compile LLVM+Clang for ARM. > Now i'm trying to use it as toolchain for Arduino and regular llvm build > does not understand "-mmcu" argument. > > You can read my topic on Arduino forum: > http://forum.arduino.cc/index.php?topic=203704.0 > > What should be done to add avr support to llvm/clang? > > Regards, Anton. > > > 2013/10/7 John Myers <ato...@gm...> > >> >> I can't get cmake+ninja to even create the makefile. It says that the c++ >> compiler is broken (unable to compile a simple program), both with clang >> and gcc. >> >> I tried using configure and gcc which will create the makefile if I >> remove the -Wcovered-switch-default switch. But the build fails with a >> bunch of undefined references when trying to link the FileCheck program. >> >> If I try with configure and clang I get a link error like yours were it >> complains about the binary format for ELF not being correct. >> I tried both with and without AVR as the target but it didn't seem to >> change anything. >> >> >> On Tue, Oct 1, 2013 at 1:44 PM, Anton Smirnov <de...@an...>wrote: >> >>> I have followed http://llvm.org/docs/HowToCrossCompileLLVM.htmlguide both on mac and linux but no luck. >>> (I've also tried with -DLLVM_ENABLE_PIC=False as it seems to be the >>> reason of "relocations in ELF" error on linux). >>> >>> Sure, i will be happy to get it finally when you have free time. >>> It would be great to have statically built libclang.so for ARM Linux and >>> x86 Linux. >>> >>> Thanks a lot! >>> Regards, Anton. >>> >>> >>> 2013/10/2 John Myers <ato...@gm...> >>> >>>> Sure, I can try and compile it. I might not have time do to it until >>>> tomorrow though. >>>> >>>> >>>> Which configure options did you use? >>>> >>>> >>>> On Mon, Sep 30, 2013 at 8:14 PM, Anton Smirnov <de...@an...>wrote: >>>> >>>>> Yes, i tried to build llvm + clang for ARM Linux and failed both on >>>>> mac (ld does not support -version-script parameter error) and on linux >>>>> (relocations in ELF error). I tried even with standalone toolchain from >>>>> android ndk but i have another source issue (some functions not found). For >>>>> host i succeed to compile but it's not what i need actually. >>>>> >>>>> Can you try to compile avr-llvm + clang for arm linux in your dev >>>>> environment please? >>>>> >>>>> Regards, Anton. >>>>> >>>>> >>>>> 2013/10/1 John Myers <ato...@gm...> >>>>> >>>>>> Hi Anton, >>>>>> >>>>>> I haven't tried yet, but I don't see any reason building for Android >>>>>> wouldn't work. I've successfully built Windows binaries on Linux. I don't >>>>>> thing there is anything AVR specific that would keep it from cross >>>>>> compiling. >>>>>> >>>>>> There isn't a step-by-step for cross compiling avr-llvm. Once clang >>>>>> and LLVM are patched with the AVR stuff the instructions for cross >>>>>> compiling should be the same as it would be for the regular clang/LLVM. >>>>>> >>>>>> I don't have a Mac to test with. It could be a Mac specific issue. >>>>>> Have you tried building the android binaries on a Linux host? >>>>>> >>>>>> >>>>>> On Mon, Sep 30, 2013 at 12:06 AM, Anton Smirnov < >>>>>> de...@an...> wrote: >>>>>> >>>>>>> Hello. >>>>>>> >>>>>>> Can avr-llvm be hosted on ARM or x86 Linux device (Android to be >>>>>>> more detailed)? >>>>>>> Is there any step-by-step guide for cross-compilation on darwin or >>>>>>> linux machine? >>>>>>> (i've tried to cross-compile original llvm/clang on mac for arm >>>>>>> linux and there is are a lot of unexpected problems) >>>>>>> >>>>>>> Thanks, >>>>>>> Anton. >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> October Webinars: Code for Performance >>>>>>> Free Intel webinars can help you accelerate application performance. >>>>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>>>>> most from >>>>>>> the latest Intel processors and coprocessors. See abstracts and >>>>>>> register > >>>>>>> >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> avr-llvm-devel mailing list >>>>>>> avr...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > |
|
From: Rick M. <rm...@la...> - 2013-10-10 20:13:08
|
Just saw this on the LLVM list, is it in our AVR port as well?
Begin forwarded message:
> From: Behan Webster <be...@co...>
> Subject: [LLVMdev] A new builtin: __builtin_stack_pointer()
> Date: October 10, 2013 12:32:42 PDT
> To: "ll...@cs... List" <ll...@cs...>
> Cc: Mark Charlebois <cha...@gm...>
>
> One of the issues the LLVMLinux project is having is with the use of
> named registers in the Linux kernel code. The kernel uses something like
> this in order to assign a C variable name to a register (one for each
> kernel arch).
>
> register unsigned long current_stack_pointer asm("esp");
>
> clang doesn't allow this kind of thing which required a patch which less
> efficient:
>
> #define current_stack_pointer ({ \
> unsigned long esp; \
> asm("mov %%esp, %0" : "=r"(esp)); \
> esp; \
> })
>
> This works for both gcc and clang, but often adds in 3 extra
> instructions since you need to copy the stack pointer to another
> register, but first that register needs to be saved to the stack and
> then restored after the stackpointer has been used; inefficient.
>
> Another way would be to introduce a new builtin in parallel to others
> like __builtin_return_address(). Essentially adding a
> __builtin_stack_pointer() which does what the above code does. The idea
> would be to get something like this added to both clang and gcc in order
> to make this work across compilers, and across arches.
>
> It ends up being a trivial patch for clang (see below). We're still
> looking for someone to help us on the gcc side.
>
> The goal is to ideally make the kernel code work equally well with both
> compilers (clang and gcc).
>
> Thoughts?
>
> Thanks to Mark Charlebois for writing the patch below.
>
> Behan
>
> --
> Behan Webster
> be...@co...
>
>
> diff --git a/include/clang/Basic/Builtins.def b/include/clang/Basic/Builtins.def
> index 0a513ef..ca68f7e 100644
> --- a/include/clang/Basic/Builtins.def
> +++ b/include/clang/Basic/Builtins.def
> @@ -437,6 +437,7 @@ BUILTIN(__builtin_strstr, "c*cC*cC*", "nF")
> BUILTIN(__builtin_return_address, "v*IUi", "n")
> BUILTIN(__builtin_extract_return_addr, "v*v*", "n")
> BUILTIN(__builtin_frame_address, "v*IUi", "n")
> +BUILTIN(__builtin_stack_pointer, "v*", "n")
> BUILTIN(__builtin_flt_rounds, "i", "nc")
> BUILTIN(__builtin_setjmp, "iv**", "j")
> BUILTIN(__builtin_longjmp, "vv**i", "r")
> diff --git a/lib/CodeGen/CGBuiltin.cpp b/lib/CodeGen/CGBuiltin.cpp
> index d187678..f66f506 100644
> --- a/lib/CodeGen/CGBuiltin.cpp
> +++ b/lib/CodeGen/CGBuiltin.cpp
> @@ -736,6 +736,11 @@ RValue CodeGenFunction::EmitBuiltinExpr(const FunctionDecl *FD,
> Value *F = CGM.getIntrinsic(Intrinsic::frameaddress);
> return RValue::get(Builder.CreateCall(F, Depth));
> }
> + case Builtin::BI__builtin_stack_pointer: {
> + Value *StackAddr =
> + Builder.CreateCall(CGM.getIntrinsic(Intrinsic::stacksave));
> + return RValue::get(StackAddr);
> + }
> case Builtin::BI__builtin_extract_return_addr: {
> Value *Address = EmitScalarExpr(E->getArg(0));
> Value *Result = getTargetHooks().decodeReturnAddress(*this, Address);
>
> _______________________________________________
> LLVM Developers mailing list
> LL...@cs... http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
--
Rick
|
|
From: John M. <ato...@gm...> - 2013-10-07 16:34:52
|
I can't get cmake+ninja to even create the makefile. It says that the c++ compiler is broken (unable to compile a simple program), both with clang and gcc. I tried using configure and gcc which will create the makefile if I remove the -Wcovered-switch-default switch. But the build fails with a bunch of undefined references when trying to link the FileCheck program. If I try with configure and clang I get a link error like yours were it complains about the binary format for ELF not being correct. I tried both with and without AVR as the target but it didn't seem to change anything. On Tue, Oct 1, 2013 at 1:44 PM, Anton Smirnov <de...@an...> wrote: > I have followed http://llvm.org/docs/HowToCrossCompileLLVM.htmlguide both on mac and linux but no luck. > (I've also tried with -DLLVM_ENABLE_PIC=False as it seems to be the > reason of "relocations in ELF" error on linux). > > Sure, i will be happy to get it finally when you have free time. > It would be great to have statically built libclang.so for ARM Linux and > x86 Linux. > > Thanks a lot! > Regards, Anton. > > > 2013/10/2 John Myers <ato...@gm...> > >> Sure, I can try and compile it. I might not have time do to it until >> tomorrow though. >> >> >> Which configure options did you use? >> >> >> On Mon, Sep 30, 2013 at 8:14 PM, Anton Smirnov <de...@an...>wrote: >> >>> Yes, i tried to build llvm + clang for ARM Linux and failed both on mac >>> (ld does not support -version-script parameter error) and on linux >>> (relocations in ELF error). I tried even with standalone toolchain from >>> android ndk but i have another source issue (some functions not found). For >>> host i succeed to compile but it's not what i need actually. >>> >>> Can you try to compile avr-llvm + clang for arm linux in your dev >>> environment please? >>> >>> Regards, Anton. >>> >>> >>> 2013/10/1 John Myers <ato...@gm...> >>> >>>> Hi Anton, >>>> >>>> I haven't tried yet, but I don't see any reason building for Android >>>> wouldn't work. I've successfully built Windows binaries on Linux. I don't >>>> thing there is anything AVR specific that would keep it from cross >>>> compiling. >>>> >>>> There isn't a step-by-step for cross compiling avr-llvm. Once clang and >>>> LLVM are patched with the AVR stuff the instructions for cross compiling >>>> should be the same as it would be for the regular clang/LLVM. >>>> >>>> I don't have a Mac to test with. It could be a Mac specific issue. Have >>>> you tried building the android binaries on a Linux host? >>>> >>>> >>>> On Mon, Sep 30, 2013 at 12:06 AM, Anton Smirnov <de...@an...>wrote: >>>> >>>>> Hello. >>>>> >>>>> Can avr-llvm be hosted on ARM or x86 Linux device (Android to be more >>>>> detailed)? >>>>> Is there any step-by-step guide for cross-compilation on darwin or >>>>> linux machine? >>>>> (i've tried to cross-compile original llvm/clang on mac for arm linux >>>>> and there is are a lot of unexpected problems) >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> October Webinars: Code for Performance >>>>> Free Intel webinars can help you accelerate application performance. >>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>>> most from >>>>> the latest Intel processors and coprocessors. See abstracts and >>>>> register > >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> avr-llvm-devel mailing list >>>>> avr...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >>>>> >>>>> >>>> >>> >> > |
|
From: Anton S. <de...@an...> - 2013-10-07 11:40:36
|
Hey. Any update on this? Regards, Anton. 2013/10/2 Anton Smirnov <de...@an...> > I have followed http://llvm.org/docs/HowToCrossCompileLLVM.htmlguide both on mac and linux but no luck. > (I've also tried with -DLLVM_ENABLE_PIC=False as it seems to be the > reason of "relocations in ELF" error on linux). > > Sure, i will be happy to get it finally when you have free time. > It would be great to have statically built libclang.so for ARM Linux and > x86 Linux. > > Thanks a lot! > Regards, Anton. > > > 2013/10/2 John Myers <ato...@gm...> > >> Sure, I can try and compile it. I might not have time do to it until >> tomorrow though. >> >> >> Which configure options did you use? >> >> >> On Mon, Sep 30, 2013 at 8:14 PM, Anton Smirnov <de...@an...>wrote: >> >>> Yes, i tried to build llvm + clang for ARM Linux and failed both on mac >>> (ld does not support -version-script parameter error) and on linux >>> (relocations in ELF error). I tried even with standalone toolchain from >>> android ndk but i have another source issue (some functions not found). For >>> host i succeed to compile but it's not what i need actually. >>> >>> Can you try to compile avr-llvm + clang for arm linux in your dev >>> environment please? >>> >>> Regards, Anton. >>> >>> >>> 2013/10/1 John Myers <ato...@gm...> >>> >>>> Hi Anton, >>>> >>>> I haven't tried yet, but I don't see any reason building for Android >>>> wouldn't work. I've successfully built Windows binaries on Linux. I don't >>>> thing there is anything AVR specific that would keep it from cross >>>> compiling. >>>> >>>> There isn't a step-by-step for cross compiling avr-llvm. Once clang and >>>> LLVM are patched with the AVR stuff the instructions for cross compiling >>>> should be the same as it would be for the regular clang/LLVM. >>>> >>>> I don't have a Mac to test with. It could be a Mac specific issue. Have >>>> you tried building the android binaries on a Linux host? >>>> >>>> >>>> On Mon, Sep 30, 2013 at 12:06 AM, Anton Smirnov <de...@an...>wrote: >>>> >>>>> Hello. >>>>> >>>>> Can avr-llvm be hosted on ARM or x86 Linux device (Android to be more >>>>> detailed)? >>>>> Is there any step-by-step guide for cross-compilation on darwin or >>>>> linux machine? >>>>> (i've tried to cross-compile original llvm/clang on mac for arm linux >>>>> and there is are a lot of unexpected problems) >>>>> >>>>> Thanks, >>>>> Anton. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> October Webinars: Code for Performance >>>>> Free Intel webinars can help you accelerate application performance. >>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>>> most from >>>>> the latest Intel processors and coprocessors. See abstracts and >>>>> register > >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> avr-llvm-devel mailing list >>>>> avr...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >>>>> >>>>> >>>> >>> >> > |
|
From: Anton S. <de...@an...> - 2013-10-01 20:44:11
|
I have followed http://llvm.org/docs/HowToCrossCompileLLVM.html guide both on mac and linux but no luck. (I've also tried with -DLLVM_ENABLE_PIC=False as it seems to be the reason of "relocations in ELF" error on linux). Sure, i will be happy to get it finally when you have free time. It would be great to have statically built libclang.so for ARM Linux and x86 Linux. Thanks a lot! Regards, Anton. 2013/10/2 John Myers <ato...@gm...> > Sure, I can try and compile it. I might not have time do to it until > tomorrow though. > > > Which configure options did you use? > > > On Mon, Sep 30, 2013 at 8:14 PM, Anton Smirnov <de...@an...>wrote: > >> Yes, i tried to build llvm + clang for ARM Linux and failed both on mac >> (ld does not support -version-script parameter error) and on linux >> (relocations in ELF error). I tried even with standalone toolchain from >> android ndk but i have another source issue (some functions not found). For >> host i succeed to compile but it's not what i need actually. >> >> Can you try to compile avr-llvm + clang for arm linux in your dev >> environment please? >> >> Regards, Anton. >> >> >> 2013/10/1 John Myers <ato...@gm...> >> >>> Hi Anton, >>> >>> I haven't tried yet, but I don't see any reason building for Android >>> wouldn't work. I've successfully built Windows binaries on Linux. I don't >>> thing there is anything AVR specific that would keep it from cross >>> compiling. >>> >>> There isn't a step-by-step for cross compiling avr-llvm. Once clang and >>> LLVM are patched with the AVR stuff the instructions for cross compiling >>> should be the same as it would be for the regular clang/LLVM. >>> >>> I don't have a Mac to test with. It could be a Mac specific issue. Have >>> you tried building the android binaries on a Linux host? >>> >>> >>> On Mon, Sep 30, 2013 at 12:06 AM, Anton Smirnov <de...@an...>wrote: >>> >>>> Hello. >>>> >>>> Can avr-llvm be hosted on ARM or x86 Linux device (Android to be more >>>> detailed)? >>>> Is there any step-by-step guide for cross-compilation on darwin or >>>> linux machine? >>>> (i've tried to cross-compile original llvm/clang on mac for arm linux >>>> and there is are a lot of unexpected problems) >>>> >>>> Thanks, >>>> Anton. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> October Webinars: Code for Performance >>>> Free Intel webinars can help you accelerate application performance. >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the >>>> most from >>>> the latest Intel processors and coprocessors. See abstracts and >>>> register > >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> avr-llvm-devel mailing list >>>> avr...@li... >>>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >>>> >>>> >>> >> > |
|
From: John M. <ato...@gm...> - 2013-10-01 20:39:40
|
Sure, I can try and compile it. I might not have time do to it until tomorrow though. Which configure options did you use? On Mon, Sep 30, 2013 at 8:14 PM, Anton Smirnov <de...@an...>wrote: > Yes, i tried to build llvm + clang for ARM Linux and failed both on mac > (ld does not support -version-script parameter error) and on linux > (relocations in ELF error). I tried even with standalone toolchain from > android ndk but i have another source issue (some functions not found). For > host i succeed to compile but it's not what i need actually. > > Can you try to compile avr-llvm + clang for arm linux in your dev > environment please? > > Regards, Anton. > > > 2013/10/1 John Myers <ato...@gm...> > >> Hi Anton, >> >> I haven't tried yet, but I don't see any reason building for Android >> wouldn't work. I've successfully built Windows binaries on Linux. I don't >> thing there is anything AVR specific that would keep it from cross >> compiling. >> >> There isn't a step-by-step for cross compiling avr-llvm. Once clang and >> LLVM are patched with the AVR stuff the instructions for cross compiling >> should be the same as it would be for the regular clang/LLVM. >> >> I don't have a Mac to test with. It could be a Mac specific issue. Have >> you tried building the android binaries on a Linux host? >> >> >> On Mon, Sep 30, 2013 at 12:06 AM, Anton Smirnov <de...@an...>wrote: >> >>> Hello. >>> >>> Can avr-llvm be hosted on ARM or x86 Linux device (Android to be more >>> detailed)? >>> Is there any step-by-step guide for cross-compilation on darwin or linux >>> machine? >>> (i've tried to cross-compile original llvm/clang on mac for arm linux >>> and there is are a lot of unexpected problems) >>> >>> Thanks, >>> Anton. >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >>> from >>> the latest Intel processors and coprocessors. See abstracts and register >>> > >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> avr-llvm-devel mailing list >>> avr...@li... >>> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >>> >>> >> > |
|
From: Anton S. <de...@an...> - 2013-10-01 03:14:47
|
Yes, i tried to build llvm + clang for ARM Linux and failed both on mac (ld does not support -version-script parameter error) and on linux (relocations in ELF error). I tried even with standalone toolchain from android ndk but i have another source issue (some functions not found). For host i succeed to compile but it's not what i need actually. Can you try to compile avr-llvm + clang for arm linux in your dev environment please? Regards, Anton. 2013/10/1 John Myers <ato...@gm...> > Hi Anton, > > I haven't tried yet, but I don't see any reason building for Android > wouldn't work. I've successfully built Windows binaries on Linux. I don't > thing there is anything AVR specific that would keep it from cross > compiling. > > There isn't a step-by-step for cross compiling avr-llvm. Once clang and > LLVM are patched with the AVR stuff the instructions for cross compiling > should be the same as it would be for the regular clang/LLVM. > > I don't have a Mac to test with. It could be a Mac specific issue. Have > you tried building the android binaries on a Linux host? > > > On Mon, Sep 30, 2013 at 12:06 AM, Anton Smirnov <de...@an...>wrote: > >> Hello. >> >> Can avr-llvm be hosted on ARM or x86 Linux device (Android to be more >> detailed)? >> Is there any step-by-step guide for cross-compilation on darwin or linux >> machine? >> (i've tried to cross-compile original llvm/clang on mac for arm linux and >> there is are a lot of unexpected problems) >> >> Thanks, >> Anton. >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk >> _______________________________________________ >> avr-llvm-devel mailing list >> avr...@li... >> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel >> >> > |
|
From: John M. <ato...@gm...> - 2013-09-30 23:53:08
|
Hi Anton, I haven't tried yet, but I don't see any reason building for Android wouldn't work. I've successfully built Windows binaries on Linux. I don't thing there is anything AVR specific that would keep it from cross compiling. There isn't a step-by-step for cross compiling avr-llvm. Once clang and LLVM are patched with the AVR stuff the instructions for cross compiling should be the same as it would be for the regular clang/LLVM. I don't have a Mac to test with. It could be a Mac specific issue. Have you tried building the android binaries on a Linux host? On Mon, Sep 30, 2013 at 12:06 AM, Anton Smirnov <de...@an...>wrote: > Hello. > > Can avr-llvm be hosted on ARM or x86 Linux device (Android to be more > detailed)? > Is there any step-by-step guide for cross-compilation on darwin or linux > machine? > (i've tried to cross-compile original llvm/clang on mac for arm linux and > there is are a lot of unexpected problems) > > Thanks, > Anton. > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > > |
|
From: Anton S. <de...@an...> - 2013-09-30 07:06:14
|
Hello. Can avr-llvm be hosted on ARM or x86 Linux device (Android to be more detailed)? Is there any step-by-step guide for cross-compilation on darwin or linux machine? (i've tried to cross-compile original llvm/clang on mac for arm linux and there is are a lot of unexpected problems) Thanks, Anton. |
|
From: Borja F. <bor...@gm...> - 2013-09-27 11:21:05
|
Hello,
Currently our avr backend only supports the atmega644 mcu. Your patch about
rcall works for that cpu, but bear in mind that other unsupported
instructions will get generated like mul and friends.
Yes, rcall is shorter and faster to execute but at this stage very few
optimizations are implemented in favour of getting a fully functional
compiler. Indeed rcall is not always safe to use in larger targets, that
should be resolved by the linker when symbols get resolved.
2013/9/27 Matthijs Kooijman <mat...@st...>
> Hi folks,
>
> I just tried avr-llvm for the first time and after I finally properly
> followed the official instructions (I first didn't see that you also
> need a patched clang), I got things to run and compile. I did need a
> tiny patch to make it compile (PCSymbol was removed in llvm r191362):
>
> Index: AVR/MCTargetDesc/AVRMCAsmInfo.cpp
> ===================================================================
> --- AVR/MCTargetDesc/AVRMCAsmInfo.cpp (revision 293)
> +++ AVR/MCTargetDesc/AVRMCAsmInfo.cpp (working copy)
> @@ -22,7 +22,6 @@
> {
> PointerSize = CalleeSaveStackSlotSize = 2;
>
> - PCSymbol = ".";
> CommentString = ";";
> PrivateGlobalPrefix = ".L";
>
>
>
> Running clang for my ATtiny13, I did get another error:
>
> $ clang -Os -I/usr/lib/avr/include -D__AVR_ATtiny13__ -target avr
> -Wno-attributes backpack.c
> /tmp/backpack-7ccd60.s: Assembler messages:
> /tmp/backpack-7ccd60.s:376: Error: illegal opcode call for mcu avr2
> /tmp/backpack-7ccd60.s:462: Error: illegal opcode call for mcu avr2
> /tmp/backpack-7ccd60.s:503: Error: illegal opcode call for mcu avr2
> /tmp/backpack-7ccd60.s:505: Error: illegal opcode call for mcu avr2
> clang-3.4: error: assembler (via gcc) command failed with exit
> code 1 (use -v to see invocation)
>
> I'm not entirely sure if I'm specifying my target CPU correctly, but the
> complaint from the assembler looks valid (the tiny13 really doesn't have
> a call instruction, only icall and rcall).
>
> Looking in the code, I don't see anything for emitting rcall, so I guess
> this is just not implemented yet. If I simply replace the call
> instruction with rcall in the code, my program compiles succesfully.
>
> Index: AVRInstrInfo.td
> ===================================================================
> --- AVRInstrInfo.td (revision 293)
> +++ AVRInstrInfo.td (working copy)
> @@ -812,7 +812,7 @@
> //:TODO: the imm field can be either 16 or 22 bits in devices with
> more
> // than 64k of ROM, fix it once we support the largests devices.
> (ins i16imm:$dst),
> - "call\t$dst",
> + "rcall\t$dst",
> [(AVRcall imm:$dst)]>;
> }
>
>
> This is probably not the best way to fix this, though. Thinking about
> it, I'm not sure what a proper fix would be. For small targets, just
> using rcall is fine. However, for bigger targets, one would want to use
> rcall whenever possible, or fall back to call otherwise. But I don't
> think you can actually know (in all cases) if using rcall is possible
> until after assembling, right?
>
> Gr.
>
> Matthijs
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAlJFVP8ACgkQz0nQ5oovr7w0UwCfWb4uYGSCZdUDxKNB0j7HHRy4
> 4FIAn0kb5n48bjTB996tiqYbm2XqaX0R
> =3NHj
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> avr-llvm-devel mailing list
> avr...@li...
> https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel
>
>
|
|
From: Matthijs K. <mat...@st...> - 2013-09-27 10:30:59
|
Hi folks,
I just tried avr-llvm for the first time and after I finally properly
followed the official instructions (I first didn't see that you also
need a patched clang), I got things to run and compile. I did need a
tiny patch to make it compile (PCSymbol was removed in llvm r191362):
Index: AVR/MCTargetDesc/AVRMCAsmInfo.cpp
===================================================================
--- AVR/MCTargetDesc/AVRMCAsmInfo.cpp (revision 293)
+++ AVR/MCTargetDesc/AVRMCAsmInfo.cpp (working copy)
@@ -22,7 +22,6 @@
{
PointerSize = CalleeSaveStackSlotSize = 2;
- PCSymbol = ".";
CommentString = ";";
PrivateGlobalPrefix = ".L";
Running clang for my ATtiny13, I did get another error:
$ clang -Os -I/usr/lib/avr/include -D__AVR_ATtiny13__ -target avr -Wno-attributes backpack.c
/tmp/backpack-7ccd60.s: Assembler messages:
/tmp/backpack-7ccd60.s:376: Error: illegal opcode call for mcu avr2
/tmp/backpack-7ccd60.s:462: Error: illegal opcode call for mcu avr2
/tmp/backpack-7ccd60.s:503: Error: illegal opcode call for mcu avr2
/tmp/backpack-7ccd60.s:505: Error: illegal opcode call for mcu avr2
clang-3.4: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)
I'm not entirely sure if I'm specifying my target CPU correctly, but the
complaint from the assembler looks valid (the tiny13 really doesn't have
a call instruction, only icall and rcall).
Looking in the code, I don't see anything for emitting rcall, so I guess
this is just not implemented yet. If I simply replace the call
instruction with rcall in the code, my program compiles succesfully.
Index: AVRInstrInfo.td
===================================================================
--- AVRInstrInfo.td (revision 293)
+++ AVRInstrInfo.td (working copy)
@@ -812,7 +812,7 @@
//:TODO: the imm field can be either 16 or 22 bits in devices with more
// than 64k of ROM, fix it once we support the largests devices.
(ins i16imm:$dst),
- "call\t$dst",
+ "rcall\t$dst",
[(AVRcall imm:$dst)]>;
}
This is probably not the best way to fix this, though. Thinking about
it, I'm not sure what a proper fix would be. For small targets, just
using rcall is fine. However, for bigger targets, one would want to use
rcall whenever possible, or fall back to call otherwise. But I don't
think you can actually know (in all cases) if using rcall is possible
until after assembling, right?
Gr.
Matthijs
|
|
From: Borja F. <bor...@gm...> - 2013-09-17 22:57:06
|
Ok now I've seen all your messages in the list. Thanks for getting this done. You only need to recommit that patch that made the PPC bots fail. El lunes, 16 de septiembre de 2013, Borja Ferrer escribió: > Last time I checked it they didnt reply to your message in the commit > list. So try pinging them. > > El lunes, 16 de septiembre de 2013, Stepan Dyatkovskiy escribió: > >> Hello Borja. I hope so. But the way they suggested is a bit problematic >> :-( I'm pushing it... >> -Stepan >> Borja Ferrer wrote: >> >>> 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...> >>> >>> 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<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<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> >>>> >>>> >>> >> |
|
From: Borja F. <bor...@gm...> - 2013-09-16 18:58:59
|
Last time I checked it they didnt reply to your message in the commit list. So try pinging them. El lunes, 16 de septiembre de 2013, Stepan Dyatkovskiy escribió: > Hello Borja. I hope so. But the way they suggested is a bit problematic > :-( I'm pushing it... > -Stepan > Borja Ferrer wrote: > >> 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...> >> >> 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<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<https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel> >>> >>> >> > |
|
From: Stepan D. <stp...@na...> - 2013-09-16 18:27:35
|
Hello Borja. I hope so. But the way they suggested is a bit problematic :-( I'm pushing it... -Stepan Borja Ferrer wrote: > 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...> > > 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
>>
>>
>
|
|
From: John M. <ato...@gm...> - 2013-08-26 20:21:43
|
Hi Antal, l don't believe much progress has been made since those posts on llvm-dev. Some LLVM interfaces will need to change in order for avr-llvm to get merged upstream. Borja, could you submit a patch or get a discussion going on llvm-dev on getting whatever the necessary changes to LLVM added? On Sat, Aug 24, 2013 at 3:42 AM, Szabó Antal <sza...@gm...>wrote: > Hi, > > I've seen some posts on llvm-dev about merging avr-llvm, but there > hasn't been a conclusion. > Is there any progress regarding this? > > > Antal Szabó > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > avr-llvm-devel mailing list > avr...@li... > https://lists.sourceforge.net/lists/listinfo/avr-llvm-devel > |
|
From: Szabó A. <sza...@gm...> - 2013-08-24 10:42:45
|
Hi, I've seen some posts on llvm-dev about merging avr-llvm, but there hasn't been a conclusion. Is there any progress regarding this? Antal Szabó |
|
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-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: 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-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: 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: 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>> > > > > > |
14 messages has been excluded from this view by a project administrator.
