Nabble - AVR - Libc - Dev

[bug #28135] malloc(): expand the last free chunk when expanding __brkval

2009-11-30T14:41:39Z

Additional Item Attachment, bug #28135 (project avr-libc):

File name: bug-28135.diff Size:2 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28135>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #28135] malloc(): expand the last free chunk when expanding __brkval

2009-11-30T14:38:06Z

URL:
<http://savannah.nongnu.org/bugs/?28135>

Summary: malloc(): expand the last free chunk when expanding
__brkval
Project: AVR C Runtime Library
Submitted by: kanchev
Submitted on: Mon 30 Nov 2009 10:38:05 PM GMT
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: libc code
Status: None
Percent Complete: 100%
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Release: 1.7.*
Fixed Release: None

_______________________________________________________

Details:

This bug covers the situation described in patch #6895 and bug #27235.
I've added an alternative patch for this bug and a test case for
regressions.

Quote from patch #6895:
"Situation:
a = malloc(10);
b = malloc(10);
free(b);
Now there is a free chunk at the end of the used area of the heap.
b = malloc(20);
The new request can not be satisfied by any free chunk, therefore the used
area needs to be expanded."

_______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Mon 30 Nov 2009 10:38:05 PM GMT Name:
malloc-expand-last-free-chunk.diff Size: 702B By: kanchev
make malloc() expand the last free chunk when expanding __brkval
<http://savannah.nongnu.org/bugs/download.php?file_id=19165>

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28135>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #25723] Realloc corrupts free list when growing into the next free item

2009-11-30T10:40:34Z

Follow-up Comment #8, bug #25723 (project avr-libc):

Stefan Ernst came across the same regression and filed it as bug #27242. I've
posted a patch there which should fix the problem.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?25723>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #27242] realloc: serious error when size shrinks

2009-11-30T10:36:02Z

Follow-up Comment #2, bug #27242 (project avr-libc):

I've attached a patch and a regression test for this bug. The patch passes my
test cases and also the test cases of bug #25723 which caused this
regression.

This was a very serious bug, I hope that all of it is fixed now.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?27242>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #27242] realloc: serious error when size shrinks

2009-11-30T10:25:35Z

Additional Item Attachment, bug #27242 (project avr-libc):

File name: bug-27242.diff Size:2 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?27242>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #27242] realloc: serious error when size shrinks

2009-11-30T10:22:53Z

Additional Item Attachment, bug #27242 (project avr-libc):

File name: realloc-regression-25723.diff Size:1 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?27242>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: Re: [bug #28108] bug with winavr20090313

2009-11-30T04:01:49Z

David,

>This is a closer but it is still not enough to be able to help you. We
>need a code /snippet/ - cut down the code to the minimal necessary so
>that we can compile the code and see the problem.

There is no point in forcing the OP to do so. The bug is related to an extensive use of registers by attempt of the optimiser to keep "common subexpressions" (constants) across the function, combined with error in choice of "upper" register to load a constant; and is hard to reproduce in a simplified setup.

The attachment is fully justified here.

Please refer to the discussion at avrfreaks.net for further details.

Please note, that citing a lengthy post in full in your response is no better bandwidth-wise than posting attachments to the bug tracker.

Jan Waclawek

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [bug #28108] bug with winavr20090313

2009-11-30T03:47:42Z

Please follow the avrfreaks link given by OP for further discussion and a link to a similar bug already reported and apparently solved.

JW

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [bug #28108] bug with winavr20090313

2009-11-30T03:43:16Z

Hi Brn,

This is a closer but it is still not enough to be able to help you. We
need a code /snippet/ - cut down the code to the minimal necessary so
that we can compile the code and see the problem. Your code below won't
compile because it is missing some defines, and it has lots more code
making it hard to see where the problem might lie. It could well be
that your code here (once you've included the missing defines) /is/ the
minimal code that shows the error, in which case adding the missing
parts should be easy enough.

You are also missing the compile flags and the compiler version.
Without these, we can't replicate the error or give useful advice (such
as alternative compiler flags to try).

mvh.,

David

Brn Gomes wrote:

> Follow-up Comment #1, bug #28108 (project avr-libc):
>
> If I want a CAN msg with ID=0xFDFFFFF0 on msg2
>
> it sends
>
> ID=0xFDFDFFF0....
>
> #define TEST_CAN_MSG1_ID 0xFDFFFFE0L
> #define TEST_CAN_MSG2_ID 0xFDFFFFD0L
> #define TEST_CAN_MSG3_ID 0xFDFFFFC0L
>
> #define TEST_CAN_TX_MSG0_ID TEST_CAN_MSG3_ID
> #define TEST_CAN_TX_MSG1_ID TEST_CAN_MSG1_ID
> #define TEST_CAN_TX_MSG2_ID TEST_CAN_MSG2_ID
>
> typedef struct
> {
> uint32_t id;
> uint32_t id_msk;
> uint8_t *data_ptr;
> uint8_t status;
> uint8_t proc;
> void *action_ptr;
> uint8_t max_size;
> uint8_t size;
> uint8_t mob_num;
> uint8_t wdlc;
> uint8_t mob_assign;
> } can_msg_t;
>
> static volatile can_msg_t can_tx_msg0;
> static volatile can_msg_t can_tx_msg1;
> static volatile can_msg_t can_tx_msg2;
>
> static volatile uint8_t can_buf_out_msg0[10];
> static volatile uint8_t can_buf_out_msg1[10];
> static volatile uint8_t can_buf_out_msg2[10];
>
>
> funtion called in C code:
>
> void InitCan(void){
>
> /*
> * Msg 0
> */
> can_tx_msg0.id = TEST_CAN_TX_MSG0_ID;
> can_tx_msg0.data_ptr = (uint8_t *) can_buf_out_msg0;
> can_tx_msg0.max_size = 8;
> can_tx_msg0.size = 8;
> can_tx_msg0.status = NOT_SENT;
> can_tx_msg0.mob_num = 0;
> can_tx_msg0.mob_assign = FIXED_MOB;
>
> /* send dummy data... */
> can_buf_out_msg0[0] = 0;
> can_buf_out_msg0[1] = 0;
> can_buf_out_msg0[2] = 0;
> can_buf_out_msg0[3] = 0;
> can_buf_out_msg0[4] = 0xDE;
> can_buf_out_msg0[5] = 0xAD;
> can_buf_out_msg0[6] = 0xFA;
> can_buf_out_msg0[7] = 0xCE;
>
> /*
> * Msg 1
> */
> can_tx_msg1.id = TEST_CAN_TX_MSG1_ID;
> can_tx_msg1.data_ptr = (uint8_t *) can_buf_out_msg1;
> can_tx_msg1.max_size = 8;
> can_tx_msg1.size = 8;
> can_tx_msg1.status = NOT_SENT;
> can_tx_msg1.mob_assign = FLOATING_MOB;
>
> /* send dummy data... */
> can_buf_out_msg1[0] = 0xDE;
> can_buf_out_msg1[1] = 0xAD;
> can_buf_out_msg1[2] = 0xFA;
> can_buf_out_msg1[3] = 0xCE;
> can_buf_out_msg1[4] = 0;
> can_buf_out_msg1[5] = 0;
> can_buf_out_msg1[6] = 0;
> can_buf_out_msg1[7] = 0;
>
> /*
> * Msg 2
> */
> can_tx_msg2.id = TEST_CAN_TX_MSG2_ID;
> can_tx_msg2.data_ptr = (uint8_t *) can_buf_out_msg2;
> can_tx_msg2.max_size = 8;
> can_tx_msg2.size = 8;
> can_tx_msg2.status = NOT_SENT;
> can_tx_msg2.mob_assign = FLOATING_MOB;
>
> /* send dummy data... */
> can_buf_out_msg2[0] = 0xDE;
> can_buf_out_msg2[1] = 0xAD;
> can_buf_out_msg2[2] = 0xFA;
> can_buf_out_msg2[3] = 0xCE;
> can_buf_out_msg2[4] = 0;
> can_buf_out_msg2[5] = 0;
> can_buf_out_msg2[6] = 0;
> can_buf_out_msg2[7] = 0;
>
> ......-----------......
>
> the .lss file generated with the error at line 724:
>
> can_tx_msg2.id = TEST_CAN_TX_MSG2_ID;
> 71a: 00 ed ldi r16, 0xD0 ; 208
> 71c: e0 2e mov r14, r16
> 71e: 0f ef ldi r16, 0xFF ; 255
> 720: f0 2e mov r15, r16
> 722: 0f ef ldi r16, 0xFF ; 255
> 724: 00 2f mov r16, r16
> 726: 0d ef ldi r16, 0xFD ; 253
> 728: 10 2f mov r17, r16
> 72a: e0 92 0f 02 sts 0x020F, r14
> 72e: f0 92 10 02 sts 0x0210, r15
> 732: 00 93 11 02 sts 0x0211, r16
> 736: 10 93 12 02 sts 0x0212, r17
> can_tx_msg2.data_ptr = (uint8_t *) can_buf_out_msg2;
> 73a: 86 e3 ldi r24, 0x36 ; 54
> 73c: 92 e0 ldi r25, 0x02 ; 2
> 73e: 90 93 18 02 sts 0x0218, r25
> 742: 80 93 17 02 sts 0x0217, r24
> can_tx_msg2.max_size = 8;
> 746: 60 93 1d 02 sts 0x021D, r22
> can_tx_msg2.size = 8;
> 74a: 60 93 1e 02 sts 0x021E, r22
> can_tx_msg2.status = NOT_SENT;
> 74e: 70 93 19 02 sts 0x0219, r23
>

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #28108] bug with winavr20090313

2009-11-30T03:23:57Z

Follow-up Comment #2, bug #28108 (project avr-libc):

brief problem summary:

I'm having a sort of a "bug" after compiling with winavr 2009-03-13 because i
noticed that i wasn't receiving one specific CAN message for some reason. The
reason was the msg_id on the transmitter was not correct so the receiver
didn't "caught" any because the ID were diferent. But the main problem was
that in code C was everything perfect but when I saw the assembly, there was
some wrong stuff there (see below please).
The ID is a #define and for some reason r16 is wrongly changed into the last
ID byte... making an erroneous ID.

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28108>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #28108] bug with winavr20090313

2009-11-30T03:17:47Z

Follow-up Comment #1, bug #28108 (project avr-libc):

If I want a CAN msg with ID=0xFDFFFFF0 on msg2

it sends

ID=0xFDFDFFF0....

#define TEST_CAN_MSG1_ID 0xFDFFFFE0L
#define TEST_CAN_MSG2_ID 0xFDFFFFD0L
#define TEST_CAN_MSG3_ID 0xFDFFFFC0L

#define TEST_CAN_TX_MSG0_ID TEST_CAN_MSG3_ID
#define TEST_CAN_TX_MSG1_ID TEST_CAN_MSG1_ID
#define TEST_CAN_TX_MSG2_ID TEST_CAN_MSG2_ID

typedef struct
{
uint32_t id;
uint32_t id_msk;
uint8_t *data_ptr;
uint8_t status;
uint8_t proc;
void *action_ptr;
uint8_t max_size;
uint8_t size;
uint8_t mob_num;
uint8_t wdlc;
uint8_t mob_assign;
} can_msg_t;

static volatile can_msg_t can_tx_msg0;
static volatile can_msg_t can_tx_msg1;
static volatile can_msg_t can_tx_msg2;

static volatile uint8_t can_buf_out_msg0[10];
static volatile uint8_t can_buf_out_msg1[10];
static volatile uint8_t can_buf_out_msg2[10];

funtion called in C code:

void InitCan(void){

/*
* Msg 0
*/
can_tx_msg0.id = TEST_CAN_TX_MSG0_ID;
can_tx_msg0.data_ptr = (uint8_t *) can_buf_out_msg0;
can_tx_msg0.max_size = 8;
can_tx_msg0.size = 8;
can_tx_msg0.status = NOT_SENT;
can_tx_msg0.mob_num = 0;
can_tx_msg0.mob_assign = FIXED_MOB;

/* send dummy data... */
can_buf_out_msg0[0] = 0;
can_buf_out_msg0[1] = 0;
can_buf_out_msg0[2] = 0;
can_buf_out_msg0[3] = 0;
can_buf_out_msg0[4] = 0xDE;
can_buf_out_msg0[5] = 0xAD;
can_buf_out_msg0[6] = 0xFA;
can_buf_out_msg0[7] = 0xCE;

/*
* Msg 1
*/
can_tx_msg1.id = TEST_CAN_TX_MSG1_ID;
can_tx_msg1.data_ptr = (uint8_t *) can_buf_out_msg1;
can_tx_msg1.max_size = 8;
can_tx_msg1.size = 8;
can_tx_msg1.status = NOT_SENT;
can_tx_msg1.mob_assign = FLOATING_MOB;

/* send dummy data... */
can_buf_out_msg1[0] = 0xDE;
can_buf_out_msg1[1] = 0xAD;
can_buf_out_msg1[2] = 0xFA;
can_buf_out_msg1[3] = 0xCE;
can_buf_out_msg1[4] = 0;
can_buf_out_msg1[5] = 0;
can_buf_out_msg1[6] = 0;
can_buf_out_msg1[7] = 0;

/*
* Msg 2
*/
can_tx_msg2.id = TEST_CAN_TX_MSG2_ID;
can_tx_msg2.data_ptr = (uint8_t *) can_buf_out_msg2;
can_tx_msg2.max_size = 8;
can_tx_msg2.size = 8;
can_tx_msg2.status = NOT_SENT;
can_tx_msg2.mob_assign = FLOATING_MOB;

/* send dummy data... */
can_buf_out_msg2[0] = 0xDE;
can_buf_out_msg2[1] = 0xAD;
can_buf_out_msg2[2] = 0xFA;
can_buf_out_msg2[3] = 0xCE;
can_buf_out_msg2[4] = 0;
can_buf_out_msg2[5] = 0;
can_buf_out_msg2[6] = 0;
can_buf_out_msg2[7] = 0;

......-----------......

the .lss file generated with the error at line 724:

can_tx_msg2.id = TEST_CAN_TX_MSG2_ID;
71a: 00 ed ldi r16, 0xD0 ; 208
71c: e0 2e mov r14, r16
71e: 0f ef ldi r16, 0xFF ; 255
720: f0 2e mov r15, r16
722: 0f ef ldi r16, 0xFF ; 255
724: 00 2f mov r16, r16
726: 0d ef ldi r16, 0xFD ; 253
728: 10 2f mov r17, r16
72a: e0 92 0f 02 sts 0x020F, r14
72e: f0 92 10 02 sts 0x0210, r15
732: 00 93 11 02 sts 0x0211, r16
736: 10 93 12 02 sts 0x0212, r17
can_tx_msg2.data_ptr = (uint8_t *) can_buf_out_msg2;
73a: 86 e3 ldi r24, 0x36 ; 54
73c: 92 e0 ldi r25, 0x02 ; 2
73e: 90 93 18 02 sts 0x0218, r25
742: 80 93 17 02 sts 0x0217, r24
can_tx_msg2.max_size = 8;
746: 60 93 1d 02 sts 0x021D, r22
can_tx_msg2.size = 8;
74a: 60 93 1e 02 sts 0x021E, r22
can_tx_msg2.status = NOT_SENT;
74e: 70 93 19 02 sts 0x0219, r23

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28108>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #28108] bug with winavr20090313

2009-11-30T02:57:24Z

Additional Item Attachment, bug #28108 (project avr-libc):

File name: can_bug.zip Size:8 KB

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28108>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: [bug #28108] bug with winavr20090313

2009-11-30T02:24:22Z

Brn wrote:

> URL:
> <http://savannah.nongnu.org/bugs/?28108>
>
> Summary: bug with winavr20090313
> Project: AVR C Runtime Library
> Submitted by: unknwn
> Submitted on: Fri 27 Nov 2009 06:40:01 PM GMT
> Category: None
> Severity: 3 - Normal
> Priority: 5 - Normal
> Item Group: None
> Status: None
> Percent Complete: 0%
> Assigned to: None
> Open/Closed: Open
> Discussion Lock: Any
> Release: 1.6.6
> Fixed Release: None
>
> _______________________________________________________
>
> Details:
>
> greetings,
>
> I'm using winavr20090313 which has gcc 4.3.2 and i'm getting the bug that I
> reported at:
> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=86733
>
> In attachment there's a .rar that shows the error.
>
> Give me a help on this one please.
>
> Thanks ;)
>

I can first give you some tips on how to post questions or reports in
this mailing list, avr freaks, bug trackers, etc. The avr-gcc
community, both developers and users, are happy to help people - but we
do expect people to follow certain rules so that we /can/ help you.

First off, use a real name and a real email address. This is a
community of real people, giving up their real life time to help. We
expect a certain amount of respect, and using a real name is a minimum.
You don't get a second chance on this one (from me, anyway - I can't
speak for any others). I won't give any more help or advice to someone
who uses an "I'm a cool dude 12 year old" pretend swear word as an email
address.

Second, we don't want attachments on this list (and the mailing list
software helpfully strips them). What we like is /small/ snippets of
code that show the problem. That way we can easily test out the code
and quickly see if it is a problem with the compiler, or with the user's
code. Trim your code down to a minimal example that can be easily
compiled without needing any other files (standard headers like
<stdint.h> are fine). We also need to know the compiler flags you are
using - sometimes issues are dependant on the particular options used.
Once we've got that, it is easy for others to test the code or to
recognize known issues.

If you do ever need to send attachments, don't use rar format. Use zip
for windows style, or tgz or tar.bj2 for *nix style.

As others in avrfreaks have said, it looks like your code is triggering
a known bug in gcc, which appears to have been fixed in the gcc source
but has not yet made it into a winavr release. If you remove yourself
from this mailing list, join on again with a real email address, post a
brief summary of the problem you are having (not just a link to
avrfreaks) and a code snippet, then we will be able to tell you if there
is a workaround or other fix that will help you.

mvh.,

David Brown

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #25723] Realloc corrupts free list when growing into the next free item

2009-11-29T06:21:27Z

Follow-up Comment #7, bug #25723 (project avr-libc):

Hello, I think that there is a miscalculation in the patch which leads to a
severe bug.

In realloc.c:
58: cp = (char *)ptr + len; /* new next pointer */
62: fp2 = (struct __freelist *)(cp - sizeof(size_t));
71: if (len <= fp1->sz) {
77: fp2->sz = fp1->sz - len - sizeof(size_t);
78: fp1->sz = len;

This leads to fp1 being actually 2 bytes less than the size stored into
fp1->sz. Also it changes the last two bytes of the allocated memory and this
is how I found it.

Code to reproduce the bug:
int main(void) {
uint8_t *p;
p = malloc(16);
p[8] = 8;
p[9] = 9;
p = realloc(p, 10);
if (p[8] != 8 && p[9] != 9)
/* memory looks like this:
* p - 2: 0A 00
* p : FF FF FF FF
* p + 4: FF FF FF FF
* p + 8: 04 00
*/
return 1;
return 0;
}

Since I'm not very sure how to fix this, could please someone confirm and fix
this. Thanks!

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?25723>

_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #28108] bug with winavr20090313

2009-11-27T10:40:07Z

URL:
<http://savannah.nongnu.org/bugs/?28108>

Summary: bug with winavr20090313
Project: AVR C Runtime Library
Submitted by: unknwn
Submitted on: Fri 27 Nov 2009 06:40:01 PM GMT
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: None
Status: None
Percent Complete: 0%
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Release: 1.6.6
Fixed Release: None

_______________________________________________________

Details:

greetings,

I'm using winavr20090313 which has gcc 4.3.2 and i'm getting the bug that I
reported at:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=86733

In attachment there's a .rar that shows the error.

Give me a help on this one please.

Thanks ;)

_______________________________________________________

File Attachments:

-------------------------------------------------------
Date: Fri 27 Nov 2009 06:40:01 PM GMT Name: can_bug.rar Size: 8kB By:
unknwn

<http://savannah.nongnu.org/bugs/download.php?file_id=19140>

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28108>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: Re: eeprom_read_byte and clr ret_hi

2009-11-24T08:15:16Z

David Brown schreef:

> Wouter van Gulik wrote:
>> David Brown schreef:
>>> Wouter van Gulik wrote:
>>>> David Brown schreef:
>>>>> Weddington, Eric wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message----- From:
>>>>>>> avr-libc-dev-bounces+eric.weddington=atmel.com@...
>>>>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
>>>>>>> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
>>>>>>> avr-libc-dev@... Subject: Re: [avr-libc-dev]
>>>>>>> eeprom_read_byte and clr ret_hi
>>>>>>>
>>>>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
>>>>>>>>> eerd_byte.S: clr ret_hi
>>>>>>>>>
>>>>>>>>> Does the AVR ABI require that r25 be zeroed in a function
>>>>>>> returning a
>>>>>>>>> single byte? If not, this instruction could be removed.
>>>>>>> This is a misty point. Look an example:
>>>>>>>
>>>>>>> unsigned char foo1 (unsigned char *p) { return *p; }
>>>>>>>
>>>>>>> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
>>>>>>> 1; }
>>>>>>>
>>>>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
>>>>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
>>>>>>> foo1().
>>>>>>>
>>>>>>> Note, the function return value is present only in expression. So
>>>>>>> it is promoted to integer. So it would be better to clear R25 in
>>>>>>> foo1() only (at one place).
>>>>>>
>>>>>> I agree that that is the way it should be.
>>>>>>
>>>>>
>>>>> I'm a little confused by this - I hope this is not implying a
>>>>> return to avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above
>>>>> would clear R25 even though it is returning an 8-bit value. This
>>>>> has always been a waste of time and space - caller functions make
>>>>> no use of the cleared R25, and thus clear it again themselves (such
>>>>> as in foo2() after calling ext2()). With avr-gcc 4.3, the extra
>>>>> clear R25 instructions are omitted for functions returning 8-bit
>>>>> values. This is the way it should be (unless the C standards
>>>>> disagree...), IMHO. But it looks a little like you want foo1() to
>>>>> clear R25 here?
>>>>>
>>>>>
>>>>> Incidentally, avr-gcc 4.2.2 actually produces better code for
>>>>> foo2() than avr-gcc 4.3.2.
>>>>>
>>>>> With 4.2.2, the code is:
>>>>> foo2:
>>>>> call ext2
>>>>> ldi R25, lo8(0)
>>>>> adiw r24,1
>>>>> ret
>>>>>
>>>>> With 4.3.2 (and 4.3.0), we get:
>>>>> foo2:
>>>>> call ext2
>>>>> mov r18, r24
>>>>> ldi r19, lo8(0)
>>>>> subi r18, lo8(-(1))
>>>>> sbci r19, hi8(-(1))
>>>>> movw r24, r18
>>>>> ret
>>>>>
>>>>> Is this regression is news to you, I can take it up in the main
>>>>> avr-gcc mailing list and/or a missed optimisation bug report.
>>>>>
>>>>
>>>> This is "normal" GCC behaviour, caused by internal promotion to int
>>>> types. Having the clr r25 would have saved the ldi r19. Altough
>>>> these type of missed optimization are known for long, it
>>>> (apparently) is difficult to fix them. IIRC the main problem is the
>>>> carry bit propagation. I still don't now why exactly that is such a
>>>> big problem, but then again I am no gcc expert.
>>>>
>>>
>>> I understand about int promotion, and how it's a PITA to remove all
>>> the extra code that the avr backend has to put in because the gcc
>>> frontend has promoted the 8-bit data to 16-bit ints. However,
>>> avr-gcc 4.2 /does/ do a clr R25 in the function returning an 8-bit
>>> result, and then it clears it /again/ after calling it (as in foo2
>>> above). That is definitely a waste, and it has been removed in 4.3+.
>>>
>>> The problem I have with the 4.3.2 code above is not the zeroing of
>>> the upper byte - that's standard int promotion, and is required for
>>> correct code. The problem is that the result of ext2() is first
>>> moved into a new register pair and then promoted to an int - an
>>> unnecessary move, which forces the subi/sbci pair instead of subw,
>>> and requires an additional move before the ret instruction. In more
>>> complex code, the wasted register resources may also be relevant.
>>>
>>
>> You're right, I was not grasping the real problem. However using
>> -fno-split-wide-types makes 4.3.2 behave like 4.2.2. Split wide types
>> seems to be the problem here.
>>
>
> You are correct - I hadn't thought of that. However,
> -fno-split-wide-types is a workaround, rather than a solution. Ideally,
> the good code should be produced regardless of that flag, since
> split-wide-types is enabled implicitly by all -Ox flags. The
> split-wide-types is also useful to improve some code sequences, such as
> when you have 32-bit data but only want to look at part of it.
>

Yes of course it is a workaround, it might be a hint on where the
problem is. I did some simple experiments and it seems that split wide
type only enforces a copy to a new register pair, which makes it less
efficient.

HTH,

Wouter

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: Re: eeprom_read_byte and clr ret_hi

2009-11-24T06:41:50Z

Wouter van Gulik wrote:

> David Brown schreef:
>> Wouter van Gulik wrote:
>>> David Brown schreef:
>>>> Weddington, Eric wrote:
>>>>>
>>>>>
>>>>>> -----Original Message----- From:
>>>>>> avr-libc-dev-bounces+eric.weddington=atmel.com@...
>>>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
>>>>>> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
>>>>>> avr-libc-dev@... Subject: Re: [avr-libc-dev]
>>>>>> eeprom_read_byte and clr ret_hi
>>>>>>
>>>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
>>>>>>>> eerd_byte.S: clr ret_hi
>>>>>>>>
>>>>>>>> Does the AVR ABI require that r25 be zeroed in a function
>>>>>> returning a
>>>>>>>> single byte? If not, this instruction could be removed.
>>>>>> This is a misty point. Look an example:
>>>>>>
>>>>>> unsigned char foo1 (unsigned char *p) { return *p; }
>>>>>>
>>>>>> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
>>>>>> 1; }
>>>>>>
>>>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
>>>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
>>>>>> foo1().
>>>>>>
>>>>>> Note, the function return value is present only in expression. So
>>>>>> it is promoted to integer. So it would be better to clear R25 in
>>>>>> foo1() only (at one place).
>>>>>
>>>>> I agree that that is the way it should be.
>>>>>
>>>>
>>>> I'm a little confused by this - I hope this is not implying a return
>>>> to avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above would
>>>> clear R25 even though it is returning an 8-bit value. This has
>>>> always been a waste of time and space - caller functions make no use
>>>> of the cleared R25, and thus clear it again themselves (such as in
>>>> foo2() after calling ext2()). With avr-gcc 4.3, the extra clear R25
>>>> instructions are omitted for functions returning 8-bit values. This
>>>> is the way it should be (unless the C standards disagree...), IMHO.
>>>> But it looks a little like you want foo1() to clear R25 here?
>>>>
>>>>
>>>> Incidentally, avr-gcc 4.2.2 actually produces better code for foo2()
>>>> than avr-gcc 4.3.2.
>>>>
>>>> With 4.2.2, the code is:
>>>> foo2:
>>>> call ext2
>>>> ldi R25, lo8(0)
>>>> adiw r24,1
>>>> ret
>>>>
>>>> With 4.3.2 (and 4.3.0), we get:
>>>> foo2:
>>>> call ext2
>>>> mov r18, r24
>>>> ldi r19, lo8(0)
>>>> subi r18, lo8(-(1))
>>>> sbci r19, hi8(-(1))
>>>> movw r24, r18
>>>> ret
>>>>
>>>> Is this regression is news to you, I can take it up in the main
>>>> avr-gcc mailing list and/or a missed optimisation bug report.
>>>>
>>>
>>> This is "normal" GCC behaviour, caused by internal promotion to int
>>> types. Having the clr r25 would have saved the ldi r19. Altough these
>>> type of missed optimization are known for long, it (apparently) is
>>> difficult to fix them. IIRC the main problem is the carry bit
>>> propagation. I still don't now why exactly that is such a big
>>> problem, but then again I am no gcc expert.
>>>
>>
>> I understand about int promotion, and how it's a PITA to remove all
>> the extra code that the avr backend has to put in because the gcc
>> frontend has promoted the 8-bit data to 16-bit ints. However, avr-gcc
>> 4.2 /does/ do a clr R25 in the function returning an 8-bit result, and
>> then it clears it /again/ after calling it (as in foo2 above). That
>> is definitely a waste, and it has been removed in 4.3+.
>>
>> The problem I have with the 4.3.2 code above is not the zeroing of the
>> upper byte - that's standard int promotion, and is required for
>> correct code. The problem is that the result of ext2() is first moved
>> into a new register pair and then promoted to an int - an unnecessary
>> move, which forces the subi/sbci pair instead of subw, and requires an
>> additional move before the ret instruction. In more complex code, the
>> wasted register resources may also be relevant.
>>
>
> You're right, I was not grasping the real problem. However using
> -fno-split-wide-types makes 4.3.2 behave like 4.2.2. Split wide types
> seems to be the problem here.
>

You are correct - I hadn't thought of that. However,
-fno-split-wide-types is a workaround, rather than a solution. Ideally,
the good code should be produced regardless of that flag, since
split-wide-types is enabled implicitly by all -Ox flags. The
split-wide-types is also useful to improve some code sequences, such as
when you have 32-bit data but only want to look at part of it.

mvh.,

David

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: Re: eeprom_read_byte and clr ret_hi

2009-11-24T03:55:01Z

David Brown schreef:

> Wouter van Gulik wrote:
>> David Brown schreef:
>>> Weddington, Eric wrote:
>>>>
>>>>
>>>>> -----Original Message----- From:
>>>>> avr-libc-dev-bounces+eric.weddington=atmel.com@...
>>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
>>>>> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
>>>>> avr-libc-dev@... Subject: Re: [avr-libc-dev]
>>>>> eeprom_read_byte and clr ret_hi
>>>>>
>>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
>>>>>>> eerd_byte.S: clr ret_hi
>>>>>>>
>>>>>>> Does the AVR ABI require that r25 be zeroed in a function
>>>>> returning a
>>>>>>> single byte? If not, this instruction could be removed.
>>>>> This is a misty point. Look an example:
>>>>>
>>>>> unsigned char foo1 (unsigned char *p) { return *p; }
>>>>>
>>>>> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
>>>>> 1; }
>>>>>
>>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
>>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
>>>>> foo1().
>>>>>
>>>>> Note, the function return value is present only in expression. So
>>>>> it is promoted to integer. So it would be better to clear R25 in
>>>>> foo1() only (at one place).
>>>>
>>>> I agree that that is the way it should be.
>>>>
>>>
>>> I'm a little confused by this - I hope this is not implying a return
>>> to avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above would
>>> clear R25 even though it is returning an 8-bit value. This has
>>> always been a waste of time and space - caller functions make no use
>>> of the cleared R25, and thus clear it again themselves (such as in
>>> foo2() after calling ext2()). With avr-gcc 4.3, the extra clear R25
>>> instructions are omitted for functions returning 8-bit values. This
>>> is the way it should be (unless the C standards disagree...), IMHO.
>>> But it looks a little like you want foo1() to clear R25 here?
>>>
>>>
>>> Incidentally, avr-gcc 4.2.2 actually produces better code for foo2()
>>> than avr-gcc 4.3.2.
>>>
>>> With 4.2.2, the code is:
>>> foo2:
>>> call ext2
>>> ldi R25, lo8(0)
>>> adiw r24,1
>>> ret
>>>
>>> With 4.3.2 (and 4.3.0), we get:
>>> foo2:
>>> call ext2
>>> mov r18, r24
>>> ldi r19, lo8(0)
>>> subi r18, lo8(-(1))
>>> sbci r19, hi8(-(1))
>>> movw r24, r18
>>> ret
>>>
>>> Is this regression is news to you, I can take it up in the main
>>> avr-gcc mailing list and/or a missed optimisation bug report.
>>>
>>
>> This is "normal" GCC behaviour, caused by internal promotion to int
>> types. Having the clr r25 would have saved the ldi r19. Altough these
>> type of missed optimization are known for long, it (apparently) is
>> difficult to fix them. IIRC the main problem is the carry bit
>> propagation. I still don't now why exactly that is such a big problem,
>> but then again I am no gcc expert.
>>
>
> I understand about int promotion, and how it's a PITA to remove all the
> extra code that the avr backend has to put in because the gcc frontend
> has promoted the 8-bit data to 16-bit ints. However, avr-gcc 4.2 /does/
> do a clr R25 in the function returning an 8-bit result, and then it
> clears it /again/ after calling it (as in foo2 above). That is
> definitely a waste, and it has been removed in 4.3+.
>
> The problem I have with the 4.3.2 code above is not the zeroing of the
> upper byte - that's standard int promotion, and is required for correct
> code. The problem is that the result of ext2() is first moved into a
> new register pair and then promoted to an int - an unnecessary move,
> which forces the subi/sbci pair instead of subw, and requires an
> additional move before the ret instruction. In more complex code, the
> wasted register resources may also be relevant.
>

You're right, I was not grasping the real problem. However using
-fno-split-wide-types makes 4.3.2 behave like 4.2.2. Split wide types
seems to be the problem here.

HTH

Wouter

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: eeprom_read_byte and clr ret_hi

2009-11-23T14:25:13Z

Weddington, Eric wrote:

>
>
>> -----Original Message----- From:
>> avr-libc-dev-bounces+eric.weddington=atmel.com@...
>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
>> On Behalf Of David Brown Sent: Monday, November 23, 2009 3:25 AM
>> To: avr-libc-dev@... Subject: [avr-libc-dev] Re:
>> eeprom_read_byte and clr ret_hi
>>
>> Weddington, Eric wrote:
>>>
>>>> -----Original Message----- From:
>>>> avr-libc-dev-bounces+eric.weddington=atmel.com@...
>>>> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
>>>> org] On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009
>>>> 12:21 AM To: avr-libc-dev@... Subject: Re:
>>>> [avr-libc-dev] eeprom_read_byte and clr ret_hi
>>>>
>>>>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
>>>>>> eerd_byte.S: clr ret_hi
>>>>>>
>>>>>> Does the AVR ABI require that r25 be zeroed in a function
>>>> returning a
>>>>>> single byte? If not, this instruction could be removed.
>>>> This is a misty point. Look an example:
>>>>
>>>> unsigned char foo1 (unsigned char *p) { return *p; }
>>>>
>>>> extern unsigned char ext2 (void); int foo2 (void) { return
>>>> ext2() + 1; }
>>>>
>>>> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
>>>> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25
>>>> in foo1().
>>>>
>>>> Note, the function return value is present only in expression.
>>>> So it is promoted to integer. So it would be better to clear
>>>> R25 in foo1() only (at one place).
>>> I agree that that is the way it should be.
>>>
>> I'm a little confused by this - I hope this is not implying a
>> return to avr-gcc 4.2 R25 clearing?
>
> No, that wasn't my intention. I was merely commenting that the return
> type of the macro/function should not be made int (16-bit), that it
> should be a byte (uint8_t) as the API name implicates. If it is
> returned as a byte, then yes it is implied and I agree that R25
> should not be cleared.
>

