Re: About the clang/llvm tool chain for AVR

I am current maintainer of the llvm-avr backend, and I would like to ask for your feedback on my work. My final goal is making clang-llvm-lld-compiler_rt chain fully functional, and let AVR program developers get rid of the GNU tool chain. So any complain/concern/report is welcome. As you are

Re: ATmega3208

Hi, I think this has been applied a week ago or so: https://github.com/avrdudes/avr-libc/commit/afb1ffdb8e35065f7fb5317bb6693311f5eec7a5 Johann Am 06.02.24 um 13:46 schrieb Jürgen Appel via Discussion of avr-libc development: Hej, Some time last fall I had trouble using my atmega3208 and

Re: About the clang/llvm tool chain for AVR

Am 15.01.24 um 04:53 schrieb Ben Shi via Discussion of avr-libc development: Dear AVR-libc developers, I am current maintainer of the llvm-avr backend, and I would like to ask for your feedback on my work. My final goal is making clang-llvm-lld-compiler_rt chain fully functional, and let

Running the AVR-LibC test suite

Trying to run the AVR-LibC test suite, I came across some problems and have some questions. tests/simulate/runtest.sh sets libs as follows: libs="$AVRDIR/avr/lib/$multilibdir/libc.a\ $AVRDIR/avr/lib/$multilibdir/libm.a \ $AVRDIR/avr/lib/$multilibdir/$2/lib$2.a

Why is AVR-LibC still using -fno-jump-tables?

