From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31060 invoked by alias); 20 Feb 2015 09:30:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 30948 invoked by uid 89); 20 Feb 2015 09:30:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 Feb 2015 09:30:24 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1K9UIR2006912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 20 Feb 2015 04:30:18 -0500 Received: from zebedee.pink (ovpn-113-74.phx2.redhat.com [10.3.113.74]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1K9UD2c011865; Fri, 20 Feb 2015 04:30:14 -0500 Message-ID: <54E6FEA4.8000104@redhat.com> Date: Fri, 20 Feb 2015 09:30:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jeff Prothero , gcc@gcc.gnu.org Subject: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00184.txt.bz2 On 18/02/15 19:21, Jeff Prothero wrote: > BTW, I'd also be curious to know what is regarded as engineering > best practice for writing a value to address zero when this is > architecturally required by the hardware platform at hand. > Obviously one can do various things to obscure the process > sufficiently that the current gcc implementation won't detect it and > complain, but as gcc gets smarter about optimization those are at > risk of failing in a future release. It would be nice to have a > guaranteed-to-work future-proof idiom for doing this. Do we have > one, short of retreating to assembly code? I doubt that such a thing is ever going to be safe. The idea that a null pointer points to nothing is so hard-baked into the design of C that you can't get away from it. Also, almost every C programmer and especially library writer "knows" that a null pointer points to nothing. The only way to initialize an interrupt vector table at address zero is to go outside the language. While it may be possible to use some proprietary GCC options to get around this, it's never going to be a good idea because some GCC author (or indeed library author) may make the "mistake" of assuming that null pointer point to nothing. Using C to initialize anything at address zero is so dangerous that we shouldn't tell people that they can use such-and-such a GCC option to support it; we should warn them never to do it, and provide as many warnings as we can. IMO, engineering best practice is to use assembly code. Andrew.