All of these functions overflow the loop induction variable so only -fwrapv will provide the behavior you want for all of the functions.  The inconsistent behavior is due to the overflows happening for induction variables.  If it was not an induction variable then -fno-strict-overflow would have worked..-fno-strict-overflow is only defined to work for non loop variables.

Thanks,
Andrew

On Sep 17, 2013, at 6:28 PM, "mednafen at gmail dot com" <gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454
> 
>            Bug ID: 58454
>           Summary: Potentially wrong(or at least weird/inconsistent) code
>                    generation with -O2 -fno-strict-overflow
>           Product: gcc
>           Version: 4.8.1
>            Status: UNCONFIRMED
>          Severity: normal
>          Priority: P3
>         Component: c
>          Assignee: unassigned at gcc dot gnu.org
>          Reporter: mednafen at gmail dot com
> 
> Created attachment 30844 [details]
>  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30844&action=edit
> Testcase program.
> 
> Working:
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O0 -o halt halt.c 
> XXX@willow:~/halt$ ./halt 
> IMm3: ****
> IMm2: ***
> IMm1: **
> IM: *
> 
> 
> ????:
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -o halt halt.c 
> XXX@willow:~/halt$ ./halt 
> IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3:
> ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3:
> ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3: ****IMm3:
> ****IMm3: ****Aborted
> 
> 
> Working:
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2
> -fno-aggressive-loop-optimizations -o halt halt.c
> XXX@willow:~/halt$ ./halt 
> IMm3:
> ****************************************************************************************************Aborted
> 
> 
> Broken:
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow
> -o halt halt.c 
> XXX@willow:~/halt$ ./halt 
> IMm3: ****
> IMm2: ***
> IMm1:
> *********************************************************************************************Aborted
> 
> 
> Broken:
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2
> -fno-aggressive-loop-optimizations -fno-strict-overflow -o halt halt.c 
> XXX@willow:~/halt$ ./halt 
> IMm3: ****
> IMm2: ***
> IMm1:
> *********************************************************************************************Aborted
> 
> 
> Working:
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow
> -fno-tree-vrp -o halt halt.c
> XXX@willow:~/halt$ ./halt
> IMm3: ****
> IMm2: ***
> IMm1: **
> IM: *
> 
> 
> Working:
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow
> -fwrapv -o halt halt.c
> XXX@willow:~/halt$ ./halt 
> IMm3: ****
> IMm2: ***
> IMm1: **
> IM: *
> 
> 
> XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/local/gcc-4.8.1/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc-4.8.1
> Thread model: posix
> gcc version 4.8.1 (GCC)

Your assertion conflicts with the gcc 4.2 release change-list at http://gcc.gnu.org/gcc-4.2/changes.html when the strict-overflow options were added.

Additionally, -fwrapv produces unnecessarily bloated code compared to -fno-strict-overflow, in my experience.

-fno-strict-overflow should have never been added because it certainly does not disable all use of undefined signed overflow behavior.  Which makes it kind-of
useless.

Ian, the documentation of -fno-strict-overflow suggests that the compiler
will not rely on signed overflow not happening.  That's not true, so this
is definitely a documentation bug.

Richi, as you know, -fno-strict-overflow was added to prevent people from configuring GCC to make -fwrapv the default.  I know you hate the option but I continue to think that adding was the right tactical move at the time.  We can't just ignore the world outside the compiler development community.

It's true that -fno-strict-overflow does not apply to loop optimizations, which are covered by -fno-aggressive-loop-optimizations.  I agree that that is a doc omission.

(In reply to Ian Lance Taylor from comment #4)
> It's true that -fno-strict-overflow does not apply to loop optimizations,
> which are covered by -fno-aggressive-loop-optimizations.  I agree that that
> is a doc omission.

The examples above suggest that this is not true either. Only -fno-tree-vrp or -fwrapv do the trick.

Richard, is this bug fixed for GCC 8?

I'd like to update the FAQ: https://gcc.gnu.org/wiki/FAQ#signed_overflow

On September 4, 2017 5:51:13 PM GMT+02:00, "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454
>
>Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>             CC|                            |rguenth at gcc dot gnu.org
>
>--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
>Richard, is this bug fixed for GCC 8?
>
>I'd like to update the FAQ:
>https://gcc.gnu.org/wiki/FAQ#signed_overflow

Given -fno-strict-overflow is now mapped to -fwrapv you could say so.

Fixed in GCC 8, it won't be backported.

GCC 8.1 has been released.

GCC 8.2 has been released.

GCC 8.3 has been released.

GCC 8.4.0 has been released, adjusting target milestone.

Fixed then.