[Bug c++/50364] New: Volatile miscompilation

[abramobagnara at tin dot it]

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

 Bug #: 50364
   Summary: Volatile miscompilation
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: abramobagn...@tin.it


$ cat p.cc
volatile int a, b;
void f() {
  b = 1 + (a = 0);
}
$ g++ -O2 -S p.cc
$ cat p.s
.file   p.cc
.text
.p2align 4,,15
.globl  _Z1fv
.type   _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
movl$0, a
movl$1, b
ret
.cfi_endproc
...

As the typescript above shows, the conversion between lvalue (a = 0) and
relative rvalue does not generate a volatile read memory access unlike what I
think that standard mandates.

[Bug c/38960] New: Wrong floating point reorder

[abramobagnara at tin dot it]

The program below show that gcc reorder floating point instructions in such a
way to make inexact checking fruitless.

Reading generated assembler I see two problems:

1) the cast to float in x assignment is executed *after* fetestexcept and not
before as it's written (and needed to get the correct result). This infringes
C99 standard sequence point rules.

2) the second division is not recomputed (because CSE), then inexact flag is
not changed after feclearexcept

I guess that the latter is due to missing #pragma STDC FENV_ACCESS
implementation, but the former undermine the whole fetestexcept usability.

$ cat bug.c
#include fenv.h
#include stdio.h

double vf = 0x0fff;
double vg = 0x1000;

/* vf/vg is exactly representable as IEC559 64 bit floating point,
   while it's not representable exactly as a 32 bit one */

int main() {
  double a = vf;
  double b = vg;

  feclearexcept(FE_INEXACT);
  float x;
  x = a / b;
  printf(%i %.1000g\n, fetestexcept(FE_INEXACT), x);

  feclearexcept(FE_INEXACT);
  double y;
  y = a / b;
  printf(%i %.1000g\n, fetestexcept(FE_INEXACT), y);
  return 0;
}
$ gcc -O2 bug.c -lm
$ ./a.out
0 1
0 0.62747097015380859375
$


-- 
   Summary: Wrong floating point reorder
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: abramobagnara at tin dot it
GCC target triplet:  i486-linux-gnu


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

[Bug middle-end/38960] Wrong floating point reorder

[abramobagnara at tin dot it]

--- Comment #1 from abramobagnara at tin dot it  2009-01-24 15:14 ---
Created an attachment (id=17176)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17176action=view)
Assembler generated by gcc -S -O2 bug.c


-- 


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

[Bug target/37581] IEEE inexact-flag not working on the Alpha

[abramobagnara at tin dot it]

--- Comment #6 from abramobagnara at tin dot it  2009-01-24 15:41 ---
(In reply to comment #5)

 Because it looks to me that this is libc problem with fetestexcept. As far as
 the compiler is concerned, GCC correctly decorates trapping instructions with
 /sui and puts trap barrier to expected place:
 
 ...
 jsr $26,($27),__nldbl_printf!lituse_jsr!5
 ldah $29,0($26) !gpdisp!6
 divs/sui $f3,$f2,$f0
 trapb
 ...

I've reported a bug according to the valuable info you provide.

http://sourceware.org/bugzilla/show_bug.cgi?id=9783


-- 


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

[Bug target/37581] IEEE inexact-flag not working on the Alpha

[abramobagnara at tin dot it]

--- Comment #3 from abramobagnara at tin dot it  2009-01-24 05:43 ---
The test case you have used it's different from the original that showed the
bug.

Nevertheless it's useful to understand the possible nature of the bug.

It seems that if feenableexcept(FE_INEXACT) is not called
fetestexcept(FE_INEXACT) doesn't work as expected (and as C99 standard
provides).

Please note that according to documentation GNU extension
feenableexcept/fedisablexcept does not enable/disable inexact detection, but
does enable/disable inexact *trapping* via SIGFPE signal.

Here below there is a new test case that shows the wrong behaviour.

$ cat sf2.c 
#define _GNU_SOURCE
#include fenv.h
#include signal.h
#include stdio.h

static void foo (int sig)
{
  printf(inexact\n);
}


float __attribute__((noinline)) test (float x) {
printf(%f / %f\n, 2.0f, x);
return 2.0f / x;
}

void t()
{
  volatile float x;
  feclearexcept (FE_ALL_EXCEPT);
  x = test (3.0f);
  printf(fetestexcept(FE_INEXACT) = %d\n, fetestexcept(FE_INEXACT));
  feclearexcept (FE_ALL_EXCEPT);
  x = test (2.0f);
  printf(fetestexcept(FE_INEXACT) = %d\n, fetestexcept(FE_INEXACT));
}

int main() {
  printf(\nWith FE_INEXACT SIGFPE disabled\n);
  t();

  printf(\nWith FE_INEXACT SIGFPE enabled\n);
  signal (SIGFPE, foo);
  feenableexcept (FE_INEXACT);
  t();
}
$ gcc -O2 -lm -mieee-with-inexact sf2.c
$ ./a.out

With FE_INEXACT SIGFPE disabled
2.00 / 3.00
fetestexcept(FE_INEXACT) = 0
2.00 / 2.00
fetestexcept(FE_INEXACT) = 0

With FE_INEXACT SIGFPE enabled
2.00 / 3.00
inexact
fetestexcept(FE_INEXACT) = 2097152
2.00 / 2.00
fetestexcept(FE_INEXACT) = 0
$


-- 

abramobagnara at tin dot it changed:

   What|Removed |Added

 CC||abramobagnara at tin dot it


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