Ah, good - as I hoped. I just wanted to be sure.

>
>> Is this regression is news to you, I can take it up in the main
>> avr-gcc mailing list and/or a missed optimisation bug report.
>
> Please fill out a bug report. That way it won't get lost.

I've added it to the WinAVR bug tracker:
<https://sourceforge.net/tracker/?func=detail&aid=2902772&group_id=68108&atid=520074>

Hope that helps!

p.s. - I'm looking forward to gcc 4.5 with LTO. For small targets like
the AVR, that should mean full program optimisation for everything,
including the libraries.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: Re: eeprom_read_byte and clr ret_hi

2009-11-23T08:17:00Z

> -----Original Message-----
> From:
> avr-libc-dev-bounces+eric.weddington=atmel.com@...
> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of David Brown
> Sent: Monday, November 23, 2009 3:25 AM
> To: avr-libc-dev@...
> Subject: [avr-libc-dev] Re: eeprom_read_byte and clr ret_hi
>
> Weddington, Eric wrote:
> >
> >
> >> -----Original Message----- From:
> >> avr-libc-dev-bounces+eric.weddington=atmel.com@...
> >> [mailto:avr-libc-dev-bounces+eric.weddington=atmel.com@nongnu. org]
> >> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To:
> >> avr-libc-dev@... Subject: Re: [avr-libc-dev]
> >> eeprom_read_byte and clr ret_hi
> >>
> >>>> eeprom_read_byte returns a uint8_t. Why does it clear r25?
> >>>> eerd_byte.S: clr ret_hi
> >>>>
> >>>> Does the AVR ABI require that r25 be zeroed in a function
> >> returning a
> >>>> single byte? If not, this instruction could be removed.
> >> This is a misty point. Look an example:
> >>
> >> unsigned char foo1 (unsigned char *p) { return *p; }
> >>
> >> extern unsigned char ext2 (void); int foo2 (void) { return ext2() +
> >> 1; }
> >>
> >> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
> >> foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25 in
> >> foo1().
> >>
> >> Note, the function return value is present only in expression. So
> >> it is promoted to integer. So it would be better to clear R25 in
> >> foo1() only (at one place).
> >
> > I agree that that is the way it should be.
> >
>
> I'm a little confused by this - I hope this is not implying a
> return to
> avr-gcc 4.2 R25 clearing?

