[BUG/PATCH 2.95.3] [V3 also] rs6000.c tests TREE_ASM_WRITTEN too early.

["Dave Korn" <davek-ml at ntlworld dot com>]

      Hi everyone,

[ Mike and David: this explains the problem you two were discussing back
in July in http://gcc.gnu.org/ml/gcc/2000-07/msg00148.html ]

  The rs6000 backend uses SYMBOL_REF_FLAG to indicate to callers that a
function exists in the current compilation unit, with the implication that
it can be reached by a short branch. Look at this code from rs6000.c which
implements the setting of the flag (similar exists in rs6000.h, but
sysv4.h overrides that with this definition for Svr4 ABI/EABI-based
targets).
------
/* If we are referencing a function that is static or is known to be
   in this file, make the SYMBOL_REF special.  We can use this to indicate
   that we can branch to this function without emitting a no-op after the
   call.  For real AIX and NT calling sequences, we also replace the
   function name with the real name (1 or 2 leading .'s), rather than
   the function descriptor name.  This saves a lot of overriding code
   to read the prefixes.  */

void
rs6000_encode_section_info (decl)
     tree decl;
{
  if (TREE_CODE (decl) == FUNCTION_DECL)
    {
      rtx sym_ref = XEXP (DECL_RTL (decl), 0);
      if ((TREE_ASM_WRITTEN (decl) || ! TREE_PUBLIC (decl))
          && !DECL_WEAK (decl))
 SYMBOL_REF_FLAG (sym_ref) = 1;
------
  Now, ENCODE_SECTION_INFO (the target macro that this points to) is
called from make_function_rtl in varasm.c, which is called from
start_function in c-decl.c, which is called by the parser when it
encounters a function. The logic it uses is that static functions can be
assumed to be within the current compilation unit, and global functions
that we have already output earlier in the file are also local. But
TREE_ASM_WRITTEN isn't set when the parser finds the function; it gets set
in toplev.c much later on. So the test fails to set SYMBOL_REF_FLAG for
globally visible functions when they are encountered. This means that
current_file_function_operand (in rs6000.c) returns zero when it should be
returning one.

  I decided that the best fix for this problem is to remove the
TREE_ASM_WRITTEN test altogether. Instead, I think it's safe to assume
that if we are in output_prolog, the current_function_decl is probably a
function in the current file, so we set the SYMBOL_REF_FLAG there. This is
in plenty of time for the information to be used when compiling branches
from functions later in the compilation unit. I have tested this solution
and confirmed (by printf debugging) that current_file_function_operand
returned zero for a global function in a test file without this fix and
returns 1 with it, and that it didn't alter the value returned for
globally visible symbol references that weren't in the same compilation
unit.

   Test results:  Here's my baseline test results for powerpc-wrs-vxworks.
This is based on the CVS 2.95 branch without alterations. (Note also that
I had to limit the memory on the target board to 16M. Without doing so
there would be 100% execution failures).  The baseline was a couple of
days ago.

  === gcc tests ===

# of expected passes  7759
# of unexpected failures 251
# of unexpected successes 1
# of expected failures  30
# of unresolved testcases 14
# of unsupported tests  27
/home/dkadmin/gcc/build/cvs.orig/gcc/xgcc version 2.95.3 20001220
(prerelease)

  === g++ Summary ===

# of expected passes  3416
# of unexpected failures 999
# of expected failures  807
# of untested testcases  17

  I haven't looked into all the failures yet, although I noticed that all
but one of the varargs tests failed. Most of the g++ failures were caused
by the absence of libstdc++.a; none of the target libs build for vxworks,
but their functionality is in the OS anyway. I did try providing a dummy
libstdc++.a; that changed the most of the XFAILs into UNRESOLVEDs. For
some reason the compiler started outputting the files with '.exe'
extensions (I'm running cygwin) and so the download process couldn't find
them. I haven't investigated further yet. However it did fix 666 (!) of
the FAILs.

  The SYMBOL_REF_FLAG bug also exists in V3, but I'm not up and running
with that yet, so I haven't supplied patches or test results. I'm just
mentioning it.

  I also noticed that some of the gcc.c-torture/memcheck tests were
failing because they contained a global variable the name of which clashes
with (and overrides) the vxworks command shell function that is used to
spawn tasks, so I changed it.  I've attached that patch as well.

  Here are my test results with both patches applied.

                === gcc Summary ===

# of expected passes            7767
# of unexpected failures        242
# of unexpected successes       1
# of expected failures          30
# of unresolved testcases       15
# of unsupported tests          27

  9 cases were fixed by the changes to memcheck testcases, which I did
live while the testsuite was in the middle of running them! Sorry if
that's a bit naughty.

  1 case failed due to a seg violation in the download process - this is
probably the typical cygwin - signal 11 thing.

Executing on host:
/home/dkadmin/gcc/build/cvs4/gcc/xgcc -B/home/dkadmin/gcc/build/cvs4/gcc/
/gccdev/gcc/gcc/testsuite/gcc.c-torture/execute/920710-1.c
/home/dkadmin/gcc/build/cvs4/gcc/testsuite/testglue.o  -w  -Os   -mstrict-
align -DCPU=PPC603  -nostdlib -r  -Wl,-wrap,exit -Wl,-wrap,main -Wl,-wrap,
abort    -o /home/dkadmin/gcc/build/cvs4/gcc/testsuite/920710-1.x5
(timeout = 300)
spawn
/home/dkadmin/gcc/build/cvs4/gcc/xgcc -B/home/dkadmin/gcc/build/cvs4/gcc/
/gccdev/gcc/gcc/testsuite/gcc.c-torture/execute/920710-1.c
/home/dkadmin/gcc/build/cvs4/gcc/testsuite/testglue.o -w -Os -mstrict-alig
n -DCPU=PPC603 -nostdlib -r -Wl,-wrap,exit -Wl,-wrap,main -Wl,-wrap,abort
-o /home/dkadmin/gcc/build/cvs4/gcc/testsuite/920710-1.x5
PASS: gcc.c-torture/execute/920710-1.c compilation,  -Os
ERROR: remote_download to build of
/home/dkadmin/gcc/build/cvs4/gcc/testsuite/920710-1.x5 to
/download//920710-1.x5: child killed: segmentation violation

-> ld < /download//920710-1.x5
Error: File D:\download\920710-1.x5 does not exist
can't open input '/download//920710-1.x5'
  errno = 0x226
-> ERROR: Can't access /download//920710-1.x5.
ld < /download//920710-1.x5
Error: File D:\download\920710-1.x5 does not exist
can't open input '/download//920710-1.x5'
  errno = 0x226
-> UNRESOLVED: gcc.c-torture/execute/920710-1.c execution,  -Os

                === g++ Summary ===

# of expected passes            4082
# of unexpected failures        333
# of unexpected successes       2
# of expected failures          178
# of unresolved testcases       627
# of untested testcases         17

  The main change here is that adding the dummy libstdc++.a shunted a lot
of XFAILs into UNRESOLVEDs owing to the '.exe' file extension I mentioned
earlier, so I re-ran the baseline g++ tests. Here are the results:

                === g++ Summary ===

# of expected passes            4082
# of unexpected failures        333
# of unexpected successes       2
# of expected failures          178
# of unresolved testcases       627
# of untested testcases         17

  So, no regressions.

  Here's a ChangeLog entry for the symbol ref flag patch:

        * rs6000.c (rs6000_encode_section_info): Removed premature test of
        TREE_ASM_WRITTEN.
        (output_prolog): Set SYMBOL_REF_FLAG to indicate function exists
        in current compilation unit for current_file_function_operand.
        * rs6000.h (ENCODE_SECTION_INFO): Removed premature test of
        TREE_ASM_WRITTEN.

  And here's one for the testcases

        * gcc.c-torture/execute/memcheck/t4.c: Rename global struct 'sp'
        to 'sp2' to avoid nameclash in vxworks OS.
        * gcc.c-torture/execute/memcheck/t5.c: Likewise.
        * gcc.c-torture/execute/memcheck/t6.c: Likewise.
        * gcc.c-torture/execute/memcheck/t7.c: Likewise.


    Happy $religious_festival,
        DaveK
--
> If you do not cease your spamming activities, I will drop a large
   nuclear weapon on your servers.
> Si usted no cesa en sus actividades de spam, caerá una gran arma nuclear
   en sus servidores
       -- from Learn to speak Spanish with teleline.es!

diff-symrefflag.patch

diff-testcases.patch