> 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 th
Andy Armstrong wrote:
The ARM exception table looks like this:
0x Reset
0x0004 Undefined instruction
0x0008 Software interrupt
0x000C Prefetch Abort
0x0010 Data Abort
0x0014 Reserved
0x0018 IRQ
0x001C FIQ
so only the reset vector is at 0.
Right, so the res
Ross Smith wrote:
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.
That's not quite the story. It's
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 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, t
Zoltán Kócsi wrote:
On Thu, 29 Jan 2009 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.
Um, the linker *must* place the vector table at
On Thu, 29 Jan 2009 08:53:10 +
Andrew Haley 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 guar
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
docume
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
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."
>
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 z
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 have
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 NUL
On Wednesday 28 of January 2009 17:39:39 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 ze
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
>> points to something".
>
> A question then:
>
> H
Zoltán Kócsi 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 *will* reside at addre
> 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
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).
Wh
Zoltán Kócsi wrote:
> On Tue, 27 Jan 2009 07:08:51 -0500
> Robert Dewar 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 p
On Tue, 27 Jan 2009 07:08:51 -0500
Robert Dewar 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 is not
Chris Lattner wrote:
It will be quite a while before whole program optimization is good
enough to prove that my_null_pointer is not referenced by anything
else.
Why not just make it volatile, that way, the compiler cannot assume
anything about the value.
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 -O2.
Chris Lattner writes:
> On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote:
>
>> Chris Lattner writes:
>>
>>> On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
>>>
Laurent GUERBY writes:
> Just curious: is there a "portable" way to read from memory
> address zero in C code
On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote:
Chris Lattner writes:
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY 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 compile
Chris Lattner writes:
> On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
>
>> Laurent GUERBY 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.
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY 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() { re
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.
Florian Weimer wrote:
> > No, C hasn't got a notion of addresses. The situation i
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 addresses. The situation is likely to
get even
Robert Dewar 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 only be in
> fav
Laurent GUERBY 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 quite a while be
Daniel Jacobowitz writes:
> 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 list frequently. Do folks thi
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
* 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 l
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 c
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_cast(0) yields a pointe
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 o
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 m
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_cast(0) yields a pointer with
the value 0 that is not
On Tue, 2009-01-27 at 00:11 -0800, James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, 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 circum
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 list frequently. Do folks think a
corresponding warning would be a w
Robert Dewar 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.
In general I agree; on the other hand, for this particular optimizat
> I don't think that the compiler has a right to remove my test, just
> because it assumes that if I derferenced a pointer then it surely was not
> NULL.
While not related to your testcase directly, you contributed to finding
a couple of relatively severe bugs in GCC, so thank you!
Paolo
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 a
Richard Guenther wrote:
> On Tue, Jan 27, 2009 at 11:35 AM, 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
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 tes
On Tue, Jan 27, 2009 at 11:35 AM, 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 righ
>>> 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
On Tue, Jan 27, 2009 at 11:29 AM, Paolo Bonzini 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 doesn't
>> However, -fno-delete-null-pointer-checks will do.
>
> Not for PTA though ;)
Care to expand?
Paolo
On Tue, Jan 27, 2009 at 9:33 AM, Paolo Bonzini wrote:
> James Dennett wrote:
>> On Mon, Jan 26, 2009 at 11:52 PM, 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) wit
James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, 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
>> i
On Tue, 27 Jan 2009, James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, 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 assum
On Mon, Jan 26, 2009 at 11:52 PM, 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 dereferenced, it can not
52 matches
Mail list logo
