[Bug target/37162] [4.4 Regression] gcc.c-torture/compile/20020120-1.c fails with ICE on -O[23s]
--- 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 CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37162
[Bug target/37163] [4.4 Regression] gcc.c-torture/compile/pr32606.c fails with ICE on -Os
--- 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 CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37163
[Bug target/32895] Clobber list isn't working
--- 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 |Added CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32895
[Bug testsuite/38202] [avr] FAIL: gcc.dg/torture/pr37868.c
--- 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/show_bug.cgi?id=38202
[Bug target/39633] [avr] loop bug
--- 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 CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633
[Bug target/39184] ICE in tree_low_cst, at tree.c:4976
--- 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
[Bug target/39633] [avr] loop bug
--- 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 PM To: Singh, Abnikant Subject: [Bug target/39633] [avr] loop bug --- Comment #2 from eric dot weddington at atmel dot com 2009-08-17 11:56 --- (In reply to comment #1) > At -O2, -O3, -Os g_52 contains the value 5 while in -O1 it is 1.It is > confirmed. > Hi Abnikant, What version did you use to confirm this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633
[Bug target/39633] [avr] loop bug
--- 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
[Bug other/19815] Documentation change - GCC Internals MODES_TIEABLE_P
--- 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 to return zero unless some other mechanism ensures the accessibility of the value in a narrower mode." In case of avr: if (mode1 != mode2) then HARD_REGNO_MODE_OK (r, mode1) != HARD_REGNO_MODE_OK (r, mode2) and hence MODES_TIEABLE_P (mode1, mode2) should be 0. [ But this is true only if we do not have other mechanism to access the value in narrower mode ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19815
[Bug driver/28718] Call to -lgcc added prior to user libraries
--- Comment #9 from abnikant dot singh at atmel dot com 2009-08-19 15:32 --- This is because libstdc++ is not build in case of avr(8 bit),I did check it in avr32 there I get flags in the sequence : -lstdc++ -lm -lgcc -- abnikant dot singh at atmel dot com changed: What|Removed |Added CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718
[Bug target/35936] Cannot compile libgcc.S on avr
--- 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
[Bug rtl-optimization/25742] Internal compiler error in gen_rtx_SUBREG
--- 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
[Bug target/35507] [avr] 4.3.0: size of small funcion increases from 2 to 29 words
--- 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 */ ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35507
[Bug middle-end/31528] Inlining with -Os increases code size
--- 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)
static void putch(char ch);
void putch(char ch)
{
while (!(UCSRA & (1<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
[Bug middle-end/30908] tree cost for types which are > WORD_SIZE
--- 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] by performing inline.
If the test case is changed slightly as
given below, the head version does not perform the inline because without
performing inline it gets better code size.
#ifdef NOINLINE
__attribute__((noinline))
#endif
;
static void wait(int i)
{
volatile int a = 5;
while (i-- > 0)
{
a = a + i;
}
asm volatile("" ::: "memory");
}
int
main(void)
{
volatile x;
for (;;) {
x = 1;
wait(100);
x = 0;
wait(100);
}
return 0;
}
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
CC| |abnikant dot singh at atmel
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug target/43088] [avr] Suspect optimizer missed code in gcc 4.4.3..
--- 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 by (mask & 0x00ff) != 0. Similarly other checks in andhi3 and andsi3 need to be replaced. -- abnikant dot singh at atmel dot com changed: What|Removed |Added CC| |abnikant dot singh at atmel | |dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43088
[Bug tree-optimization/34737] Scheduling of post-modified function arguments is not good
--- 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(p++);
foo(p++);
}
void test2(char * p)
{
foo(p); p++;
foo(p); p++;
foo(p); p++;
foo(p); p++;
}
we get:
test1:
push r28
push r29
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
.L__stack_usage = 2
mov r28,r24
mov r29,r25
rcall foo
mov r24,r28
mov r25,r29
adiw r24,1
rcall foo
mov r24,r28
mov r25,r29
adiw r24,2
rcall foo
mov r24,r28
mov r25,r29
adiw r24,3
rcall foo
/* epilogue start */
pop r29
pop r28
ret
.size test1, .-test1
.global test2
.type test2, @function
test2:
push r28
push r29
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
.L__stack_usage = 2
mov r28,r24
mov r29,r25
rcall foo
mov r24,r28
mov r25,r29
adiw r24,1
rcall foo
mov r24,r28
mov r25,r29
adiw r24,2
rcall foo
mov r24,r28
mov r25,r29
adiw r24,3
rcall foo
/* epilogue start */
pop r29
pop r28
ret
.size test2, .-test2
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
CC||abnikant dot singh at atmel
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
[Bug middle-end/33970] Missed optimization using unsigned char loop variable
--- 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 the latest head.
The assembly for the following piece of code:
int sub2(unsigned char); // external function
void foo(void) {
unsigned char x;
for(x=0;x<128; x++)
{
sub2(x); //x is becomes a int (16bit)
// sub2(x+1); //x is char (8bit)
}
}
in gcc-4.3.3 is:
foo:
push r17
/* prologue: function */
/* frame size = 0 */
ldi r17,lo8(0)
.L2:
mov r24,r17
rcall sub2
subi r17,lo8(-(1))
cpi r17,lo8(-128)
brne .L2
/* epilogue start */
pop r17
ret
.size foo, .-foo
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
CC| |abnikant dot singh at atmel
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33970
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
--- 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=21787&action=view) Test case assembler output for 4.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
--- 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 CC||abnikant dot singh at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly
--- 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 promotions defined in ISO C99 6.3.1.1/2. */
bool
c_promoting_integer_type_p (const_tree t)
{
switch (TREE_CODE (t))
{
case INTEGER_TYPE:
return (TYPE_MAIN_VARIANT (t) == char_type_node
|| TYPE_MAIN_VARIANT (t) == signed_char_type_node
|| TYPE_MAIN_VARIANT (t) == unsigned_char_type_node
|| TYPE_MAIN_VARIANT (t) == short_integer_type_node
|| TYPE_MAIN_VARIANT (t) == short_unsigned_type_node
|| TYPE_PRECISION (t) < TYPE_PRECISION (integer_type_node));
case ENUMERAL_TYPE:
/* ??? Technically all enumerations not larger than an int
promote to an int. But this is used along code paths
that only want to notice a size change. */
return TYPE_PRECISION (t) < TYPE_PRECISION (integer_type_node);
case BOOLEAN_TYPE:
return 1;
default:
return 0;
}
}
So by commenting the case INTEGER_TYPE, we will get the call to _divmodqi4, but
I don't think this is the right thing to do.
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
CC| |abnikant dot singh at atmel
| |dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065
[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly
--- 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
[Bug target/18145] Do not emit __do_copy_data or __do_clear_bss if .data or .bss is empty.
--- 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=21788&action=view) attached patch solves this problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145
[Bug target/43088] [avr] Suspect optimizer missed code in gcc 4.4.3..
--- 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]. > > i.e. in andhi3 we need to replace > > (mask & 0x00ff) != 0xff by (mask & 0x00ff) != 0. > > > > Similarly other checks in andhi3 and andsi3 need to be replaced. > > > > Abnikant, > > Is this bug confirmed for the reported version (4.4.3), or for trunk/4.6? > It exits for the reported version (4.4.3) and as well as for trunk/4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43088
