[Bug c/17564] New: [4.0 Regression] New treatment of function pointers when used with equality operators

[Bug c/17564] New: [4.0 Regression] New treatment of function pointers when used with equality operators

[danglin at gcc dot gnu dot org]

As a GCC extension, GCC allows the comparison of a function pointer and
a void pointer.  Previous versions of GCC didn't canonicalize the function
pointer when it was compared with a void pointer.  Unfortunately, there
doesn't appear to be any documentation on when canonicalization is
performed.

Now GCC canonicalizes the function pointer when compared with a void
pointer.  It even does so when the function pointer is cast to a void
pointer.  The following program demonstrates the problem:

void *f (void) __attribute__ ((__noinline__));
void *
f (void)
{
  return f;
}
int
main (void)
{
  if (f () != f)
    abort ();
  exit (0);
}

000105b4 <main>:
   105b4:       6b c2 3f d9     stw rp,-14(,sp)
   105b8:       e8 5f 1f d5     b,l 105a8 <f>,rp
   105bc:       6f c4 01 00     stw,ma r4,80(,sp)
   105c0:       08 1c 02 44     copy ret0,r4
   105c4:       23 88 10 00     ldil 10800,ret0
   105c8:       e8 40 00 60     b,l 10600 <__canonicalize_funcptr_for_compare>,r
p
   105cc:       4b 9a 02 b0     ldw 158(,ret0),r26
   105d0:       80 9c 20 0a     cmpb,=,n ret0,r4,105dc <main+0x28>
   105d4:       e8 5f 1d 5d     b,l 10488 <_end_init+0x24>,rp


The address of the function descriptor for f is passed to
__canonicalize_funcptr_for_compare for canonicalization whereas the pointer
passed back from f as a void pointer is not canonicalized.  The causes
the program to abort with the current 4.0 CVS source.

The change in function pointer canonicalization causes the testcase
for PR17377 to fail.

-- 
           Summary: [4.0 Regression] New treatment of function pointers when
                    used with equality operators
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug target/17564] [4.0 Regression] New treatment of function pointers when used with equality operators

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-19 23:22 -------
This is a target problem, not a generic C one.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target
           Keywords|                            |wrong-code
   Target Milestone|---                         |4.0.0


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

[Bug target/17564] [4.0 Regression] New treatment of function pointers when used with equality operators

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-09-19 23:34 -------
Subject: Re:  [4.0 Regression] New treatment of function poi

> This is a target problem, not a generic C one.

The problem was caused by a change to the generic C code, not to the
target.  The target provides a mechanism to canonicalize function
pointers when necessary (i.e., the canonicalize_funcptr_for_compare
pattern in pa.md).

Dave


-- 


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-20 00:16 -------
Then this is a middle-end issue as the C front-end is not where the problem is really.

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


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-09-23 02:34 -------
Subject: Re:  [4.0 Regression] New treatment of function

> Then this is a middle-end issue as the C front-end is not where the problem
> is really.

FWIW, this was instroduced in the tree-ssa merge.

Dave


-- 


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators

[tausq at debian dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tausq at debian dot org


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2004-11-27 00:53 -------
I'm going to guess that one solution is to canonicalize any function pointer 
any time it's cast to a void pointer.  (Or do you really, really want 
noncanonicalized pointers, which is likely to be harder?) 
 
This probably requires recognition at tree level that casts from function 
pointer to void pointer may be necessary (among other things). 
 
>From tree_ssa_useless_type_conversion_1 in tree_ssa.c: 
  /* If both types are pointers and the outer type is a (void *), then 
     the conversion is not necessary.  The opposite is not true since 
     that conversion would result in a loss of information if the 
     equivalence was used.  Consider an indirect function call where 
     we need to know the exact type of the function to correctly 
     implement the ABI.  */ 
  else if (POINTER_TYPE_P (inner_type) 
           && POINTER_TYPE_P (outer_type) 
           && TYPE_MODE (inner_type) == TYPE_MODE (outer_type) 
           && TYPE_REF_CAN_ALIAS_ALL (inner_type) 
              == TYPE_REF_CAN_ALIAS_ALL (outer_type) 
           && TREE_CODE (TREE_TYPE (outer_type)) == VOID_TYPE) 
    return true; 
 
