public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/29964]  New: volatile problem in optimized functions
@ 2006-11-23 21:31 sb at anoto dot com
  2006-11-23 21:34 ` [Bug c/29964] " sb at anoto dot com
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: sb at anoto dot com @ 2006-11-23 21:31 UTC (permalink / raw)
  To: gcc-bugs

Using -Os and volatile results in functions, sometimes the optimizer 'forgets'
the volatile property of the function and makes it pure. This has a major
impact in some cases. Test case 1 gives buggy code where test case 2 & 3 works.
The command line to compile this was arm-elf-gcc -c test.c -Os

/* Test case 1 */

struct test_a { volatile int a; };

int func_a(void) __attribute__ ((noinline));
int func_a(void)
{
        return ((struct test_a *)0)->a;
}

void a(void)
{
        while(func_a() == 0);
}

/* Test case 2 */

struct test_b { volatile int a;};

int func_b(void) __attribute__ ((noinline));
int func_b(void)
{
        volatile struct test_b *t= 0;
        return t->a;
}

void b(void)
{
        while(func_b() == 0);
}

/* Test case 3 */

struct test_c { volatile int a; };

int func_c(void) __attribute__ ((noinline));
int func_c(void)
{
        return ((volatile struct test_c *)0)->a;
}

void c(void)
{
        while(func_c() == 0);
}


The result from this is:


00000000 <func_a>:
   0:   e3a03000        mov     r3, #0  ; 0x0
   4:   e5930000        ldr     r0, [r3]
   8:   e12fff1e        bx      lr

0000000c <a>:
   c:   e52de004        str     lr, [sp, #-4]!
  10:   ebfffffe        bl      0 <func_a>
  14:   e3500000        cmp     r0, #0  ; 0x0
  18:   0a000003        beq     14 <a+0x8>      <--- looping back to the cmp!?!
  1c:   e49df004        ldr     pc, [sp], #4

00000020 <func_b>:
  20:   e3a03000        mov     r3, #0  ; 0x0
  24:   e5930000        ldr     r0, [r3]
  28:   e12fff1e        bx      lr

0000002c <b>:
  2c:   e52de004        str     lr, [sp, #-4]!
  30:   ebfffffe        bl      20 <func_b>
  34:   e3500000        cmp     r0, #0  ; 0x0
  38:   0a00000a        beq     30 <b+0x4> <--- looping back to the functon
call
  3c:   e49df004        ldr     pc, [sp], #4

00000040 <func_c>:
  40:   e3a03000        mov     r3, #0  ; 0x0
  44:   e5930000        ldr     r0, [r3]
  48:   e12fff1e        bx      lr

0000004c <c>:
  4c:   e52de004        str     lr, [sp, #-4]!
  50:   ebfffffe        bl      40 <func_c>
  54:   e3500000        cmp     r0, #0  ; 0x0
  58:   0a000012        beq     50 <c+0x4> <--- looping back to the functon
call
  5c:   e49df004        ldr     pc, [sp], #4


-- 
           Summary: volatile problem in optimized functions
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sb at anoto dot com
 GCC build triplet: x86-pc-cygwin
  GCC host triplet: x86-pc-cygwin
GCC target triplet: arm-elf-gcc


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


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2006-11-25 21:12 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-11-23 21:31 [Bug c/29964] New: volatile problem in optimized functions sb at anoto dot com
2006-11-23 21:34 ` [Bug c/29964] " sb at anoto dot com
2006-11-23 21:41 ` [Bug tree-optimization/29964] [4.1/4.2/4.3 Regression] function with volatile operators still found to be pure pinskia at gcc dot gnu dot org
2006-11-23 22:08 ` pinskia at gcc dot gnu dot org
2006-11-23 22:49 ` pinskia at gcc dot gnu dot org
2006-11-24 18:32 ` pinskia at gcc dot gnu dot org
2006-11-24 18:34 ` [Bug tree-optimization/29964] [4.1/4.2 " pinskia at gcc dot gnu dot org
2006-11-25 16:45 ` pinskia at gcc dot gnu dot org
2006-11-25 21:12 ` [Bug tree-optimization/29964] [4.1 " pinskia at gcc dot gnu dot org
2006-11-25 21:12 ` pinskia at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).