1

Like the title suggest I am wondering if there is a way to turn on the GCC flag 

-Waggressive-loop-optimizations

when the optimizations level is -O0 or without using -OX at all.

Lets see the following example:

#include <stdio.h>

int main ( void ){
    int arr[4] = { 0 };

    for ( int i = 0 ; i < 5 ; i++ ){
        arr[i] = i+1;
    }

    for ( int j = 0; j < 4 ; j++ ){
        printf("Arr[%d] = %d\n", j, arr[j] );
    }
}

as you can see, when i == 4 here:

for ( int i = 0 ; i < 5 ; i++ )

the program reads the Array outside of its bounds.

With the following GCC flags -O1 to -O3 The compiler informs me about this:

INPUT:

gcc-7 -Wpedantic -std=c11 -Wall -Wextra -Werror -O1

Output:

program.c: In function ‘main’:
program.c:6:16: error: iteration 4 invokes undefined behavior [-Werror=aggressive-loop-optimizations]
         arr[i] = i+1;
         ~~~~~~~^~~~~
program.c:5:5: note: within this loop
     for ( int i = 0 ; i < 5 ; i++ ){
     ^~~
cc1: all warnings being treated as errors

But of course it does not with -O0.

I was trying the following:

gcc-7 -Wpedantic -std=c11 -Wall -Wextra -Werror -Waggressive-loop-optimizations -O0 program.c -o program

and even the following (without -O0:

gcc-7 -Wpedantic -std=c11 -Wall -Wextra -Werror -Waggressive-loop-optimizations program.c -o program

And the compiler just ignores this flag:

-Waggressive-loop-optimizations

Does anyone know why it is happening that and if there is a possible way to turn this flag ON ?: -Waggressive-loop-optimizations

EDIT:

I need this because for example when I compile the above program with:

gcc-7 -Wpedantic -std=c11 -Wall -Wextra -Werror -Wstrict-prototypes -Wmissing-prototypes -Wmisleading-indentation -Wduplicated-cond -Wold-style-definition -Wconversion -Wshadow -Winit-self -Wfloat-equal -Wwrite-strings -Wpointer-compare -Waggressive-loop-optimizations -g program.c -o program

And then I do:

valgrind --leak-check=full --track-origins=yes ./program

valgrind does not report something, because I think that the compiler Optimize that away ( I think):

michi@michael ~/Compile $ valgrind --leak-check=full --track-origins=yes ./program
==5818== Memcheck, a memory error detector
==5818== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==5818== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==5818== Command: ./program
==5818== 
Arr[0] = 1
Arr[1] = 2
Arr[2] = 3
Arr[3] = 4
==5818== 
==5818== HEAP SUMMARY:
==5818==     in use at exit: 0 bytes in 0 blocks
==5818==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==5818== 
==5818== All heap blocks were freed -- no leaks are possible
==5818== 
==5818== For counts of detected and suppressed errors, rerun with: -v
==5818== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Any way in the comments, there is some misunderstanding about the edit part and the Question itself.

No, I do not need a valgrind fix here, the edit is just to explain one of the situations where there is no catch of accessing an Array out of its bounds because the flag -Waggressive-loop-optimizations does not Work like when you use the optimizations level -O1, -O2 or -O3.

Michi
  • 5,175
  • 7
  • 33
  • 58
  • 1
    I suppose the compiler detected the undefined behavior while trying to unroll the loop. I doubt that there's code in the compiler whose only purpose is to find that error for you. Which is to say that I'm guessing that `-Waggressive-loop-optimizations` is meaningless if you don't run the optimizer. – user3386109 Feb 12 '18 at 22:10
  • The edit seems like an entirely different question to me. As in, "How do I get valgrind to detect out-of-bounds array accesses?" You should really put that in the title, or ask it as a separate question. – user3386109 Feb 12 '18 at 22:19
  • @user3386109 The edit is there to show just an example of the need of this flag and definitely is not there to change the Question. Please read it again. – Michi Feb 12 '18 at 22:21
  • I don't see any reason for using `-O0`. `because I think that the compiler Optimize that away` you should use `-Og` for debugging, not `-O0` – phuclv Feb 13 '18 at 01:36
  • Perhaps a sequence of [diagnostic pragmas](https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Diagnostic-Pragmas.html) around the code - i.e., `push`, `warning "-Waggressive-loop-optimizations"`, `pop` – Brett Hale Feb 13 '18 at 06:42
  • @BrettHale That should do what I need, but what happens if I use another compoiler? does this work too or is just GCC stuff? – Michi Feb 13 '18 at 09:43

0 Answers0