[Bug ada/36939] Build Failure Ada SH2e

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu.org]

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

--- Comment #14 from Joel Sherrill <joel at gcc dot gnu.org> 2011-02-07 00:18:37 UTC ---
Created attachment 23261
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23261
Patch to use stub file

With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a
minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds Ada.

Is this OK to commit?

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu.org]

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

--- Comment #15 from Joel Sherrill <joel at gcc dot gnu.org> 2011-02-07 01:13:51 UTC ---
ACATS results are not perfect but not bad for a first run.  

PASSED: 1984 FAILED  335

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

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

--- Comment #16 from Laurent GUERBY <laurent at guerby dot net> 2011-02-07 06:10:13 UTC ---
Joel, could you send me the compressed acats.log or at least post the failing
tests? 335 failures likely mean one Ada feature is broken.

Re: [Bug ada/36939] Build Failure Ada SH2e

[Arnaud Charlet]

> With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a
> minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds
> Ada.
> 
> Is this OK to commit?

Note that the proper place to submit a patch officially is gcc-patches.

In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to
have target specific implementations, or stubbed implementation, that's
a kludge which is not really acceptable for mainstream.

Arno

[Bug ada/36939] Build Failure Ada SH2e

[charlet at adacore dot com]

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

--- Comment #17 from charlet at adacore dot com <charlet at adacore dot com> 2011-02-07 09:04:18 UTC ---
> With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a
> minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds
> Ada.
> 
> Is this OK to commit?

Note that the proper place to submit a patch officially is gcc-patches.

In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to
have target specific implementations, or stubbed implementation, that's
a kludge which is not really acceptable for mainstream.

Arno

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu.org]

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

--- Comment #18 from Joel Sherrill <joel at gcc dot gnu.org> 2011-02-07 14:22:20 UTC ---
(In reply to comment #17)
> > With Laurent's stub version of s-scaval.adb added as s-scaval-sh.adb and a
> > minor change to a ada/gcc-interface/Makefile.in, sh-rtems now builds
> > Ada.
> > 
> > Is this OK to commit?
> 
> Note that the proper place to submit a patch officially is gcc-patches.
> 
> In any case, adding s-scaval-sh.adb isn't OK, s-scaval.adb isn't meant to
> have target specific implementations, or stubbed implementation, that's
> a kludge which is not really acceptable for mainstream.

I didn't like this solution but it does let the target compile.

But the underlying problem is more general.  How should targets with only
single precision floating point be supported by s-scaval.adb?  I am pretty sure
there  is currently a PowerPC e500 core with only single precision.  

> Arno

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu.org]

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

--- Comment #19 from Joel Sherrill <joel at gcc dot gnu.org> 2011-02-07 17:22:59 UTC ---
Following up on my own comment.  Dealing with targets without double precision
FPUs is a broader issue:

$ grep -r DOUBLE_TYPE_SIZE . | grep "SIZE.*32" | grep -v .svn
./rx/rx.h:#define DOUBLE_TYPE_SIZE         (TARGET_64BIT_DOUBLES ? 64 : 32)
./rx/rx.h:#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE   32
./sh/sh.h:#define DOUBLE_TYPE_SIZE ((TARGET_SH2E && ! TARGET_SH4 && !
TARGET_SH2A_DOUBLE) ? 32 : 64)
./picochip/picochip.h:#define DOUBLE_TYPE_SIZE 32
./picochip/picochip.h:#define LONG_DOUBLE_TYPE_SIZE 32
./h8300/h8300.h:#define DOUBLE_TYPE_SIZE    32
./avr/avr.h:#define DOUBLE_TYPE_SIZE 32
./avr/avr.h:#define LONG_DOUBLE_TYPE_SIZE 32

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

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

--- Comment #20 from Laurent GUERBY <laurent at guerby dot net> 2011-02-07 21:42:25 UTC ---
Thanks Joel for the acats.log. 

from the failing test list my guess is that tasking is broken and was working
for your previous test.

All tests with an Ada task in them fail with "program stopped with signal 7.".

Could you try the simplest possible tasking program?

$ cat t.adb
procedure t is
task a;
task body a is         
begin
null;
end a;
begin
null;
end t;

If my guess is correct it should get a signal 7.

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu.org]

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

