Re: Not a GCC bug (was Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please])
On Mar 30, 2005, at 20:12, Nick Piggin wrote: Why should this be in the kernel makefiles? If my_struct is NULL, then the kernel will never reach the if statement. Well, I think there is probably some arch code that uses 16-bit that might use a null pointer, or at least a struct that starts at the 0 address, which would have problems. I think it would be better to avoid that issue just in case, especially since this optimization does not save anything in the case of properly written code. A warning might be nice though. If we could turn off the optimization and add a warning, I would support that. Even if we could only add the warning, then at least people would know. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a GCC bug (was Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please])
Kyle Moffett wrote: On Mar 30, 2005, at 18:38, Jakub Jelinek wrote: This testcase violates ISO C99 6.3.2.3: If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. Except that the result of dereferencing a null pointer is implementation defined according to the C99 standard. My implementation allows me to mmap stuff at NULL, and therefore its compiler should be able to handle that case. I would have no problem with either the standard or implementation if it either properly handled the case or didn't allow it in the first place. On another note, I've discovered the flag "-fno-delete-null-pointer-checks", which should probably be included in the kernel makefiles to disable that optimization for the kernel. (Ok, yes, I apologize, this isn't really a GCC bug, the behavior is documented, although it can be quite confusing. I suspect it may bite some platform-specific code someday. It also muddies the waters somewhat with respect to the original note (and the effects on the generated code): int x = my_struct->the_x; if (!my_struct) return; Why should this be in the kernel makefiles? If my_struct is NULL, then the kernel will never reach the if statement. A warning might be nice though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a GCC bug (was Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please])
On Mar 30, 2005, at 18:38, Jakub Jelinek wrote: This testcase violates ISO C99 6.3.2.3: If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. Except that the result of dereferencing a null pointer is implementation defined according to the C99 standard. My implementation allows me to mmap stuff at NULL, and therefore its compiler should be able to handle that case. I would have no problem with either the standard or implementation if it either properly handled the case or didn't allow it in the first place. On another note, I've discovered the flag "-fno-delete-null-pointer-checks", which should probably be included in the kernel makefiles to disable that optimization for the kernel. (Ok, yes, I apologize, this isn't really a GCC bug, the behavior is documented, although it can be quite confusing. I suspect it may bite some platform-specific code someday. It also muddies the waters somewhat with respect to the original note (and the effects on the generated code): int x = my_struct->the_x; if (!my_struct) return; Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please]
Kyle Moffett wrote: Dereferencing null pointers is relied upon by a number of various emulators and such, and is "platform-defined" in the standard, so since Linux allows mmap at NULL, GCC shouldn't optimize that case any differently. From the GCC manual: "The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null. In some environments, this assumption is not true, and programs can safely dereference null pointers. Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior. " -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Big GCC bug!!! [Was: Re: Do not misuse Coverity please]
On Mar 30, 2005, at 14:14, Paulo Marques wrote:
Just a minor nitpick, though: wouldn't it be possible for an
application to catch the SIGSEGV and let the code proceed,
making invalid the assumption made by gcc?
Uhh, it's even worse than that. Have a look at the following code:
#include
#include
#include
#include
#include
#include
struct test {
int code;
};
int test_check_first(struct test *a) {
int ret;
if (!a) return -1;
ret = a->code;
return ret;
}
int test_check_last(struct test *a) {
int ret;
ret = a->code;
if (!a) return -1;
return ret;
}
int main() {
int i;
struct test *nullmem = mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0);
if (nullmem == MAP_FAILED) {
fprintf(stderr,"mmap: %s\n",strerror(errno));
exit(1);
}
for (i = 0; i < 2; i++) {
nullmem[i].code = i;
printf("nullmem[%d].code = %d\n",i,i);
printf("test_check_first([%d]) = %d\n",i,
test_check_first([i]));
printf("test_check_last([%d]) = %d\n",i,
test_check_last([i]));
}
munmap(nullmem,4096);
exit(0);
}
Without optimization:
king:~# gcc -o mmapnull mmapnull.c
king:~# ./mmapnull
nullmem[0].code = 0
test_check_first([0]) = -1
test_check_last([0]) = -1
nullmem[1].code = 1
test_check_first([1]) = 1
test_check_last([1]) = 1
With optimization:
king:~# gcc -O2 -o mmapnull mmapnull.c
king:~# ./mmapnull
nullmem[0].code = 0
test_check_first([0]) = -1
test_check_last([0]) = 0
BUG ==> ^^^
nullmem[1].code = 1
test_check_first([1]) = 1
test_check_last([1]) = 1
This is on multiple platforms, including PPC Linux, X86 Linux, and
PPC Mac OS X. All exhibit the exact same behavior and output. I
think I'll probably go report a GCC bug now :-D
Dereferencing null pointers is relied upon by a number of various
emulators and such, and is "platform-defined" in the standard, so
since Linux allows mmap at NULL, GCC shouldn't optimize that case
any differently.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r
!y?(-)
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Big GCC bug!!! [Was: Re: Do not misuse Coverity please]
On Mar 30, 2005, at 14:14, Paulo Marques wrote:
Just a minor nitpick, though: wouldn't it be possible for an
application to catch the SIGSEGV and let the code proceed,
making invalid the assumption made by gcc?
Uhh, it's even worse than that. Have a look at the following code:
#include stdio.h
#include stdlib.h
#include string.h
#include errno.h
#include sys/types.h
#include sys/mman.h
struct test {
int code;
};
int test_check_first(struct test *a) {
int ret;
if (!a) return -1;
ret = a-code;
return ret;
}
int test_check_last(struct test *a) {
int ret;
ret = a-code;
if (!a) return -1;
return ret;
}
int main() {
int i;
struct test *nullmem = mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_ANON|MAP_FIXED|MAP_PRIVATE, -1, 0);
if (nullmem == MAP_FAILED) {
fprintf(stderr,mmap: %s\n,strerror(errno));
exit(1);
}
for (i = 0; i 2; i++) {
nullmem[i].code = i;
printf(nullmem[%d].code = %d\n,i,i);
printf(test_check_first(nullmem[%d]) = %d\n,i,
test_check_first(nullmem[i]));
printf(test_check_last(nullmem[%d]) = %d\n,i,
test_check_last(nullmem[i]));
}
munmap(nullmem,4096);
exit(0);
}
Without optimization:
king:~# gcc -o mmapnull mmapnull.c
king:~# ./mmapnull
nullmem[0].code = 0
test_check_first(nullmem[0]) = -1
test_check_last(nullmem[0]) = -1
nullmem[1].code = 1
test_check_first(nullmem[1]) = 1
test_check_last(nullmem[1]) = 1
With optimization:
king:~# gcc -O2 -o mmapnull mmapnull.c
king:~# ./mmapnull
nullmem[0].code = 0
test_check_first(nullmem[0]) = -1
test_check_last(nullmem[0]) = 0
BUG == ^^^
nullmem[1].code = 1
test_check_first(nullmem[1]) = 1
test_check_last(nullmem[1]) = 1
This is on multiple platforms, including PPC Linux, X86 Linux, and
PPC Mac OS X. All exhibit the exact same behavior and output. I
think I'll probably go report a GCC bug now :-D
Dereferencing null pointers is relied upon by a number of various
emulators and such, and is platform-defined in the standard, so
since Linux allows mmap at NULL, GCC shouldn't optimize that case
any differently.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r
!y?(-)
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please]
Kyle Moffett wrote: Dereferencing null pointers is relied upon by a number of various emulators and such, and is platform-defined in the standard, so since Linux allows mmap at NULL, GCC shouldn't optimize that case any differently. From the GCC manual: The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null. In some environments, this assumption is not true, and programs can safely dereference null pointers. Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a GCC bug (was Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please])
On Mar 30, 2005, at 18:38, Jakub Jelinek wrote: This testcase violates ISO C99 6.3.2.3: If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. Except that the result of dereferencing a null pointer is implementation defined according to the C99 standard. My implementation allows me to mmap stuff at NULL, and therefore its compiler should be able to handle that case. I would have no problem with either the standard or implementation if it either properly handled the case or didn't allow it in the first place. On another note, I've discovered the flag -fno-delete-null-pointer-checks, which should probably be included in the kernel makefiles to disable that optimization for the kernel. (Ok, yes, I apologize, this isn't really a GCC bug, the behavior is documented, although it can be quite confusing. I suspect it may bite some platform-specific code someday. It also muddies the waters somewhat with respect to the original note (and the effects on the generated code): int x = my_struct-the_x; if (!my_struct) return; Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a GCC bug (was Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please])
Kyle Moffett wrote: On Mar 30, 2005, at 18:38, Jakub Jelinek wrote: This testcase violates ISO C99 6.3.2.3: If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. Except that the result of dereferencing a null pointer is implementation defined according to the C99 standard. My implementation allows me to mmap stuff at NULL, and therefore its compiler should be able to handle that case. I would have no problem with either the standard or implementation if it either properly handled the case or didn't allow it in the first place. On another note, I've discovered the flag -fno-delete-null-pointer-checks, which should probably be included in the kernel makefiles to disable that optimization for the kernel. (Ok, yes, I apologize, this isn't really a GCC bug, the behavior is documented, although it can be quite confusing. I suspect it may bite some platform-specific code someday. It also muddies the waters somewhat with respect to the original note (and the effects on the generated code): int x = my_struct-the_x; if (!my_struct) return; Why should this be in the kernel makefiles? If my_struct is NULL, then the kernel will never reach the if statement. A warning might be nice though. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Not a GCC bug (was Re: Big GCC bug!!! [Was: Re: Do not misuse Coverity please])
On Mar 30, 2005, at 20:12, Nick Piggin wrote: Why should this be in the kernel makefiles? If my_struct is NULL, then the kernel will never reach the if statement. Well, I think there is probably some arch code that uses 16-bit that might use a null pointer, or at least a struct that starts at the 0 address, which would have problems. I think it would be better to avoid that issue just in case, especially since this optimization does not save anything in the case of properly written code. A warning might be nice though. If we could turn off the optimization and add a warning, I would support that. Even if we could only add the warning, then at least people would know. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r !y?(-) --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
