home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sgi / 12885 < prev    next >
Encoding:
Text File  |  1992-08-25  |  3.2 KB  |  93 lines
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!mips!odin!bananapc.csd.sgi.com!ciemo
  2. From: ciemo@bananapc.csd.sgi.com (Dave Ciemiewicz)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Optimization problem with 3.1 compilers
  5. Message-ID: <1992Aug26.024734.2951@odin.corp.sgi.com>
  6. Date: 26 Aug 92 02:47:34 GMT
  7. References: <1992Aug19.000616.8590@leland.Stanford.EDU> <1992Aug25.183256.3342@odin.corp.sgi.com>
  8. Sender: news@odin.corp.sgi.com (Net News)
  9. Organization: Silicon Graphics, Customer Support Division
  10. Lines: 80
  11. Nntp-Posting-Host: bananapc.csd.sgi.com
  12.  
  13. In article <1992Aug25.183256.3342@odin.corp.sgi.com>, ciemo@bananapc.csd.sgi.com (Dave Ciemiewicz) writes:
  14. |> In article <1992Aug19.000616.8590@leland.Stanford.EDU>, dhinds@leland.Stanford.EDU (David Hinds) writes:
  15. |> |> I have a program that compiles and executes reliably with the MIPS 2.1
  16. |> |> compilers under Irix 4.0.1, but core dumps with a segmentation violation
  17. |> |> when a particular function is compiled at -O2 or above with the 3.1
  18. |> |> compilers and Irix 4.0.5A.   Here is a short example with the problem:
  19. |> |> 
  20. |> |> > #include <stdio.h>
  21. |> |> > #define MAXP 12
  22. |> |> > 
  23. |> |> > void main(void)
  24. |> |> >   {
  25. |> |> >   int *i, *j, step[MAXP+1], k;
  26. |> |> >   double sum;
  27. |> |> >   float all2[MAXP+1];
  28. |> |> >
  29. |> |> >   for (k = 0; k < MAXP+1; k++) {
  30. |> |> >     step[k] = k; all2[k] = 2.0;
  31. |> |> >     }
  32. |> |> >
  33. |> |> >   sum = 0.0; k = 2;
  34. |> |> >   for (i = &step[2]; i <= &step[MAXP]; i++, k++) {
  35. |> |> >     printf("k = %d\n", k);
  36. |> |> >     for (j = &step[1]; j != i; j++)
  37. |> |> >       sum += all2[*j] - 1;
  38. |> |> >     }
  39. |> |> >   printf("Sum = %f\n", sum);
  40. |> |> >   }
  41. |> |> 
  42. |> |> When I compile this with 'cc -O2 bug.c' and run a.out, I get:
  43. |> |> 
  44. |> |> > k = 2
  45. |> |> > k = 3
  46. |> |> > k = 4
  47. |> |> > k = 5
  48. |> |> > k = 6
  49. |> |> > Segmentation fault (core dumped)
  50. |> |> 
  51. |> 
  52. |> I don't know if you got a response on this or not.  The problem is a bug
  53. |> in the 3.10 version of /usr/lib/uopt which incorrectly unrolls the inner
  54. |> loop "for (j = ...".  There is a bug submitted on this problem.
  55. |> 
  56. |> To work around this problem, turn off loop unrolling in uopt (see uopt(1)
  57. |> man page):
  58. |> 
  59. |>         cc -O2 -Wo,-loopunroll,0 bug.c -o bug.c
  60. |> 
  61.  
  62. I discovered another workaround which will allow the loopunrolling to occur.
  63. Change:
  64.  
  65.     for (j = &step[1]; j != i; j++)
  66.            sum += all2[*j] - 1;
  67.     }
  68.  
  69. to:
  70.  
  71.     for (j = &step[1]; j < i; j++)
  72.         sum += all2[*j] - 1;
  73.         }
  74.  
  75. The benefit of this change, beyond just working around the uopt bug, is that
  76. it changes the first for (loop) from being what the Power C analyzer considers
  77. to be a "while" loop into a form which is more like a tradition "for" loop.
  78. This allows the analyzer to do a better job of code restructuring.  Besides,
  79. the "j < i" test is more correct than the "j != i" test because you the first
  80. guarantees that the address is within the subrange of the array and the other
  81. just tests to see if j is not the i address.  Of course, all of this is should
  82. not be construed as an excuse for uopt not doing the right thing in the
  83. first place.
  84.  
  85.     
  86. -- 
  87.  
  88.     __   * __   _  __  ___            
  89.    /  \ / / /  / \/  \/   \     He was a man like any other man, however, not
  90.   /    /  \/  /  /\  /    /    quite like any other man.
  91.   \___/\__/\_/  /_/ / \__/    
  92.                *        
  93.