In devtools/gen-avr-lib-tree.sh we have CFLAGS_BIG_MEMORY='-Os $(FNO_JUMP_TABLES)' where FNO_JUMP_TABLES is resolved to -fno-jump-tables by configure. CFLAGS_BIG_MEMORY is then used as build flags for cores and devices with more than 64 KiB of program memory (i.e. with 3-byte PC i.e. that

[patch #9543] Add avrxmega3 devices.

Follow-up Comment #29, patch #9543 (project avr-libc): This patch is best integrated after the changes from https://savannah.nongnu.org/bugs/?49567 and https://savannah.nongnu.org/bugs/?57071 which will greatly reduce the number of conflicts.

Re: can't reproduce documented overflow behavior of _delay_ms()

Am 04.02.20 um 23:05 schrieb Joerg Wunsch: As Georg-Johann Lay wrote: hmmm. So there is more work to do for double support? We definitely do not want double here but float instead... I disagree. This is all just happening in temporary variables inside of "static inline"

Re: can't reproduce documented overflow behavior of _delay_ms()

Joerg Wunsch schrieb: > No, obviously, the documentation is wrong, and the delay functions clip the delay value at a __builtin_avr_delay_cycles() value of UINT_MAX rather than setting it to 0. However, I just revisited the C standard on this. All this is simply undefined behaviour: the

Re: can't reproduce documented overflow behavior of _delay_ms()

Am 23.01.20 um 23:57 schrieb Britton Kerin: On a 16 MHz Arduino Mega 256, this code: __builtin_avr_delay_cycles (100.0); // Compiles, so we apparently have it debug_led_on (); _delay_ms (29.0); debug_led_off (); assert (0); leaves the debug led on for about 269 s. Same

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #13, bug #57071 (project avr-libc): [comment #12 comment #12:] > Here is a small addendum which fixes some problems that I ran into when building avr-libc with avr-gcc v3.4.6: Note: Just the fact that current avr-libc can be built with avr-gcc v3.4.6 does not mean the result

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #12, bug #57071 (project avr-libc): Here is a small addendum which fixes some problems that I ran into when building avr-libc with avr-gcc v3.4.6: 1) The compiler might not recognize -Wno-sign-compare or -Wno-maybe-uninitialized which are used to silence some build warnings.

[bug #49567] Use meta-info from --print-multi-lib and --print-multi-directory

Follow-up Comment #2, bug #49567 (project avr-libc): Attached a new proposal mlib-gen-3.diff that has some minor simplifications and fixes typos in comments. Apart from that, we should remove ./devtools/make-binary-dist.sh as it makes no more sense to have binary distributions because the binary

[bug #49567] Use meta-info from --print-multi-lib and --print-multi-directory

Additional Item Attachment, bug #49567 (project avr-libc): File name: mlib-gen-2.diffSize:75 KB ___ Reply to this item at:

[bug #49567] Use meta-info from --print-multi-lib and --print-multi-directory

Follow-up Comment #1, bug #49567 (project avr-libc): Attached a first draft version. The $(srcdir)/avr tree is now generated by a new Python script mlib-gen.py which should work with Python v2.7 and v3. Which parts of that tree will we used (and how) is determined by configure using

Re: support for atmega4809 family?

Am 08.12.19 um 21:10 schrieb Britton Kerin: I notice there are official arduinos (arduino nano every and variants) which use the 4809 now so there's presumably some support for this chip somewhere. Is it going to show up in my beloved avr-libc? The common approach is to fiddle with device

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #11, bug #57071 (project avr-libc): Hi, here is an updated version of the patch. Compared to the patch proposed in comment #10, it fixes the vfprintf issues: * Treat %f like %lf, same for other float printers. If double is 64 bits, it will only print "?". * Support %Lf for

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #10, bug #57071 (project avr-libc): Here is an updated version of the patch with the following changes: * It also defines alias symbols for long double provided long double = float. * It provides long double prototypes in math.h. * Adds a new file common/alias.h which defines

[patch #9543] Add avrxmega3 devices.

Follow-up Comment #21, patch #9543 (project avr-libc): FYI, support for devices from the 0-series like ATmega4808 (also filed under avrxmega3) has been added to avr-gcc: https://gcc.gnu.org/PR92545 ___ Reply to this item at:

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #9, bug #57071 (project avr-libc): The GCC feature is upstream: https://gcc.gnu.org/r277908 The new configure options are: --with-double={32|64|32,64|64,32} --with-long-double={32|64|32,64|64,32|double} For a documentation, see

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #8, bug #57071 (project avr-libc): FYI, there is the according GCC issue + patch http://gcc.gnu.org/PR92055 >From the doc of https://gcc.gnu.org/bugzilla/attachment.cgi?id=47114=diff +@item -mdouble=@var{bits} +@opindex mdouble +Set the size (in bits) of the @code{double}

[bug #57114] Do not #define abs / labs

URL: Summary: Do not #define abs / labs Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Fri 25 Oct 2019 08:42:00 AM UTC Category: None Severity:

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #7, bug #57071 (project avr-libc): [comment #6 comment #6:] > The current patch is supposed to be a no-op, so that > no observable effect should occur. There are observable effects actually: The patch should also result in the resolution of bug #49984.

[bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #6, bug #57071 (project avr-libc): [comment #5 comment #5:] > Thanks for the explanation. > > I think I'll apply the patch then as is by now, and we might > add some words about the usage later on, when the configuration > is settled. Great. The current patch is supposed to

[avr-libc-dev] [bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #2, bug #57071 (project avr-libc): Here is a version without __asm(symbol) that defines a symbol for double only if sizeof(double) == sizeof(float). * include/math.h (cosf, sinf, tanf, fmodf, modff, sqrtf, cbrtf, hypotf, squaref) (floorf, ceilf, frexpf,

[avr-libc-dev] [patch #9864] Use proper float function names and prototypes.

URL: Summary: Use proper float function names and prototypes. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Thu 17 Oct 2019 08:27:15 AM UTC Category: None

[avr-libc-dev] [bug #57071] Fix math.h and function names that block 64-bit double

Follow-up Comment #1, bug #57071 (project avr-libc): * include/math.h (cos, sin, tan, fmod, modf, sqrt, cbrt, hypot, square, floor, ceil) (frexp, ldexp, exp, cosh, sinh, tanh, asin, acos, atan, atan2) (log, log10, pow, isnan, isinf, signbit, fdim, fma, fmax, fmin)

[avr-libc-dev] [bug #57071] Fix math.h and function names that block 64-bit double

URL: Summary: Fix math.h and function names that block 64-bit double Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Thu 17 Oct 2019 07:10:37 AM UTC Category:

[avr-libc-dev] [bug #56093] Wrong constraint in pgmspace.h::pgm_get_far_address

URL: Summary: Wrong constraint in pgmspace.h::pgm_get_far_address Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Sun 07 Apr 2019 01:00:58 PM UTC Category:

Re: [avr-libc-dev] fwrite() not working as expected

avr-libc-...@nicohood.de schrieb: Hi, I am trying to use fwrite() to write the first X bytes of a string like this, but with a wrong output: auto ret = fwrite("Hello World!", 1, 5, stdout); printf("%d\n", ret); // Output: H0 Its documented here:

Re: [avr-libc-dev] PSTR() in static initialisers

Joerg Wunsch schrieb: As Georg-Johann Lay wrote: If that static is not function-static, then __flash can be used: Thanks for that, Johann. I tried to come up with a __flash-based implementation myself, but didn't get it to work. Maybe your "recipe" would be worth an entry into th

Re: [avr-libc-dev] PSTR() in static initialisers

On 31.01.2018 21:15, Paul "LeoNerd" Evans wrote: On Wed, 31 Jan 2018 21:04:55 +0100 Joerg Wunsch wrote: As Paul "LeoNerd" Evans wrote: Does anyone have a suggestion on how I can have a string pointer to a flash-stored string in a static initialiser? This only works

[avr-libc-dev] [patch #9553] Fix some issues in libc/

URL: Summary: Fix some issues in libc/ Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Wed 24 Jan 2018 04:01:56 PM UTC Category: None Priority: 5

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

Follow-up Comment #8, patch #9543 (project avr-libc): There must still be missing something, at least _PROTECTED_WRITE_SPM. Apart from a build warning for a missing prototype, it's neither resolved by a macro nor my a symbol: $ echo 'int main(){}' | avr-gcc -xc - -Wl,-u,eeprom_write_block

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

Follow-up Comment #6, patch #9543 (project avr-libc): Thanks, I can build avr-libc now and a quick test looks good. Regarding the changes to eewr_block_xmega.c, maybe it's clearer to special-case the different NVM flavours instead of #define + #undef + #define chains? I allowed me to attach a

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

Additional Item Attachment, patch #9543 (project avr-libc): File name: avrxmega3-v4.diff.bz2 Size:283 KB ___ Reply to this item at: ___

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

Follow-up Comment #4, patch #9543 (project avr-libc): With that patch, avr-libc fails to build: ++ Making all in avrxmega3 make[4]: Entering directory '/srv/local/gnu/build/avrlibc-trunk/avr/lib/avrxmega3' Making all in attiny1614 make[5]: Entering directory

[avr-libc-dev] [patch #9405] Add ISR_NOGCCISR macro to avr/interrupt.h

Follow-up Comment #1, patch #9405 (project avr-libc): Ping #1 ___ Reply to this item at: ___ Message sent via/by Savannah

[avr-libc-dev] [patch #9416] AVR_TINY: Avoid conatraint "w" in delay.h

Follow-up Comment #1, patch #9416 (project avr-libc): Ping #1 ___ Reply to this item at: ___ Message sent via/by Savannah

[avr-libc-dev] [patch #9543] Add avrxmega3 devices.

Follow-up Comment #1, patch #9543 (project avr-libc): > Changed files: [...] ChangeLog The delta to ChangeLog is not reasonable, too much lines affected. Usually, ChangeLog is prone to conflicts as each push is touching it; hence it might be more comfortable to supply it as plain text snipped

[avr-libc-dev] [bug #52181] assert should make Serial.flush() before calling abort()

Follow-up Comment #1, bug #52181 (project avr-libc): This is not an avr-libc problem. The stdio routines like prinf are fully synchronous, and there is no buffering. Hence any buffering must emerge from the applicaton's stream implementation, i.e. from the callbacks you are providing with

[avr-libc-dev] [patch #9416] AVR_TINY: Avoid conatraint "w" in delay.h

URL: Summary: AVR_TINY: Avoid conatraint "w" in delay.h Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mon 24 Jul 2017 12:47:36 PM UTC Category: None

[avr-libc-dev] [patch #9405] Add ISR_NOGCCISR macro to avr/interrupt.h

URL: Summary: Add ISR_NOGCCISR macro to avr/interrupt.h Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mon 10 Jul 2017 01:12:15 PM UTC Category: None

[avr-libc-dev] [bug #41435] math library functions in uril/delay.h

Follow-up Comment #2, bug #41435 (project avr-libc): > /* #APP */ > ; 110 "c:\program files (x86)\avr8-gnu-toolchain\avr\include\util\delay_basic.h" 1 > 1: subi r24A,1 > brne 1b > ; 0 "" 2 > /* #NOAPP */ By no means I can see how __STC_HOSTED__ could get you in "A" after "r24".

[avr-libc-dev] [patch #9400] Add avrxmega3 multilibs

URL: Summary: Add avrxmega3 multilibs Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Wed 05 Jul 2017 07:58:48 PM UTC Category: None Priority: 5

Re: [avr-libc-dev] [patch] Add support for avrxmega3.

On 08.06.2017 12:44, Georg-Johann Lay wrote: Hi, this patch adds avrxmega3 support and the 2 multilib versions associated with it. avr-gcc doesn't yet have respective support, but the Makefiles scale accordingly. As is is easier to get something into avr-gcc, and because the libc and gcc must

[avr-libc-dev] [patch #9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.

Follow-up Comment #1, patch #9187 (project avr-libc): Ping #1 ___ Reply to this item at: ___ Message sent via/by Savannah

[avr-libc-dev] [patch] Add support for avrxmega3.

Hi, this patch adds avrxmega3 support and the 2 multilib versions associated with it. avr-gcc doesn't yet have respective support, but the Makefiles scale accordingly. As is is easier to get something into avr-gcc, and because the libc and gcc must agree on the support, I am starting with the

Re: [avr-libc-dev] Approaching #49567: Use meta-info from --print-multi-lib

On 29.05.2017 15:40, Georg-Johann Lay wrote: Hi. This thread is about https://savannah.nongnu.org/bugs/?49567 and how it can be solved. The current implementation is agnostic of gcc's multilib layout and uses much of hard-coded knowledge. This makes it hard to extend avr-gcc and add new

[avr-libc-dev] Approaching #49567: Use meta-info from --print-multi-lib

Hi. This thread is about https://savannah.nongnu.org/bugs/?49567 and how it can be solved. The current implementation is agnostic of gcc's multilib layout and uses much of hard-coded knowledge. This makes it hard to extend avr-gcc and add new multilib variants because avr-libc must always be

[avr-libc-dev] [bug #50811] using -Wl, -u, vfprintf -lprintf_min causes program to grow a lot

Follow-up Comment #9, bug #50811 (project avr-libc): Re. the "compiler thing" mentioned above: avr-gcc might replace a call to printf by a call to puts provided the arguments of printf allows to do so. You can avoid this optimization by means of -fno-builtin-printf which takes away any

[avr-libc-dev] [bug #50987] Not all registers need to be declared volatile

Follow-up Comment #1, bug #50987 (project avr-libc): Would you be a /bit/ more specific? ___ Reply to this item at: ___ Message sent via/by Savannah

Re: [avr-libc-dev] Missed optimizations

On 16.04.2017 19:30, Raul Sanchez wrote: Your email is badly broken, something it terribly wrong with your line breaks. Just wanted to report the following observations in generated code. Target: __AVR_ATtiny85__ Version: AVR gcc 4.6.4 Quite old a version, dates 6 years back which is 6

Re: [avr-libc-dev] Request: gcrt1.S with empty section .init9

Marko Mäkelä schrieb: Hallo Johann, When you need optimizations at a lever where 2 instructions matter, then it's very likely you need a project specific start-up code and linker description anyway. For example, you might truncate the vector table after the last vector used by the

Re: [avr-libc-dev] Request: gcrt1.S with empty section .init9

Marko Mäkelä schrieb: I am trying to move from assembler to C programming on the AVR while avoiding unnecessary overhead. I see that crt1/gcrt1.S contains the following code: .section .init9,"ax",@progbits #ifdef __AVR_ASM_ONLY__ XJMPmain #else/* !__AVR_ASM_ONLY__ */ XCALL

[avr-libc-dev] [bug #49984] fabs missing from libm implementation.

Follow-up Comment #1, bug #49984 (project avr-libc): Some text has been thrown away by the web interface: * Linker error re. missing fabs implementation occurs of compiled with -ffreestanding or with -fno-builtin * Compiler error because of unknown key word "inline" occurrs in C90 mode.

[avr-libc-dev] [bug #49984] fabs missing from libm implementation.

URL: Summary: fabs missing from libm implementation. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Wed 04 Jan 2017 11:19:01 AM GMT Category: Library

Re: [avr-libc-dev] Suggested improvement to

On 02.01.2017 11:58, Marko Mäkelä wrote: Hi all, I am trying to revive my AVR hobby again, this time using the avr-libc, mainly to introduce my kids to low-level programming. I am using a couple of Arduino boards with the ATmega328P. I started with a simple "hello world" program that outputs a

Re: [avr-libc-dev] Even faster decimal code

George Spelvin schrieb: Georg-Johann Lay wrote: We only have multilib granularity, and there are not so many features that are related to the flash size. One is __AVR_HAVE_JMP_CALL__ which applies to devices with >= 16 KiB flash. The next size milestone is __AVR_HAVE_ELPM__ which means >

Re: [avr-libc-dev] Even faster decimal code

George Spelvin schrieb: I mentioned last time trying doing something like this, and now I have it coded up (as utoa_bytes()). Input Decimal bitsmem_toa mem_tod itoanibbles bytes 8 269 220 217 141 143 16 664 462 451 321 273 24 1294

Re: [avr-libc-dev] Printing octal (brain dump)

On 20.12.2016 00:51, George Spelvin wrote: Is 8000 ticks too slow? Is 3000 ticks acceptable? And for what reason? Are 3000 acceptable just because we have an algorithm that performs in 3000 ticks? My strong preference is still to have a one-fits-all algorithm that might very well be slower

Re: [avr-libc-dev] Printing octal (brain dump)

On 19.12.2016 23:05, George Spelvin wrote: Georg-Johann Lay wrote: George Spelvin schrieb: It is unfortunately one instruction longer than ultoa_invert: textdata bss dec hex filename 188 0 0 188 bc ultoa_invert.o 190 0 0 190

Re: [avr-libc-dev] Supporting AVR_TINY, draft HOWTO

George Spelvin schrieb: Having seen Georg-Johann's patch to enable more code on AVR-TINY, I'd like to know how to do it myself. So I've written the following draft of a document explaining how, which might eventually be useful for the project, but currently is for people to point out the error

Re: [avr-libc-dev] Printing octal (brain dump)

George Spelvin schrieb: tl;dr: Beta code included below; it passes my initial testing. I named it _itoa_engine, following "ftoa_engine", but suggestions are welcome. It is unfortunately one instruction longer than ultoa_invert: textdata bss dec hex filename 188 0

[avr-libc-dev] [patch #9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.

URL: Summary: [AVR_TINY]: Support 16-bit xtoa functons and more string functions. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Fri 09 Dec 2016 01:02:16 PM GMT

[avr-libc-dev] [patch #9187] [AVR_TINY]: Support 16-bit xtoa functons and more string functions.

Additional Item Attachment, patch #9187 (project avr-libc): File name: alibc-tiny-2.diff Size:12 KB ___ Reply to this item at: ___

[avr-libc-dev] [patch #8729] [avr/interrupt.h] Add ISR_NOICF, ISR_FLATTEN. Fix namespace of identifiers.

Follow-up Comment #1, patch #8729 (project avr-libc): PING! ___ Reply to this item at: ___ Message sent via/by Savannah

Re: [avr-libc-dev] [untested PATCH] Save 11 instructions in vfprintf_flt.o

George Spelvin schrieb: As part of poking around vfprintf.c, I came across this low-hanging fruit. I'm waiting to test all of my printf changes together, but I thought I'd throw it out for comment early. I presume this sort of thing is okay? Basically, by reversing the sense of the FL_FLTUPP

Re: [avr-libc-dev] I just noticed OPTIMIZE_SPEED

On 06.12.2016 23:59, Joerg Wunsch wrote: As George Spelvin wrote: Perhaps the two different reduction-mod-5 schemes should depend on OPTIMIZE_SPEED? Doesn't really matter much. Since the library is pre-compiled, you cannot map it to the user's -Ox compiler option anyway. As Johann already

Re: [avr-libc-dev] Interested in 64-bit printf support?

On 08.12.2016 00:34, George Spelvin wrote: Georg-Johann Lay <a...@gjlay.de> wrote: The algo is rather slow because it always iterates over all digits, i.e. it won't run faster for small numbers. Have fun! Code size is ~140 bytes. Well, it's bigger (140 > 124), slower, and doesn

Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?

George Spelvin schrieb: Either Debian is running patches atop GNU, or avr-libc test suite has not been adjusted to factor out different gcc versions. The Debian diffs can be found in the right-hand column of https://packages.debian.org/sid/gcc-avr specifically

Re: [avr-libc-dev] How attached are people to the implementation of rand()/random()?

George Spelvin schrieb: Thanks for the help. It's not on the critical path yet, but I would like to get some self-tests working. This looks strange. With avr-libc from trunk and a reasonable up to date avr-gcc (5.2+) the crt should be located in $prefix/avr/lib/avr51/crtatmega128.o Perhaps

Re: [avr-libc-dev] Interested in 64-bit printf support?

On 04.12.2016 23:53, George Spelvin wrote: The developers of the TICC time interval counter are having a problem printing 64-bit integers: https://github.com/TAPR/TICC/blob/master/TO-DO.txt I went to work figuring out how to do that conversion, and after some false starts, came up with some

[avr-libc-dev] [bug #49565] at43usb320 in wrong multilib set

URL: Summary: at43usb320 in wrong multilib set Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Wed 09 Nov 2016 02:03:26 PM GMT Category: Library

[avr-libc-dev] [bug #45701] redundant stack initialization in crt1.o

Follow-up Comment #1, bug #45701 (project avr-libc): The current startup code allows a custom value for SP init by defining symbol __stack , for example: -Wl,--defsym,__stack=0x123 or by defining that symbol in a custom linker description file. Moreover it is not uncommon to (re)start an

[avr-libc-dev] [bug #48473] FAQ: "How do I relocate code to a fixed address?" can be misleading

Follow-up Comment #1, bug #48473 (project avr-libc): If inlining is a problem, then the same applies to cloning. Hence the docs should also recommend __noclone__ and __no_icf__ (provided gcc supports these attributes). ___ Reply to

Re: [avr-libc-dev] C11 Atomics and GCC libatomic

://en.wikipedia.org/wiki/Posting_style#Top-posting On Jun 25, 2016 5:13 PM, "Joerg Wunsch" wrote: As Georg-Johann Lay wrote: As libatomic will need close cooperation with the compiler, I'd recommend to add it to GCC. That would be my recommendation, too. If it's a compile feature, it wo

Re: [avr-libc-dev] Need new avr-libc release

Sivanupandi, Pitchumani schrieb: -Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: 25 January 2016 21:56 To: Joerg Wunsch <joerg_wun...@uriah.heep.sax.de>; avr-libc-dev@nongnu.org; Sivanupandi, Pitchumani <pitchumani.sivanupa...@atmel.com>; Selvaraj, S

Re: [avr-libc-dev] Need new avr-libc release

Joerg Wunsch schrieb: As Sivanupandi, Pitchumani wrote: Can you make a new release? I can give it a try, to see whether "make distcheck" works out of the box. As a quick fix, it could be pointed out on AVR-LibC's front page that 1.8.1 won't work with GCC v5.2+ and at least SVN trunk xyzw

[avr-libc-dev] [patch #8728] [stdio.h] Use __extension__ with long long.

URL: http://savannah.nongnu.org/patch/?8728 Summary: [stdio.h] Use __extension__ with long long. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mi 26 Aug 2015 13:20:27 GMT Category: None

[avr-libc-dev] [patch #8729] [avr/interrupt.h] Add ISR_NOICF, ISR_FLATTEN. Fix namespace of identifiers.

URL: http://savannah.nongnu.org/patch/?8729 Summary: [avr/interrupt.h] Add ISR_NOICF, ISR_FLATTEN. Fix namespace of identifiers. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mi 26 Aug 2015 13:28:10 GMT

Re: [avr-libc-dev] User-manual/optimization.html

Am 06/18/2015 um 02:58 PM schrieb David Brown: Hi, In the user manual: http://www.nongnu.org/avr-libc/user-manual/optimization.html there is a discussion about the unexpected code generation from: #define cli() __asm volatile( cli ::: memory ) #define sei() __asm volatile( sei ::: memory )

Re: [avr-libc-dev] [bug #43828] wdt.h: Wrong inline assembler arguments

Am 04/30/2015 um 12:09 PM schrieb Sivanupandi, Pitchumani: -Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Wednesday, April 29, 2015 3:11 PM To: Sivanupandi, Pitchumani Cc: avr-libc-dev@nongnu.org Subject: Re: [bug #43828] wdt.h: Wrong inline assembler arguments

Re: [avr-libc-dev] [bug #43828] wdt.h: Wrong inline assembler arguments

Am 04/28/2015 um 12:53 PM schrieb Sivanupandi, Pitchumani: Hi Johann, ... Below is the patch to fix this issue. diff --git a/avr-libc/include/avr/wdt.h b/avr-libc/include/avr/wdt.h index [...] Is this change Ok? That patch is malformed, presumably because of missing / spurious spaces or

Re: [avr-libc-dev] [bug #44869] trunk doesn't work with gcc 5.1.0-RC-20150412

Am 04/27/2015 um 04:52 PM schrieb Sivanupandi, Pitchumani: From: Joerg Wunsch [mailto:j...@uriah.heep.sax.de] Yes. If we release from revision r2473 it will work with gcc-5.1, not trunk. If we release from last revision r2474, it will work with gcc trunk, not gcc-5.1. It will also work

[avr-libc-dev] [bug #44869] trunk doesn't work with gcc 5.1.0-RC-20150412

Follow-up Comment #5, bug #44869 (project avr-libc): The GCC 5 release notes say that when avr-gcc is used together with AVR-LibC, that requires at least avr-gcc 5.2: https://gcc.gnu.org/gcc-5/changes.html ___ Reply to this item at:

[avr-libc-dev] [bug #44869] trunk doesn't work with gcc 5.1.0-RC-20150412

Follow-up Comment #1, bug #44869 (project avr-libc): If you want to use avr-gcc 5.0 or 5.1 with avr-libc, avr-libc must not be newer than svn r2473. If you want to use svn r2474 or newer, you need avr-gcc 5.2 or up. ___ Reply to this item

[avr-libc-dev] [bug #44574] Place device-specific libraries in their multilib directory.

URL: http://savannah.nongnu.org/bugs/?44574 Summary: Place device-specific libraries in their multilib directory. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mi 18 Mär 2015 19:10:31 GMT Category:

[avr-libc-dev] [bug #44514] Wrong build option '-mtiny-stack' instead of '-msp8'

URL: http://savannah.nongnu.org/bugs/?44514 Summary: Wrong build option '-mtiny-stack' instead of '-msp8' Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mi 11 Mär 2015 19:37:20 GMT Category: Build

[avr-libc-dev] device libs and spaces

avr-gcc adds the new device specific libraries like dev/atmega8/devlib.a by means if lib_spec, which is defined in the device specific specs file. Here an example for ATmega8: *lib: -lc dev/atmega8/libdev.a%s The %s makes the compiler driver to expand the argument to an absolute

Re: [avr-libc-dev] [Patch] Generalize wdt.h by removing hardcoded device names

Senthil Kumar Selvaraj schrieb: The attached patch to wdt.h gets rid of the huge device specific conditional branches for wdt_enable and wdt_disable. The branching is now based primarily on architecture (xmega, tiny and everything else) and then on the legality of using the OUT instruction to

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

Follow-up Comment #2, bug #38125 (project avr-libc): I'd propose in a place that's part of the default include path so that it can be dragged by #include optional-path/gcrt1.S. Maybe in ./avr/include/util ? Unfortunately gcrt1.S has some dependencies (macros.inc) and some awkward includes

[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

[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

[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

[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

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

URL: http://savannah.nongnu.org/bugs/?38125 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] 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 #38037] Building and Installing needs round-up

URL: http://savannah.nongnu.org/bugs/?38037 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.1

[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 world?

  1   2   >