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

2016-12-07 Thread Georg-Johann Lay
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()?

2016-12-07 Thread George Spelvin
> I'd propose you use GCC trunk HEAD and Binutils master; if that and > rerunning bootstrap does not do the trick, you found a bug and I > wonder how the folks are testing avr-libc :-) I'm working on compiling GCC trunk, but it has required a little debugging. The build has failed a couple of tim

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

2016-12-07 Thread Joerg Wunsch
As George Spelvin wrote: > Simulate: regression/bug-22828.c atmega128 ... /tmp/cciW6XcS.o: In function > `main': > ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:50: undefined > reference to `eeprom_write_block' > ~/avr/avr-libc/avr-libc/tests/simulate/regression/bug-22828.c:52: u

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

2016-12-07 Thread Joerg Wunsch
As Georg-Johann Lay wrote: > >Simulate: scanf/sscanf_flt-f1.c /scanf_flt atmega128 ... > >scanf/sscanf_flt-f1.c: In function 'main': > >scanf/sscanf_flt-f1.c:162:1: internal compiler error: in push_reload, at > >reload.c:1380 > > } > > ^ > >no stack trace because unwind library not available > >

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

2016-12-07 Thread Joerg Wunsch
As George Spelvin wrote: > Er... AFAICT, that option has nothing to do with -O compiler > flags, but is set as part of library compilation. I know. I've never really been happy with that, but it's been in use for so long, so it won't be changed. -- cheers, Joerg .-.-. --... ...

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

2016-12-07 Thread George Spelvin
>> Simulate: stdlib/dtostrf-01.c atmega128 ... In file included from >> stdlib/dtostrf-01.c:36:0: >> stdlib/dtostrf.h: In function 'run_dtostrf': >> stdlib/dtostrf.h:99:8: warning: assignment discards 'const' qualifier from >> pointer target type [-Wdiscarded-array-qualifiers] >> pv = & pt->

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

2016-12-07 Thread Joerg Wunsch
As George Spelvin wrote: > I just updated and it's still there. Commit 2532 got the one in > avr-libc/tests/simulate/stdlib/dtostre.h, but the one I tripped over in > dtostrf.h is still there. Ah OK. Then I missed it, somehow. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL

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

2016-12-07 Thread George Spelvin
> Ah OK. Then I missed it, somehow. Here's my patch. (ObLegalese: Yes, *of course* I grant permission for this, and anything else I post to avr-libc-dev, to be distributed under the terms of the 3-clause BSD license in the LICENSE file.) BTW, is there a reason avr-libc doesn't use the "__flash"

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

2016-12-07 Thread Joerg Wunsch
As George Spelvin wrote: > > Ah OK. Then I missed it, somehow. > > Here's my patch. Thanks, committed. > (ObLegalese: Yes, *of course* I grant permission for > this, and anything else I post to avr-libc-dev, to be distributed under > the terms of the 3-clause BSD license in the LICENSE file.)

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

2016-12-07 Thread Georg-Johann Lay
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

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

2016-12-07 Thread George Spelvin
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 flag so it has the same po

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

2016-12-07 Thread George Spelvin
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 sizes *other* than 64 bits, so that's not terribly use