--- Comment #3 from abnikant dot singh at atmel dot com 2010-09-20 04:24
---
(In reply to comment #2)
(In reply to comment #1)
This bug is confirmed. andhi3/andsi3 causing this problem. conditional
checks
in andhi3 and andsi3 need to compare with zero instead of 0xff [etc
--- Comment #8 from abnikant dot singh at atmel dot com 2010-09-14 06:23
---
Created an attachment (id=21787)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21787action=view)
Test case assembler output for 4.5.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
--- Comment #9 from abnikant dot singh at atmel dot com 2010-09-14 06:25
---
Lot better code size in gcc-4.5.0 and above [head]. See the attachment in
comment #8.
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
--- Comment #34 from abnikant dot singh at atmel dot com 2010-09-14 07:06
---
Yeah, this is happening because of the type promotion in gcc/c-common.c in the
function c_promoting_integer_type_p. See this:
/* Nonzero if the type T promotes to int. This is (nearly) the
integral
--- Comment #35 from abnikant dot singh at atmel dot com 2010-09-14 07:13
---
In the head c-common.c is placed in gcc/c-family/c-common.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
--- Comment #3 from abnikant dot singh at atmel dot com 2010-09-14 08:17
---
Created an attachment (id=21788)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21788action=view)
attached patch solves this problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145
--- Comment #6 from abnikant dot singh at atmel dot com 2010-09-13 11:38
---
we get better code in the head. Both the cases [test1 and test2] produce the
same piece of code:
i.e for the following test case:
void foo(char *p);
void test1(char * p)
{
foo(p++);
foo(p++);
foo
--- Comment #12 from abnikant dot singh at atmel dot com 2010-09-13 12:09
---
I have verified the attached test case and test case with other comments and
found the code generated is correct i.e. the variable is not promoted to
integer in gcc-4.3.3, gcc-4.4.3, gcc-4.5.0 and also
--- Comment #1 from abnikant dot singh at atmel dot com 2010-09-13 05:58
---
This bug is confirmed. andhi3/andsi3 causing this problem. conditional checks
in andhi3 and andsi3 need to compare with zero instead of 0xff [etc].
i.e. in andhi3 we need to replace
(mask 0x00ff) != 0xff
--- Comment #21 from abnikant dot singh at atmel dot com 2010-09-08 09:50
---
The head version [gcc version 4.6.0 20100907 (experimental) (GCC)] tends to
inline the attached test case in case of -Os, just because it gets better code
size [see the dump using : -fdump-ipa-inline
--- Comment #9 from abnikant dot singh at atmel dot com 2010-09-07 11:36
---
gcc version 4.6.0 20100907 (experimental) is not performing the inline in -Os
for the test case:
#define UCSRA (*(volatile unsigned char *)0x2B)
#define UDRE 5
#define UDR (*(volatile unsigned char *)0x2C
--- Comment #5 from abnikant dot singh at atmel dot com 2010-09-03 06:45
---
gcc version 4.6.0 20100903 (experimental) (GCC) [Head] produces 2 words:
mult:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
rcall __mulsi3
/* epilogue start
--- Comment #6 from abnikant dot singh at atmel dot com 2009-08-30 02:02
---
f32.c succeeds for
4.3.2, -O[0123s]
4.4.0, -O[0123s]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25742
--- Comment #3 from abnikant dot singh at atmel dot com 2009-08-20 12:03
---
No error observed in gcc-4.4.0,libgcc.S compiles fine for -mmcu=avr31 with the
same command line as reported in the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35936
--- Comment #1 from abnikant dot singh at atmel dot com 2009-08-19 11:57
---
If HARD_REGNO_MODE_OK (r, mode1) and HARD_REGNO_MODE_OK (r, mode2) are always
the same for any r, then MODES_TIEABLE_P (mode1, mode2) should be nonzero. If
they differ for any r, you should define this macro
--- Comment #1 from abnikant dot singh at atmel dot com 2009-08-17 09:40
---
At -O2, -O3, -Os g_52 contains the value 5 while in -O1 it is 1.It is
confirmed.
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-17 10:03
---
The attached preprocessed file compiles fine with avr-gcc-4.4.0,4.3.2,4.3.3
with --mmcu=avr25 for all optimization levels.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39184
--- Comment #3 from abnikant dot singh at atmel dot com 2009-08-17 12:02
---
Subject: RE: [avr] loop bug
Hi Eric,
Version is (avr-gcc )4.3.2.
-Original Message-
From: eric dot weddington at atmel dot com [mailto:gcc-bugzi...@gcc.gnu.org]
Sent: Monday, August 17, 2009 5:26
--- Comment #4 from abnikant dot singh at atmel dot com 2009-08-17 12:08
---
4.3.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633
--- Comment #5 from abnikant dot singh at atmel dot com 2009-08-06 10:30
---
I guess this link can be of help
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01292.html [r28 and r29 frame
pointer]
--
abnikant dot singh at atmel dot com changed:
What|Removed
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-06 11:13
---
gcc.dg/torture/pr37868.c should report the error..This is the positive test
case for avr-gcc as the size of int = 16 bits,and in the struct X int bit field
width is 16
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:52
---
It compiles fine with both avr-gcc-4.3.3 and avr-gcc-4.4.0
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
--- Comment #2 from abnikant dot singh at atmel dot com 2009-08-05 11:56
---
gcc.c-torture/compile/pr32606.c compiles fine with both avr-gcc-4.3.3 and
avr-gcc-4.4.0
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
23 matches
Mail list logo