No, that wasn't my intention. I was merely commenting that the return type of the macro/function should not be made int (16-bit), that it should be a byte (uint8_t) as the API name implicates. If it is returned as a byte, then yes it is implied and I agree that R25 should not be cleared.

> Is this regression is news to you, I can take it up in the
> main avr-gcc
> mailing list and/or a missed optimisation bug report.

Please fill out a bug report. That way it won't get lost.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: eeprom_read_byte and clr ret_hi

2009-11-23T02:24:38Z

Weddington, Eric wrote:

I'm a little confused by this - I hope this is not implying a return to
avr-gcc 4.2 R25 clearing? With avr-gcc 4.2, foo1() above would clear
R25 even though it is returning an 8-bit value. This has always been a
waste of time and space - caller functions make no use of the cleared
R25, and thus clear it again themselves (such as in foo2() after calling
ext2()). With avr-gcc 4.3, the extra clear R25 instructions are omitted
for functions returning 8-bit values. This is the way it should be
(unless the C standards disagree...), IMHO. But it looks a little like
you want foo1() to clear R25 here?

Incidentally, avr-gcc 4.2.2 actually produces better code for foo2()
than avr-gcc 4.3.2.

With 4.2.2, the code is:
foo2:
call ext2
ldi R25, lo8(0)
adiw r24,1
ret

