[Bug c/45126] New: volatile lost in optimization

[Bug c/45126] New: volatile lost in optimization

[majbrock at dse dot nl]

Hi,

When -O -ftree-vrp optimizations are used the volatileness seems to be lost.
Even though this test relies upon undefined behaviour according to the C99 spec
the result is different with optimizations on or off.

I think that even when both accesses of vus are in the same expression it
should still be read twice and no assumption should be made to its value.

Maarten Brock
Developer of SDCC, Small Device C Compiler, http://sdcc.sourceforge.net

Here is the compiler output:

Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus'
'-mtune=generic' '-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -E -quiet -v vus.c -D_FORTIFY_SOURCE=2
-mtune=generic -march=i486 -ftree-vrp -O -fpch-preprocess -fstack-protector -o
vus.i
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/i486-linux-gnu/4.4.1/include
 /usr/lib/gcc/i486-linux-gnu/4.4.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus'
'-mtune=generic' '-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.1/cc1 -fpreprocessed vus.i -quiet -dumpbase
vus.c -mtune=generic -march=i486 -auxbase vus -O -version -ftree-vrp
-fstack-protector -o vus.s
GNU C (Ubuntu 4.4.1-4ubuntu9) version 4.4.1 (i486-linux-gnu)
        compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version
2.4.1-p2.
GGC heuristics: --param ggc-min-expand=61 --param ggc-min-heapsize=59624
Compiler executable checksum: 8f30a5fdc2c06e07cc337ee4c8f69ccf
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus'
'-mtune=generic' '-march=i486'
 as -V -Qy -o vus.o vus.s
GNU assembler version 2.20 (i486-linux-gnu) using BFD version (GNU Binutils for
Ubuntu) 2.20
COMPILER_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/i486-linux-gnu/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' '-ftree-vrp' '-o' 'vus'
'-mtune=generic' '-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.1/collect2 --build-id --eh-frame-hdr -m
elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o vus -z relro
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crt1.o
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crti.o
/usr/lib/gcc/i486-linux-gnu/4.4.1/crtbegin.o
-L/usr/lib/gcc/i486-linux-gnu/4.4.1 -L/usr/lib/gcc/i486-linux-gnu/4.4.1
-L/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.4.1/../../..
-L/usr/lib/i486-linux-gnu vus.o -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i486-linux-gnu/4.4.1/crtend.o
/usr/lib/gcc/i486-linux-gnu/4.4.1/../../../../lib/crtn.o

And the preprocessed file:

# 1 "vus.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "vus.c"
# 1 "/usr/include/assert.h" 1 3 4
# 37 "/usr/include/assert.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 313 "/usr/include/features.h" 3 4
# 1 "/usr/include/bits/predefs.h" 1 3 4
# 314 "/usr/include/features.h" 2 3 4
# 346 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 353 "/usr/include/sys/cdefs.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 354 "/usr/include/sys/cdefs.h" 2 3 4
# 347 "/usr/include/features.h" 2 3 4
# 378 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4



# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 5 "/usr/include/gnu/stubs.h" 2 3 4


# 1 "/usr/include/gnu/stubs-32.h" 1 3 4
# 8 "/usr/include/gnu/stubs.h" 2 3 4
# 379 "/usr/include/features.h" 2 3 4
# 38 "/usr/include/assert.h" 2 3 4
# 68 "/usr/include/assert.h" 3 4



extern void __assert_fail (__const char *__assertion, __const char *__file,
      unsigned int __line, __const char *__function)
     __attribute__ ((__nothrow__)) __attribute__ ((__noreturn__));


extern void __assert_perror_fail (int __errnum, __const char *__file,
      unsigned int __line,
      __const char *__function)
     __attribute__ ((__nothrow__)) __attribute__ ((__noreturn__));




extern void __assert (const char *__assertion, const char *__file, int __line)
     __attribute__ ((__nothrow__)) __attribute__ ((__noreturn__));



# 2 "vus.c" 2

volatile unsigned short vus = 0xfffe;

int main(void)
{
  ((vus * vus < 1) ? (void) (0) : __assert_fail ("vus * vus < 1", "vus.c", 7,
__PRETTY_FUNCTION__));
  return 1;
}


-- 
           Summary: volatile lost in optimization
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: majbrock at dse dot nl
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c/45126] volatile lost in optimization

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-07-29 11:25 -------
Possible values for vus are [0, 65535], volatileness does not change that.
Multiplying this as int is always positive (overflow is undefined), so
we can change the test to (vus * vus) != 0.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug c/45126] volatile lost in optimization

[majbrock at dse dot nl]

------- Comment #2 from majbrock at dse dot nl  2010-07-29 12:00 -------
Ok, that is a choice.

But even then vus is read only once, where it appeared twice in the expression.
What about the possible side-effects of reading a volatile?


-- 

majbrock at dse dot nl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug c/45126] volatile lost in optimization

[schwab at linux-m68k dot org]

------- Comment #3 from schwab at linux-m68k dot org  2010-07-29 12:21 -------
That does not change the fact that vus*vus can be assumed to be non-negative.


-- 

schwab at linux-m68k dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug c/45126] volatile lost in optimization

[majbrock at dse dot nl]

------- Comment #4 from majbrock at dse dot nl  2010-07-29 12:41 -------
Andreas said:
>> That does not change the fact that vus*vus can be assumed to be non-negative.

And then this bug was closed again.

So because one part of my report is dismissed you also dismiss the other part?
I already confirmed that you can choose to assume vus*vus to be non-negative.
But still I sustain that vus should read TWICE and it isn't. And thus I
conclude that its volatileness is lost.

Before you close it again can you please explain to me on what grounds vus
should not be read twice?


-- 

majbrock at dse dot nl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug c/45126] volatile lost in optimization

[schwab at linux-m68k dot org]

------- Comment #5 from schwab at linux-m68k dot org  2010-07-29 12:55 -------
Works fine here with gcc 4.4.4.

        movzwl  vus, %eax
        movzwl  vus, %edx


-- 

schwab at linux-m68k dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug c/45126] volatile lost in optimization

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-07-29 13:27 -------
And with all other versions I tried (4.3 and 4.5)


-- 


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

[Bug c/45126] volatile lost in optimization

[majbrock at dse dot nl]

------- Comment #7 from majbrock at dse dot nl  2010-07-29 13:30 -------
Thank you both for looking into it and explaining the behaviour.
I feel stupid and apologize, because I was certain that it was not read twice.
Yet now I can no longer reproduce that, so I guess I was wrong after all.

Thanks again.


-- 


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