[avr-libc-dev] [bug #32988] Internal compiler error: build_unary_op

Follow-up Comment #1, bug #32988 (project avr-libc): This is addressed in http://gcc.gnu.org/PR44643 Besides changes in avr-gcc, definition of include/avr/pgmspace.h:PSTR has to be changed from # define PSTR(s) (__extension__({static char __c[] PROGMEM = (s); &__c[0];})) to # define PSTR(s) (

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

URL: Summary: Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Sa 02 Jul 2011 22:12

[avr-libc-dev] [bug #33716] pgmspace typedefs not legal

Follow-up Comment #1, bug #33716 (project avr-libc): As Bill already wrote, attribute progmem just works by accident in avr-gcc ( and not at all in avr-g++). It appears that const prog_char c = 'a'; works for C and not for C++. However, there is *no* support for progmem in types it in avr-gcc

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #2, bug #33698 (project avr-libc): Hi Eric, XJMP/XCALL look reasonable, but I am not familiar with avr-libc and don't know what is best practice here. ./libm/fplib/log.S is the only module that I am aware of. Maybe there are others that are not as common as log like gamma or be

[avr-libc-dev] [patch #6352] Far pointer library

Follow-up Comment #8, patch #6352 (project avr-libc): > They don't use the ELPM instruction rather, incorrectly, > the LPM instruction. The very problem is that AVR with > 64k flash is a segmented architecture and it's not easy to handle them correctly. For example, ELPM Z+ might change RAMPZ so

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #5, bug #33698 (project avr-libc): > I think that all math libraries are put into their own > linker section, and so will be close enough to use > rcall/rjmp, but this would have to be verified. So ./ld/scripttempl/avr.sc will be arranged to sort .text* input sections?

Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal

Eric Weddington schrieb: Update of bug #33716 (project avr-libc): Status:None => In Progress Percent Complete: 0% => 50% ___ Follow-up Com

Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal

Rather than deprecating the typedefs in pgmspace.h, I would suggest to replace them by respective macros. That would be nice, but I don't think it's possible. There are too many places where: #define prog_uchar unsigned char PROGMEM would behave differently than typedef unsigned char PROGMEM

Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal

Jan Waclawek schrieb: IMO such macros are bad style, there is no reason for them. I already said what is the reasons for them, here: https://savannah.nongnu.org/bugs/?33716 and here http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=871000#871000 . And I repeat, it is a feature f

Re: [avr-libc-dev] [bug #33716] pgmspace typedefs not legal

Jan Waclawek schrieb: >> prog_char as a macro is dreaded. >> >> const prog_char * const p = NULL; >> >> puts p in progmem so it's broken by design. With that users will be taken >> for a ride. > > But it's not the macro which is broken, it's the attribute! > > The manual explains in > http://gc

[avr-libc-dev] [bug #34423] util/crc16.h: with -Os option inline functions are called causing registers value loss

Follow-up Comment #6, bug #34423 (project avr-libc): This is http://gcc.gnu.org/PR46779 which is fixed in 4.6.2+ (09/2011) and not yet released. You or someone alse will have to backport it to 4.5, and as Joerg reports that works without itches. Joerg, would you attach .i or appropriate .c toget

[avr-libc-dev] More .weak in ./crt1/gcrt1.S?

Hi, would it make sense to weaken __vectors and __bad_interrupt in gcrt1.S so that users can implement their own vector table more easily? Regards, Johann ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/

Re: [avr-libc-dev] rjmp across FLASHEND

Bernhard Kuemel schrieb: > Hi! > > My avr-gcc (debian/squeeze, gcc version 4.3.5 (GCC)), as it seems, > doesn't support rjmp across FLASHEND for ATmega168 (16K Flash): > > #include > > .global main > main: > rjmptinyloader > > > .org FLASHEND+1-0x3e > tinyloader: >

[avr-libc-dev] [bug #34560] math.h error while compiling

Follow-up Comment #1, bug #34560 (project avr-libc): math.h's line #462 is the end of the file and empty. Thus math.h:426:15 is no part of math.h and the error message might be misleading because of fuzzyness in compiler location tracking and just as well point to some other header or your source

[avr-libc-dev] [bug #34560] math.h error while compiling

Follow-up Comment #3, bug #34560 (project avr-libc): It's problem in Arduino header, see http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=870506#870506 ___ Reply to this item at:

[avr-libc-dev] [bug #28837] using PSTR with c++ produces warnings

Follow-up Comment #6, bug #28837 (project avr-libc): > Backport the gcc fix :-) > it looks like it could be quite a while before it becomes > available by normal upgrade. avr-gcc's PR34734 is fixed in 4.6.2 and GCC 4.6.2 is available, see http://gcc.gnu.org/gcc-4.6 B

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

Bob Paddock schrieb: All this appears to be specific only to some proprietary lint that unlike gcc doesn't even run everywhere, so not a relevant argument IMHO. It is one of the most common Lints in commercial environments. But why clutter avr-libc with lint? You will have __attribute__((prog

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__(mode)

David Brown a écrit: While I agree with your principle here, I think there is good reason for changing the typedefs in this case - and nothing to lose. People use different tools with their code, such as static error checkers, documentation generators, and "smart" editors like Eclipse. They

[avr-libc-dev] [bug #34719] Check for right build compiler

URL: Summary: Check for right build compiler Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Di 01 Nov 2011 17:08:53 GMT Category: Build Infrastructure

Re: [avr-libc-dev] [bug #28837] using PSTR with C++ produces warnings

Volker Kuhlmann wrote: > Quick heads-up before I rush to work > > On Tue 01 Nov 2011 03:08:57 NZDT +1300, Jörg Wunsch wrote: > >> the newer versions a try. GCC 4.6.2 has just been released, so it's a >> good idea to peek at his work by trying it. > > I've been trying for 3 days now (incl half a

Re: [avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

Joerg Wunsch schrieb: OK, so what's wrong with writing #if defined(__DOXYGEN__) || defined(LINT) then? LINT is the wrong name space; should be __LINT or _LINT ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman

Re: [avr-libc-dev] [avr-gcc-list] [bug #28837] using PSTR with c++ produces warnings

Volker Kuhlmann schrieb: ./configure --disable/enable-shared/static Don't do that. It's stringly discouraged to configure GCC like that: http://gcc.gnu.org/install/configure.html Johann ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http

Re: [avr-libc-dev] [avr-gcc-list] [bug #28837] using PSTR with c++ produces warnings

Joerg Wunsch schrieb: As Georg-Johann Lay wrote: ./configure --disable/enable-shared/static Don't do that. I thought this was referring to the way the prerequisite libraries (gmp, gpc, mpfr) are configured. The easiest way is to not configure them by hand, but let GCC do that in

Re: [avr-libc-dev] The GCC error message

jerrykmhan wrote: > Dear Sir, > > (.text.avr-libc.fplib+0x3e): relocation truncated to fit: R_AVR_13_PCREL > against symbol `__subsf3' defined in .text section in > c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/avr5\libgcc.a(_addsub_sf.o) > make: *** [ION528-V7.elf] Error 1 > > When I used the fu

[avr-libc-dev] [bug #35003] wdt_enable() has a wrong code sequence for many parts

Follow-up Comment #1, bug #35003 (project avr-libc): AFAIK, setting the I-big for non-Xmega devices has a latency of 1 instruction, so the code looks fine. ___ Reply to this item at:

[avr-libc-dev] [bug #35003] wdt_enable() has a wrong code sequence for many parts

Follow-up Comment #2, bug #35003 (project avr-libc): I-bit, of course ___ Reply to this item at: ___ Nachricht geschickt von/durch Savannah http://

Re: [avr-libc-dev] [bug #35003] wdt_enable() has a wrong code sequencefor many parts

Joerg Wunsch wrote: > As Jan Waclawek wrote: > >> Do you find that a sufficient documentation of this feature? > > Strictly, that description is only guaranteed to apply to the SEI > instruction, not to other ways that modify the I flag. Apparently, > this one-instruction delay is implemented in

Re: [avr-libc-dev] Progmem types compatibility

Dmitry schrieb: Hi! There are a bit of worses with deprecation of prog types in 1.8.0. First, look the possibility of usage progmem attribute with a typedef depending on GCC version and source language: C source: typedef char prog_char __attribu

Re: [avr-libc-dev] Progmem types compatibility

Joerg Wunsch wrote: > As Jan Waclawek wrote: > > I agree that having typedefs for the named address space > implementation might be a good thing. They should probably start I am really not sure. There is no read use of such a type, it's just because some guys are to lazy to type some letters. Mo

[avr-libc-dev] [bug #35407] Missing multilib versions for tiny-stack targets

URL: Summary: Missing multilib versions for tiny-stack targets Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mo 30 Jan 2012 19:19:29 GMT Category: Feature Reque

Re: [avr-libc-dev] getting a short interrupt vector table

Bill Westfield schrieb: In the case where a size-limited program is only using one interrupt (this is "usbtiny" on an ATtiny2313, and avr-gcc 4.3.2), is there a good way to get an "abbreviated" vector table instead of having vectors for everything? Jörg, would it help to make ./crt1/gcrt1.S:__v

[avr-libc-dev] [bug #35407] Missing multilib versions for tiny-stack targets

Follow-up Comment #1, bug #35407 (project avr-libc): > If no library is found, the default from avr2 is used Please notice: If no directory avr25/tiny-stack is available and thus the default avr2 is used, the linker will report an error because he cannot find the crtxxx.o startup code. As a cons

[avr-libc-dev] [bug #35496] _FFS: Macro should be obsoleted/no more recommended

URL: Summary: _FFS: Macro should be obsoleted/no more recommended Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Do 09 Feb 2012 21:43:52 GMT Category: Library

[avr-libc-dev] [bug #35500] --gc-sections doesn't track use via --defsym

Follow-up Comment #1, bug #35500 (project avr-libc): > I'm not sure that this is the right place to report > this problem It's not the right place. F'up to binutils [1] and [2]. > In this simple test case, main calls a non-existent > function "foo" and the linker option --defsym,foo=foo2 > is us

[avr-libc-dev] [bug #35539] stdlib.h does not provide EXIT_SUCCESS et al.

URL: Summary: stdlib.h does not provide EXIT_SUCCESS et al. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mi 15 Feb 2012 21:50:54 GMT Category: Header

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #7, bug #33698 (project avr-libc): > IMO, I think the cleaner solution is to: > > 1. Improve the definition of XCALL/XJMP - at present > it's defines call/jmp when __AVR_MEGA__ and rjmp/rcall > otherwise. We need to correct this. That won't catch all cases because sources use R

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #9, bug #33698 (project avr-libc): >> That won't catch all cases because sources use RJMP directly. >> See the initial post for examples. > > I wanted to mean that if we replace all the rjmp/rcalls to > XJMP/XCALLs... I don't think you really want to do *that*! It's 1000s of

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #11, bug #33698 (project avr-libc): Dmitry Xmelkov: > The math library is not designed to use float routines > from libgcc. The float routines of libm are extended in > comparison to standart ones. For example, the 40-bit > float and bit T are widely used (32-bit mantissa). > N

[avr-libc-dev] [bug #35407] Missing multilib versions for tiny-stack targets

Follow-up Comment #3, bug #35407 (project avr-libc): Thanks for the changes. What will happen if a 16-bit SP target in avr2 resp. avr25 is compiled with -mtiny-stack? In that case the compiler assumes SP_H to be always zero. However, the startup code will initialize SP to RAMEND so that SP_H is

[avr-libc-dev] [bug #36454] string.h: Error for long long in C90

URL: Summary: string.h: Error for long long in C90 Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Sa 12 Mai 2012 08:27:10 GMT Category: Header Se

[avr-libc-dev] [bug #36454] string.h: Error for long long in C90

Follow-up Comment #4, bug #36454 (project avr-libc): > Another try: > > -extern int ffsll (long long _val) __ATTR_CONST_; > +__extension__ extern int ffsll (long long _val) __ATTR_CONST_; Yes, looks better. No more complaints. Thanks. __

[avr-libc-dev] [bug #36571] stdint.h: INTn_C not standard compliant

URL: Summary: stdint.h: INTn_C not standard compliant Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Do 31 Mai 2012 20:02:57 GMT Category: Header

[avr-libc-dev] [bug #34695] fixed width int types without __attribute__()

Follow-up Comment #7, bug #34695 (project avr-libc): FYI, the attached files show avr-gcc's understanding of the C99 types with and without -mint8 You can use these defines as a blueprint for the stdin.h headers or use them directly (once a fix for http://gcc.gnu.org/PR46261 is upsteram). The ad

[avr-libc-dev] [bug #36609] pgmspace.h uses constraint "p"

URL: Summary: pgmspace.h uses constraint "p" Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Fr 08 Jun 2012 08:23:28 GMT Category: Header Severity

[avr-libc-dev] [bug #36611] _delay_loop_2 must not use constraint "w" with all targets

URL: Summary: _delay_loop_2 must not use constraint "w" with all targets Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Fr 08 Jun 2012 22:36:27 GMT Category: Hea

[avr-libc-dev] [bug #26734] Unsafe SP register changes in ISR_NOBLOCK interrupt handlers

Follow-up Comment #2, bug #26734 (project avr-libc): With avr-gcc 4.7.1 and higher, attribute interrupt will override attribute signal, see http://gcc.gnu.org/PR53256 and the GCC manual. ___ Reply to this item at:

[avr-libc-dev] [bug #36921] util/delay.h uses inline...

URL: Summary: util/delay.h uses inline... Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mo 23 Jul 2012 10:02:36 GMT Category: Header Severity: 3

Re: [avr-libc-dev] [bug #36921] util/delay.h uses inline...

Weddington, Eric schrieb: I guess it's the larger issue of "What standard does avr-libc comply to? C? C89 is a subset thereof, and the problem is also present with -std=c90. And it can be seen in more headers like math.h IMO it's reasonable if the C modules require some more modern standard

[avr-libc-dev] [bug #37026] ABI documentation and 8-bit integer promotion of function return

URL: Summary: ABI documentation and 8-bit integer promotion of function return Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Sa 04 Aug 2012 12:48:57 GMT Categor

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #12, bug #33698 (project avr-libc): ./libm/fplib/fp_rempio2.S is also affected, see 0: rjmp_U(__fp_nan) rcall _U(__fp_splitA) rjmp_U(__fp_mpack_finite) ___ Reply to this item at:

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #13, bug #33698 (project avr-libc): More modules are: ./libm/fplib/ceil.S ./libm/fplib/exp.S ./libm/fplib/floor.S ./libm/fplib/fma.S and maybe even more. ___ Reply to this item at:

Re: [avr-libc-dev] [bug #37104] ATtiny5/9/10/20/40 interrupt wrapper uses invalid register

Dean Camera wrote in Comment #3, bug #37104 (project avr-libc): can upstream GCC not use the patches Atmel provides in their toolchain releases? The patches must be used atop whatever version Atmel used to build their release, presumably something like gcc_4_6_2_release in http://gcc.gnu.org/

Re: [avr-libc-dev] fflush() implementation

Daniel Otte schrieb: Hi, the current state of fflush() according to stdio.h is: Flush \c stream. This is a null operation provided for source-code compatibility only, as the standard IO implementation currently does not perform any buffering. This is ok for the stream implementation

Re: [avr-libc-dev] fflush() implementation

Weddington, Eric schrieb: On Behalf Of Georg-Johann Lay Daniel Otte schrieb: Hi, the current state of fflush() according to stdio.h is: Flush \c stream. This is a null operation provided for source-code compatibility only, as the standard IO implementation currently does not perform

Re: [avr-libc-dev] the latest release?

Ivan Shmakov schrieb: BTW, what is the latest AVR Libc release? The project's page at Savannah [1] refers to 1.7.1 in the news, while the downloads page has 1.8.0, and I seem to find only a couple mentions of the latter in this mailing list's archive. (No

[avr-libc-dev] [bug #3485] Using float arithmetic without linking with -lm result in incorrect code

Follow-up Comment #6, bug #3485 (project avr-libc): See also the discussion in avr-gcc: Add --with-avrlibc configure option for AVR-Libc ___ Reply to this item at:

Re: [avr-libc-dev] the latest release?

Joerg Wunsch schrieb: As Ivan Shmakov wrote: Supports “long” integers' arithmetics, as well as fixed and floating point numbers, Well, that's more a feature of the compiler. Perhaps you want to replace the “long” by `64-bit' to be more exact? (Though AVR-GCC's 64-bit support, while

[avr-libc-dev] [bug #36581] avr-libc: pgmspace.h is not ANSI compliant

Follow-up Comment #2, bug #36581 (project avr-libc): > The header file pgmspace.h uses the inline-attribute. > This attribute is not part of ANSI C. Similar applies to: include/util/delay.h.in include/util/delay_basic.h ___ Reply to thi

[avr-libc-dev] [bug #37104] ATtiny5/9/10/20/40 interrupt wrapper uses invalid register

Follow-up Comment #4, bug #37104 (project avr-libc): > Can upstream GCC not use the [ATtiny5/9/10/20/40] patches > Atmel provides in their toolchain releases? Atmel never proposed such patches for GCC at gcc-patc...@gcc.gnu.org, at least none I am aware of. AFAIK Atmel's toolchain is based on th

Re: [avr-libc-dev] Possible hole in the assembler interrupt documentation

Joerg Wunsch schrieb: As Dale wrote: The issue then is the case of a library that contains an ISR. That's correct. In this case, you have to cause an explicit undefined reference to it, in order to make the linker even consider pulling the library module. Doesn't the linker look in the lib

[avr-libc-dev] [bug #35240] Incomplete Description of Calling Convention

Follow-up Comment #1, bug #35240 (project avr-libc): For a complete description of the calling conversion, see the avr-gcc AVI in the GCC Wiki: http://gcc.gnu.org/wiki/avr-gcc#Calling_Convention ___ Reply to this item at:

Re: [avr-libc-dev] 1.8.1?

Weddington, Eric wrote: > Hi All, > > It seems like it's been forever since we've had a discussion... > > Do you think we have enough changes in the repo to warrant a 1.8.1 release? #35407 Missing multilib versions for tiny-stack targets is a new feature and needed by people that roll distribu

[avr-libc-dev] [bug #35500] --gc-sections doesn't track use via --defsym

Follow-up Comment #3, bug #35500 (project avr-libc): Whatever it is, it's not an AVR Libc problem as I already said. ___ Reply to this item at: ___ N

[avr-libc-dev] [bug #35539] stdlib.h does not provide EXIT_SUCCESS et al.

Follow-up Comment #3, bug #35539 (project avr-libc): Just do #define EXIT_SUCCESS 0 #define EXIT_FAILURE 1 ___ Reply to this item at: ___ Nachricht

[avr-libc-dev] [bug #35496] _FFS: Macro should be obsoleted/no more recommended

Follow-up Comment #2, bug #35496 (project avr-libc): GCC's optimization for ffs depends on -std=, and users will use ffs and not __builtin_ffs. I'd say close this issue ...because it is tedious to work out in configure whether or not avr-gcc comes with optimized ffs insns and if it's appropriate

[avr-libc-dev] [bug #36611] _delay_loop_2 must not use constraint "w" with all targets

Follow-up Comment #2, bug #36611 (project avr-libc): Factor out the ISA / architecture by means of #if / #ifdef __HAVE_ADIW__ or __HAVE_CONSTRAINT_W__ or __AVR_ARCH__ or whatever your tools provide and use 2-insn decrement alongside with "d". If your tools have __builtin_delay_cycles you can use

[avr-libc-dev] [bug #36571] stdint.h: INTn_C not standard compliant

Follow-up Comment #1, bug #36571 (project avr-libc): Here is the output for -mint8: $ echo | avr-gcc-4.7.2 -x c - -E -dM -mint8 | sort | grep 'INT.*_C' #define __INT16_C(c) c ## L #define __INT32_C(c) c ## LL #define __INT8_C(c) c #define __INTMAX_C(c) c ## LL #define __UINT16_C(c) c ## UL #defi

[avr-libc-dev] [bug #37778] _MemoryBarrier() in cpufunc.h error on compile

Follow-up Comment #1, bug #37778 (project avr-libc): ...and while your are fixing avr/cpufunc.h, don't forget to fix _NOP which reads: #define _NOP() __asm__ __volatile__("nop") but should get a memory barrier: #define _NOP() __asm__ __volatile__("nop" ::: memory)

[avr-libc-dev] [bug #36124] Improve documentation on .bss clear when used in assembler

Follow-up Comment #1, bug #36124 (project avr-libc): Since GCC 3.4, the respective bits of startup code are hosted with GCC (namely as part of libgcc) and not in AVR Libc. It's highly recommended that any user who updates or downgrades or changes vendor / distributor of the toolchain reads all th

[avr-libc-dev] [bug #37825] math.h wrong code and not C90 compliant

URL: Summary: math.h wrong code and not C90 compliant Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mi 28 Nov 2012 23:06:19 GMT Category: Header

Re: [avr-libc-dev] Pow Function in avr8

Jan Waclawek schrieb: Floating point equivalence is not guaranteed so is this comparison valid ? C99 in 5.2.4.2.2#5 says: The accuracy ofthe floating-point operations (+, -, *, /) and of the library functions in and that return floating-point results is implementation-defined [...] The impleme

Re: [avr-libc-dev] Pow Function in avr8

Amine Najahi schrieb: The floating point standard leaves their accuracy implementation defined (for now, this will surely change in the future) which means that as soon as you use one of these functions, your program has probably no chance to be reproducible on a different machine. Well, this

Re: [avr-libc-dev] Pow Function in avr8

Thomas, George schrieb: Also adding to the points mentioned above, is it required to use the logrithms for getting this done as we explicitly say the second argument of pow should be an integer ? This is rather an optimization for the compiler and than map pow to a powi something. IIRC GCC

Re: [avr-libc-dev] Pow Function in avr8

Thomas, George schrieb: If you know that the exponent is integral you may want to have a look at GCC's __builtin_powi* functions. http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html You asked for a base of 2, maybe ldexp() fits your use case. Handling integral exponents separately will incre

Re: [avr-libc-dev] 1.8.1?

Erik Walthinsen wrote: Weddington, Eric wrote: XMega device support is coming out of Atmel. I'm reviewing a second draft of patches for binutils at the moment. Joerg and Georg-Johann have been reviewing this patches as well. So, that means no support for over half of all devices available on t

Re: [avr-libc-dev] 1.8.1?

Weddington, Eric schrieb: Hi Johann, I'm understand your rant, but from my experience, I can't share in it. More comments inline below. Sorry to say that, but supporting each device in the compiler / binutils is bit of --censored--. Y'know it's been this way for over 10 years. And other AVR

Re: [avr-libc-dev] 1.8.1?

Joerg Wunsch schrieb: As Weddington, Eric wrote: Regarding device support, I would hold off doing any work until I can confirm that everything is in order for gcc and avr-libc. The problem with supporting new devices is, without a corresponding addition to binutils and GCC, it could not even

Re: [avr-libc-dev] 1.8.1?

Joerg Wunsch schrieb: As Georg-Johann Lay wrote: They just add startup code, perhaps a linker script to describe memory on their boards and compile for their architecture. Still, if it's not the IDE that does it on their behalf, most of those professional ARM developers are hosed.

Re: [avr-libc-dev] 1.8.1?

Erik Walthinsen schrieb: Honestly I've got to wonder if LLVM does this any better. I know basically nothing about it except that it's not quite up to GCC's standards yet, but it might have potential and be more properly layered. LLVM's structure is cleaner and the code base is younger, so t

Re: [avr-libc-dev] 1.8.1?

Joerg Wunsch schrieb: As Georg-Johann Lay wrote: #35407 Missing multilib versions for tiny-stack targets I agree that we should at least have a glance at the bugs and patches before rolling a new release. One problem is that there is currently no AVR Libc version that can be used with

Re: [avr-libc-dev] 1.8.1?

Joerg Wunsch schrieb: The problem with supporting new devices is, without a corresponding addition to binutils and GCC, it could not even be compile-tested in avr-libc. If it's really the case that avr-libc waits for avr-gcc -mmmcu=device and the compiler waits until avr-libc supports Device,

Re: [avr-libc-dev] 1.8.1?

Joerg Wunsch schrieb: As Georg-Johann Lay wrote: If you use 4.7 with 1.8.0 you'll get a broken toolchain, for example some linux distros or MHV AVR tools 4.7.2. Just in order to demonstrate the breakage caused by this, do you perchance have a small example that shows the problem? Tha

Re: [avr-libc-dev] [Debian Wheezy] crttn13a.o: No such file?

Joerg Wunsch schrieb: As Ivan Shmakov wrote: I've just tried to build a program for ATtiny13A on a recent Debian Wheezy, and got: $ avr-gcc -g -O2 -Wall -pedantic -std=gnu99 -mmcu=attiny13a \ -L/usr/lib/avr/lib/avr25 ../6pp5iouyw6unnen7egfroozp8b.c \ -o 6pp5iouyw6u

[avr-libc-dev] [bug #37951] qsort will throw throws warning

URL: Summary: qsort will throw throws warning Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Di 18 Dez 2012 13:07:20 GMT Category: Library Severi

Re: [avr-libc-dev] [patch #7909] Adding __volatile__ to __asm__ within pgmspace header

Alex Crawford schrieb: Here is a boiled down example of the issue I was seeing: while (pgm_read_word_far(0x) != 0x) { avr109_process(); } Just to make sure everybody has a valid test case (here witha byte access for simplicity): #include extern void avr109_process (void);

[avr-libc-dev] [bug #38021] pgm_read macros don't model the memory accesses

URL: Summary: pgm_read macros don't model the memory accesses Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Fr 04 Jan 2013 13:05:37 GMT Category: Header

[avr-libc-dev] [patch #7909] Adding __volatile__ to __asm__ within pgmspace header

Follow-up Comment #1, patch #7909 (project avr-libc): FYI, I filed this as bug #38021 http://savannah.nongnu.org/bugs/index.php?38021 ___ Reply to this item at: __

[avr-libc-dev] [bug #38021] pgm_read macros don't model the memory accesses

Follow-up Comment #2, bug #38021 (project avr-libc): Jan Waclawek wrote in comment #1: > It is a very bad idea overall. It would increase code size > of existing programs, with little to no benefit except of > a negligibly small group of applications. Would you give a test case from the real worl

[avr-libc-dev] [bug #38025] Documentation misses memcpy_P et at.

URL: Summary: Documentation misses memcpy_P et at. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Sa 05 Jan 2013 19:06:29 GMT Category: Documentation

[avr-libc-dev] [bug #38037] "Building and Installing" needs round-up

URL: Summary: "Building and Installing" needs round-up Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mo 07 Jan 2013 18:17:52 GMT Category: Documentation

Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

Weddington, Eric wrote: > First, I think it's great that you're working on this, and I'm all for > having RTEMS synced with avr-libc, as much as is feasible. > > The current release of avr-libc is 1.8.0, though we've been discussing > recently about fixing a bunch of bugs on HEAD for a future 1.8.

Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

Cynthia Rempel wrote: > The bugs that were listed on the avr-libc bug-tracker looked resolved... > although I'm currently experiencing the joys of trying to get the svn > version of avr-gcc to compile (for testing purposes :). Just stumbled across > ATMEL's Linux Toolset w/patches, > http://distrib

[avr-libc-dev] avr-libc and stdfix.h

avr-gcc 4.8 supports fixed-point arithmetic according to the ISO/IEC TR 18037 "Embedded C" paper. Some parts of stdfix.h that are closely related to avr-gcc could be supplied by the compiler, for other parts that are supplied by avr-libc, it makes sense if avr-libc supplies these bits. This

[avr-libc-dev] [bug #38125] Distribute gcrt1.S

URL: Summary: Distribute gcrt1.S Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: So 20 Jan 2013 15:15:31 GMT Category: Feature Request Severity: 3

[avr-libc-dev] [bug #38135] Install a dummy stdfix-avrlibc.h

URL: Summary: Install a dummy stdfix-avrlibc.h Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mo 21 Jan 2013 18:50:39 GMT Category: Feature Request

Re: [avr-libc-dev] [bug #37778] _MemoryBarrier() in cpufunc.h error on compile

Dmitry Xmelkov a écrit: Follow-up Comment #2: What is the necessity to add memory barrier for _NOP()? Common usage, like: PORTB |= 1; _NOP(); PORTB &= ~1; is safe, as hardware registers are volatile. Question is whether or not NOP should be allowed to be moved across ordinary memor

[avr-libc-dev] [bug #37778] _MemoryBarrier() in cpufunc.h error on compile

Follow-up Comment #3, bug #37778 (project avr-libc): Question is whether or not NOP should be allowed to be moved across ordinary memory moves. For SEI and CLI, for example, I think this is not wanted in general. NOP is less intrusive than SEI / CLI, of course, but avr-gcc emits __builtin_avr_no

[avr-libc-dev] [bug #35483] ./configure does not accept --target

Follow-up Comment #2, bug #35483 (project avr-libc): --host specifies the platform that runs the software, thus --target=avr would be confusing. --host is common practice. For example, if you cross-build libraries like GSL (so that they run on a platform fifferent to the build platform), you spe

[avr-libc-dev] [bug #33698] Explicit use of RJMP/RCALL can cause "relocation truncated to fit: R_AVR_13_PCREL" linker error

Follow-up Comment #15, bug #33698 (project avr-libc): FYI, if the compiler is configured with --with-avrlibc, it will omit functions from libgcc that are known to be provided by libm.a. This is supported in avr-gcc 4.7.2 and up, cf. http://gcc.gnu.org/PR54461 However, I still think AVR-LibC need

[avr-libc-dev] [bug #32945] Wrong PF implementation in pmstring

Follow-up Comment #3, bug #32945 (project avr-libc): If someone fixes this issue, please don't forget to reset RAMPZ to 0 after changing it. This is necessary for devices that have RAMPD. Otherwise, reading vom RAM using indirect Z addressing might read from the wrong address. For devices witho

  1   2   3   >