With 4.3.2 (and 4.3.0), we get:
foo2:
call ext2
mov r18, r24
ldi r19, lo8(0)
subi r18, lo8(-(1))
sbci r19, hi8(-(1))
movw r24, r18
ret

Is this regression is news to you, I can take it up in the main avr-gcc
mailing list and/or a missed optimisation bug report.

mvh.,

David

>> Possibly, it is needed to change eeprom_read_byte() definition to
>> int return value. This can reduce summary size. Opinions?
>
> This does not make sense to me. Eeprom_read_byte() is supposed to
> read, and return, a single byte. So why should it return a 16-bit
> int? In my mind this would just make it more confusing to the end
> user.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: eeprom_read_byte and clr ret_hi

2009-11-22T14:45:04Z

> > Possibly, it is needed to change eeprom_read_byte() definition
> > to int return value. This can reduce summary size. Opinions?
>
> This does not make sense to me. Eeprom_read_byte() is supposed to read, and
> return, a single byte. So why should it return a 16-bit int? In my mind
> this would just make it more confusing to the end user.

Agree, it was a bad idea.
More, the definition of eeprom_read_byte() as int will
decrease performance in cases, where Avr-gcc can omit
integral promotion, for example:
if (eeprom_read_byte(&x) < 10)

Regards,
Dmitry.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: stdint.h problem with gcc

