* Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc
@ 2002-12-13 8:42 Morten Welinder
2002-12-13 9:02 ` Andrew Pinski
2002-12-13 9:09 ` Andrew Haley
0 siblings, 2 replies; 6+ messages in thread
From: Morten Welinder @ 2002-12-13 8:42 UTC (permalink / raw)
To: gcc
Andreas Schwab writes:
> "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> writes:
>|> By calling fill ((int*) 0xffffffc, q);
> Undefined behaviour.
True, but its_somewhere_in_my_libc() is not. Implementation defined,
yes, but not undefined.
A quick scan of mmap's manual page suggests that it is not completely
ruled out that you would get 0xfffffffc for an area that includes
space for ten ints thereafter. (Perhaps you would have to ask for
memory starting a bit earlier, namely at the start of a page.)
With PROT_NONE this would merely be absurd behaviour, IMHO, as opposed
to certifiably insane.
Morten
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc
2002-12-13 8:42 optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc Morten Welinder
@ 2002-12-13 9:02 ` Andrew Pinski
2002-12-13 9:09 ` Andrew Haley
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Pinski @ 2002-12-13 9:02 UTC (permalink / raw)
To: Morten Welinder; +Cc: Andrew Pinski, gcc
In fact the old test for gcc.c-torture/execute/loop-2e.c was using nmap
before I said something because I getting a PASS on i686-unknown-openbsd
when it was giving the same assembly as i686-pc-gnu-linux.
Thanks,
Andrew Pinski
On Friday, Dec 13, 2002, at 08:28 US/Pacific, Morten Welinder wrote:
>
> Andreas Schwab writes:
>
>> "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> writes:
>> |> By calling fill ((int*) 0xffffffc, q);
>
>> Undefined behaviour.
>
> True, but its_somewhere_in_my_libc() is not. Implementation defined,
> yes, but not undefined.
>
> A quick scan of mmap's manual page suggests that it is not completely
> ruled out that you would get 0xfffffffc for an area that includes
> space for ten ints thereafter. (Perhaps you would have to ask for
> memory starting a bit earlier, namely at the start of a page.)
>
> With PROT_NONE this would merely be absurd behaviour, IMHO, as opposed
> to certifiably insane.
>
> Morten
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc
2002-12-13 8:42 optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc Morten Welinder
2002-12-13 9:02 ` Andrew Pinski
@ 2002-12-13 9:09 ` Andrew Haley
2002-12-13 10:38 ` Paul Koning
1 sibling, 1 reply; 6+ messages in thread
From: Andrew Haley @ 2002-12-13 9:09 UTC (permalink / raw)
To: Morten Welinder; +Cc: gcc
Morten Welinder writes:
>
> Andreas Schwab writes:
>
> > "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> writes:
> >|> By calling fill ((int*) 0xffffffc, q);
>
> > Undefined behaviour.
>
> True, but its_somewhere_in_my_libc() is not. Implementation defined,
> yes, but not undefined.
>
> A quick scan of mmap's manual page suggests that it is not completely
> ruled out that you would get 0xfffffffc for an area that includes
> space for ten ints thereafter.
It is: a null pointer is guranteed to compare unequal to a pointer to
any object.
See C90, Section 6.2.2.3.
Andrew.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc
2002-12-13 9:09 ` Andrew Haley
@ 2002-12-13 10:38 ` Paul Koning
0 siblings, 0 replies; 6+ messages in thread
From: Paul Koning @ 2002-12-13 10:38 UTC (permalink / raw)
To: aph; +Cc: terra, gcc
>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
Andrew> Morten Welinder writes:
>> Andreas Schwab writes:
>>
>> > "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> writes:
>> >|> By calling fill ((int*) 0xffffffc, q);
>>
>> > Undefined behaviour.
>>
>> True, but its_somewhere_in_my_libc() is not. Implementation
>> defined, yes, but not undefined.
>>
>> A quick scan of mmap's manual page suggests that it is not
>> completely ruled out that you would get 0xfffffffc for an area
>> that includes space for ten ints thereafter.
Andrew> It is: a null pointer is guranteed to compare unequal to a
Andrew> pointer to any object.
Morten's comment is still valid for a platform where the encoding of a
null pointer is not the all-zero bitpattern. (Is there such a
platform? I've never seen one, but I know they are legal...)
paul
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc
2002-12-13 13:36 Morten Welinder
@ 2002-12-16 12:17 ` Richard Henderson
0 siblings, 0 replies; 6+ messages in thread
From: Richard Henderson @ 2002-12-16 12:17 UTC (permalink / raw)
To: Morten Welinder; +Cc: gcc
On Fri, Dec 13, 2002 at 09:09:15PM -0000, Morten Welinder wrote:
> 1. sizeof(int) == sizeof(char) == 1. int is four bytes wide.
Eh? 1 == 4?
> 2. NULL represented as address 0.
> 3. OS support to read/write unaligned.
> 4. OS support to read/write wrapped, e.g., read four bytes at 0xffffffff.
You're trying too hard. We do not care about theory so much as
practice. Are you seriously suggesting that there exists an OS
that is this broken?
The signed/unsigned wrap at 0x80000000 as exemplified by loop-3.c
is a real bug, distilled from a real test case on a real os. The
situation you are describing is absurd.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc
@ 2002-12-13 13:36 Morten Welinder
2002-12-16 12:17 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: Morten Welinder @ 2002-12-13 13:36 UTC (permalink / raw)
To: gcc
I'll give it another try... Recall that all this is for i86.
1. sizeof(int) == sizeof(char) == 1. int is four bytes wide.
2. NULL represented as address 0.
3. OS support to read/write unaligned.
4. OS support to read/write wrapped, e.g., read four bytes at 0xffffffff.
(1 is not unheard of, 2 is normal, 3 is normal on i86, 4 is bizarre.)
malloc (10) can then return address 0xffffffff as the address of
10 ints.
I think assumption 1 makes impossible to do valid pointer gymnastics
to get NULL from 0xffffffff. Everything you do is going to be in
steps of four on the address level.
Morten
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-12-16 20:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-13 8:42 optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc Morten Welinder
2002-12-13 9:02 ` Andrew Pinski
2002-12-13 9:09 ` Andrew Haley
2002-12-13 10:38 ` Paul Koning
2002-12-13 13:36 Morten Welinder
2002-12-16 12:17 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).