[Bug target/51251] New: SPARC _64 instructions in V7 executables

[Bug target/51251] New: SPARC _64 instructions in V7 executables

[joel at gcc dot gnu.org]

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

             Bug #: 51251
           Summary: SPARC _64 instructions in V7 executables
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: joel@gcc.gnu.org


Sun Nov 20 19:34:53 UTC 2011 (revision 181531)
But this has probably existed a long time.

Target: sparc-rtems4.11

I am testing gfortran on rtems and it appears that about 1/2 of the failures on
sparc are related to this.  

Some branches have  ",pn" and ",pl" attached and it is not supported.

  0x020012a4 <+36>:    ble,pn   %icc, 0x20013ec <foo_+364>
...
  0x020012f8 <+120>:    be,pn   %icc, 0x20013fc <foo_+380>

I checked sparc.c and there are some cases where the ",pX" are only generated
for sparc64 and others where they are not.

I don't expect this is hard to fix for a sparc maintainer. :)

[Bug target/51251] SPARC _64 instructions in V7 executables

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill <joel at gcc dot gnu.org> 2011-11-21 00:55:32 UTC ---
Command used to compile and link the test.


/home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../gfortran \
  -L /users/joel/test-gcc/install-svn/sparc-rtems4.11/lib/ \
  -B/home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../
-B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/
/users/joel/test-gcc/gcc-svn/gcc/testsuite/gfortran.dg/vect/vect-5.f90
gfortran_tg.o    -O  -O2 -ftree-vectorize -fno-vet-cost-model
-ftree-vectorizer-verbose=4 -fdump-tree-vect-stats -mcpu=ultrasparc -mvis 
-B/users/joel/test-gcc/install-svn/sparc-rtems4.11/sis/lib/ -specs bsp_specs
-qrtems -mcpu=cypress  /home2/joel/build/b-sparc-fortran/rtems_gcc_main.o 
-B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs
-L/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs 
-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm   -o
./vect-5.exe

Hmmm... because of the way the test is compiled and the target flags are added,
there is ... "-mcpu=ultrasparc -mvis" and then later on the command line
"-mcpu=cypress".  I wonder what that results in other than a mess.

I added -mno-vis after the -mcpu=cypress and that let the test compile and run.

Any ideas on how to deal with that?  Should -mcpu=cypress turn off vis?

[Bug target/51251] SPARC _64 instructions in V7 executables

[davem at davemloft dot net]

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

--- Comment #2 from David S. Miller <davem at davemloft dot net> 2011-11-21 05:05:02 UTC ---
I'll take a look at this.  The branch prediction tags are guarded by either
TARGET_V9 or TARGET_ARCH64, but not TARGET_VIS.

[Bug target/51251] SPARC _64 instructions in V7 executables

[davem at davemloft dot net]

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

--- Comment #3 from David S. Miller <davem at davemloft dot net> 2011-11-21 05:06:09 UTC ---
BTW, Joel, you might want to check out "-mdebug=options" :-)