So it seems that this type conversion isn't useless when converting from 
a function pointer to a void pointer (on targets where function pointers need 
canonicalization); it requires a canonicalization.  (Or a forcing of 
non-canonicalization, which sounds harder.) 
 
Confirming. 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-11-27 00:53:19
               date|                            |
            Summary|[4.0 Regression] New        |[4.0 Regression] New
                   |treatment of function       |treatment of function
                   |pointers when used with     |pointers when used with
                   |equality operators          |equality operators, when
                   |                            |casts are involved


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-11-27 04:09 -------
Subject: Re:  [4.0 Regression] New treatment of function

> ------- Additional Comments From neroden at gcc dot gnu dot org  2004-11-27
> 00:53 -------
> I'm going to guess that one solution is to canonicalize any function pointer
> 
> any time it's cast to a void pointer.  (Or do you really, really want 
> noncanonicalized pointers, which is likely to be harder?) 

I believe we really want noncanonicalized pointers.  For example, the
following code works in 3.4 (i.e., a function pointer cast to void
pointer and back to a function pointer yields a function pointer that
can be used in a call to a compatible function):

void *f (void) __attribute__ ((__noinline__));
void *
f (void)
{
  return f;
}
int
main (void)
{
  void * (*g) (void) = f ();
  if (g () != f)
    abort ();
  exit (0);
}

If the call to f returned a canonicalized value, the call using g
would fail if the target was in a shared library (external).  The
PIC register wouldn't be correctly set.

Dave


-- 


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-11-28 23:16 -------
Subject: Re:  [4.0 Regression] New treatment of function

> Do you think we could canonicalize only when
> we compare a function pointer to a function pointer
> (rather than when comparing a function pointer to a void pointer)?  Would
> that
> do the trick, or would it lead to further trouble?

That seems correct to me.  Similarly, we wouldn't want canonicalization
when comparing a function pointer with an integer.

> Tentative, untested patch attached.

I'll give it a try.

Dave


-- 


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-11-30 03:42 -------
Subject: Re:  [4.0 Regression] New treatment of function

> Do you think we could canonicalize only when
> we compare a function pointer to a function pointer
> (rather than when comparing a function pointer to a void pointer)?  Would
> that
> do the trick, or would it lead to further trouble?
> 
> Tentative, untested patch attached.

This provides some improvement (i.e., it fixes the testsuite fail
that prompted the PR) but the testcase that I submitted with the PR
still fails.  I need to investigate why the function pointer in the
comparison is still getting canonicalized.

Dave


-- 


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-12-05 22:43 -------
Subject: Re:  [4.0 Regression] New treatment of function

Nathanael,

> Do you think we could canonicalize only when
> we compare a function pointer to a function pointer
> (rather than when comparing a function pointer to a void pointer)?  Would
> that
> do the trick, or would it lead to further trouble?
> 
> Tentative, untested patch attached.

I seem to have used a version of gcc without your patch when
I checked it with the PR testcase.  Would you please submit it
to gcc-patches as a fix for the PR?  The patch has a parenthesis
typo that needs fixing.

Dave


-- 


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-12 21:01 -------
Subject: Bug 17564

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	danglin@gcc.gnu.org	2004-12-12 21:01:17

Modified files:
	gcc            : ChangeLog dojump.c 

Log message:
	PR middle-end/17564
	* dojump.c (do_compare_and_jump): Only canonicalize function pointers
	in a comparison if both sides are function pointers.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6793&r2=2.6794
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dojump.c.diff?cvsroot=gcc&r1=1.33&r2=1.34



-- 


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[danglin at gcc dot gnu dot org]

------- Additional Comments From danglin at gcc dot gnu dot org  2004-12-12 21:19 -------
Fixed by patch.


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


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

[Bug middle-end/17564] [4.0 Regression] New treatment of function pointers when used with equality operators, when casts are involved

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-13 04:08 -------
Subject: Bug 17564

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	danglin@gcc.gnu.org	2004-12-13 04:08:40

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/execute: 20041212-1.c 

Log message:
	PR middle-end/17564
	* gcc.c-torture/execute/20041212-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4742&r2=1.4743
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20041212-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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