This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: memset zero bytes at NULL - isolate-erroneous-paths
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, Dominic News <d dot newsgroups at googlemail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 19 Nov 2013 12:57:15 +0100
- Subject: Re: memset zero bytes at NULL - isolate-erroneous-paths
- Authentication-results: sourceware.org; auth=none
- References: <CALx3oLxLBCYez=jUiD7sLE-ynVHZ0Dr9QfX3QeLqCP-1p2p1nw at mail dot gmail dot com> <CAH6eHdSS9q-McGntA1+61TSe8EU_GVZ67RiFdLkr2APWVT7Evg at mail dot gmail dot com> <87d2lyn0u8 dot fsf at mid dot deneb dot enyo dot de> <5289980B dot 4080309 at redhat dot com> <87habachfy dot fsf at mid dot deneb dot enyo dot de> <CAFiYyc1riMiOkoJWzdGU6rJe7p263K2A4noHw9-1doY0XT=7=g at mail dot gmail dot com> <528A232E dot 4030903 at redhat dot com>
On Mon, Nov 18, 2013 at 3:24 PM, Jeff Law <law@redhat.com> wrote:
> On 11/18/13 04:08, Richard Biener wrote:
>>>
>>> I'd say that turning memset (0, '\0', 0) into a trap is bad from a QOI
>>
>> perspective. Jeff, is there an easy way to avoid this? Testcase:
>>
>> void fn (void *addr, int a)
>> {
>> if (a == 0)
>> addr = (void *)0;
>> __builtin_memset (addr, '\0', a);
>> }
>>
>> I wonder where in isolate-paths you check for builtins at all? ah,
>> it's probably from the nonnull attribute on memset. Which also
>> means that trying to catch this case reliably isn't going to work
>> (you cannot prove the program has len == 0 in this case and
>> conditionally not trapping would somewhat defeat the purpose
>> of isolating this path)
>
> It's the nonnull attribute on memset. One thought would split the
> optimization into two parts. One which transforms *0 and the other which
> transforms calls/returns. Have the former enabled by -O2 the latter off for
> now. For the next release, both enabled by default at -O2.
>
> Add distinct warnings for both cases, possibly enabled by -Wall (depends on
> the noise).
>
> That gets most of the benefit now and gives a way for users to identify
> brokenness in their code.
>
> Sadly, this feels a lot like -fstrict-aliasing did eons ago. Aggressive
> TBAA exposed all kinds problems and it took a lot of user (re)education to
> get them fixed.
Yeah ... splitting the flag may help tracking down bogus nonnull attributes
as well (we're still seeing invalid uses of the malloc attribute ...).
Richard.
> jeff