This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Ada] new warning


Tested on i686-linux, committed on trunk.

This patch implements a new warning. If there are uninitialized
variables declared in the visible part of a package, which are
initialized directly or indirectly by a initialization section
in the package body, then it is a good idea to add a pragma
Elaborate_Body. Otherwise elaboration code accessing these
variables may look at them when the package spec (and the
relevant declarations) have been elaborated, but before they
have been properly initialized by the body).

There is nothing in the rules of Ada that requires that the
body be elaborated before any clients in such a case, but it
seems a good idea to do so, and consequently it seems useful
to warn when we detect this has not been done.

Since the initialization block in the body may call other
subprograms, it is not good enough to look for explicit
assignments in this block. Instead we have to trace the
flow of the elaboration code, which is a big job, but easy
because we already do this for the access before elaboration
checks for the static elaboration model.

As a side part of this patch, we use the flag In_Private_Part
in objects to flag them as declared in the private part of a
package (we don't want to issue a warning in this case). There
are in fact a whole sequence of slightly complex exclusions
to ensure we don't get excessive false positives from this
warning. See body of Check_Elab_Assign for details.

Here is a simple test program (compiled with -gnatlj60)

     1. package t is
     2.    procedure initx (a : integer);
     3.    x : integer;
     4. end t;

     1. package body t is
     2.    procedure initx (a : integer) is
     3.    begin
     4.       x := a;
              |
        >>> warning: elaboration code may access "x" before
            it is initialized, suggest adding pragma
            Elaborate_Body to spec of "t", or an explicit
            initialization could be added at t.ads:3

     5.    end initx;
     6. begin
     7.    initx (43);
     8. end;

Some elaboration checks must be performed on generic units for legality
purposes, but no run-time checks need to be generated if the context is
generic. If expansion is disabled then the full semantic information may
not be available for subunits, which results in compiler aborts.
No simple example available.

2006-10-31  Robert Dewar  <dewar@adacore.com>
	    Ed Schonberg  <schonberg@adacore.com>

	* sem_elab.ads, sem_elab.adb (Check_Elab_Assign): New procedure
	Add new calls to this procedure during traversal
	(Activate_Elaborate_All_Desirable): Do not set elaboration flag on
	another unit if expansion is disabled.

Attachment: difs
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]