Re: c/3752: gcc 3.0: __builtin_constant_p(ptr==ptr), regression

Re: c/3752: gcc 3.0: __builtin_constant_p(ptr==ptr), regression

[rodrigc]

Synopsis: gcc 3.0: __builtin_constant_p(ptr==ptr), regression

State-Changed-From-To: open->closed
State-Changed-By: rodrigc
State-Changed-When: Wed Mar  6 15:33:36 2002
State-Changed-Why:
    Fixed in gcc 3.0.4
    
    2001-07-22  Richard Henderson  <rth@redhat.com>
     
            * fold-const.c (fold): Test vs FLOAT_TYPE_P instead of
            INTEGRAL_TYPE_P when folding comparisons with operand_equal_p
            arguments.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3752

Re: c/3752: gcc 3.0: __builtin_constant_p(ptr==ptr), regression

[Richard Henderson]

The following reply was made to PR c/3752; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: Kevin Ryde <user42@zip.com.au>, gcc-gnats@gcc.gnu.org,
        gcc-patches@gcc.gnu.org
Cc:  
Subject: Re: c/3752: gcc 3.0: __builtin_constant_p(ptr==ptr), regression
Date: Mon, 23 Jul 2001 14:24:19 -0700

 On Sun, Jul 22, 2001 at 10:58:54PM -0700, Richard Henderson wrote:
 > I guess this worked before by having CSE simplify the code appropriately.
 > If so, this means we've got a CSE regression somewhere too.  I guess I'll
 > look for that...
 
 CSE isn't very good at simplifying
 
 	(set (reg:SI X) (const_int 0))
 
 	[...]
 
 	(set (strict_low_part (subreg:QI (reg:SI X) 0))
 	     (eq:QI ...))
 
 It's probably best if we avoid that construct early on,
 and make that sort of transformation later if we can.
 
 Tested on i686 linux; applied mainline and branch.
 
 
 r~
 
 
         * config/i386/i386.c (ix86_expand_setcc): Don't use method 0
         before CSE.
         * config/i386/i386.md: New setcc+movzbl peephole2.
 
 Index: i386.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
 retrieving revision 1.288
 diff -c -p -d -r1.288 i386.c
 *** i386.c	2001/07/22 21:42:35	1.288
 --- i386.c	2001/07/23 21:13:21
 *************** ix86_expand_setcc (code, dest)
 *** 6357,6365 ****
             emit subreg setcc, zero extend.
        2 -- destination is in QImode:
             emit setcc only.
 -   */
   
 !   type = 0;
   
     if (GET_MODE (dest) == QImode)
       type = 2;
 --- 6357,6368 ----
             emit subreg setcc, zero extend.
        2 -- destination is in QImode:
             emit setcc only.
   
 !      We don't use mode 0 early in compilation because it confuses CSE.
 !      There are peepholes to turn mode 1 into mode 0 if things work out
 !      nicely after reload.  */
 ! 
 !   type = cse_not_expected ? 0 : 1;
   
     if (GET_MODE (dest) == QImode)
       type = 2;
 Index: i386.md
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.md,v
 retrieving revision 1.288
 diff -c -p -d -r1.288 i386.md
 *** i386.md	2001/07/20 12:15:36	1.288
 --- i386.md	2001/07/23 21:13:21
 ***************
 *** 13133,13138 ****
 --- 13133,13157 ----
   			   (match_dup 0)
   			   (pc)))]
     "")
 + 
 + ;; Convert setcc + movzbl to xor + setcc if operands don't overlap.
 + 
 + (define_peephole2
 +   [(set (reg 17) (match_operand 0 "" ""))
 +    (set (match_operand:QI 1 "register_operand" "")
 + 	(match_operator:QI 2 "ix86_comparison_operator"
 + 	  [(reg 17) (const_int 0)]))
 +    (set (match_operand 3 "q_regs_operand" "")
 + 	(zero_extend (match_dup 1)))]
 +   "peep2_reg_dead_p (3, operands[1])
 +    && ! reg_overlap_mentioned_p (operands[3], operands[0])"
 +   [(parallel [(set (match_dup 3) (const_int 0))
 + 	      (clobber (reg:CC 17))])
 +    (set (match_dup 4) (match_dup 0))
 +    (set (strict_low_part (match_dup 5))
 + 	(match_dup 2))]
 +   "operands[4] = gen_rtx_REG (GET_MODE (operands[0]), 17);
 +    operands[5] = gen_rtx_REG (QImode, REGNO (operands[3]));")
   \f
   ;; Call instructions.
   

Re: c/3752: gcc 3.0: __builtin_constant_p(ptr==ptr), regression

[Richard Henderson]

The following reply was made to PR c/3752; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: Kevin Ryde <user42@zip.com.au>
Cc: gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: c/3752: gcc 3.0: __builtin_constant_p(ptr==ptr), regression
Date: Sun, 22 Jul 2001 22:58:54 -0700

 On Sat, Jul 21, 2001 at 07:27:36AM +1000, Kevin Ryde wrote:
 > >Description:
 > gcc 3 __builtin_constant_p fails to recognise "ptr==ptr" as a
 > constant, whereas gcc 2.95.x did.
 
 INTEGRAL_TYPE_P does not include POINTER_TYPE_P.
 
 I guess this worked before by having CSE simplify the code appropriately.
 If so, this means we've got a CSE regression somewhere too.  I guess I'll
 look for that...
 
 In any case, we should simplify this sort of thing as early as possible.
 
 Tested on i686 linux.
 
 
 r~
 
 
         * fold-const.c (fold): Test vs FLOAT_TYPE_P instead of 
         INTEGRAL_TYPE_P when folding comparisons with operand_equal_p 
         arguments.
 
 Index: fold-const.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
 retrieving revision 1.146.2.6
 diff -u -p -r1.146.2.6 fold-const.c
 --- fold-const.c	2001/04/02 08:32:00	1.146.2.6
 +++ fold-const.c	2001/07/23 05:47:42
 @@ -6489,7 +6489,7 @@ fold (expr)
  	    case EQ_EXPR:
  	    case GE_EXPR:
  	    case LE_EXPR:
 -	      if (INTEGRAL_TYPE_P (TREE_TYPE (arg0)))
 +	      if (! FLOAT_TYPE_P (TREE_TYPE (arg0)))
  		return constant_boolean_node (1, type);
  	      code = EQ_EXPR;
  	      TREE_SET_CODE (t, code);
 @@ -6497,7 +6497,7 @@ fold (expr)
  
  	    case NE_EXPR:
  	      /* For NE, we can only do this simplification if integer.  */
 -	      if (! INTEGRAL_TYPE_P (TREE_TYPE (arg0)))
 +	      if (FLOAT_TYPE_P (TREE_TYPE (arg0)))
  		break;
  	      /* ... fall through ...  */
  	    case GT_EXPR:

c/3752: gcc 3.0: __builtin_constant_p(ptr==ptr), regression

[Kevin Ryde]

>Number:         3752
>Category:       c
>Synopsis:       gcc 3.0: __builtin_constant_p(ptr==ptr), regression
>Confidential:   yes
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          pessimizes-code
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 20 14:36:03 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     
>Release:        3.0 (Debian) (Debian testing/unstable)
>Organization:
>Environment:
System: Linux blah 2.2.15 #1 Tue Apr 25 17:13:48 EST 2000 i586 unknown
Architecture: i586
	<machine, os, target, libraries (multiple lines)>
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux

>Description:
gcc 3 __builtin_constant_p fails to recognise "ptr==ptr" as a
constant, whereas gcc 2.95.x did.

>How-To-Repeat:
A program foo.c

        int
        main (int argc, char **argv)
        {
          printf ("%d\n", __builtin_constant_p (argv == argv));
          return 0;
        }

compiled with

        gcc-3.0 -O9 foo.c

prints "0" whereas I might have hoped it could print "1" since
argv==argv can certainly be known at compile time.

Curiously, using "argc" instead of "argv" gives the hoped-for "1".
Also a gcc 2.95.4 pre-release gives "1" in both cases.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: