From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12928 invoked by alias); 18 Feb 2015 19:24:45 -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 12918 invoked by uid 89); 18 Feb 2015 19:24:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: na01-bn1-obe.outbound.protection.outlook.com Received: from mail-bn1bon0074.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) (157.56.111.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Wed, 18 Feb 2015 19:24:43 +0000 Received: from CO2PR03CA0015.namprd03.prod.outlook.com (10.141.194.142) by CO2PR03MB1147.namprd03.prod.outlook.com (10.141.187.22) with Microsoft SMTP Server (TLS) id 15.1.87.18; Wed, 18 Feb 2015 19:24:38 +0000 Received: from BY2FFO11FD013.protection.gbl (2a01:111:f400:7c0c::138) by CO2PR03CA0015.outlook.office365.com (2a01:111:e400:1414::14) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Wed, 18 Feb 2015 19:24:38 +0000 Received: from sj-itexedge03.altera.priv.altera.com (66.35.236.227) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Wed, 18 Feb 2015 19:24:38 +0000 Received: from sj-mail01.altera.com (137.57.1.6) by sj-itexedge03.altera.priv.altera.com (66.35.236.227) with Microsoft SMTP Server id 14.3.174.1; Wed, 18 Feb 2015 11:21:22 -0800 Received: from sj-interactive3.altera.com (sj-interactive3.altera.com [137.57.232.59]) by sj-mail01.altera.com (8.13.7+Sun/8.13.7) with ESMTP id t1IJLuaJ021065 for ; Wed, 18 Feb 2015 11:21:56 -0800 (PST) From: Jeff Prothero To: Subject: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference Date: Wed, 18 Feb 2015 19:24:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning altera.com discourages use of 66.35.236.227 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.35.236.227) smtp.mailfrom=jprother@altera.com; gcc.gnu.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:66.35.236.227;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(23726002)(46102003)(97756001)(53416004)(46406003)(92566002)(87936001)(15975445007)(6806004)(86362001)(47776003)(230783001)(16796002)(105596002)(50986999)(2351001)(62966003)(107886001)(54356999)(106466001)(110136001)(19580395003)(33646002)(229853001)(450100001)(50466002)(77156002)(7099025);DIR:OUT;SFP:1101;SCL:1;SRVR:CO2PR03MB1147;H:sj-itexedge03.altera.priv.altera.com;FPR:;SPF:SoftFail;MLV:ovrnspm;PTR:InfoDomainNonexistent;LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB1147; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005003);SRVR:CO2PR03MB1147; X-Forefront-PRVS: 04916EA04C X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR03MB1147; X-OriginatorOrg: altera.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2015 19:24:38.3335 (UTC) X-MS-Exchange-CrossTenant-Id: fbd72e03-d4a5-4110-adce-614d51f2077a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fbd72e03-d4a5-4110-adce-614d51f2077a;Ip=[66.35.236.227] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB1147 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00163.txt.bz2 Starting with gcc 4.9, -O2 implicitly invokes -fisolate-erroneous-paths-dereference: which https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html documents as Detect paths that trigger erroneous or undefined behavior due to dereferencing a null pointer. Isolate those paths from the main control flow and turn the statement with erroneous or undefined behavior into a trap. This flag is enabled by default at -O2 and higher. This results in a sizable number of previously working embedded programs mysteriously crashing when recompiled under gcc 4.9. The problem is that embedded programs will often have ram starting at address zero (think hardware-defined interrupt vectors, say) which gets initialized by code which the -fisolate-erroneous-paths-deference logic can recognize as reading and/or writing address zero. What happens then is that the previously running program compiles without any warnings, but then typically locks up mysteriously (often disabling the remote debug link) due to the trap not being gracefully handled by the embedded runtime. Granted, such code is out-of-spec wrt to C standards. None the less, the problem is quite painful to track down and unexpected. Is there any good reason the -fisolate-erroneous-paths-dereference logic could not issue a compiletime warning or error, instead of just silently generating code virtually certain to crash at runtime? Such a warning/error would save a lot of engineers significant amounts of time, energy and frustration tracking down this problem. I would like to think that the spirit of gcc is about helping engineers efficiently correct nonstandard pain, rather than inflicting maximal pain upon engineers violating C standards. :-) -Jeff 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?