[Bug tree-optimization/47239] New: (int)&func & 3 is always optimized to 0 on some targets

[Bug tree-optimization/47239] New: (int)&func & 3 is always optimized to 0 on some targets

[kkojima at gcc dot gnu.org]

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

           Summary: (int)&func & 3 is always optimized to 0 on some
                    targets
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: kkojima@gcc.gnu.org


Targets like arm, hppa and sh64 use the lower bits of the address
of functions for special purposes.  Even on those targets,

----
extern void plabel32_function (void);

int
is_plabel32 (void)
{
  return ((unsigned long) &plabel32_function & 3);
}
----

which was the test case of PR 35705, is wrongly compiled with -O2.
It seems that tree-bit-ccp optimization evaluates the expression
((unsigned long) &plabel32_function & 3) to zero always.
With -fno-tree-bit-ccp, the result looks OK.  For example, arm-eabi
compiler outputs

    mov    r0, #0
    bx    lr

with -O2 and

    ldr    r0, .L2
    and    r0, r0, #3
    bx    lr
.L3:
    .align    2
.L2:
    .word    plabel32_function

with -O2 -fno-tree-bit-ccp.  I've got similar results for hppa and sh64
compilers.

[Bug tree-optimization/47239] [4.6 Regression] (int)&func & 3 is always optimized to 0 on some targets

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.01.11 12:53:34
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.6.0
            Summary|(int)&func & 3 is always    |[4.6 Regression] (int)&func
                   |optimized to 0 on some      |& 3 is always optimized to
                   |targets                     |0 on some targets
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 12:53:34 UTC ---
Confirmed, mine.  The fix for PR35705 only extracts alignment information
from function decls for the single case &fn & 1.  That's odd.  I'm going
to simply punt for function-decls for now.

[Bug tree-optimization/47239] [4.6 Regression] (int)&func & 3 is always optimized to 0 on some targets

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 14:23:23 UTC ---
Author: rguenth
Date: Tue Jan 11 14:23:20 2011
New Revision: 168661

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

    PR tree-optimization/47239
    * tree-ssa-ccp.c (get_value_from_alignment): Punt for FUNCTION_DECLs.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-ccp.c

[Bug tree-optimization/47239] [4.6 Regression] (int)&func & 3 is always optimized to 0 on some targets

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2011-01-11 23:14:45 UTC ---
I've tried 168661 with arm, hppa and sh64 cc1's. The problem
has gone away on all these 3 targets.  Thanks!

[Bug tree-optimization/47239] [4.6 Regression] (int)&func & 3 is always optimized to 0 on some targets

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-12 12:10:05 UTC ---
Fixed.