2009-11-22T09:33:02Z

I have posted patch to "ignore" gcc stdint test failure due to limit
range of prtdiff for AVR (c99 wants +-65535)
Though we could use "long" that is pointless with restriction on objects
being <= 32767 bytes.

There are several errors/problems remaining with avr-libc stdint.h - gcc
version passes most (all?) tests.
I would be grateful if someone could review this.

Andy

Andrew Hutchinson wrote:

> I have been going through the gcc tests for V4.5 and come across some
> issues with avr-lic stdint.h
>
> The tests that fails are gcc/gcc/testsuite/gcc.dg/c99-stdint-1.c
>
> gcc will create it's own stdint.h and this is fine for V4.5. I have
> attached this for reference.
>
> The definition of UINT8_MAX is unsigned e.g. 255U - this fails test.
> 255 is ok
> wchar limits are not defined- ok we dont have wchar.h but we should
> still define the types.
>
> There is another issue related to ptrdiff type. This is posted as gcc
> bug - since it is possible that this particular subtest is
> inappropriate for avr.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114
>
> =================================================================
> /* Copyright (C) 2008, 2009 Free Software Foundation, Inc.
>
> This file is part of GCC.
>
> GCC is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 3, or (at your option)
> any later version.
>
> GCC is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> GNU General Public License for more details.
>
> Under Section 7 of GPL version 3, you are granted additional
> permissions described in the GCC Runtime Library Exception, version
> 3.1, as published by the Free Software Foundation.
>
> You should have received a copy of the GNU General Public License and
> a copy of the GCC Runtime Library Exception along with this program;
> see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
> <http://www.gnu.org/licenses/>. */
>
> /*
> * ISO C Standard: 7.18 Integer types <stdint.h>
> */
>
> #ifndef _GCC_STDINT_H
> #define _GCC_STDINT_H
>
> /* 7.8.1.1 Exact-width integer types */
>
> #ifdef __INT8_TYPE__
> typedef __INT8_TYPE__ int8_t;
> #endif
> #ifdef __INT16_TYPE__
> typedef __INT16_TYPE__ int16_t;
> #endif
> #ifdef __INT32_TYPE__
> typedef __INT32_TYPE__ int32_t;
> #endif
> #ifdef __INT64_TYPE__
> typedef __INT64_TYPE__ int64_t;
> #endif
> #ifdef __UINT8_TYPE__
> typedef __UINT8_TYPE__ uint8_t;
> #endif
> #ifdef __UINT16_TYPE__
> typedef __UINT16_TYPE__ uint16_t;
> #endif
> #ifdef __UINT32_TYPE__
> typedef __UINT32_TYPE__ uint32_t;
> #endif
> #ifdef __UINT64_TYPE__
> typedef __UINT64_TYPE__ uint64_t;
> #endif
>
> /* 7.8.1.2 Minimum-width integer types */
>
> typedef __INT_LEAST8_TYPE__ int_least8_t;
> typedef __INT_LEAST16_TYPE__ int_least16_t;
> typedef __INT_LEAST32_TYPE__ int_least32_t;
> typedef __INT_LEAST64_TYPE__ int_least64_t;
> typedef __UINT_LEAST8_TYPE__ uint_least8_t;
> typedef __UINT_LEAST16_TYPE__ uint_least16_t;
> typedef __UINT_LEAST32_TYPE__ uint_least32_t;
> typedef __UINT_LEAST64_TYPE__ uint_least64_t;
>
> /* 7.8.1.3 Fastest minimum-width integer types */
>
> typedef __INT_FAST8_TYPE__ int_fast8_t;
> typedef __INT_FAST16_TYPE__ int_fast16_t;
> typedef __INT_FAST32_TYPE__ int_fast32_t;
> typedef __INT_FAST64_TYPE__ int_fast64_t;
> typedef __UINT_FAST8_TYPE__ uint_fast8_t;
> typedef __UINT_FAST16_TYPE__ uint_fast16_t;
> typedef __UINT_FAST32_TYPE__ uint_fast32_t;
> typedef __UINT_FAST64_TYPE__ uint_fast64_t;
>
> /* 7.8.1.4 Integer types capable of holding object pointers */
>
> #ifdef __INTPTR_TYPE__
> typedef __INTPTR_TYPE__ intptr_t;
> #endif
> #ifdef __UINTPTR_TYPE__
> typedef __UINTPTR_TYPE__ uintptr_t;
> #endif
>
> /* 7.8.1.5 Greatest-width integer types */
>
> typedef __INTMAX_TYPE__ intmax_t;
> typedef __UINTMAX_TYPE__ uintmax_t;
>
> #if !defined __cplusplus || defined __STDC_LIMIT_MACROS
>
> /* 7.18.2 Limits of specified-width integer types */
>
> #ifdef __INT8_MAX__
> # undef INT8_MAX
> # define INT8_MAX __INT8_MAX__
> # undef INT8_MIN
> # define INT8_MIN (-INT8_MAX - 1)
> #endif
> #ifdef __UINT8_MAX__
> # undef UINT8_MAX
> # define UINT8_MAX __UINT8_MAX__
> #endif
> #ifdef __INT16_MAX__
> # undef INT16_MAX
> # define INT16_MAX __INT16_MAX__
> # undef INT16_MIN
> # define INT16_MIN (-INT16_MAX - 1)
> #endif
> #ifdef __UINT16_MAX__
> # undef UINT16_MAX
> # define UINT16_MAX __UINT16_MAX__
> #endif
> #ifdef __INT32_MAX__
> # undef INT32_MAX
> # define INT32_MAX __INT32_MAX__
> # undef INT32_MIN
> # define INT32_MIN (-INT32_MAX - 1)
> #endif
> #ifdef __UINT32_MAX__
> # undef UINT32_MAX
> # define UINT32_MAX __UINT32_MAX__
> #endif
> #ifdef __INT64_MAX__
> # undef INT64_MAX
> # define INT64_MAX __INT64_MAX__
> # undef INT64_MIN
> # define INT64_MIN (-INT64_MAX - 1)
> #endif
> #ifdef __UINT64_MAX__
> # undef UINT64_MAX
> # define UINT64_MAX __UINT64_MAX__
> #endif
>
> #undef INT_LEAST8_MAX
> #define INT_LEAST8_MAX __INT_LEAST8_MAX__
> #undef INT_LEAST8_MIN
> #define INT_LEAST8_MIN (-INT_LEAST8_MAX - 1)
> #undef UINT_LEAST8_MAX
> #define UINT_LEAST8_MAX __UINT_LEAST8_MAX__
> #undef INT_LEAST16_MAX
> #define INT_LEAST16_MAX __INT_LEAST16_MAX__
> #undef INT_LEAST16_MIN
> #define INT_LEAST16_MIN (-INT_LEAST16_MAX - 1)
> #undef UINT_LEAST16_MAX
> #define UINT_LEAST16_MAX __UINT_LEAST16_MAX__
> #undef INT_LEAST32_MAX
> #define INT_LEAST32_MAX __INT_LEAST32_MAX__
> #undef INT_LEAST32_MIN
> #define INT_LEAST32_MIN (-INT_LEAST32_MAX - 1)
> #undef UINT_LEAST32_MAX
> #define UINT_LEAST32_MAX __UINT_LEAST32_MAX__
> #undef INT_LEAST64_MAX
> #define INT_LEAST64_MAX __INT_LEAST64_MAX__
> #undef INT_LEAST64_MIN
> #define INT_LEAST64_MIN (-INT_LEAST64_MAX - 1)
> #undef UINT_LEAST64_MAX
> #define UINT_LEAST64_MAX __UINT_LEAST64_MAX__
>
> #undef INT_FAST8_MAX
> #define INT_FAST8_MAX __INT_FAST8_MAX__
> #undef INT_FAST8_MIN
> #define INT_FAST8_MIN (-INT_FAST8_MAX - 1)
> #undef UINT_FAST8_MAX
> #define UINT_FAST8_MAX __UINT_FAST8_MAX__
> #undef INT_FAST16_MAX
> #define INT_FAST16_MAX __INT_FAST16_MAX__
> #undef INT_FAST16_MIN
> #define INT_FAST16_MIN (-INT_FAST16_MAX - 1)
> #undef UINT_FAST16_MAX
> #define UINT_FAST16_MAX __UINT_FAST16_MAX__
> #undef INT_FAST32_MAX
> #define INT_FAST32_MAX __INT_FAST32_MAX__
> #undef INT_FAST32_MIN
> #define INT_FAST32_MIN (-INT_FAST32_MAX - 1)
> #undef UINT_FAST32_MAX
> #define UINT_FAST32_MAX __UINT_FAST32_MAX__
> #undef INT_FAST64_MAX
> #define INT_FAST64_MAX __INT_FAST64_MAX__
> #undef INT_FAST64_MIN
> #define INT_FAST64_MIN (-INT_FAST64_MAX - 1)
> #undef UINT_FAST64_MAX
> #define UINT_FAST64_MAX __UINT_FAST64_MAX__
>
> #ifdef __INTPTR_MAX__
> # undef INTPTR_MAX
> # define INTPTR_MAX __INTPTR_MAX__
> # undef INTPTR_MIN
> # define INTPTR_MIN (-INTPTR_MAX - 1)
> #endif
> #ifdef __UINTPTR_MAX__
> # undef UINTPTR_MAX
> # define UINTPTR_MAX __UINTPTR_MAX__
> #endif
>
> #undef INTMAX_MAX
> #define INTMAX_MAX __INTMAX_MAX__
> #undef INTMAX_MIN
> #define INTMAX_MIN (-INTMAX_MAX - 1)
> #undef UINTMAX_MAX
> #define UINTMAX_MAX __UINTMAX_MAX__
>
> /* 7.18.3 Limits of other integer types */
>
> #undef PTRDIFF_MAX
> #define PTRDIFF_MAX __PTRDIFF_MAX__
> #undef PTRDIFF_MIN
> #define PTRDIFF_MIN (-PTRDIFF_MAX - 1)
>
> #undef SIG_ATOMIC_MAX
> #define SIG_ATOMIC_MAX __SIG_ATOMIC_MAX__
> #undef SIG_ATOMIC_MIN
> #define SIG_ATOMIC_MIN __SIG_ATOMIC_MIN__
>
> #undef SIZE_MAX
> #define SIZE_MAX __SIZE_MAX__
>
> #undef WCHAR_MAX
> #define WCHAR_MAX __WCHAR_MAX__
> #undef WCHAR_MIN
> #define WCHAR_MIN __WCHAR_MIN__
>
> #undef WINT_MAX
> #define WINT_MAX __WINT_MAX__
> #undef WINT_MIN
> #define WINT_MIN __WINT_MIN__
>
> #endif /* !defined __cplusplus || defined __STDC_LIMIT_MACROS */
>
> #if !defined __cplusplus || defined __STDC_CONSTANT_MACROS
>
> #undef INT8_C
> #define INT8_C(c) __INT8_C(c)
> #undef INT16_C
> #define INT16_C(c) __INT16_C(c)
> #undef INT32_C
> #define INT32_C(c) __INT32_C(c)
> #undef INT64_C
> #define INT64_C(c) __INT64_C(c)
> #undef UINT8_C
> #define UINT8_C(c) __UINT8_C(c)
> #undef UINT16_C
> #define UINT16_C(c) __UINT16_C(c)
> #undef UINT32_C
> #define UINT32_C(c) __UINT32_C(c)
> #undef UINT64_C
> #define UINT64_C(c) __UINT64_C(c)
> #undef INTMAX_C
> #define INTMAX_C(c) __INTMAX_C(c)
> #undef UINTMAX_C
> #define UINTMAX_C(c) __UINTMAX_C(c)
>
> #endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */
>
> #endif /* _GCC_STDINT_H */
>
>
>
>
>

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: Float equivalents to double functions

2009-11-22T05:21:16Z

No objections with me. Sounds like a good idea.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: eeprom_read_byte and clr ret_hi

2009-11-22T05:20:49Z

I agree that that is the way it should be.

> Possibly, it is needed to change eeprom_read_byte() definition
> to int return value. This can reduce summary size. Opinions?

This does not make sense to me. Eeprom_read_byte() is supposed to read, and return, a single byte. So why should it return a 16-bit int? In my mind this would just make it more confusing to the end user.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: Float equivalents to double functions

2009-11-21T23:22:28Z

On Sunday 22 November 2009 12:32, Andrew Hutchinson wrote:
> Could someone add float variations of common functions to avr libc -
> this would match gcc expectations for available libc functions.

Good observation.
If no objections, I will do this.

Regards,
Dmitry.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: eeprom_read_byte and clr ret_hi

2009-11-21T23:21:07Z

> > eeprom_read_byte returns a uint8_t. Why does it clear r25?
> > eerd_byte.S:
> > clr ret_hi
> >
> > Does the AVR ABI require that r25 be zeroed in a function returning a
> > single byte? If not, this instruction could be removed.

This is a misty point.
Look an example:

unsigned char foo1 (unsigned char *p)
{
return *p;
}

extern unsigned char ext2 (void);
int foo2 (void)
{
return ext2() + 1;
}

Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1()
and foo2(). The new Avr-gcc (4.3.3 and 4.4.2) are not
clear R25 in foo1().

