- Package:
- gcc
- Source:
- gcc-defaults
- Description:
- GNU C compiler
- Submitter:
- Ben Golightly
- Date:
- 2022-06-01 00:39:03 UTC
- Severity:
- important
Dear Maintainer,
The following three line C programme generates erroneous output when
compiled with i586-mingw32msvc-gcc -std=c99
#include <assert.h>
float getfloat() { return 12345.6789f; }
int main(void) { assert(12345.6789f == getfloat()); }
When running the generated binary, the assertion is always triggered.
Steps to reproduce:
$ gcc float.c -o float-linux
$ i586-mingw32msvc-gcc float.c -o float
$ i586-mingw32msvc-gcc float.c -o float-c99 -std=c99
$ ./float-linux // works
$ wine ./float // works
$ wine ./float-c99 // outputs "Assertion failed!"
More information:
$ wine --version
wine-1.4.1
Regards,
Ben <golightly.ben@googlemail.com>
reassign 693173 gcc thanks Hi Ben, The following causes the assertion too, using gcc 4.7.2: % gcc -std=c99 float.c -o float-linux-c99 % ./float-linux-c99 float-linux-c99: float.c:3: main: Assertion `12345.6789f == getfloat()' failed. It seems this bug is not specific to gcc-mingw32, but is either really a bug in gcc or expected behaviour in C99 (I don't know which). Incidentally, since you're running unstable, you can use the i686-w64-mingw32 triplet instead of i586-mingw32msvc; the latter will be going away at some point... Regards, Stephen
I have just now reproduced this bug in Debian Buster x86_64 using
i686-w64-mingw32-gcc-win32 with -std=c99 and wine32, using the
original example above.
Source file foo.c:
#include <assert.h>
float getfloat() { return 12345.6789f; }
int main(void) { assert(12345.6789f == getfloat()); }
Steps to reproduce:
$ i686-w64-mingw32-gcc-win32 foo.c -std=c99
$ wine ./a.exe
Assertion failed: 12345.6789f == getfloat(), file foo.c, line 3
It does not happen when I compile with gcc and run it natively on
linux. It also does not happen if I compile with
x86_64-w64-mingw32-gcc foo.c -std=c99.
Above it was suggested that this might be some kind of expected
behavior. I don't know whether that is the case (seems unlikely to me,
but I don't know). Just reporting that it still happens.
I also confirm this behavior on x86_64 when compiled with 'gcc -m32 -std=c99'. It seems to happen with 32-bit C99, but not in any other case.