Re: fix for avr-libc-2.0.0/include/util/eu_dst.h

Am 30.10.24 um 14:18 schrieb pjw: Dear All, I think I have fixed a bug in avr-libc-2.0.0include/util/eu_dst.h where the summer time was being imposed after summer time had finished, and vice-versa. To decipher the code:-     if (month == MARCH) {     if (final_sunday < today)

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 as

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 tr

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 AV

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 have

[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" func

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 interna

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 for

[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 is

[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. 2)

[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 -print-multi

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 packs

[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 lo

[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 la

[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 https://gcc.gnu.org/install/configure.html#avr

[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&action=diff +@item -mdouble=@var{bits} +@opindex mdouble +Set the size (in bits) of the @code{doub

[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 be

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

Follow-up Comment #4, bug #57071 (project avr-libc): [comment #3 comment #3:] > Curious, what's the compiler switch to select 32- vs. 64-bit double? I'd like to add a bit of documentation about the entire topic as well. I didn't settle on an interface yet, my preferred choice would be configure o

[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: No

[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: Heade

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: https://www.nongnu.org/avr-libc/user-manual/group

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 in

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 by allocating each of th

[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 #10, patch #9543 (project avr-libc): Ok, better now. At least the trivial example builds now. Some final notes on xmega.h: Constraint "d" for [ccp_ioreg] resp. [ccp_spm_mask] could be relaxed to the less restrictive "r". And from a strict point of view, both _PROTECTED_WRITE

[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 -mmcu

[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 re

[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: ___ Mes

[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 '/srv/local/gnu/build/avrlibc-trunk/av

[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 http://savannah.nongnu.or

[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 http://savannah.nongnu.or

[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 a

[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 FDEV_S

[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". Th

[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

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

Georg-Johann Lay schrieb: 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 o

[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 http://savannah.nongnu.or

[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 ad

[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 ad

[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 knowledge

[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 majo

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 applicatio

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 7

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 than

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 i

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] [bug #49567] Use meta-info from --print-multi-lib and --print-multi-directory

URL: Summary: Use meta-info from --print-multi-lib and --print-multi-directory Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Wed 09 Nov 2016 02:32:38 PM GMT Cat

[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-3.diff Size:12 KB ___ Reply to this item at: ___ Mess

[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: ___ Mess

[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 http://savannah.nongnu.org/

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 f

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 e

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

On 08.12.2016 00:34, George Spelvin wrote: Georg-Johann Lay 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't handle

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

George Spelvin a écrit: 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 As an aside, attached is an AVR asm code (needs MUL) that transforms uint64_t to decimal string. Despite most algorithms, i

Re: [avr-libc-dev] Testsuite (Was: How attached are people ...)

On 06.12.2016 22:39, Joerg Wunsch wrote: I just fixed a few errors in the testsuite where code has been causing warnings or compilation errors. Being still at GCC 5.3.0 here, all the scanf tests stumble across a GCC ICE: Simulate: scanf/sscanf_flt-f1.c /scanf_flt atmega128 ... scanf/sscanf_flt-

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 http://http.debian.net/debian/pool

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] How attached are people to the implementation of rand()/random()?

George Spelvin schrieb: A README in test/simulate would definitely help. Based on my quick glance at things: [...] "You may add new files to the existing test directories freely, but adding a new directory requires updating the list in runtest.sh." However, I can't get it to work. For me, it

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 quit

[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 S

[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 appli

[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 thi

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

-) https://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 compi

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

Jacob Moroni schrieb: Hello, After the C11 spec was finalized, GCC added a bunch of new built-in “__atomic_X” functions to replace the older “__sync_” functions. These atomic functions are generally used by headers, as they were designed to adhere to the C11 memory model, but there’s nothing pr

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 ; avr-libc-dev@nongnu.org; Sivanupandi, Pitchumani ; Selvaraj, Senthil_Kumar Subject: Re: [avr-libc-dev] Need new avr-libc release Joerg Wunsch

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 i

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

URL: 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

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

URL: 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

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

Am 06/18/2015 um 02:58 PM schrieb David Brown: Hi, In the user manual: there is a discussion about the unexpected code generation from: #define cli() __asm volatile( "cli" ::: "memory" ) #define sei() __asm volatile( "sei" ::: "me

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

Am 06/17/2015 um 12:02 PM schrieb Sivanupandi, Pitchumani: All the asms are changing memory but don't mention that. Usually it is not wanted that (non-volatile) memory accesses are dragged across the inline asm. Easy fix is to clobber memory, more exact is to explicitly describe the effect on me

[avr-libc-dev] [bug #44140] wdt_disable() macro clobbers prescaller bits and can cause unexpected resets

Follow-up Comment #4, bug #44140 (project avr-libc): Remaks to https://savannah.nongnu.org/bugs/download.php?file_id=33934 * adds "memory" clobber to all * use constraint "d" with ORI reg * use constraint "n" with SFR_MEM_ADDR * use "n" with some non-address compile time constants * use SFR_

[avr-libc-dev] [bug #44140] wdt_disable() macro clobbers prescaller bits and can cause unexpected resets

Additional Item Attachment, bug #44140 (project avr-libc): File name: wdt-2.diff Size:8 KB ___ Reply to this item at: ___ Nachri

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

Additional Item Attachment, bug #43828 (project avr-libc): File name: wdt-h.diff Size:8 KB ___ Reply to this item at: ___ Nachri

[avr-libc-dev] [bug #45033] stdio.h using "long long" in C90 mode.

URL: Summary: stdio.h using "long long" in C90 mode. Project: AVR C Runtime Library Submitted by: gjlayde Submitted on: Mi 06 Mai 2015 10:57:57 GMT Category: Library

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 ne

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 wit

[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:

  1   2   3   >