[Bug bootstrap/20493] New: [4.0 Regression] Bootstrap failure

[Bug bootstrap/20493] New: [4.0 Regression] Bootstrap failure

[danglin at gcc dot gnu dot org]

stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/gcc/gcc-4.1.0/hppa-linux/bin/ -c   -g
 -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototype
s -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -
fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -Ibuild -I../../gcc/gcc -I.
./../gcc/gcc/build -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
 \
 -o build/errors.o ../../gcc/gcc/errors.c
stage1/xgcc -Bstage1/ -B/home/dave/opt/gnu/gcc/gcc-4.1.0/hppa-linux/bin/   -g -O
2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -
pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno
-common   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/genmodes \
 build/genmodes.o build/errors.o ../build-hppa-linux/libiberty/libiberty.a
build/genmodes -h > tmp-modes.h
make[2]: *** [s-modes] Error 139

(gdb) r -h > tmp-modes.h
Starting program: /home/dave/gnu/gcc-4.0/objdir/gcc/build/genmodes -h > tmp-
modes.h

Program received signal SIGSEGV, Segmentation fault.
0x00013c68 in __canonicalize_funcptr_for_compare (fptr=@0xffffffff: 0)
    at fptr.c:61
61      {
(gdb) disass __canonicalize_funcptr_for_compare
Dump of assembler code for function __canonicalize_funcptr_for_compare:
0x00013c64 <__canonicalize_funcptr_for_compare+0>:      stw rp,-14(,sp)
0x00013c68 <__canonicalize_funcptr_for_compare+4>:      stw,ma r6,80(,sp)
0x00013c6c <__canonicalize_funcptr_for_compare+8>:      ldi 0,r6
0x00013c70 <__canonicalize_funcptr_for_compare+12>:     stw r5,-7c(,sp)
0x00013c74 <__canonicalize_funcptr_for_compare+16>:     stw r4,-78(,sp)
0x00013c78 <__canonicalize_funcptr_for_compare+20>:     copy r19,r4
0x00013c7c <__canonicalize_funcptr_for_compare+24>:     stw r3,-74(,sp)
0x00013c80 <__canonicalize_funcptr_for_compare+28>:     copy r26,r3
0x00013c84 <__canonicalize_funcptr_for_compare+32>:     b,l 0x13c64 <
__canonicalize_funcptr_for_compare>,rp
0x00013c88 <__canonicalize_funcptr_for_compare+36>:     stw r19,-20(,sp)
0x00013c8c <__canonicalize_funcptr_for_compare+40>:     copy r4,r19
0x00013c90 <__canonicalize_funcptr_for_compare+44>:     copy ret0,r5
0x00013c94 <__canonicalize_funcptr_for_compare+48>:     b,l 0x13c64 <
__canonicalize_funcptr_for_compare>,rp
0x00013c98 <__canonicalize_funcptr_for_compare+52>:     ldi -1,r26

The function is miscompiled completely.  It calls itself recursively
until stack allocation fails.

-- 
           Summary: [4.0 Regression] Bootstrap failure
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: bootstrap
        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=20493

[Bug middle-end/20493] [4.0 Regression] Bootstrap failure

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-16 06:26 -------
The following code is another example:
typedef int (*fptr_t) (void);

int __canonicalize_funcptr_for_compare (fptr_t t)
{
  return (int)(t) == -1;
}

Hmm, I have not traced it yet but maybe we should not call __canonicalize_funcptr_for_compare when 
we are comparing against constants.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |middle-end
           Keywords|                            |build


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

[Bug middle-end/20493] [4.0 Regression] Bootstrap failure

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-16 06:42 -------
Created an attachment (id=8400)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8400&action=view)
patch which might fix this

This patch might fix the problem.  Basically we should not do canonicalizing if
one side is an integer constant.  Could you test this for me since I don't have
access to hppa-linux-gnu at all (or any other hppa machine)?

Also does the 4.0 branch fail or just the mainline?
I want to say both since this was introduced with the patch to fix PR 17564.

Oh, in the following code should we be doing the canonicalizing:
typedef int (*fptr_t) (void);
int f (fptr_t t)
{
  return t == (fptr_t)-1;
}

Because after this patch we don't, I don't know if this is the correct thing to
do or not, I want to say yes but you should know better.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED


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

