On Monday 23 May 2005 15:01, Larry Barello wrote:
Before I submit a bug report, is this old news? If the union is aligned
(e.g. the byte array is the same length as the union object) the compiler
is happy. Make them different and it ICE. Put the union on the stack and
the problem goes away.
On Saturday 11 June 2005 03:16, intiha Ho gai wrote:
Hi,
I dont know if this an avr-gcc issue, but it seems that if i am try to
typecast variables in an array of uint32_t to uint64_T as follows:
sumX += (uint64_t)array.x;
(where sumX is an uint64_t var, while array.x is uint32_t),
then this
Hi, I have add '4.1-20050723' snapshot:
3.2.3 3.3.5 3.4.3 4.0.1 4.1
bsearch 69+12 68+12 67+12 65+12 65+12
d2stream479+24 453+25 438+25 471+29 431+27
dtoa_cln183+5 188+5 185+5 199+5 194+5
dtoa_lim312+12 317+12 326+12
Hi all.
I have compared the size of two programs which contain an output
of a string into a stdout. The first uses original Avr-libc.
The second uses the modified library where the stdout connects
at a link stage, and the user is obliged to write base functions
of i/o only.
Results are (in
On Wednesday 07 September 2005 03:55, Joerg Wunsch wrote:
[...]
Oh, you did that work independently from the currently running
discussion about stdio improvements that will be in avr-libc 1.4?
Too bad, I've already get everything ready to commit right now.
I have executed this experiment,
On Monday 26 September 2005 13:50, choo kok seng wrote:
Dear All,
I tried to compile a simple code using SIGNAL API for Attiny2313
target, but I always hit the following warning: main.c:14: warning:
`SIG_OVERFLOW1' appears to be a misspelled signal handler
[...]
This is named
On Thursday 13 October 2005 07:22, Eric Pasquier wrote:
Dear All,
I have implemented a 32-bits time information using the code below.
Timer1 is incremented using internal clock, prescaler=1;
SIG_OVERFLOW interrupt is used to increment a variable used to complete
the 16-bits of Timer1.
In
On Monday 07 November 2005 16:04, Joerg Wunsch wrote:
Follow-up Comment #6, bug #14855 (project avr-libc):
This rather looks like a libgcc bug to me then. libgcc should not
supply anything that is supplied by avr-libc.
Now there is an opportunity to choose, what base float arithmetic
https://savannah.nongnu.org/patch/?func=detailitemitem_id=4611
The macro 'sleep_if' is the unique in Avr-libc which uses a
command 'sei'. Is it the realized choice, to use this command
instead of 'out SREG, old_SREG_value' ? (It is possible to use
'sleep' in a combination to a disabling of
On Saturday 10 December 2005 01:32, Paulo Marques wrote:
Hi, all
A while ago I noticed gcc for i386 sometimes optimized a division with a
constant value by doing a multiply with the inverse in fixed point.
It goes something like:
a / b = (a * (0x1 / b)) / 0x1 (*)
Due to the fact
On Thursday 19 January 2006 17:46, David Brown wrote:
There have already been a dozen answers pointing out the O/P's problem. I
thought you might like to know, however, that there is another way to do an
atomic read of such a counter without disabling interrupts, which can be
useful in some
On Tuesday 07 February 2006 07:24, Joerg Wunsch wrote:
[EMAIL PROTECTED] wrote:
I must have mixed up some of my testing results. Thanks to
lfmorrison from AVRfreaks.
Here's the smallest reproducible test case:
#define STRUCTSIZE 5
struct a {
char z[STRUCTSIZE];
};
extern
Perfectly! Thanks, Anatoly!
This is very needed now.
Whether you plan to add an __AVR_HAVE_LPMX__ ?
One suggestion about 'macros.inc': define __AVR_HAVE_MOVW__
as `1' (not as an empty string). All predefined macroses are
defined as `1' (__AVR__, __AVR_ENHANCED__, __AVR_ATmega8__ ...).
This give
On Thursday 09 February 2006 03:20, Anatoly Sokolov wrote:
Hello.
Whether you plan to add an __AVR_HAVE_LPMX__ ?
I plan to add 'avr55' architecture for ATmega128(x) devices, for which
__AVR_HAVE_ELPM__ is defined.
It will allow to solve a following problem:
Some functions from 'fplib',
Hi.
Very thanks to Björn Haase (and Marek Michalkiewicz)
about ATmega2561 work! This is needed now.
After fluent viewing I had a question on necessity of use of
the instruction `eicall/eijmp' in Avr-gcc. In fact all indirect
calls (and jumps) are carried out to the 16-bit address. It is
On Monday 05 June 2006 10:42, Trampas wrote:
Ok, I know somewhere there is a manual where this information exists, but I
have not found it.
I am using a buffer in an ISR
#define BUFF_SIZE 0x1F
UINT8 Data[BUFF_SIZE];
volatile UINT8 Read;
volatile UINT8 Write;
ISR(xxx)
{
//OK to
Hi.
avr-gcc (GCC) 4.1.1
Compilation of next program (-W -Wall -Os -S):
extern int signbit (double);
int foo (double x)
{
return signbit (x);
}
causes a compilation abort with message:
internal compiler error: in gen_lowpart_general, at rtlhooks.c:51
Older versions
Hi.
I have compile CVS version avr-libc (2007-02-20)
with for different compilers.
Results are below.
AVR: at90s8515 atmega8
avr-gcc version: 3.3.6 3.4.6 4.0.4 4.1.2 3.3.6 3.4.6 4.0.4 4.1.2
On Thursday 22 February 2007 04:37, Bruce D. Lightner wrote:
Dmitry K. wrote:
Hi.
I have compile CVS version avr-libc (2007-02-20)
with for different compilers.
Results are below.
[...]
I assume that the Flash and Stack values are in bytes. What are the
Time units
Hi,
wrong code by avr-gcc 4.1.1:
Program:
~~~
/* This program is compiled as endless loop: condition `c1 != 0'
is not tested. In original (real) program there was an another
error: in conditional expression based on c1 and c2 inside the
loops (here this is removed).
Compiler:
On Wednesday 07 March 2007 04:10, Eric Weddington wrote:
[...]
It seems that when compiling to assembler (-S as Dmitry recommends above),
then you'll note that the epilogue is set to noreturn, which also ends up
taking out the final breq of the outer loop, as there is nothing to branch
to
On Wednesday 07 March 2007 13:18, Eric Weddington wrote:
[...]
Going back to your original code, see the resulting attached files:
bug.lst - The assembler listing after compiling and assembling
bug.dis - The disassembled output from avr-objdump -d bug.o
These files are generated with avr-gcc
On Thursday 08 March 2007 09:41, Shaun Jackman wrote:
On 3/7/07, Eric Weddington [EMAIL PROTECTED] wrote:
Hi Shaun,
Thanks a lot for doing the leg work on this!
But I have a favor to ask: Can you find out approximately *when* this got
fixed? i.e., can you test 4.1.2, and the current
On Friday 06 April 2007 17:10, rtwas wrote:
gcc: avr-gcc (GCC) 4.1.1
libc: avr-libc-1.4.4
[...]
/usr/local/atmel/bin/avr-gcc -g -Os -Wall -mcall-prologues
-mmcu=atmega128 -save-temps main.o spim.o spim_tmr0.o diag.o uart.o
cmd.o cmd_spi.o -o avr_sdiag0.obj
It is interesting, what was a reason to declare
default char as signed for AVR port?
Many other GCC ports use unsigned.
I find only one CPU that is suitable for such
choice: PDP-11, where the shortest method to read
memory (mov_byte_from_memory_to_register) expands
a sign bit.
Dmitry.
Hi.
Below is the results of compiling recent CVS main
branch of Avr-libc with a set of avr-gcc versions.
AVR: at90s8515 atmega8
avr-gcc vers:3.3.6 3.4.6 4.0.4 4.1.2 4.2.0 3.3.6 3.4.6 4.0.4 4.1.2 4.2.0
On Monday 10 December 2007 09:30, John Regehr wrote:
operand. I believe this means that the result of the shift in your
example is a uint16_t, so you get 0xfffe which is then promoted to an
int32_t on assignment to x.
Ok but notice that the same code gives a different result on x86-gcc.
On Wednesday 12 December 2007 01:16, Albert Andras wrote:
- Original Message -
From: Nathan Moore [EMAIL PROTECTED]
unsigned char a, b, c;
c = some_input_function();
LABEL:
a = c/10;
b = c%10;
...
*
LABEL:
mov r24,r18
ldi
On Wednesday 12 December 2007 09:29, Weddington, Eric wrote:
Should we implement 2 (or 3) div functions then in avr-libc? 8, 16, and
32 bit?
Possible, yes. Today the libgcc labrary contains 6 division
functions (8, 16, 32 bits, signed and unsigned), but Avr-libc
includes only 2 links (div,
On Saturday 22 December 2007 02:35, Eric Pasquier wrote:
Hi All,
I am using avr-gcc version 4.1.2 (WinAVR 20070525).
I noticed that the compiler is saving a few registers in the main()
function, so I used the naked attribute.
Does anybody know if this may cause a problem ?
Yes, the
On Friday 21 December 2007 16:15, Weddington, Eric wrote:
[...]
A completely rewritten floating-point library, contributed by Dmitry
Xmelkov. It is smaller and faster, but as it's an almost full rewrite.
A correction is needed:
The speed: yes. But the size is not a strong feature
of new
Hi.
I try to build the avr-gcc 4.3-20080104 snapshot.
Binutils is 2.18.
Build is fault at compilation 'libgcc' for avr35:
illegal opcode movw.
Is there any method to configure GCC to work with
binutils-2.18 ?
Thanks,
Dmitry.
___
AVR-GCC-list
On Tuesday 08 January 2008 16:21, Joerg Wunsch wrote:
Build is fault at compilation 'libgcc' for avr35:
illegal opcode movw.
But avr35 *does* support MOVW, that's the entire point behind it.
It was a strange: xgcc (new) was called with '-mmcu=avr35'
options: but the error message was not
On Tuesday 08 January 2008 22:31, Anatoly Sokolov wrote:
Use patch:
http://sourceware.org/ml/binutils/2008-01/msg00037.html
Thanks. It was a surpise for me, that avr2 (and avr3 now)
are different for avr-gcc and avr-as.
And what is an advantage of a difference of avr2 architecture
for avr-gcc
Very interesting!
I will try this new order with Avr-libc's C-functions
(probably at the nearest week-end).
Today (with default order) the results are:
AVR: at90s8515__ atmega8
GCC: 3.3.6 3.4.6 4.0.4 4.1.2 4.2.2 4.3.X 3.3.6 3.4.6 4.0.4
On Friday 11 January 2008 11:38, Andrew Hutchinson wrote:
I tried they earlier example:
char *p1 = x;
foo(p1++);
foo(p1++);
foo(p1++);
[...]
I am not experienced enough to know why gcc cannot optimise this case.
But it looks like a weakness with gcc (not gcc-avr)
Possible,
Hi.
Summary results for Avr-libc CVS HEAD 2008-01-13, only C-functions.
Values (base variant) are slightly different from ones of 10 Jan,
due to bug #21995 is fixed. GCC 4.3.X is 4.3-20080104 snapshot.
AVR: at90s8515__ atmega8
GCC: 3.3.6
On Monday 14 January 2008 10:55, Andy wrote:
Great work!
morder1 and my order were very close. I think the difference only
becomes apparent when operands are 4 bytes or longer. morder2 is very
bad as early assignment of a byte in an odd register will bump
assignment of wider operands. So
On Wednesday 16 January 2008 22:19, Paulo Marques wrote:
[...]
Attached is a new version with the correction, that runs your test case
just fine.
[...]
Congratulation, Paulo!
Alas, the first (add.c) is still unworked.
add.c:
#define ABORT_PORT 0x49
#define abort() do {
On Thursday 17 January 2008 14:57, Paulo Marques wrote:
Quoting Dmitry K. [EMAIL PROTECTED]:
[...]
Alas, the first (add.c) is still unworked.
Ok, a new version is ready (attached) with this problem fixed (and a
few others). In this version there is a //#define LOG_DUMP 1 line
right
On Friday 18 January 2008 00:30, Weddington, Eric wrote:
I guess most of the tests (if not all) are tests for bugs
that gcc had
at some point, and are there so that gcc doesn't regress. Maybe gcc
never had a bug that involved the complement operation :)
This is correct. It is called the
On Thursday 17 January 2008 22:13, Paulo Marques wrote:
[...]
How do you come up with these tests? You're actually reading avrtest
source code , finding bugs and then coming up with code that exposes
them, aren't you?
Hi Paulo, hi all.
Of course, a reading of source is the best debug method.
On Friday 18 January 2008 13:28, Paulo Marques wrote:
[...]
Say, one of the things I wanted to implement, was something like an
include file with (just a rough sketch):
#define COUNTER_CTRL_PORT 0x56
static void avrtest_counter_start(byte counter)
{
*((volatile unsigned char *)
Hi.
'avr-as --help' (version 2.18) says:
...
-mno-skip-bug disable warnings for skipping two-word instructions
(default for avr4, avr5)
It is needed to add 'avr2' to the default list:
-mno-skip-bug disable warnings for skipping two-word instructions
On Monday 21 January 2008 11:00, Weddington, Eric wrote:
A couple of quick comments/suggestions:
- Please drop -morder1. We generally don't recommend this to users, and
it looks like it really doesn't affect the results that much
- Can you also try with avr-gc 4.2.2 and avr-libc 1.6.1? These
On Wednesday 23 January 2008 02:24, Weddington, Eric wrote:
Can you tell me how you measured code size and number of cycles?
avr-size -- Size of .text, as there are not any data.
(Or avr-objcopy to binary).
Number of cycles: simulavr, set stop point ('-B' option) at exit
from main() (this is
On Wednesday 23 January 2008 12:35, you wrote:
[...]
Why unit at a time compilation produced faster result ? But the code
was totally inlined and perhaps it optimised out something that it
should not have for this purpose.
This Whetstone Benchmark is not a good test. It is
subjected to
On Thursday 24 January 2008 12:28, Andrew Hutchinson wrote:
[...]
I was mistaken, I am using libc l.6.1
[...]
Tried Winavr compiler with same setting and not sure what library
version I have for 4.2
There is no way to tell after its built but I guess it might be 1.2
So instead look at xlib
On Friday 25 January 2008 22:35, Wouter van Gulik wrote:
__clzqi2:
clr r_count ; load with 0
com r_count ; invert (load with -1) + set carry
__clzqi2_loop:
rol r_arg1L ; Rotate through carry
inc r_count ; Carry not touch by inc
On Saturday 26 January 2008 06:24, Joerg Wunsch wrote:
Gre7g Luterman [EMAIL PROTECTED] wrote:
IIRC, it is actually the responsibility of the called
function (the callee) to clear r25 when returning an
unsigned byte. The caller can presume this to be
clear already.
You're right, it's a
On Wednesday 05 March 2008 03:06, Joerg Wunsch wrote:
The better method is to add checking into Avr-libc: as Avr-libc
is busy by ISR vectors, so Avr-libc must to check names. There
is a decision based on C preprocessor's manipulations: it was
disscussed a few years ago.
Do you have a
On Wednesday 05 March 2008 08:16, Dmitry K. wrote:
On Wednesday 05 March 2008 03:06, Joerg Wunsch wrote:
The better method is to add checking into Avr-libc: as Avr-libc
is busy by ISR vectors, so Avr-libc must to check names. There
is a decision based on C preprocessor's manipulations
Hi.
GCC 4.3.0 is available to download.
A few of new bugs are open at gcc-bugzilla:
[35506] New: [avr] 4.3.0 buid error: illegal opcode movw for mcu avr3
[35507] New: [avr] 4.3.0: size of small funcion increases from 2 to 29 words
[35508] New: [avr] 4.3.0: undefined reference to `__ffshi2'
/* The next program is aborted with avr-gcc 4.1.2, 4.2.3, 4.3.0:
result of char promotion comes out of CHAR_MIN/MAX.
Options: -W -Wall -Os
Know to work:
3.3.6, 3.4.6 - good code
4.0.4 - correct, but not the best
4.1.2, 4.2.3, 4.3.0 - without optimization only
*/
On Wednesday 19 March 2008 22:17, Paulo Marques wrote:
Is this strictly wrong, from the C definition point of view?
I know that signed overflow is undefined. How does this test case
interacts with -fwrapv and -fno-strict-overflow?
For those unaware of signed overflow issues, there is a nice
Hi.
Traditionally Avr-libc's longjmp() function uses
the 'eijmp' instruction to make jump (and destroys
EIND register). Does avr6 GCC extension known
about this?
And, in general, what is the status of EIND register?
Is it needed to save/restore in assembler functions?
In inline assembler?
On Saturday 12 April 2008 01:01, Klaus Rudolph wrote:
I have installed gcc 4.3.0 and becomes a bit confused :-)
main ends now with a ret and returns to undefined address from stack?
Bug or feature?
Unfortunately, this is a feature. Since 4.3.0 Avr-gcc considers
the main() as a normal
On Wednesday 16 April 2008 14:02, Andy H wrote:
RFC
A problem has come up trying to fix function pointer arthmetic bugs.
[...]
(It is difficult to understand all quickly.)
A question: Is it safety to use common indirect call
of function with avr6 at present moment? It is interesting,
as
On Thursday 17 April 2008 00:17, Andy wrote:
Indirect calls - ie simple function pointers are safe!
It is only when you try and do some arithmetic with them that there is
potential problem. The only reason to use arithmetic is for ASM related
manipulations. (but very useful!)
For example ,
On Friday 18 April 2008 12:56, Weddington, Eric wrote:
2008/4/17, Wouter van Gulik [EMAIL PROTECTED]:
For a 2 cycles delays an rjmp can be used. Saves an instruction!
And so on:
3 cycles:
rjmp .
nop
I shall try to replace 'nop' with 'rjmp .' for two cycle
delay.
On Sunday 20 April 2008 01:28, Wouter van Gulik wrote:
[...]
../../gcc/config/avr/libgcc.S:280: Error: illegal opcode movw for mcu
avr3
[...]
This is because binutils 2.18 does not support avr architecture 35.
Use binutils 2.18.5 or more recent.
More exactly: this is because binutils 2.18
On Saturday 03 May 2008 03:36, Anatoly Sokolov wrote:
[...]
What your opinion on this offer?
Anatoly.
Hmm... Once we will provide the 'far' allocation, so
we must to provide the method to obtain the address?
Seems, the GET_FAR_ADDRESS() is not a release quality.
Dmitry.
Is the cLib, in general, written as reentrant code?
Specifically floating point (yes), printf and friends?, small
string functions (strcat_P(), etc)? intrinsic like div() and ldiv()?
See:
http://savannah.nongnu.org/bugs/?23128
In addition: the float point functions are not change the
On Thursday 14 May 2009 07:42, Sean D'Epagnier wrote:
[...]
Also, there is the issue of longjmp setting EIND and not restoring it.
It gets a little tricky with interrupts that can potentially set EIND
as well.
Yes, the longjmp() sets EIND. It is impossible to restore EIND,
as the EIJMP is
On Thursday 14 May 2009 09:23, Anatoly Sokolov wrote:
Thanks!
What about to copy yours mail into Avr-libc doc?
[...]
Calling the bootloader code from application code and
calling application from bootloader is PROHIBITED, allowed only jump from
application code to reset vector of bootloader
On Thursday 14 May 2009 09:31, you wrote:
[...]
I like that solution. Is this correct?
Index: setjmp.S
===
RCS file: /sources/avr-libc/avr-libc/libc/stdlib/setjmp.S,v
retrieving revision 1.7
diff -u -r1.7 setjmp.S
---
On Thursday 14 May 2009 14:03, Dmitry K. wrote:
And some optimization is needed to exclude pop/push sequences.
I shall fix this bug (mismatch of longjmp() to Avr-gcc's API)
at the nearest week-end.
Dmitry.
___
AVR-GCC-list mailing list
AVR-GCC-list
I shall fix this bug (mismatch of longjmp() to Avr-gcc's API)
at the nearest week-end.
Done, without any optimization.
Dmitry.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Sean D'Epagnier wrote:
Did you only upgrade avr libc, or also gcc? I noticed that newer gcc
(newer than 4.2.2) versions made my program 14k larger.
The new gcc (4.3.2) using the old libc makes my loader 10 bytes larger
(compared to gcc 4.1.2 using the old libc). So the big bloat still
On Tuesday 26 May 2009 15:19, Joerg Wunsch wrote:
You can apply the Avr-libc patch #6718. It makes the EEPROM
functions compact. (It is not checked with Xmega.)
Xmega isn't supported currently anyway.
Well, I will commit this patch to HEAD (first) branch.
Regards,
Dmitry.
On Thursday 28 May 2009 01:58, Joerg Wunsch wrote:
What aspect(s) of Xmega isn't supported? Not supported by
avr-libc? Or some recent versions of gcc? Or are you just
referring to the EEPROM functions?
Just the EEPROM functions, yes.
In addition, it is needed a clarification about
the
In addition, there is the benchmark table in avr-libc doc.
Regards,
Dmitry.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
72 matches
Mail list logo
