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-74027 Heilbronn
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 * Development engineer
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:
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, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC:
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
As Georg-Johann Lay wrote:
What do you propose?
I'm fine with that option, and think it's a good idea.
--
cheers, Jorg .-.-. --... ...-- -.. . 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:
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 to
As Georg-Johann Lay wrote:
So here is the next version of the patch, returning to printf again
:-)
works for me
--
cheers, Jorg .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have
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.texi
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:
Ok for trunk?
Fine with me, too!
--
cheers, Jorg .-.-. --... ...-- -.. . 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:
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 longer at
all?
I
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, Jorg
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
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, so I
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, AFAIK,
16 matches
Mail list logo
