[Bug tree-optimization/48766] New: Infinite recursion in fold_binary_loc()

[Bug tree-optimization/48766] New: Infinite recursion in fold_binary_loc()

[arthur.j.odwyer at gmail dot com]

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

           Summary: Infinite recursion in fold_binary_loc()
           Product: gcc
           Version: 4.4.5
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: arthur.j.odwyer@gmail.com


Created attachment 24097
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24097
Output of "ajo-gcc -O2 -fwrapv -ftrapv -S test746998981.c -v"

The following test case causes gcc to enter an infinite regress, recursing
among fold_binary_loc() and fold_build2_stat_loc(). They can't decide whether
the tree should contain a MINUS_EXPR or a PLUS_EXPR.  This reproduces for me
with svn revision 172796 (2011-04-20), and at least as far back as gcc 4.4.5.
I'm on Ubuntu 10.10, x86-64.  Attached "gcc-v.txt".

cat >test746998981.c <<EOF
extern short g, a, b;
void f() {
    g -= (a == -32768 && b == -1) ? -32768 : (a / b);
}
EOF
gcc -O2 -fwrapv -ftrapv -S test746998981.c

gcc: Internal error: Segmentation fault (program cc1)


This test case is reduced from the output of Csmith
(http://embed.cs.utah.edu/csmith/), using the following command line:
csmith --bitfields --packed-struct -s 746998981 > test746998981.c

[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.1.2
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|                            |2011.04.26 11:29:36
     Ever Confirmed|0                           |1
            Summary|Infinite recursion in       |[4.3/4.4/4.5/4.6/4.7
                   |fold_binary_loc()           |Regression] Infinite
                   |                            |recursion in
                   |                            |fold_binary_loc()
   Target Milestone|---                         |4.3.6
      Known to fail|                            |4.3.4

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-26 11:29:36 UTC ---
Confirmed.

[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iant at google dot com

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2011-04-26 13:26:19 UTC ---
It is caused by revision 121254:

http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00960.html

which adds -fstrict-overflow.

[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-04-26 21:18:56 UTC ---
The combination -fwrapv -ftrapv is not particularly meaningful; it ought 
to act exactly the same as -ftrapv (i.e. -ftrapv should override any 
previous -fwrapv, and vice versa; -fwrapv -fno-trapv should mean -fwrapv 
and -ftrapv -fno-wrapv should mean -ftrapv, as at present).

[Bug tree-optimization/48766] [4.3/4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.6                       |4.4.7

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-27 12:14:08 UTC ---
4.3 branch is being closed, moving to 4.4.7 target.

[Bug tree-optimization/48766] [4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug tree-optimization/48766] [4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-06 10:33:11 UTC ---
(In reply to comment #3)
> The combination -fwrapv -ftrapv is not particularly meaningful; it ought 
> to act exactly the same as -ftrapv (i.e. -ftrapv should override any 
> previous -fwrapv, and vice versa; -fwrapv -fno-trapv should mean -fwrapv 
> and -ftrapv -fno-wrapv should mean -ftrapv, as at present).

I suppose the new Negative() .opt file annotation cannot cover this?

Internally we probably should have a single enum that enumerates all
valid integer overflow behaviors (what about the weak -f[no-]strict-overflow)?

[Bug tree-optimization/48766] [4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-06 16:35:02 UTC ---
On Tue, 6 Dec 2011, rguenth at gcc dot gnu.org wrote:

> > The combination -fwrapv -ftrapv is not particularly meaningful; it ought 
> > to act exactly the same as -ftrapv (i.e. -ftrapv should override any 
> > previous -fwrapv, and vice versa; -fwrapv -fno-trapv should mean -fwrapv 
> > and -ftrapv -fno-wrapv should mean -ftrapv, as at present).
> 
> I suppose the new Negative() .opt file annotation cannot cover this?

Negative() isn't particularly new, and it can't handle those semantics.

> Internally we probably should have a single enum that enumerates all
> valid integer overflow behaviors (what about the weak -f[no-]strict-overflow)?

Yes, I think one enum makes sense.  You need to work out what cases such 
as -ftrapv -fwrapv -fno-wrapv do (whether it means -ftrapv as at present, 
or the default state - I think probably the default state; that is, 
-ftrapv and -fwrapv would set the enum to appropriate values, -fno-trapv 
and -fno-wrapv would set it to default if -ftrapv or -fwrapv respectively 
were in effect, and otherwise do nothing).

I don't know about -fstrict-overflow, but maybe that should be separate 
(controlling whether, in cases where the default semantics are in effect, 
certain optimizations relating to overflow are made).

[Bug tree-optimization/48766] [4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[iant at google dot com]

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

--- Comment #7 from iant at google dot com <iant at google dot com> 2011-12-06 18:40:58 UTC ---
> I don't know about -fstrict-overflow, but maybe that should be separate 
> (controlling whether, in cases where the default semantics are in effect, 
> certain optimizations relating to overflow are made).

That was my intent for -fno-strict-overflow: it does not change the
semantics, it just disables optimizations.  Of course when -fwrapv or
-ftrapv are set, overflow behaviour is defined, so -fno-strict-overflow
does nothing.  -fno-strict-overflow is only meaningful when neither
-fwrapv nor -ftrapv are set.

[Bug tree-optimization/48766] [4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[joseph at codesourcery dot com]

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

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-12-06 20:12:12 UTC ---
On Tue, 6 Dec 2011, iant at google dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766
> 
> --- Comment #7 from iant at google dot com <iant at google dot com> 2011-12-06 18:40:58 UTC ---
> > I don't know about -fstrict-overflow, but maybe that should be separate 
> > (controlling whether, in cases where the default semantics are in effect, 
> > certain optimizations relating to overflow are made).
> 
> That was my intent for -fno-strict-overflow: it does not change the
> semantics, it just disables optimizations.  Of course when -fwrapv or
> -ftrapv are set, overflow behaviour is defined, so -fno-strict-overflow
> does nothing.  -fno-strict-overflow is only meaningful when neither
> -fwrapv nor -ftrapv are set.

As I understand it, -fno-strict-overflow also affects optimizations for 
pointer overflow in any of the three -fwrapv/-ftrapv/default modes (those 
modes only relate to integer arithmetic semantics, not anything for 
pointer arithmetic).

[Bug tree-optimization/48766] [4.4/4.5/4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[iant at google dot com]

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

--- Comment #9 from iant at google dot com <iant at google dot com> 2011-12-06 21:33:33 UTC ---
> As I understand it, -fno-strict-overflow also affects optimizations for 
> pointer overflow in any of the three -fwrapv/-ftrapv/default modes (those 
> modes only relate to integer arithmetic semantics, not anything for 
> pointer arithmetic).

Yes, good point.

[Bug tree-optimization/48766] [4.5/4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |4.5.4

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 12:47:24 UTC ---
4.4 branch is being closed, moving to 4.5.4 target.

[Bug tree-optimization/48766] [4.5/4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.4                       |4.6.4

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-02 11:21:02 UTC ---
The 4.5 branch is being closed, adjusting target milestone.

[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-14 14:24:32 UTC ---
Created attachment 29161
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29161
gcc48-pr48766.patch

Untested fix.  Seems in the previous option processing the negative options
cancel their corresponding positive options (and vice versa), and only the last
occurrence of the option from the command line remains and the patch just
disables -fwrapv if -ftrapv comes after -fwrapv, and vice versa.
So e.g.
-fwrapv -ftrapv -fwrapv results in -fwrapv
-fwrapv -ftrapv results in -ftrapv
-fwrapv -ftrapv -fno-wrapv results in -ftrapv
-ftrapv -fwrapv -fno-trapv results in -fwrapv
etc.

[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2013-01-14 15:48:41 UTC ---
(In reply to comment #12)
> Created attachment 29161 [details]
> gcc48-pr48766.patch
> 
> Untested fix.  Seems in the previous option processing the negative options
> cancel their corresponding positive options (and vice versa), and only the last
> occurrence of the option from the command line remains and the patch just
> disables -fwrapv if -ftrapv comes after -fwrapv, and vice versa.
> So e.g.
> -fwrapv -ftrapv -fwrapv results in -fwrapv
> -fwrapv -ftrapv results in -ftrapv
> -fwrapv -ftrapv -fno-wrapv results in -ftrapv
> -ftrapv -fwrapv -fno-trapv results in -fwrapv
> etc.

Why not use Negative in common.opt?

[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-14 16:01:36 UTC ---
Because it behaves differently.
./xgcc -B ./ -fwrapv -ftrapv -fno-trapv -fverbose-asm -S -xc /dev/null -o -
2>&1 | grep rapv
# -march=x86-64 -auxbase-strip - -fno-trapv -fverbose-asm
with Negative(fwrapv) resp. Negative(ftrapv) added instead of this patch, while
with that patch it was -fwrapv.

[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-15 08:17:09 UTC ---
Author: jakub
Date: Tue Jan 15 08:16:56 2013
New Revision: 195186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195186
Log:
    PR tree-optimization/48766
    * opts.c (common_handle_option): For -fwrapv disable -ftrapv, for
    -ftrapv disable -fwrapv.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/opts.c

[Bug tree-optimization/48766] [4.6/4.7 Regression] Infinite recursion in fold_binary_loc()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.8.0
            Summary|[4.6/4.7/4.8 Regression]    |[4.6/4.7 Regression]
                   |Infinite recursion in       |Infinite recursion in
                   |fold_binary_loc()           |fold_binary_loc()

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-15 08:34:59 UTC ---
Fixed on the trunk so far.

[Bug tree-optimization/48766] [4.7 Regression] Infinite recursion in fold_binary_loc()

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.4                       |4.7.4

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:16:48 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug tree-optimization/48766] [4.7 Regression] Infinite recursion in fold_binary_loc()

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|4.7.4                       |4.8.0
      Known to fail|                            |4.7.4

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.8.0.