[Bug middle-end/53647] New: [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[Bug middle-end/53647] New: [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[hjl.tools at gmail dot com]

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

             Bug #: 53647
           Summary: [4.8 Regression] gcc.c-torture/compile/20011229-1.c
                    and gcc.c-torture/compile/pr25311.c
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com
                CC: wschmidt@linux.vnet.ibm.com


On Linux/x86, revision 188457 gave

FAIL: gcc.c-torture/compile/20011229-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr25311.c  -Os  (internal compiler error)

Revision 188451 is OK.

[Bug middle-end/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wschmidt at gcc dot gnu.org

--- Comment #1 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-12 17:27:18 UTC ---
Can you please post the symptom of the ICE?  These errors don't occur on ppc so
will be some work for me to replicate.

[Bug middle-end/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2012-06-12 17:45:40 UTC ---
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -fno-diagnostics-show-caret
-Os -w -c -o pr25311.o
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/compile/pr25311.c
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/compile/pr25311.c: In
function ‘set_size’:
/export/gnu/import/git/gcc/gcc/testsuite/gcc.c-torture/compile/pr25311.c:16:1:
internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

Program received signal SIGFPE, Arithmetic exception.
0x0000000000cdefb5 in hoist_adjacent_loads (bb0=0x7ffff1326d90, 
    bb1=0x7ffff1326e00, bb2=0x7ffff1326e70, bb3=0x7ffff1326ee0)
    at /export/gnu/import/git/gcc/gcc/tree-ssa-phiopt.c:1941
1941          align1 = DECL_ALIGN (field1) % param_align_bits;
(gdb) p param_align_bits
$1 = 0
(gdb)

[Bug middle-end/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ubizjak at gmail dot com

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2012-06-12 17:56:04 UTC ---
i386.c has

  maybe_set_param_value (PARAM_L1_CACHE_LINE_SIZE, ix86_cost->prefetch_block,
                         global_options.x_param_values,
                         global_options_set.x_param_values);

But some costs have

  0,                                    /* size of l1 cache  */
  0,                                    /* size of l2 cache  */
  0,                                    /* size of prefetch block */
  0,                                    /* number of parallel prefetches */

and we get param_align == 0:

+  int param_align = PARAM_VALUE (PARAM_L1_CACHE_LINE_SIZE);
+  unsigned param_align_bits = (unsigned) (param_align * BITS_PER_UNIT);
+  gimple_stmt_iterator gsi;

[Bug target/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

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

--- Comment #4 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-12 19:05:55 UTC ---
So, appears to be a target issue.  The only other use of L1_CACHE_SIZE in the
top-level gcc directory is in tree-ssa-loop-prefetch.c, where 0 is apparently
undetected but causes prefetching to be quietly disabled.  Specifying 0 doesn't
appear to be intentionally valid.

[Bug target/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-12 19:09:48 UTC ---
If this is incorrect, and zero is supposed to indicate a cacheless memory (do
they exist anymore?), then I can disable the adjacent-loads hoisting
optimization for that case.  Someone know the answer for this?

[Bug target/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> 2012-06-12 19:26:12 UTC ---
We should update i386.c to have reasonable values for
size of l1 cache, size of l2 cache, size of prefetch block
and number of parallel prefetches, instead of 0s.

[Bug target/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2012-06-12 19:40:21 UTC ---
Perhaps simply:

--cut here--
Index: tree-ssa-phiopt.c
===================================================================
--- tree-ssa-phiopt.c   (revision 188475)
+++ tree-ssa-phiopt.c   (working copy)
@@ -1830,6 +1830,11 @@
   unsigned param_align_bits = (unsigned) (param_align * BITS_PER_UNIT);
   gimple_stmt_iterator gsi;

+  /* We assume that transformation is not profitable
+     on targets without cache.  */
+  if (param_align_bits == 0)
+    return;
+
   /* Walk the phis in bb3 looking for an opportunity.  We are looking
      for phis of two SSA names, one each of which is defined in bb1 and
      bb2.  */
--cut here--

[Bug target/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Uros Bizjak <ubizjak at gmail dot com> 2012-06-12 19:45:56 UTC ---
Alternative patch with the same functionality:

--cut here--
Index: tree-ssa-phiopt.c
===================================================================
--- tree-ssa-phiopt.c   (revision 188475)
+++ tree-ssa-phiopt.c   (working copy)
@@ -1976,12 +1976,14 @@
 /* Determine whether we should attempt to hoist adjacent loads out of
    diamond patterns in pass_phiopt.  Always hoist loads if
    -fhoist-adjacent-loads is specified and the target machine has
-   a conditional move instruction.  */
+   defined cache line size and a conditional move instruction.  */

 static bool
 gate_hoist_loads (void)
 {
-  return (flag_hoist_adjacent_loads == 1 && HAVE_conditional_move);
+  return (flag_hoist_adjacent_loads == 1
+         && PARAM_VALUE (PARAM_L1_CACHE_LINE_SIZE)
+         && HAVE_conditional_move);
 }

 /* Always do these optimizations if we have SSA
--cut here--

--- Comment #9 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-12 19:46:30 UTC ---
Yes, that can be done, but the question is whether it is correct, or just
hiding the issue.  Do the processors really not have cache?  Or was this just
an error not filling in the values?  I don't want to hide a real problem if
that's the situation.  Waiting for someone to clarify the intent behind these
processor descriptions.

There's nothing in the documentation of the parameter to suggest zero is a
magic number for no cache, but nothing to suggest otherwise, either.

[Bug target/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[ubizjak at gmail dot com]

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

--- Comment #8 from Uros Bizjak <ubizjak at gmail dot com> 2012-06-12 19:45:56 UTC ---
Alternative patch with the same functionality:

--cut here--
Index: tree-ssa-phiopt.c
===================================================================
--- tree-ssa-phiopt.c   (revision 188475)
+++ tree-ssa-phiopt.c   (working copy)
@@ -1976,12 +1976,14 @@
 /* Determine whether we should attempt to hoist adjacent loads out of
    diamond patterns in pass_phiopt.  Always hoist loads if
    -fhoist-adjacent-loads is specified and the target machine has
-   a conditional move instruction.  */
+   defined cache line size and a conditional move instruction.  */

 static bool
 gate_hoist_loads (void)
 {
-  return (flag_hoist_adjacent_loads == 1 && HAVE_conditional_move);
+  return (flag_hoist_adjacent_loads == 1
+         && PARAM_VALUE (PARAM_L1_CACHE_LINE_SIZE)
+         && HAVE_conditional_move);
 }

 /* Always do these optimizations if we have SSA
--cut here--

[Bug tree-optimization/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-06-12
          Component|target                      |tree-optimization
         AssignedTo|unassigned at gcc dot       |wschmidt at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #10 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-12 20:30:46 UTC ---
OK, after looking at these machine descriptions I think we will have to
tolerate a line size of 0.  They appear to be for the ancient 386 chips that
didn't have onboard cache, and sometimes no offboard cache.  So I'll go ahead
and make the fix.

[Bug tree-optimization/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-13 12:34:02 UTC ---
Author: wschmidt
Date: Wed Jun 13 12:33:55 2012
New Revision: 188509

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188509
Log:
2012-06-13  Bill Schmidt  <wschmidt@linux.ibm.com>

    PR tree-optimization/53647
    * tree-ssa-phiopt.c (gate_hoist_loads): Skip transformation for
    targets with no defined cache line size.

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

[Bug tree-optimization/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

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

--- Comment #12 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-13 12:40:20 UTC ---
Fixed.

[Bug tree-optimization/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[hjl at gcc dot gnu.org]

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

--- Comment #13 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2012-06-13 17:47:11 UTC ---
Author: hjl
Date: Wed Jun 13 17:46:59 2012
New Revision: 188523

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188523
Log:
Set cache values from -mtune

    PR target/53647
    * config/i386/i386.c (ix86_tune_cost): New variable.
    (ix86_option_override_internal): Set ix86_tune_cost.  Use
    ix86_tune_cost for simultaneous_prefetches, prefetch_block,
    l1_cache_size and l2_cache_size.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

[Bug tree-optimization/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0