Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation failures with Ravenscar before GCC 13 #18

Open
simonjwright opened this issue Feb 1, 2023 · 5 comments
Open

Compilation failures with Ravenscar before GCC 13 #18

simonjwright opened this issue Feb 1, 2023 · 5 comments
Labels
wontfix This will not be worked on

Comments

@simonjwright
Copy link
Owner

It turns out that FSF GCC versions between 10 and 12 and GNAT CE versions between 2020 and 2021 won’t compile lib/ravenscar/coldframe-events-standard.ads in the presence of the restriction No_Implicit_Heap_Allocations, which is part of the Ravenscar profile.

FSF GCC 13 (currently still under development; the 20230129 snapshot) appears not to have this problem.

@simonjwright
Copy link
Owner Author

The problem can be made to go away with this patch:

diff --git a/lib/ravenscar/coldframe-events-standard.ads b/lib/ravenscar/coldframe-events-standard.ads
index 20cdc3ba..3d8ca247 100644
--- a/lib/ravenscar/coldframe-events-standard.ads
+++ b/lib/ravenscar/coldframe-events-standard.ads
@@ -226,7 +224,7 @@ private
 
       pragma Priority (Priority);
       pragma Storage_Size (Storage_Size);
-      pragma Secondary_Stack_Size (Secondary_Stack_Size);
+      --  pragma Secondary_Stack_Size (Secondary_Stack_Size);
 
    end Dispatcher;

which is. a. shame.

Thinking about it, it’s not a surprise: the natural way to implement Secondary_Stack_Size would be to allocate the required memory, which would be an implicit heap allocation. I wonder how GCC 13 handles this?

@simonjwright
Copy link
Owner Author

simonjwright commented Feb 10, 2023

In System.Tasking.Restricted.Stages, tasks are created by

   procedure Create_Restricted_Task
     (Priority             :        Integer;
      Stack_Address        :        System.Address;
      Size                 :        System.Parameters.Size_Type;
      Sec_Stack_Address    :        System.Secondary_Stack.SS_Stack_Ptr;
      Secondary_Stack_Size :        System.Parameters.Size_Type;
      Task_Info            :        System.Task_Info.Task_Info_Type;
      CPU                  :        Integer;
      State                :        Task_Procedure_Access;
      Discriminants        :        System.Address;
      Elaborated           :        Access_Boolean;
      Chain                : in out Activation_Chain;
      Task_Image           :        String;
      Created_Task         :        Task_Id);

(or Create_Restricted_Task_Sequential), where

   --  Sec_Stack_Address is the pointer to the secondary stack created by the
   --  compiler. If null, the secondary stack is either allocated by the binder
   --  or the run-time.
   --
   --  Secondary_Stack_Size is the secondary stack size of the task to create

In GCC 12, the compiler called these procedures with Secondary_Stack_Size set to the required size and Sec_Stack_Address set to null; so the compiler knows it's requesting an implicit heap allocation. In GCC 13, Sec_Stack_Address is set to the address of an area of BSS reserved by the compiler.


Later
I think that even in GCC 12 the compiler allocated the BSS itself, except that in this case it got confused by the restriction!

@simonjwright
Copy link
Owner Author

This is a cut-down reproducer:

pragma Restrictions (No_Implicit_Heap_Allocations);

package Demo is

   type Event_Queue_Base (Secondary_Stack_Size : Natural)
      is tagged limited private;

private

   task type Dispatcher (The_Queue            : access Event_Queue_Base'Class;
                         Secondary_Stack_Size : Natural)
     with Secondary_Stack_Size => Secondary_Stack_Size;

   type Event_Queue_Base (Secondary_Stack_Size : Natural)
      is tagged limited record
         The_Dispatcher : Dispatcher
           (Event_Queue_Base'Access,
            Secondary_Stack_Size => Secondary_Stack_Size);
      end record;

end Demo;

Compiling with the native compiler results in

bash-5.2$ gnatmake -c -u -f demo.ads
gcc -c demo.ads
+===========================GNAT BUG DETECTED==============================+
| 12.2.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access  |
| Error detected at demo.ads:14:9                                          |
| Compiling demo.ads                                                       |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

demo.ads

compilation abandoned
gnatmake: "demo.ads" compilation error

@simonjwright
Copy link
Owner Author

See GCC PR 108801.

@simonjwright
Copy link
Owner Author

Another problem:

Compiling: /Users/simon/Developer/coldframe/examples/microbit/Simple_Buttons.impl/simple_buttons-button-changed.adb
Source file time stamp: 2019-03-12 12:06:37
Compiled at: 2023-02-21 11:24:21

     1. --  The state of the button has changed; tell the controlled LEDs to
     2. --  reevaluate their own states (by checking whether any of the
     3. --  Buttons they are controlled by is set).
     4.
     5. separate (Simple_Buttons.Button)
     6. procedure Changed
     7.   (This : not null Handle) is
     8.    LEDs : constant LED.Vectors.Vector := A1.Is_Controlled_By (This);
     9. begin
    10.    for L of LEDs loop
    11.       LED.Changed (L);
    12.    end loop;
    13. end Changed;

 259 lines: No errors
+===========================GNAT BUG DETECTED==============================+
| 12.2.0 (arm-eabi) Program_Error sem_ch8.adb:5773 explicit raise          |
| Error detected at simple_buttons-button-changed.adb:10:18                |
| Compiling /Users/simon/Developer/coldframe/examples/microbit/Simple_Buttons.gen/simple_buttons-button.adb|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .              |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact command that you entered.                              |
| Also include sources listed below.                                       |
+==========================================================================+

Please include these source files with error report

(snipped a long list of source files).

This was with GCC 12.2.0 (arm-eabi) and Ada.Containers.Bounded_Vectors from Cortex GNAT RTS.

These containers were derived in 2015 from those provided with GCC 4.9.1; the differences were the removal of tampering checks and the need for finalization (not available in Cortex GNAT RTS).

The same doesn’t happen with Minimal Containers.

@simonjwright simonjwright changed the title Compilation failures with Ravenscar Compilation failures with Ravenscar before GCC 13 Sep 8, 2023
@simonjwright simonjwright added the wontfix This will not be worked on label Sep 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant