Bug#503204: gcc-4.1: erroneously emits warning on C99-required #pragma STDC FENV_ACCESS
Package: gcc-4.1
Version: 4.1.1-21
Severity: important
Hi,
C99 requires that code that tests floating-point state flags (or frobs
other bits of the floating-point environment) calls #pragma STDC
FENV_ACCESS ON:
"If part of an application tests floating-point status flags, sets
floating-point control modes, or runs under non-default mode settings,
but was translated with the state for the FENV_ACCESS pragma off, the
behavior is undefined." (7.6.1.2)
Yet, if you do this in gcc with -Wall turned on, you get a warning
message:
[EMAIL PROTECTED]:/tmp$ cat test.c
#include
#include
int main(void)
{
#pragma STDC FENV_ACCESS ON
if(feclearexcept(FE_ALL_EXCEPT))
printf("feclearexcept failed\n");
else printf("feclearexcept succeeded\n");
return 0;
}
[EMAIL PROTECTED]:/tmp$ gcc -std=gnu99 -Wall test.c -lm
test.c: In function ‘main’:
test.c:6: warning: ignoring #pragma STDC FENV_ACCESS
[EMAIL PROTECTED]:/tmp$ ./a.out
feclearexcept succeeded
[EMAIL PROTECTED]:/tmp$
It's obviously buggy to emit a warning on standards-mandated behaviour!
I know you can turn this warning off with -Wno-unknown-pragmas, but
that's not something you want to be doing in production code.
Regards,
Matthew
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-2-macpro-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages gcc-4.1 depends on:
ii binutils 2.17-3The GNU assembler, linker and bina
ii cpp-4.14.1.1-21 The GNU C preprocessor
ii gcc-4.1-base 4.1.1-21 The GNU Compiler Collection (base
ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries
ii libgcc11:4.1.1-21GCC support library
ii libssp04.1.1-21 GCC stack smashing protection libr
Versions of packages gcc-4.1 recommends:
ii libc6-dev 2.3.6.ds1-13etch7 GNU C Library: Development Librari
pn libmudflap0-dev(no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503202: libc6-dev: math_errhandling isn't defined anywhere
Aurelien Jarno wrote: reassign 503202 gcc-4.3 thanks Matthew Vernon a écrit : Package: libc6-dev Version: 2.3.6.ds1-13etch7 Severity: important Hi, math.h has the following in it: /* Bitmasks for the math_errhandling macro. */ # define MATH_ERRNO 1 /* errno set by math functions. */ # define MATH_ERREXCEPT 2 /* Exceptions raised by math functions. */ but no-where is math_errhandling actually defined! This breaks code wanting to check how domain errors in floating-point code are handled (amongst other things). Section 7.12.9 of C99 discusses MATH_ERRNO, MATH_ERREXCEPT, and math_errhandling. SuSv3 also requires math_errhandling to be present: http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html This is actually a compiler problem. See the footnotes on http://gcc.gnu.org/c99status.html . Reassigning the bug accordingly. gcc on Mac OS X gets this right (the libc there defines math_errhandling), which is why I suspected glibc to be the problem. I infer from that, that glibc could fix this without needing changes to gcc? Matthew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503204: gcc-4.1: erroneously emits warning on C99-required #pragma STDC FENV_ACCESS
Hi, Bastian Blank wrote: It's obviously buggy to emit a warning on standards-mandated behaviour! I know you can turn this warning off with -Wno-unknown-pragmas, but that's not something you want to be doing in production code. Please show the part of the standard. A compiler may produce warnings without reason. Was the section I quoted in my original bug report not sufficient? Paragraph 7.6.1.2 of C99 says [again]: "If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma "off", *the behaviour is undefined*." [emphasis mine] These are things that many correct programs will want to do. For example, SuSv3 has this to say about pow(): "An application wishing to check for error situations should set errno to zero and call feclearexcept(FE_ALL_EXCEPT) before calling these functions. On return, if errno is non-zero or fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW) is non-zero, an error has occurred."[1] Gcc as-is, will encourage (quite strongly, since may people will compile with -Wall, +/- -Werror) users to write code that calls feclearexcept() and suchlike without using #pragma STDC FENV_ACCESS ON first. This is undefined behaviour, according to C99! It seems clear to me that this is a bug in gcc. Regards, Matthew [1] http://www.opengroup.org/onlinepubs/009695399/functions/pow.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384052: gcc-3.3: gcc should (optionally) warn about use of reserved identifiers
Package: gcc-3.3 Version: 1:3.3.5-13 Severity: normal Hi, There are a fair range of reserved identifiers in C; it is a not uncommon programming mistake for a coder to use one. It would be good if gcc told you when you did this; it would need to avoid doing so for system headers, but that's a general problem that gcc has already solved. http://web.archive.org/web/20050321091104/oakroadsystems.com/tech/c-predef.htm has a list of them, as does the C standard, but not collected together quite so conveniently. I suggest -Wreserved-identifiers as the option name :) Thanks, Matthew -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.2.26 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages gcc-3.3 depends on: ii binutils 2.15-6 The GNU assembler, linker and bina ii cpp-3.3 1:3.3.5-13 The GNU C preprocessor ii gcc-3.3-base 1:3.3.5-13 The GNU Compiler Collection (base ii libc6 2.3.2.ds1-22sarge3 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13 GCC support library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