[Bug middle-end/20493] [4.0 Regression] Bootstrap failure

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


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

[Bug middle-end/20493] [4.0 Regression] Bootstrap failure

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2005-03-16 14:34 -------
Subject: Re:  [4.0 Regression] Bootstrap failure

> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-16 06:26 -------
> The following code is another example:
> typedef int (*fptr_t) (void);
> 
> int __canonicalize_funcptr_for_compare (fptr_t t)
> {
>   return (int)(t) == -1;
> }
> 
> Hmm, I have not traced it yet but maybe we should not call __canonicalize_funcptr_for_compare when 
> we are comparing against constants.

Well certainly when the function pointer has been cast to an int.
In PR middle-end/17564, we changed do_compare_and_jump to only
canonicalize function pointers in a comparison if both sides are
function pointers.

Dave


-- 


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

[Bug middle-end/20493] [4.0 Regression] Bootstrap failure

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2005-03-16 14:43 -------
Subject: Re:  [4.0 Regression] Bootstrap failure

> This patch might fix the problem.  Basically we should not do canonicalizing if
> one side is an integer constant.  Could you test this for me since I don't have
> access to hppa-linux-gnu at all (or any other hppa machine)?

I'll try it tonight.

> Also does the 4.0 branch fail or just the mainline?

I believe both.  I noticed it first in a 4.0.0.

> Oh, in the following code should we be doing the canonicalizing:
> typedef int (*fptr_t) (void);
> int f (fptr_t t)
> {
>   return t == (fptr_t)-1;
> }
> 
> Because after this patch we don't, I don't know if this is the correct thing to
> do or not, I want to say yes but you should know better.

I would say that the above should cause canonicalization.

The treatment of special pointers is poorly defined.  I had to treat -1
and pointers to low memory (~ page 0) as special.  They are used by the
signal handler.  The same problem occurs on the 32-bit hpux port.

Dave


-- 


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

[Bug middle-end/20493] [4.0 Regression] Bootstrap failure

[danglin at gcc dot gnu dot org]

------- Additional Comments From danglin at gcc dot gnu dot org  2005-03-17 03:13 -------
Breakpoint 1, do_compare_and_jump (exp=0x400de208, signed_code=EQ,
    unsigned_code=EQ, if_false_label=0x40166ca8, if_true_label=0x0)
    at ../../gcc/gcc/dojump.c:930
