Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wvangulik at xs4all dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
--- Comment #1 from wvangulik at xs4all dot nl 2007-08-11 17:56 ---
Created an attachment (id=14053)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14053&action=view)
examples of good extraction and bad extraction
Adding the test file showing the missed optimization
--
Using this version/config:
~`
Using built-in specs.
Target: avr
Configured with: ../gcc-4.1.2/configure --prefix=/c/WinAVR --target=avr
--enable
-languages=c,c++ --with-dwarf2 --enable-win32-registry=WinAVR-20070525
--disable
-nls --with-gmp=/usr/local --with-mpfr=/usr/local --enab
--- Comment #1 from wvangulik at xs4all dot nl 2007-08-11 18:14 ---
Created an attachment (id=14054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14054&action=view)
Example
C source showing non optimal code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33050
--- Comment #4 from wvangulik at xs4all dot nl 2007-08-24 18:52 ---
Created an attachment (id=14105)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14105&action=view)
Assembler output of testcase using 4.1.2
This is the requested assembler output that Eric asked for
--
--- Comment #3 from wvangulik at xs4all dot nl 2007-08-24 19:36 ---
(In reply to comment #2)
> 4.3.0 20070817 snapshot generates this for the testcase:
>
Well at least the extra clr r25 is gone...
I just tried some simpler code:
extern unsigned char foo();
unsigned cha
--- Comment #1 from wvangulik at xs4all dot nl 2007-09-12 07:20 ---
Tested this against 4.1.2. The output for the given test case is different
(optimiser removed the useless loading):
/* prologue: frame size=0 */
push r28
/* prologue end (size=1) */
/* #APP */
in r28
--- Comment #2 from wvangulik at xs4all dot nl 2007-09-12 07:32 ---
(In reply to comment #1)
Hmm I cheated... I used -Os when compiling
Compiling without -O[n] gives no warning
Just tried compiling -O and then it does generate the error. It seems optimiser
flags triggers the warning
--- Comment #3 from wvangulik at xs4all dot nl 2007-09-12 07:35 ---
(In reply to comment #2)
Ok I need some coffee...
The error IS generated when using -O[n] (so on -O as well)
Without specifing -O the compiler does not generate the warning.
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from wvangulik at xs4all dot nl 2008-01-20 19:30 ---
Bug is still present in 4.2.2.
Some more info:
I rewrote the example to (atleast for me) little more clear example.
struct fseqp_void
{
void (*p) (void);
char *e;
};
struct fseqp_void c;
void bar (void
mary: Incomplete check in RTL for "pm()" annotation
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wvangulik at xs4all dot nl
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wvangulik at xs4all dot nl
GCC host triplet: linux-x86
GCC target triplet: multiple (at least: arm, x86, avr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
--- Comment #1 from wvangulik at xs4all dot nl 2009-04-03 08:48 ---
Created an attachment (id=17580)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17580&action=view)
C file showing bug
compile using:
gcc -S -funroll-loops -0[0123s] main.c
--
http://gcc.gnu.org/b
--- Comment #3 from wvangulik at xs4all dot nl 2009-04-07 07:55 ---
(In reply to comment #2)
> It'd be nice to know if -fno-tree-reassoc helped here.
>
Yes that solves the problem. I tried for -O[123s] (x86 and avr).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
--- Comment #2 from wvangulik at xs4all dot nl 2009-04-07 09:51 ---
The problem is it uses R22 as loop counter and as the shift counter. I could
not (yet) reproduce the problem in a smaller example.
This could be the same problem as:
http://lists.gnu.org/archive/html/avr-gcc-list/2009
--- Comment #3 from wvangulik at xs4all dot nl 2009-04-07 13:26 ---
(In reply to comment #2)
> The problem is it uses R22 as loop counter and as the shift counter. I could
> not (yet) reproduce the problem in a smaller example.
This is my minimal test case:
static ui
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278
Wouter van Gulik changed:
What|Removed |Added
CC||wvangulik at xs4all dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049
Wouter van Gulik changed:
What|Removed |Added
Known to fail||
--- Comment #13 from Wouter van Gulik
--- Comment #9 from wvangulik at xs4all dot nl 2010-08-23 13:36 ---
I already generated a simple testcase (although different)in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39635. The comments from Andy in
the linked report might be worth reproducing here
--
http://gcc.gnu.org
--- Comment #1 from wvangulik at xs4all dot nl 2010-06-17 18:38 ---
The linked mail shows that 4.2.2 in that test case did not suffer this problem
(it uses lpm r31, Z) which is ok.
http://lists.nongnu.org/archive/html/avr-gcc-list/2008-01/msg00026.html
Maybe it is a xmega specific
--- Comment #6 from wvangulik at xs4all dot nl 2010-06-18 08:33 ---
This bug can be closed it is a binutils bug. The dissambler is generating the
wrong instruction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564
--- Comment #13 from wvangulik at xs4all dot nl 2007-10-24 11:16 ---
(In reply to comment #10)
Something like this is smaller, faster and works for all registers (no need for
LD_regs). And could easily be writtin in to a insn:
; rOut: output register
; rIn: input register
; rIn, Z, N
--- Comment #5 from wvangulik at xs4all dot nl 2007-11-01 21:50 ---
It seems that this is caused by the fact that eeprom_read_word is actually a
piece of inline assembler returning it's value in the Z register, using z as
"pointer class" description.
This then somehow
--- Comment #6 from wvangulik at xs4all dot nl 2007-11-01 21:53 ---
(In reply to comment #5)
Oops forgot to tell I am using avr-gcc 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644
--- Comment #8 from wvangulik at xs4all dot nl 2007-11-05 22:48 ---
(In reply to comment #7)
> With Mike's description in comment #6, confirmed on 4.1.2 and 4.2.2. AVR GCC
> 4.2.2 is worse than 4.1.2, in that even if sub2 is called with (x+1), the
> variable is still 16 b
--- Comment #10 from wvangulik at xs4all dot nl 2007-11-06 19:34 ---
(In reply to comment #9)
>
> I think you will also find that if x is changed from ststic to auto the same
> problem appears.
>
Ok, I tried to find the minimum test case.
And it has nothing todo with sta
--- Comment #1 from wvangulik at xs4all dot nl 2007-11-06 20:41 ---
Well, that would be ok for the AVR. The test is allocating more than the 64K of
adressable space the AVR has. This should be a "expected to fail" for the AVR
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33782
--- Comment #11 from wvangulik at xs4all dot nl 2007-11-06 21:01 ---
I just realised I did not tried hard enough to find the smallest case:
===
volatile unsigned char bar;
void foo(void) {
unsigned char x;
for(x=0;x<128; x++) {
//bar
--- Comment #14 from wvangulik at xs4all dot nl 2007-11-30 14:59 ---
Note that the use of clz for the avr is avoided by using avr-libc's math
library.
See http://lists.gnu.org/archive/html/avr-libc-dev/2007-11/msg00048.html for
more details.
--
wvangulik at xs4all dot nl ch
--- Comment #16 from wvangulik at xs4all dot nl 2007-12-23 20:15 ---
> (In reply to comment #14)
>
> > Note that the use of clz for the avr is avoided by using avr-libc's math
> > library.
>
> Not confirmed. A simple test program using a floating point
--- Comment #4 from wvangulik at xs4all dot nl 2008-01-10 19:00 ---
In 4.2.2 there is still no warning when compiling without -O.
void main(void)
{
volatile struct
{
int a, b, c, d, e, f;
} x;
x.d = 5;
asm volatile("in r28, 0x2F" : : : "r28
--- Comment #1 from wvangulik at xs4all dot nl 2008-01-11 08:17 ---
Created an attachment (id=14920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14920&action=view)
Test case showing the three cases
Compile using -fno-line.
For the AVR I used: avr-gcc -Wall -Os -fno-inlin
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wvangulik at xs4all dot nl
GCC target triplet: multiple-none-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
--- Comment #1 from wvangulik at xs4all dot nl 2008-07-18 22:31 ---
This is because binutils 2.18 does not support architecture 35. Please update
to 2.18.5 (dev snapshot) ftp://sourceware.org/pub/binutils/snapshots. Search
the avr-gcc list for more info.
--
http://gcc.gnu.org
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wvangulik at xs4all dot nl
Target Milestone: ---
Target: arm
Given the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116677
--- Comment #2 from Wouter van Gulik ---
(In reply to Richard Biener from comment #1)
> GCC doesn't implement the "common initial sequence rule", so I think you
> need to use -fno-strict-aliasing; struct sockaddr_storage and struct
> sockaddr_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116677
Wouter van Gulik changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34737
Wouter van Gulik changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
38 matches
Mail list logo