--- Comment #21 from Joel Sherrill <joel at gcc dot gnu.org> 2011-02-07 22:27:43 UTC ---
(In reply to comment #20)
> Thanks Joel for the acats.log. 
> 
> from the failing test list my guess is that tasking is broken and was working
> for your previous test.
> 
> All tests with an Ada task in them fail with "program stopped with signal 7.".
> 
> Could you try the simplest possible tasking program?
> 
> $ cat t.adb
> procedure t is
> task a;
> task body a is         
> begin
> null;
> end a;
> begin
> null;
> end t;
> 
> If my guess is correct it should get a signal 7.

Yep.  And a signal 7 is an emulation trap.  Running it in gdb I see that
apparently, an illegal instruction for the SH-1 was generated near the
bottom of _system__task_primitives__operations__set_priority which is
early enough in the program's execution that we really don't get to the
task.

   4583c:    00 09           nop    
   4583e:    b6 dc           bsr    465fa
<_system__tasking__debug__print_task_info+0x3e6>
   45840:    00 07           .word 0x0007
   45842:    21 fc           cmp/str    r15,r1

I am suspicious that if you know how to generate the same backend behaviour
from C, it will also generate bad code also.

[Bug ada/36939] Build Failure Ada SH2e

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

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

--- Comment #22 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I think this actual problem is the same as PR 34040.

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

------- Comment #13 from joel at gcc dot gnu dot org  2009-03-23 22:14 -------
*** Bug 21377 has been marked as a duplicate of this bug. ***


-- 

joel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |corsepiu at gcc dot gnu dot
                   |                            |org


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

------- Comment #12 from laurent at guerby dot net  2009-02-27 17:50 -------
There is no need for Makefile magic here, this is a bug in s-scaval.adb logic.

As I said this file is used for only one ACATS test and one specific and not
widely used feature, so for the purpose of testing RTEMS you can just replace
unconditionally s-scaval.adb by the empty version you won't loose anything
important.


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

------- Comment #11 from joel at gcc dot gnu dot org  2009-02-27 16:24 -------
Laurent.. what Makefile magic is needed to select this file on sh Ada targets
and not on others?


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

------- Comment #10 from laurent at guerby dot net  2008-12-10 23:09 -------
Ok I'll try to come up with a real patch.


-- 

laurent at guerby dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |laurent at guerby dot net
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

------- Comment #9 from joel at gcc dot gnu dot org  2008-12-10 19:14 -------
ACATS look surprisingly good with the fix in:

http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01013.html

sh-rtems4.10-gcc (GCC) 4.4.0 20081210 (experimental) [trunk revision 142643]

=== acats Summary ===
# of expected passes 2307
# of unexpected failures 5
# of unsupported tests 3

ce2108f - simulator does not have persistent files
ce2108h - simulator does not have persistent files
ce3112d - simulator does not have persistent files
c380004 c953002 c974013 cxg2018 cxg2021 were
  Memory exception at 44000 (illegal address) the
  last time I checked on them according to my notes.

======= Logs for failed tests ======


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

------- Comment #8 from joel at gcc dot gnu dot org  2008-12-10 18:08 -------
Created an attachment (id=16876)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16876&action=view)
working s-scaval.adb

Not much.  Just an empty version of s-scaval.adb that lets the build proceed
past this point.  I also had to remove the with/use statement.  Otherwise an
obvious change per your suggestion.

Build completed successfully.  Now try to running ACATS.


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

------- Comment #7 from laurent at guerby dot net  2008-12-10 11:57 -------
Joel, did you try the change I suggested on 2008-07-25 20:04? If this works
then I can come up with a more complete patch.


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

------- Comment #6 from joel at gcc dot gnu dot org  2008-12-02 14:01 -------
Still present with

gcc (GCC) 4.4.0 20081126 (experimental) [trunk revision 142228]


-- 

joel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-12-02 14:01:50
               date|                            |


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

[Bug ada/36939] Build Failure Ada SH2e

[joseph at codesourcery dot com]

------- Comment #5 from joseph at codesourcery dot com  2008-07-25 20:53 -------
Subject: Re:   New: Build Failure Ada SH2e

On Fri, 25 Jul 2008, joel at gcc dot gnu dot org wrote:

> According to comments in sh.h, SH2e only has single precision floating point
> and fails during build of SH2e variant. 

I suppose an unfortunate choice of ABI is set in stone here?  You can 
perfectly well have hardware with only single-precision floating-point and 
still have double (and whatever Ada types correspond to it) being 64 bit.  
On Power, E500v1 does that, ABI-compatibly with E500v2 and soft-float.


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

------- Comment #4 from laurent at guerby dot net  2008-07-25 20:46 -------
Only one ACATS test activate this package to my knowledge, so the change is
safe for compiling purposes :).


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[joel at gcc dot gnu dot org]

------- Comment #3 from joel at gcc dot gnu dot org  2008-07-25 20:35 -------
> This tells us s-scaval.adb assumes long_float is at least 64 bits, but it 
> seems to be 32 bits for sh target. 

Just to precise -- only on this multilib variant.  I am pretty sure other
SH models have double precision float.  

> You can replace the body of the procedure Initialize in s-scaval.adb by an
> empty body, it will deactivate some GNAT specific features but allows for
> compilation on all targets:

Do you mean GNAT specific or Ada specified?  This code is where variables 
get their default values.  It looks dangerous to disable this for what
could happen on other targets.

> Only long_long_float seems to be 64 bits on sh and this also breaks another
> assumption made a few lines below, that is that we are on ... x86 :)

Yes that would be a very poor assumption in this case.


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

------- Comment #2 from laurent at guerby dot net  2008-07-25 20:04 -------
You can replace the body of the procedure Initialize in s-scaval.adb by an
empty body, it will deactivate some GNAT specific features but allows for
compilation on all targets:

   procedure Initialize (Mode1 : Character; Mode2 : Character) is
   begin
      null;
   end Initialize;


-- 


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

[Bug ada/36939] Build Failure Ada SH2e

[laurent at guerby dot net]

------- Comment #1 from laurent at guerby dot net  2008-07-25 19:52 -------
      AFloat : constant Boolean :=
                 Long_Float'Size = 48 and Long_Long_Float'Size = 48;
      --  Set True if we are on an AAMP with 48-bit extended floating point

      type ByteLF is array (0 .. 7 - 2 * Boolean'Pos (AFloat)) of Byte1;

      IV_Ilf : aliased ByteLF;    -- Initialize long float

      for IV_Ilf'Address use IS_Ilf'Address;

   IS_Ilf : aliased Long_Float      := 0.0;  -- Initialize long float

This tells us s-scaval.adb assumes long_float is at least 64 bits, but it seems
to be 32 bits for sh target. 

Only long_long_float seems to be 64 bits on sh and this also breaks another
assumption made a few lines below, that is that we are on ... x86 :)

     EFloat : constant Boolean := Long_Long_Float'Size > Long_Float'Size;
      --  Set True if we are on an x86 with 96-bit floats for extended


-- 


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