From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26708 invoked by alias); 13 Dec 2002 16:29:39 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25728 invoked from network); 13 Dec 2002 16:28:21 -0000 Received: from unknown (HELO hugin.diku.dk) (130.225.96.144) by sources.redhat.com with SMTP; 13 Dec 2002 16:28:21 -0000 Received: (qmail 21367 invoked from network); 13 Dec 2002 16:28:19 -0000 Received: from tyr.diku.dk (terra@130.225.96.226) by hugin.diku.dk with QMQP; 13 Dec 2002 16:28:19 -0000 Date: Fri, 13 Dec 2002 08:42:00 -0000 Message-ID: <20021213162819.20923.qmail@tyr.diku.dk> From: Morten Welinder To: gcc@gcc.gnu.org Subject: Re: optimization/7799: [3.2/3.3 regression] Loop bug withoptimization flag -Os in gcc X-SW-Source: 2002-12/txt/msg00732.txt.bz2 Andreas Schwab writes: > "Christian Ehrhardt" 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