[Bug c/51730] New: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[Bug c/51730] New: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[jakub at gcc dot gnu.org]

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

             Bug #: 51730
           Summary: [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h
                    check fails with GCC 4.7
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: jsm28@gcc.gnu.org


During a distro mass rebuild, I found that many packages still have configure
generated with autoconf 2.60 through 2.67, and these autoconf contain a not
strictly valid C:
         /* Catch a bug in IBM AIX xlc compiler version 6.0.0.0
            reported by James Lemley on 2005-10-05; see
           
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00086.html
            This test is not quite right, since xlc is allowed to
            reject this program, as the initializer for xlcbug is
            not one of the forms that C requires support for.
            However, doing the test right would require a runtime
            test, and that would make cross-compilation harder.
            Let us hope that IBM fixes the xlc bug, and also adds
            support for this kind of constant expression.  In the
            meantime, this test will reject xlc, which is OK, since
            our stdbool.h substitute should suffice.  We also test
            this with GCC, where it should work, to detect more
            quickly whether someone messes up the test in the
            future.  */
         char digs[] = "0123456789";
         int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1);
check.  Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
GCC has been accepting this though, and I suppose we don't want to fold array
refs that way when generating code.  Would it be possible to fold it that way
(try harder) just when we know we are not going to generate code based on it
(or when we know we'd error out otherwise)?  I know it sounds like an ugly
hack,
unfortunately autoconf 2.6[0-7] generated configure scripts are going to be
around for many years and the stdbool.h checks would fail in hundreds of
packages.

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-02 12:14:38 UTC ---
Note that autoconf 2.59 and earlier didn't contain this and autoconf 2.68
removed it again, as it started failing with newer xlc version too.

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-01-02 13:03:35 UTC ---
On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote:

>          char digs[] = "0123456789";
>          int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1);
> check.  Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
> GCC has been accepting this though, and I suppose we don't want to fold array
> refs that way when generating code.  Would it be possible to fold it that way
> (try harder) just when we know we are not going to generate code based on it
> (or when we know we'd error out otherwise)?  I know it sounds like an ugly

As I understand it, the point of that commit was that the conversion of 
all array references to pointer arithmetic (losing all information about 
signs of indices) was problematic.  But it should still be valid to fold a 
comparison that way: if the addresses being compared have the same base 
object and all offsets are constant integers, a final byte offset for each 
address can be computed mod the size of the address space and it's OK to 
fold based on comparing those offsets (if the actual, signed offsets 
involved overflow anywhere, that would have been execution-time undefined 
behavior).  That is, I think it would be better to fix this by improving 
the folding of address comparisons, rather than by changing how array 
references are expanded.

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-01-02
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-02 14:01:19 UTC ---
(In reply to comment #2)
> On Mon, 2 Jan 2012, jakub at gcc dot gnu.org wrote:
> 
> >          char digs[] = "0123456789";
> >          int xlcbug = 1 / (&(digs + 5)[-2 + (_Bool) 1] == &digs[4] ? 1 : -1);
> > check.  Until http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172958
> > GCC has been accepting this though, and I suppose we don't want to fold array
> > refs that way when generating code.  Would it be possible to fold it that way
> > (try harder) just when we know we are not going to generate code based on it
> > (or when we know we'd error out otherwise)?  I know it sounds like an ugly
> 
> As I understand it, the point of that commit was that the conversion of 
> all array references to pointer arithmetic (losing all information about 
> signs of indices) was problematic.  But it should still be valid to fold a 
> comparison that way: if the addresses being compared have the same base 
> object and all offsets are constant integers, a final byte offset for each 
> address can be computed mod the size of the address space and it's OK to 
> fold based on comparing those offsets (if the actual, signed offsets 
> involved overflow anywhere, that would have been execution-time undefined 
> behavior).  That is, I think it would be better to fix this by improving 
> the folding of address comparisons, rather than by changing how array 
> references are expanded.

I think what changed is that we keep &digs[4] in the IL now, rather than
representing it as &digs + 4.  So it seems to be some missed folding.

Indeed we have (char *) &digs + 4 == &digs[4]

I'll look into this.

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-02 14:15:39 UTC ---
Like

Index: gcc/fold-const.c
===================================================================
--- gcc/fold-const.c    (revision 182784)
+++ gcc/fold-const.c    (working copy)
@@ -8886,6 +8886,13 @@ fold_comparison (location_t loc, enum tr
              indirect_base0 = true;
            }
          offset0 = TREE_OPERAND (arg0, 1);
+         if (host_integerp (offset0, 1)
+             && (TREE_INT_CST_LOW (offset0)
+                 & ((unsigned HOST_WIDE_INT)-1 << (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT)))) == 0)
+           {
+             bitpos0 = TREE_INT_CST_LOW (offset0) * BITS_PER_UNIT;
+             offset0 = NULL_TREE;
+           }
        }

       base1 = arg1;
@@ -8909,6 +8916,13 @@ fold_comparison (location_t loc, enum tr
              indirect_base1 = true;
            }
          offset1 = TREE_OPERAND (arg1, 1);
+         if (host_integerp (offset1, 1)
+             && (TREE_INT_CST_LOW (offset1)
+                 & ((unsigned HOST_WIDE_INT)-1 << (HOST_BITS_PER_WIDE_INT -
exact_log2 (BITS_PER_UNIT)))) == 0)
+           {
+             bitpos1 = TREE_INT_CST_LOW (offset1) * BITS_PER_UNIT;
+             offset1 = NULL_TREE;
+           }
        }

       /* A local variable can never be pointed to by

to be beautified ...

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-03 08:59:37 UTC ---
Fixed.

[Bug c/51730] [4.7 Regression] autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-03 08:59:26 UTC ---
Author: rguenth
Date: Tue Jan  3 08:59:21 2012
New Revision: 182830

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182830
Log:
2012-01-03  Richard Guenther  <rguenther@suse.de>

    PR middle-end/51730
    * fold-const.c (fold_comparison): Properly canonicalize
    tree offset and HOST_WIDE_INT bit position.

    * gcc.dg/fold-compare-6.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/fold-compare-6.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c
    trunk/gcc/testsuite/ChangeLog