As Georg-Johann Lay wrote:
> As already discussed, this patch removes the -mshort-calls command
> option from avr-gcc.
> Ok to apply?
I'm more than happy with removing it.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: J
As Oleg Endo wrote:
> I think it's more user friendly to
> first warn and then do.
The problem is that this option would better not have existed straight
from the beginning. When using it, the compiler is at the risk of
generating code that fails to link later, because the relative calls
used co
As Senthil Kumar Selvaraj wrote:
> If ok, could someone commit please? I don't have commit access.
I don't have commit access either, but the changes look reasonable to me.
--
Joerg Wunsch * Development engineer, Dresden, Germany
Atmel Automotive GmbH, Theresienstrasse 2, D-74
The attached patch adds the new ATmega*RFR* devices to AVR-GCC.
If there are no objections, someone please commit it.
--
Joerg Wunsch * Development engineer, Dresden, Germany
Atmel Automotive GmbH, Theresienstrasse 2, D-74027 Heilbronn
Geschaeftsfuehrung: Steven A. Laub, Stephen Cumming
As Georg-Johann Lay wrote:
> Joerg Wunsch wrote:
> >The attached patch adds the new ATmega*RFR* devices to AVR-GCC.
> >[...]
>
> Supply the auto generated files, too. Cf. t-avr, avr-mcus.def etc.
OK, thanks for the reminder. Here is the updated patch.
--
Joerg Wunsch *
As Georg-Johann Lay wrote:
> What do you propose?
I'm fine with that option, and think it's a good idea.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for
As Georg-Johann Lay wrote:
> The problem was reported by Joerg. Does it work for you?
Yes, it works fine.
> + case `echo X|tr X '\101'` in\
> + A) tr -d '\015' < tmp-avr-mmcu.texi > tmp2-avr-mmcu.texi ;; \
> + *) tr -d '\r' < tmp-avr-mmcu.tex
As Richard Henderson wrote:
> Instead of writing to stdout, open the file to write, and open
> it in binary mode. Seems much easier than fighting with conversion
> after the fact.
(Disclaimer: I'm not the author.)
There has been an argument that (some) older implementations might not
be able to
As Georg-Johann Lay wrote:
> If it's appropriate I would also set svn:mime-type to something
> like application/foo but that seems bit odd.
Rather set the svn:eol-style attribute to "LF" instead, I'd say.
But wait a moment, why not setting the svn:eol-style to "native", and
the generator utility
As Georg-Johann Lay wrote:
> So here is the next version of the patch, returning to printf again
> :-)
"works for me"
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't hav
As Georg-Johann Lay wrote:
> There is ATtiny4313 (and maybe others) that have 8-bit SP and 0x100 RAM.
> As RAM starts at 0x60, I wonder what the meaning of SP is?
I think this is simply a bug in the datasheet. The device description
XML file of the ATtiny4313 mentions an SPH register, and it wou
As Georg-Johann Lay wrote:
> Then avr-mcus.def adopted this bug from the manual for ATtiny4313 at least:
>
> AVR_MCU ("attiny4313", ARCH_AVR25, "__AVR_ATtiny4313__", 1 /* short_sp, should
> be 0 ? */, 0, 0x0060, "tn4313")
Not unlikely.
I just ordered one. Hopefully, it will be here by tomorrow
As Georg-Johann Lay wrote:
> With the patch it looks like so:
>
> .
> ./tiny-stack
> ./avr25
> ./avr25/tiny-stack
> ./avr3
> ./avr31
> ./avr35
> ./avr4
> ./avr5
> ./avr51
> ./avr6
>
> -mtiny-stack is a partial multilib option now:
Is there any need to still keep the -mtiny-stack option any long
As Georg-Johann Lay wrote:
> > Is there any need to still keep the -mtiny-stack option any longer at
> > all?
> In the proposed patch the option is needed to trigger the
> appropriate multilib.
OK, then it's fine with me. avr-libc will be taught to handle it,
sooner or later.
--
cheers, J"org
As Georg-Johann Lay wrote:
> Ok for trunk?
Fine with me, too!
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
As Weddington, Eric wrote:
> > Target maintainers: I'd like to understand why it is necessary to
> > disable libssp for AVR, AIX and Microblaze, and libstdc++-v3 for AVR
> > (and what use C++ is on AVR without libstdc++-v3 - do you use another
> > C++ library?). [...]
> Regarding the AVR port, AF
16 matches
Mail list logo