[Bug target/51251] SPARC _64 instructions in V7 executables

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-11-21 08:07:29 UTC ---
(In reply to comment #1)
> Hmmm... because of the way the test is compiled and the target flags are added,
> there is ... "-mcpu=ultrasparc -mvis" and then later on the command line
> "-mcpu=cypress".


It gets added via  gcc/testsuite/lib/target-supports.exp's
check_vect_support_and_set_flags:

    } elseif [istarget sparc*-*-*] {
        lappend DEFAULT_VECTCFLAGS "-mcpu=ultrasparc" "-mvis"

Hence, it should also affect also C/C++'s vect/ tests ...

[Bug target/51251] SPARC _64 instructions in V7 executables

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-11-21
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-11-21 11:46:13 UTC ---
> Hmmm... because of the way the test is compiled and the target flags are added,
> there is ... "-mcpu=ultrasparc -mvis" and then later on the command line
> "-mcpu=cypress".  I wonder what that results in other than a mess.

Whoever automatically adds -mcpu=cypress without checking whether there isn't
already a -mcpu switch specified by the user is the culprit.

[Bug target/51251] SPARC _64 instructions in V7 executables

[joel at gcc dot gnu.org]

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

--- Comment #6 from Joel Sherrill <joel at gcc dot gnu.org> 2011-11-21 12:21:26 UTC ---
(In reply to comment #5)
> > Hmmm... because of the way the test is compiled and the target flags are added,
> > there is ... "-mcpu=ultrasparc -mvis" and then later on the command line
> > "-mcpu=cypress".  I wonder what that results in other than a mess.
> 
> Whoever automatically adds -mcpu=cypress without checking whether there isn't
> already a -mcpu switch specified by the user is the culprit.

The board in question is really a V7 and that is the proper cpu selection. It
is added by the test framework in a dejagnu board file.

We have seen this before on arm and powerpc targets. In those cases, the tests
or scripts had something added to them. Janice Johnson tinkered with the
testsuite to address a similar failure on PowerPC. I found this message in the
thread.

 http://lists.gnu.org/archive/html/dejagnu/2008-12/msg00012.html

The issue is that when running on real hardware, you can't use arbitrary cpu
flags and expect it to work.  And it is wrong to say xfail on sparc-rtems
because they could work on another board running rtems. Just not this one.

[Bug testsuite/51251] conflicting -mcpu switches during testing

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |testsuite
            Summary|SPARC _64 instructions in   |conflicting -mcpu switches
                   |V7 executables              |during testing

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-11-21 12:43:45 UTC ---
> The board in question is really a V7 and that is the proper cpu selection. It
> is added by the test framework in a dejagnu board file.

OK, but adding it like so is wrong.  Suppose that a SPARC-specific test checks
that some feature available only in V8 works; by adding -mcpu=cypress without
further ado, you'll most likely make the test fail.

Overriding compiler switches in tests is a no-no and...

> The issue is that when running on real hardware, you can't use arbitrary cpu
> flags and expect it to work.  And it is wrong to say xfail on sparc-rtems
> because they could work on another board running rtems. Just not this one.

...yes, that's why we have the dg-require-effective-target framework now.

[Bug testsuite/51251] conflicting -mcpu switches during testing

[joel at gcc dot gnu.org]

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

--- Comment #8 from Joel Sherrill <joel at gcc dot gnu.org> 2011-11-21 14:06:27 UTC ---
(In reply to comment #7)

> > The issue is that when running on real hardware, you can't use arbitrary cpu
> > flags and expect it to work.  And it is wrong to say xfail on sparc-rtems
> > because they could work on another board running rtems. Just not this one.
> 
> ...yes, that's why we have the dg-require-effective-target framework now.

I am thinking this may be a broader case than just that the CPU model on the
target doesn't have a particular feature.  sparc-rtems is different from
sparc64-rtems.  sparc-rtems is ONLY 32-bit v7 and v8.  

What's the simplest way to indicate that no 64-bit, VIS, etc tests are
applicable?

[Bug testsuite/51251] conflicting -mcpu switches during testing

[davem at gcc dot gnu.org]

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

--- Comment #9 from davem at gcc dot gnu.org 2011-11-21 19:11:56 UTC ---
In addition to the comments so far about what the testsuite framework
should be doing, I also think the sparc option processing is currently
doing the right thing given the input seen here.

If you say "-mcpu=cypress -mvis" which is what the command line amounts
to, it meant to enable VIS and that requires turning on V9 also which is
what the option processing in the sparc backend does.

[Bug testsuite/51251] conflicting -mcpu switches during testing

[joel at gcc dot gnu.org]

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

--- Comment #10 from Joel Sherrill <joel at gcc dot gnu.org> 2011-11-21 23:08:20 UTC ---
(In reply to comment #9)
> In addition to the comments so far about what the testsuite framework
> should be doing, I also think the sparc option processing is currently
> doing the right thing given the input seen here.
> 
> If you say "-mcpu=cypress -mvis" which is what the command line amounts
> to, it meant to enable VIS and that requires turning on V9 also which is
> what the option processing in the sparc backend does.

Doesn't the order of the conflicting options have an impact? The cypress flag
is last.

Conflicting cpu feature flags is bad anyway and even though many flags can be
alternated like optimzation flags with the last one winning, this situation
likely has no easy general solution which is predictable.

The best solution in this particular case is to disable all tests V9+, VIS, etc
which are
not V7/V8 since that what this target is for.