930       if (HAVE_canonicalize_funcptr_for_compare
(gdb) p debug_tree (exp)
 <eq_expr 0x400de208
    type <boolean_type 0x400dc620 _Bool public unsigned QI
        size <integer_cst 0x400d30f0 constant invariant 8>
        unit size <integer_cst 0x400d3108 constant invariant 1>
        align 8 symtab 0 alias set -1 precision 1 min <integer_cst 0x400d34e0 0> 
max <integer_cst 0x400d3510 1>>

    arg 0 <parm_decl 0x40146e00 fptr
        type <pointer_type 0x401467e0 fptr_t type <function_type 0x400e9540>
            unsigned SI
            size <integer_cst 0x400d32e8 constant invariant 32>
            unit size <integer_cst 0x400d3078 constant invariant 4>
            align 32 symtab 0 alias set -1>
        used unsigned SI file fptr.c line 60 size <integer_cst 0x400d32e8 32> 
unit size <integer_cst 0x400d3078 4>
        align 32 context <function_decl 0x40146d90 
__canonicalize_funcptr_for_compare> result <pointer_type 0x401467e0 fptr_t> 
initial <pointer_type 0x401467e0 fptr_t>
        (reg/v/f:SI 124 [ fptr ]) arg-type <pointer_type 0x401467e0 fptr_t> arg-
type-as-written <pointer_type 0x401467e0 fptr_t>
        incoming-rtl (reg:SI 26 %r26 [ fptr ])>
    arg 1 <integer_cst 0x4014b180 type <pointer_type 0x401467e0 fptr_t> constant 
invariant 4294967295>>
$1 = void
(gdb)

Your patch may fix the problem.  However, I'm concerned that I don't
see any indication in the tree that the int cast has been respected.
Rather, it looks as if -1 has been converted to a pointer type.

Possibly, Roger should look at this as I think it was his patch on
the 13th that introduced/exposed the problem.

2005-03-13  Roger Sayle  <roger@eyesopen.com>

        PR middle-end/19331
        * tree.c (get_unwidened): Treat CONVERT_EXPR and NOP_EXPR identically.
        * fold-const.c (fold_sign_changed_comparison): Likewise.
        (fold_binary): Optimize comparisons against widened operands if
        the extension is represented by a CONVERT_EXPR, same as a NOP_EXPR.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at eyesopen dot com


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|2005-03-16 06:43:10         |2005-03-17 05:01:59
               date|                            |
            Summary|[4.0 Regression] Bootstrap  |[4.0/4.1 Regression]
                   |failure                     |Bootstrap failure because of
                   |                            |aliased symbols
   Target Milestone|---                         |4.1.0


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[roger at eyesopen dot com]

------- Additional Comments From roger at eyesopen dot com  2005-03-17 05:06 -------
Hmm, yep, probably caused by my change.

It looks like with my change fold_widened_comparison is now converting
(int)t == -1 into the equivalent t == (typeof(t))-1.  Normally, this
would be reasonable but the "special" semantics of
HAVE_canonical_funcptr_for_compare clearly screw this up.

My suggestion would be to add the following to the top of the subroutine
fold_widened_comparison:

#ifdef HAVE_canonicalize_funcptr_for_compare
  /* Disable this optimization if we're casting to a function pointer
     type on targets that require function pointer canonicalization.  */
  if (HAVE_canonicalize_funcptr_for_compare
      && TREE_CODE (shorter_type) == POINTER_TYPE
      && TREE_CODE (TREE_TYPE (shorter_type)) == FUNCTION_TYPE)
    return NULL_TREE;
#endif

Dave, could you give this a try and see if it restores bootstrap for you?


-- 


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2005-03-18 02:33 -------
Subject: Re:  [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

> Hmm, yep, probably caused by my change.

Confirmed.

> It looks like with my change fold_widened_comparison is now converting
> (int)t == -1 into the equivalent t == (typeof(t))-1.  Normally, this
> would be reasonable but the "special" semantics of
> HAVE_canonical_funcptr_for_compare clearly screw this up.

The bootstrap still fails with your suggestion.  fold_widened_comparison
returns here:

  if (arg0_unw == arg0)
    return NULL_TREE;

as the function pointer is not being widen by the int cast of the
function pointer.

It seems that it's the change to tree.c that causing the problem.
However, there might still be a problem with fold_widened_comparison
if the cast had been to long long.

Dave


-- 


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2005-03-18 03:26 -------
Subject: Re:  [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

> The bootstrap still fails with your suggestion.  fold_widened_comparison
> returns here:
> 
>   if (arg0_unw == arg0)
>     return NULL_TREE;
> 
> as the function pointer is not being widen by the int cast of the
> function pointer.

We actually lose the CONVERT_EXPR in the call to fold_sign_changed_comparison
(fold-const.c:9166).  Previously, we didn't.  However, I'm not sure why.

Dave


-- 


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-19 16:46 -------
Subject: Bug 20493

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	danglin@gcc.gnu.org	2005-03-19 16:46:04

Modified files:
	gcc            : ChangeLog fold-const.c 

Log message:
	PR middle-end/20493
	* fold-const.c (fold_widened_comparison): Don't optimize casts of
	function pointers on targets that require function pointer
	canonicalization.
	(fold_sign_changed_comparison): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7910&r2=2.7911
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.543&r2=1.544



-- 


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-03-19 17:30 -------
Subject: Bug 20493

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	danglin@gcc.gnu.org	2005-03-19 17:29:54

Modified files:
	gcc            : ChangeLog fold-const.c 

Log message:
	PR middle-end/20493
	* fold-const.c (fold_widened_comparison): Don't optimize casts of
	function pointers on targets that require function pointer
	canonicalization.
	(fold_sign_changed_comparison): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.63&r2=2.7592.2.64
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.517.2.2&r2=1.517.2.3



-- 


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[danglin at gcc dot gnu dot org]

------- Additional Comments From danglin at gcc dot gnu dot org  2005-03-19 17:38 -------
Fixed in CVS.


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


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

[Bug middle-end/20493] [4.0/4.1 Regression] Bootstrap failure because of aliased symbols

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.0                       |4.0.0


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