This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- From: <Paul_Koning at Dell dot com>
- To: <law at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 20 Feb 2015 18:01:35 +0000
- Subject: Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
- Authentication-results: sourceware.org; auth=none
- References: <pdf61azt48b dot fsf at sj-interactive3 dot altera dot com> <20150218192943 dot GR1746 at tucnak dot redhat dot com> <54E64DFF dot 8030100 at codesourcery dot com> <54E71534 dot 8070805 at redhat dot com> <CAH6eHdT3jPVY-5n009r9xyRkhXUQkPkAN5cPGJEL+DREREO_+A at mail dot gmail dot com> <54E76870 dot 2070502 at redhat dot com>
> On Feb 20, 2015, at 12:01 PM, Jeff Law <law@redhat.com> wrote:
>
> On 02/20/15 04:43, Jonathan Wakely wrote:
>>> ...
>>
>> I'm inclined to agree.
>>
>> Most developers aren't aware of the preconditions on memcpy, but GCC
>> optimizes aggressively based on those preconditions, so we have a
>> large and potentially dangerous gap between what developers expect and
>> what actually happens.
> But that's always true -- this isn't any different than aliasing, arithmetic overflow, etc. The standards define the contract between the compiler/library implementors and the developers. Once the contract is broken, all bets are off.
True. The unfortunate problem with C, and even more so with C++, is that the contract is so large and complex that few, if any, are skilled enough language lawyers to know what exactly it says. For that matter, the contract (the standard) is large and complex enough that it has bugs and ambiguities, so the contract is not in fact precisely defined.
Thereâs a nice paper that drives this home: http://people.csail.mit.edu/akcheung/papers/apsys12.pdf
For example, while most people know about the âno overlapsâ rule of memcpy, stuff like aliasing are far more obscure. Or the exact meaning (if there is one) of âvolatileâ.
It also doesnât help that a large fraction of the contract is unenforced. You only find out about it when a new version of the compiler starts using a particular rule to make an optimization that suddenly breaks 10 year old code. I remember some heated debates between Linux folks and compiler builders when such things strike the Linux kernel.
paul