Note, the function return value is present only in expression.
So it is promoted to integer. So it would be better to clear
R25 in foo1() only (at one place).

Possibly, it is needed to change eeprom_read_byte() definition
to int return value. This can reduce summary size. Opinions?

Regards,
Dmitry.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Float equivalents to double functions

2009-11-21T18:32:48Z

Could someone add float variations of common functions to avr libc -
this would match gcc expectations for available libc functions.

As float == double there is little effort required.

Also I note that this and similar functions would avoids this hack on
TI benchmark, so it has practical use in code compatibility.

#include <math.h>

#ifdef __AVR__
# define atanf(x) atan(x)
# define cosf(x) cos(x)
# define expf(x) exp(x)
# define logf(x) log(x)
# define sinf(x) sin(x)
# define sqrtf(x) sqrt(x)
#endif

Andy

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

[bug #28058] parameter checking in pgm_read_xxx()

2009-11-20T02:32:07Z

URL:
<http://savannah.nongnu.org/bugs/?28058>

Summary: parameter checking in pgm_read_xxx()
Project: AVR C Runtime Library
Submitted by: wek
Submitted on: Fri 20 Nov 2009 10:32:06 AM GMT
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Header files
Status: None
Percent Complete: 0%
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Release: Any
Fixed Release: None

_______________________________________________________

Details:

The pgm_read_xxx() functions in <avr/pgmspace.h> are currently implemented as
macros, casting the parameter to (uint16_t).

While the parameter is supposed to be a pointer, this enables to use any
garbage (read: non-pointer expression used by error) quietly.

Opposed to this are the similar accessing functions in eeprom.h.

It is therefore suggested, that these macros to be replaced by the following
constructions:

// #define pgm_read_byte(address_short) pgm_read_byte_near(address_short)
__attribute__((__always_inline__)) static uint8_t pgm_read_byte(const PROGMEM
uint8_t *);
static uint8_t pgm_read_byte(const PROGMEM uint8_t *addr) {
return __LPM((uint16_t)(addr));
}

// #define pgm_read_word(address_short) pgm_read_word_near(address_short)
__attribute__((__always_inline__)) static uint16_t pgm_read_word(const
PROGMEM uint16_t *);
static uint16_t pgm_read_word(const PROGMEM uint16_t *addr) {
return __LPM_word((uint16_t)(addr));
}

// #define pgm_read_dword(address_short)
pgm_read_dword_near(address_short)
__attribute__((__always_inline__)) static uint32_t pgm_read_dword(const
PROGMEM uint32_t *);
static uint32_t pgm_read_dword(const PROGMEM uint32_t *addr) {
return __LPM_dword((uint16_t)(addr));
}

I am not expert enough to judge whether the functions may be tagged also with
the __pure__ attribute.

A discussion on the topic is on
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=85490 .

Jan Waclawek

_______________________________________________________

Reply to this item at:

<http://savannah.nongnu.org/bugs/?28058>

_______________________________________________
Message sent via/by Savannah
http://savannah.nongnu.org/

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

stdint.h problem with gcc

2009-11-19T18:11:30Z

I have been going through the gcc tests for V4.5 and come across some
issues with avr-lic stdint.h

The tests that fails are gcc/gcc/testsuite/gcc.dg/c99-stdint-1.c

gcc will create it's own stdint.h and this is fine for V4.5. I have
attached this for reference.

The definition of UINT8_MAX is unsigned e.g. 255U - this fails test. 255
is ok
wchar limits are not defined- ok we dont have wchar.h but we should
still define the types.

There is another issue related to ptrdiff type. This is posted as gcc
bug - since it is possible that this particular subtest is inappropriate
for avr.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114

=================================================================
/* Copyright (C) 2008, 2009 Free Software Foundation, Inc.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

GCC is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.

You should have received a copy of the GNU General Public License and
a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
<http://www.gnu.org/licenses/>. */

/*
* ISO C Standard: 7.18 Integer types <stdint.h>
*/

#ifndef _GCC_STDINT_H
#define _GCC_STDINT_H

/* 7.8.1.1 Exact-width integer types */

#ifdef __INT8_TYPE__
typedef __INT8_TYPE__ int8_t;
#endif
#ifdef __INT16_TYPE__
typedef __INT16_TYPE__ int16_t;
#endif
#ifdef __INT32_TYPE__
typedef __INT32_TYPE__ int32_t;
#endif
#ifdef __INT64_TYPE__
typedef __INT64_TYPE__ int64_t;
#endif
#ifdef __UINT8_TYPE__
typedef __UINT8_TYPE__ uint8_t;
#endif
#ifdef __UINT16_TYPE__
typedef __UINT16_TYPE__ uint16_t;
#endif
#ifdef __UINT32_TYPE__
typedef __UINT32_TYPE__ uint32_t;
#endif
#ifdef __UINT64_TYPE__
typedef __UINT64_TYPE__ uint64_t;
#endif

/* 7.8.1.2 Minimum-width integer types */

typedef __INT_LEAST8_TYPE__ int_least8_t;
typedef __INT_LEAST16_TYPE__ int_least16_t;
typedef __INT_LEAST32_TYPE__ int_least32_t;
typedef __INT_LEAST64_TYPE__ int_least64_t;
typedef __UINT_LEAST8_TYPE__ uint_least8_t;
typedef __UINT_LEAST16_TYPE__ uint_least16_t;
typedef __UINT_LEAST32_TYPE__ uint_least32_t;
typedef __UINT_LEAST64_TYPE__ uint_least64_t;

/* 7.8.1.3 Fastest minimum-width integer types */

typedef __INT_FAST8_TYPE__ int_fast8_t;
typedef __INT_FAST16_TYPE__ int_fast16_t;
typedef __INT_FAST32_TYPE__ int_fast32_t;
typedef __INT_FAST64_TYPE__ int_fast64_t;
typedef __UINT_FAST8_TYPE__ uint_fast8_t;
typedef __UINT_FAST16_TYPE__ uint_fast16_t;
typedef __UINT_FAST32_TYPE__ uint_fast32_t;
typedef __UINT_FAST64_TYPE__ uint_fast64_t;

/* 7.8.1.4 Integer types capable of holding object pointers */

#ifdef __INTPTR_TYPE__
typedef __INTPTR_TYPE__ intptr_t;
#endif
#ifdef __UINTPTR_TYPE__
typedef __UINTPTR_TYPE__ uintptr_t;
#endif

/* 7.8.1.5 Greatest-width integer types */

typedef __INTMAX_TYPE__ intmax_t;
typedef __UINTMAX_TYPE__ uintmax_t;

#if !defined __cplusplus || defined __STDC_LIMIT_MACROS

/* 7.18.2 Limits of specified-width integer types */

#ifdef __INT8_MAX__
# undef INT8_MAX
# define INT8_MAX __INT8_MAX__
# undef INT8_MIN
# define INT8_MIN (-INT8_MAX - 1)
#endif
#ifdef __UINT8_MAX__
# undef UINT8_MAX
# define UINT8_MAX __UINT8_MAX__
#endif
#ifdef __INT16_MAX__
# undef INT16_MAX
# define INT16_MAX __INT16_MAX__
# undef INT16_MIN
# define INT16_MIN (-INT16_MAX - 1)
#endif
#ifdef __UINT16_MAX__
# undef UINT16_MAX
# define UINT16_MAX __UINT16_MAX__
#endif
#ifdef __INT32_MAX__
# undef INT32_MAX
# define INT32_MAX __INT32_MAX__
# undef INT32_MIN
# define INT32_MIN (-INT32_MAX - 1)
#endif
#ifdef __UINT32_MAX__
# undef UINT32_MAX
# define UINT32_MAX __UINT32_MAX__
#endif
#ifdef __INT64_MAX__
# undef INT64_MAX
# define INT64_MAX __INT64_MAX__
# undef INT64_MIN
# define INT64_MIN (-INT64_MAX - 1)
#endif
#ifdef __UINT64_MAX__
# undef UINT64_MAX
# define UINT64_MAX __UINT64_MAX__
#endif

#undef INT_LEAST8_MAX
#define INT_LEAST8_MAX __INT_LEAST8_MAX__
#undef INT_LEAST8_MIN
#define INT_LEAST8_MIN (-INT_LEAST8_MAX - 1)
#undef UINT_LEAST8_MAX
#define UINT_LEAST8_MAX __UINT_LEAST8_MAX__
#undef INT_LEAST16_MAX
#define INT_LEAST16_MAX __INT_LEAST16_MAX__
#undef INT_LEAST16_MIN
#define INT_LEAST16_MIN (-INT_LEAST16_MAX - 1)
#undef UINT_LEAST16_MAX
#define UINT_LEAST16_MAX __UINT_LEAST16_MAX__
#undef INT_LEAST32_MAX
#define INT_LEAST32_MAX __INT_LEAST32_MAX__
#undef INT_LEAST32_MIN
#define INT_LEAST32_MIN (-INT_LEAST32_MAX - 1)
#undef UINT_LEAST32_MAX
#define UINT_LEAST32_MAX __UINT_LEAST32_MAX__
#undef INT_LEAST64_MAX
#define INT_LEAST64_MAX __INT_LEAST64_MAX__
#undef INT_LEAST64_MIN
#define INT_LEAST64_MIN (-INT_LEAST64_MAX - 1)
#undef UINT_LEAST64_MAX
#define UINT_LEAST64_MAX __UINT_LEAST64_MAX__

#undef INT_FAST8_MAX
#define INT_FAST8_MAX __INT_FAST8_MAX__
#undef INT_FAST8_MIN
#define INT_FAST8_MIN (-INT_FAST8_MAX - 1)
#undef UINT_FAST8_MAX
#define UINT_FAST8_MAX __UINT_FAST8_MAX__
#undef INT_FAST16_MAX
#define INT_FAST16_MAX __INT_FAST16_MAX__
#undef INT_FAST16_MIN
#define INT_FAST16_MIN (-INT_FAST16_MAX - 1)
#undef UINT_FAST16_MAX
#define UINT_FAST16_MAX __UINT_FAST16_MAX__
#undef INT_FAST32_MAX
#define INT_FAST32_MAX __INT_FAST32_MAX__
#undef INT_FAST32_MIN
#define INT_FAST32_MIN (-INT_FAST32_MAX - 1)
#undef UINT_FAST32_MAX
#define UINT_FAST32_MAX __UINT_FAST32_MAX__
#undef INT_FAST64_MAX
#define INT_FAST64_MAX __INT_FAST64_MAX__
#undef INT_FAST64_MIN
#define INT_FAST64_MIN (-INT_FAST64_MAX - 1)
#undef UINT_FAST64_MAX
#define UINT_FAST64_MAX __UINT_FAST64_MAX__

#ifdef __INTPTR_MAX__
# undef INTPTR_MAX
# define INTPTR_MAX __INTPTR_MAX__
# undef INTPTR_MIN
# define INTPTR_MIN (-INTPTR_MAX - 1)
#endif
#ifdef __UINTPTR_MAX__
# undef UINTPTR_MAX
# define UINTPTR_MAX __UINTPTR_MAX__
#endif

#undef INTMAX_MAX
#define INTMAX_MAX __INTMAX_MAX__
#undef INTMAX_MIN
#define INTMAX_MIN (-INTMAX_MAX - 1)
#undef UINTMAX_MAX
#define UINTMAX_MAX __UINTMAX_MAX__

/* 7.18.3 Limits of other integer types */

#undef PTRDIFF_MAX
#define PTRDIFF_MAX __PTRDIFF_MAX__
#undef PTRDIFF_MIN
#define PTRDIFF_MIN (-PTRDIFF_MAX - 1)

#undef SIG_ATOMIC_MAX
#define SIG_ATOMIC_MAX __SIG_ATOMIC_MAX__
#undef SIG_ATOMIC_MIN
#define SIG_ATOMIC_MIN __SIG_ATOMIC_MIN__

#undef SIZE_MAX
#define SIZE_MAX __SIZE_MAX__

#undef WCHAR_MAX
#define WCHAR_MAX __WCHAR_MAX__
#undef WCHAR_MIN
#define WCHAR_MIN __WCHAR_MIN__

#undef WINT_MAX
#define WINT_MAX __WINT_MAX__
#undef WINT_MIN
#define WINT_MIN __WINT_MIN__

#endif /* !defined __cplusplus || defined __STDC_LIMIT_MACROS */

#if !defined __cplusplus || defined __STDC_CONSTANT_MACROS

#undef INT8_C
#define INT8_C(c) __INT8_C(c)
#undef INT16_C
#define INT16_C(c) __INT16_C(c)
#undef INT32_C
#define INT32_C(c) __INT32_C(c)
#undef INT64_C
#define INT64_C(c) __INT64_C(c)
#undef UINT8_C
#define UINT8_C(c) __UINT8_C(c)
#undef UINT16_C
#define UINT16_C(c) __UINT16_C(c)
#undef UINT32_C
#define UINT32_C(c) __UINT32_C(c)
#undef UINT64_C
#define UINT64_C(c) __UINT64_C(c)
#undef INTMAX_C
#define INTMAX_C(c) __INTMAX_C(c)
#undef UINTMAX_C
#define UINTMAX_C(c) __UINTMAX_C(c)

#endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */

#endif /* _GCC_STDINT_H */

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

Re: eeprom_read_byte and clr ret_hi

2009-11-18T16:01:03Z

http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_reg_usage
This explain the why. Not sure about the ABI

On Wed, Nov 18, 2009 at 6:53 PM, Shaun Jackman <sjackman@...> wrote:

> eeprom_read_byte returns a uint8_t. Why does it clear r25?
> eerd_byte.S:
> clr ret_hi
>
> Does the AVR ABI require that r25 be zeroed in a function returning a
> single byte? If not, this instruction could be removed.
>
> Cheers,
> Shaun
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> AVR-libc-dev@...
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
>

--
Frédéric Nadeau ing. jr

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

eeprom_read_byte and clr ret_hi

2009-11-18T15:53:10Z

eeprom_read_byte returns a uint8_t. Why does it clear r25?
eerd_byte.S:
clr ret_hi

Does the AVR ABI require that r25 be zeroed in a function returning a
single byte? If not, this instruction could be removed.

Cheers,
Shaun

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: Upcoming WinAVR release...

2009-11-16T04:55:48Z

Mmm. Probably not. Sorry for the hassle.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: Upcoming WinAVR release...

2009-11-16T04:41:56Z

May be we looking forward also to a decent changelog, this time?

Jan Waclawek

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

RE: Upcoming WinAVR release...

2009-11-15T15:03:13Z

For other internal reasons, the WinAVR release will be using 4.3.3. We are specifically not moving to 4.4.x.

_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@...
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev