Re: Serious code generation/optimisation bug (I think)

2009-01-30 Thread Andy Armstrong
On 30 Jan 2009, at 05:11, Ross Smith wrote: Zoltán Kócsi wrote: On Thu, 29 Jan 2009 08:53:10 + Andrew Haley a...@redhat.com wrote: We're talking about gcc on ARM. gcc on ARM uses 0 for the null pointer constant, therefore a linker cannot place an object at address zero. All the rest is

Re: Serious code generation/optimisation bug (I think)

2009-01-30 Thread Zoltán Kócsi
This sounds like a genuine bug in gcc, then. As far as I can see, Andrew is right -- if the ARM hardware requires a legitimate object to be placed at address zero, then a standard C compiler has to use some other value for the null pointer. I think changing that would cause more trouble than

Re: Serious code generation/optimisation bug (I think)

2009-01-29 Thread Andrew Haley
Erik Trulsson wrote: On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote: 6.3.2.3 Pointers 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. This

Re: Serious code generation/optimisation bug (I think)

2009-01-29 Thread Vincent Lefevre
On 2009-01-28 16:34:29 -0500, Robert Dewar wrote: If 0 is a valid address, then it is improper for the compiler to use 0 to represent the null pointer. I disagree. You can represent addresses with some bit set. If in practice (at the processor level), this bit is ignored, then this can really

Re: Serious code generation/optimisation bug (I think)

2009-01-29 Thread Vincent Lefevre
On 2009-01-29 08:53:10 +, Andrew Haley wrote: We're talking about gcc on ARM. gcc on ARM uses 0 for the null pointer constant, therefore a linker cannot place an object at address zero. All the rest is irrelevant. How about using volatile, as suggested by Robert Dewar (if the gcc

Re: Serious code generation/optimisation bug (I think)

2009-01-29 Thread Zoltán Kócsi
On Thu, 29 Jan 2009 08:53:10 + Andrew Haley a...@redhat.com wrote: Erik Trulsson wrote: On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote: 6.3.2.3 Pointers If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is

Re: Serious code generation/optimisation bug (I think)

2009-01-29 Thread Ross Smith
Zoltán Kócsi wrote: On Thu, 29 Jan 2009 08:53:10 + Andrew Haley a...@redhat.com wrote: We're talking about gcc on ARM. gcc on ARM uses 0 for the null pointer constant, therefore a linker cannot place an object at address zero. All the rest is irrelevant. Um, the linker *must* place the

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Zoltán Kócsi
On Tue, 27 Jan 2009 07:08:51 -0500 Robert Dewar de...@adacore.com wrote: James Dennett wrote: I don't know how much work it would be to disable this optimization in gcc. To me, it is always troublesome to talk of disable this optimization in a context like this. The program in question

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Andrew Haley
Zoltán Kócsi wrote: On Tue, 27 Jan 2009 07:08:51 -0500 Robert Dewar de...@adacore.com wrote: James Dennett wrote: I don't know how much work it would be to disable this optimization in gcc. To me, it is always troublesome to talk of disable this optimization in a context like this. The

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Robert Dewar
Zoltán Kócsi wrote: I don't mean to complain, but I happen to work with embedded systems. I program them in C, or at least in a language that uses the syntactic elements of C. Yes, and that is an important distinction. If you program in C, you should program in C (and know the language).

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Zoltán Kócsi
No, this is since C90; nothing has changed in this area. NULL doesn't mean address 0, it means nothing. The C statement if (ptr) doesn't mean if ptr does not point to address zero, it means if ptr points to something. A question then: How can I make a pointer to point to the integer

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Andreas Schwab
Zoltán Kócsi zol...@bendor.com.au writes: How can I make a pointer to point to the integer located at address 0x0? It is a perfectly valid object, it exists, therefore I should be able to get its address? In fact, if I have a CPU that starts its data RAM at 0, then the first data object

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Robert Dewar
Zoltán Kócsi wrote: You say: You can't dereference a NULL pointer I say: You shouldn't dereference a NULL pointer Yes, but the standard says can't in effect, and gives no idea of what it might mean to dereference a null pointer. I shouldn't but I most certainly can. I can generate a NULL

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Robert Dewar
Paweł Sikora wrote: do you say that we can't write a valid/defined program in C for e.g. arm architercture? on some arms, the object (vector interrupt table) starts at adress 0x0. If 0 is a valid address, then it is improper for the compiler to use 0 to represent the null pointer. You may

Re: Serious code generation/optimisation bug (I think)

2009-01-28 Thread Erik Trulsson
On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote: Zoltán Kócsi wrote: No, this is since C90; nothing has changed in this area. NULL doesn't mean address 0, it means nothing. The C statement if (ptr) doesn't mean if ptr does not point to address zero, it means if ptr

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread James Dennett
On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote: I was debugging a function and by inserting the debug statement crashed the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled from sources) with -O2 under some circumstances assumes that if a pointer is

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Kaveh R. GHAZI
On Tue, 27 Jan 2009, James Dennett wrote: On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote: I was debugging a function and by inserting the debug statement crashed the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled from sources) with -O2 under some

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Paolo Bonzini
James Dennett wrote: On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote: I was debugging a function and by inserting the debug statement crashed the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled from sources) with -O2 under some circumstances assumes that if

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Richard Guenther
On Tue, Jan 27, 2009 at 9:33 AM, Paolo Bonzini bonz...@gnu.org wrote: James Dennett wrote: On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote: I was debugging a function and by inserting the debug statement crashed the system. Some investigation revealed that gcc 4.3.2 arm-eabi

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Paolo Bonzini
However, -fno-delete-null-pointer-checks will do. Not for PTA though ;) Care to expand? Paolo

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Paolo Bonzini
Not for PTA though ;) Care to expand? PTA tracks points-to-NULL as pointing to nothing. This probably should be conditional on -fdelete-null-pointer-checks. Otherwise *NULL and *anything won't alias. Yes, you're right. I'll see if I can construct a testcase and a patch. BTW, I was

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Richard Guenther
On Tue, Jan 27, 2009 at 11:35 AM, Paolo Bonzini bonz...@gnu.org wrote: Not for PTA though ;) Care to expand? PTA tracks points-to-NULL as pointing to nothing. This probably should be conditional on -fdelete-null-pointer-checks. Otherwise *NULL and *anything won't alias. Yes, you're right.

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Andrew Haley
Paolo Bonzini wrote: Not for PTA though ;) Care to expand? PTA tracks points-to-NULL as pointing to nothing. This probably should be conditional on -fdelete-null-pointer-checks. Otherwise *NULL and *anything won't alias. Yes, you're right. I'll see if I can construct a testcase and a

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Richard Guenther
On Tue, Jan 27, 2009 at 11:29 AM, Paolo Bonzini bonz...@gnu.org wrote: However, -fno-delete-null-pointer-checks will do. Not for PTA though ;) Care to expand? PTA tracks points-to-NULL separately (as pointing to nothing). See /* x = integer is all glommed to a single variable, which

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Paolo Bonzini
Richard Guenther wrote: On Tue, Jan 27, 2009 at 11:35 AM, Paolo Bonzini bonz...@gnu.org wrote: Not for PTA though ;) Care to expand? PTA tracks points-to-NULL as pointing to nothing. This probably should be conditional on -fdelete-null-pointer-checks. Otherwise *NULL and *anything won't

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Robert Dewar
James Dennett wrote: I don't know how much work it would be to disable this optimization in gcc. To me, it is always troublesome to talk of disable this optimization in a context like this. The program in question is not C, and its semantics cannot be determined from the C standard. If the

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Laurent GUERBY
On Tue, 2009-01-27 at 00:11 -0800, James Dennett wrote: On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote: I was debugging a function and by inserting the debug statement crashed the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled from sources) with -O2

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Sebastian Redl
Laurent GUERBY wrote: Just curious: is there a portable way to read from memory address zero in C code? portable here means likely to work on most compilers without exotic compile flags in 2009. For C++, in *theory*, a reinterpret_castvoid*(0) yields a pointer with the value 0 that is not

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Vincent Lefevre
On 2009-01-27 07:08:51 -0500, Robert Dewar wrote: [...] Interestingly, my viewpoint on this from the compiler domain might seem to be quite inconsistent. I think it is generally a bad idea for compilers to aggressively optimize based on assumptions that programs are free of these kinds of

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Robert Dewar
Vincent Lefevre wrote: On 2009-01-27 07:08:51 -0500, Robert Dewar wrote: [...] Interestingly, my viewpoint on this from the compiler domain might seem to be quite inconsistent. I think it is generally a bad idea for compilers to aggressively optimize based on assumptions that programs are free

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Andrew Haley
Sebastian Redl wrote: Laurent GUERBY wrote: Just curious: is there a portable way to read from memory address zero in C code? portable here means likely to work on most compilers without exotic compile flags in 2009. For C++, in *theory*, a reinterpret_castvoid*(0) yields a pointer with

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Joe Buck
On Tue, Jan 27, 2009 at 05:42:04AM -0800, Daniel Jacobowitz wrote: On Tue, Jan 27, 2009 at 06:52:18PM +1100, zol...@bendor.com.au wrote: // Debug( tst-value ); if ( ! tst ) { ptr-next = (void *) 0; break; } This optimization comes up on the

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Florian Weimer
* Laurent GUERBY: Just curious: is there a portable way to read from memory address zero in C code? portable here means likely to work on most compilers without exotic compile flags in 2009. No, C hasn't got a notion of addresses. The situation is likely to get even more extreme, not less

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Laurent GUERBY
On Tue, 2009-01-27 at 21:37 +0100, Florian Weimer wrote: * Laurent GUERBY: Just curious: is there a portable way to read from memory address zero in C code? portable here means likely to work on most compilers without exotic compile flags in 2009. No, C hasn't got a notion of

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Ian Lance Taylor
Laurent GUERBY laur...@guerby.net writes: Just curious: is there a portable way to read from memory address zero in C code? portable here means likely to work on most compilers without exotic compile flags in 2009. char *my_null_pointer; char fn() { return *my_null_pointer; } It will be

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Ian Lance Taylor
Robert Dewar de...@adacore.com writes: Interestingly, my viewpoint on this from the compiler domain might seem to be quite inconsistent. I think it is generally a bad idea for compilers to aggressively optimize based on assumptions that programs are free of these kinds of mistakes. I would

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Chris Lattner
On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote: Chris Lattner clatt...@apple.com writes: On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote: Laurent GUERBY laur...@guerby.net writes: Just curious: is there a portable way to read from memory address zero in C code? portable here

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Ian Lance Taylor
Chris Lattner clatt...@apple.com writes: On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote: Chris Lattner clatt...@apple.com writes: On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote: Laurent GUERBY laur...@guerby.net writes: Just curious: is there a portable way to read from memory

Re: Serious code generation/optimisation bug (I think)

2009-01-27 Thread Chris Lattner
On Jan 27, 2009, at 10:47 PM, Ian Lance Taylor wrote: Is LLVM smart enough to optimize that away, even when using shared libraries? Yes absolutely. Just build with -fvisibility-hidden or use an export map to say that my_null_pointer is not exported. If it is static, it will also do it at