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-
> 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
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
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
> >
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 .-.-. --... ...
>> 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->
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
> 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"
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.)
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
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
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
12 matches
Mail list logo