[Bug c/36124] New: conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[Bug c/36124] New: conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[cyprien+gccbug at cypou dot net]

Hi,

It seems to have some regression in gcc 4.3, visible on arm targets as well as
x86_64.
I originally already reported it to Debian bugtracking system
[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472867]

I tested it against the latest gcc snapshot:
    gcc (GCC) 4.3.1 20080501 (prerelease)

gcc has been built with no option, only srcdir/configure && make.

preprocessed content:
# 1 "c.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "c.c"


extern void func(void*);

void test()
{
    register long *foo = (long*) 1024;
    register int index;
    for(index=0;index<1024;index++)
        func(foo--);
}


This is a simple loop indexed on an integer. It should be finite, but when
compiling with -O2 (and -O3) the compiler removes the end condition.

gcc -S -O2 extract:
.LCFI0: 
        movl    $1024, %edi
        .p2align 4,,10
        .p2align 3
.L2:
        leaq    -8(%rdi), %rbx
        call    func
        movq    %rbx, %rdi
        jmp     .L2


Note that when using char* or non-pointer type for foo variable, it compiles
successfully.


-- 
           Summary: conditional loop becomes infinite loop in -O2 (gcc 4.2 -
                    > 4.3 regression)
           Product: gcc
           Version: 4.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: cyprien+gccbug at cypou dot net
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-04 16:34 -------
Pointers types overflow is undefined which is what you are seeing.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[cyprien+gccbug at cypou dot net]

------- Comment #2 from cyprien+gccbug at cypou dot net  2008-05-04 16:41 -------
shouldn't gcc report a warning in this case ?

because silently entering an infinite loop is not very kind...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-04 16:45 -------
(In reply to comment #2)
> shouldn't gcc report a warning in this case ?

Maybe, but really depending on undefined behavior is bad too. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2008-05-04 17:01 -------
(In reply to comment #2)
> shouldn't gcc report a warning in this case ?
> 
> because silently entering an infinite loop is not very kind...
> 

If your code invokes undefined behavior, how is gcc going
to read your mind?  Maybe the programmer meant to enter
an infinite, so a warning isn't correct.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[cyprien+gccbug at cypou dot net]

------- Comment #5 from cyprien+gccbug at cypou dot net  2008-05-04 17:03 -------
Now, this code should not rely on undefined behaviour:

extern void func(int,void*);
void test()
{
    register long *foo = (long*) (4*sizeof(*foo)) - 1;
    register int index;
    for(index=0;index<4;index++)
        func(index,foo--);
}


it still make an infinite loop, while last func call is done with foo parameter
(nil).


Do you mean I explicitely ask gcc to use foo as end-of-loop condition ??


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-05-04 17:09 -------
>Now, this code should not rely on undefined behaviour:

It does because incrementing or decrementing to a NULL Pointer is undefined.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[cyprien+gccbug at cypou dot net]

------- Comment #7 from cyprien+gccbug at cypou dot net  2008-05-04 17:31 -------
it's right, using --foo unstead of foo-- gives a better result.
But it does not make me happy (about the possibility of a bug)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[cyprien+gccbug at cypou dot net]

------- Comment #8 from cyprien+gccbug at cypou dot net  2008-05-04 20:13 -------
On some embedded machines, the SDRAM lays on 0x00000000 address. So it is not
so meaningless to increment or decrement from/to NULL pointer.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2008-05-07 19:42 -------
decrementing a NULL pointer invokes undefined behavior, incrementing not.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2008-05-13 20:02 -------
*** Bug 36232 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick dot spence at freescale
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124

[Bug middle-end/36124] conditional loop becomes infinite loop in -O2 (gcc 4.2 -> 4.3 regression)

[scottwood at freescale dot com]

------- Comment #11 from scottwood at freescale dot com  2008-05-13 21:13 -------
(In reply to comment #4)
> If your code invokes undefined behavior, how is gcc going
> to read your mind?

If GCC can tell that it is undefined behavior, then warning the user is more
useful than silently producing nasal demons, regardless of what might be in the
user's mind.  "The spec allows us to do something stupid" doesn't mean "we
should do something stupid".

> Maybe the programmer meant to enter
> an infinite, so a warning isn't correct.

If it's undefined behavior, then too bad, right?  I have a really hard time
seeing how one would derive such intent from the above code, though -- or
imagining what GCC is doing that made it think that generating the code it does
is a good idea.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36124