+2014-01-24 Ed Schonberg <schonberg@adacore.com>
+
+ * sinfo.ads: Documentation update.
+
+2014-01-24 Ed Schonberg <schonberg@adacore.com>
+
+ * sem_ch3.adb (Constant_Redeclaration): New declaration is
+ illegal if previous one has an initial expression that is an
+ aggregate expanded into assignments.
+
+2014-01-24 Ed Schonberg <schonberg@adacore.com>
+
+ * sem_ch5.adb (Analyze_Loop_Parameter_Specification): Small
+ code reorganization to remove spurious warning on a loop with
+ an array element iterator that has a null range.
+
+2014-01-24 Vincent Celier <celier@adacore.com>
+
+ * make.adb (Binding_Phase): When setting the Ada paths, use
+ the library ALI dir, not the object dir in libraries.
+
+2014-01-24 Yannick Moy <moy@adacore.com>
+
+ * sinfo.ads: Add documentation of check flag fields.
+
+2014-01-24 Ed Schonberg <schonberg@adacore.com>
+
+ * sem_res.adb (Resolve_Actuals): If an actual is a view
+ conversion of a discriminated object, and the formal type is
+ discriminated and constrained, apply a discriminant check to
+ the object itself.
+
2014-01-24 Robert Dewar <dewar@adacore.com>
* prj.adb, prj-env.adb, back_end.adb: Add comment, minor code clean ups.
-- Check for null or possibly null range and issue warning. We suppress
-- such messages in generic templates and instances, because in practice
- -- they tend to be dubious in these cases.
+ -- they tend to be dubious in these cases. The check applies as well to
+ -- rewritten array element loops where a null range may be detected
+ -- statically.
- if Nkind (DS) = N_Range and then Comes_From_Source (N) then
+ if Nkind (DS) = N_Range then
declare
L : constant Node_Id := Low_Bound (DS);
H : constant Node_Id := High_Bound (DS);
if Compile_Time_Compare
(L, H, Assume_Valid => False) = GT
then
- Error_Msg_N
- ("??loop range is null, loop will not execute", DS);
-
-- Since we know the range of the loop is null, set the
-- appropriate flag to remove the loop entirely during
-- expansion.
Set_Is_Null_Loop (Loop_Nod);
- -- Here is where the loop could execute because of invalid
- -- values, so issue appropriate message and in this case we
- -- do not set the Is_Null_Loop flag since the loop may
- -- execute.
+ if Comes_From_Source (N) then
+ Error_Msg_N
+ ("??loop range is null, loop will not execute", DS);
+ end if;
- else
+ -- Here is where the loop could execute because of
+ -- invalid values, so issue appropriate message and in
+ -- this case we do not set the Is_Null_Loop flag since
+ -- the loop may execute.
+
+ elsif Comes_From_Source (N) then
Error_Msg_N
("??loop range may be null, loop may not execute",
DS);
-- expansion is performed and the analysis must generate a tree in a
-- form that meets additional requirements.
- -- This light expansion does two transformations of the tree, that cannot
- -- be postponed after the frontend semantic analysis:
+ -- This light expansion does two transformations of the tree that cannot
+ -- be postponed after semantic analysis:
-- 1. Replace object renamings by renamed object. This requires the
- -- introdtion of temporaries at the point of the renaming, which must
- -- be properly analyzed.
+ -- introduction of temporaries at the point of the renaming, which
+ -- must be properly analyzed.
-- 2. Fully qualify entity names. This is needed to generate suitable
-- local effects and call-graphs in ALI files, with the completely
-- not make sense from a user point-of-view, and that cross-references that
-- do not lead to data dependences for subprograms can be safely ignored.
+ -----------------------
+ -- Check Flag Fields --
+ -----------------------
+
+ -- The following flag fields appear in expression nodes:
+
+ -- Do_Division_Check
+ -- Do_Overflow_Check
+ -- Do_Range_Check
+
+ -- These three flags are always set by the front end during semantic
+ -- analysis, on expression nodes that may trigger the corresponding
+ -- check. The front end then inserts or not the check during expansion.
+ -- In particular, these flags should also be correctly set in ASIS mode
+ -- and GNATprove mode.
+
+ -- Note that this accounts for all nodes that trigger the corresponding
+ -- checks, except for range checks on subtype_indications, which may be
+ -- required to check that a range_constraint is compatible with the given
+ -- subtype (RM 3.2.2(11)).
+
+ -- The following flag fields appear in various nodes:
+
+ -- Do_Accessibility_Check
+ -- Do_Discriminant_Check
+ -- Do_Length_Check
+ -- Do_Storage_Check
+ -- Do_Tag_Check
+
+ -- These flags are used in some specific cases by the front end, either
+ -- during semantic analysis or during expansion, and cannot be expected
+ -- to be set on all nodes that trigger the corresponding check.
+
------------------------
-- Common Flag Fields --
------------------------
-- Etype (Node5-Sem)
-- Must_Not_Freeze (Flag8-Sem)
- -- Note: Etype is a copy of the Etype field of the Subtype_Mark. The
- -- reason for this redundancy is so that in a list of array index types,
- -- the Etype can be uniformly accessed to determine the subscript type.
- -- This means that no Itype is constructed for the actual subtype that
- -- is created by the subtype indication. If such an Itype is required,
- -- it is constructed in the context in which the indication appears.
+ -- Note: Depending on context, the Etype is either the entity of the
+ -- Subtype_Mark field, or it is an itype constructed to reify the
+ -- subtype indication. In particular, such itypes are created for a
+ -- subtype indication that appears in an array type declaration. This
+ -- simplifies constraint checking in indexed components.
+
+ -- For subtype indications that appear in scalar type and subtype
+ -- declarations, the Etype is the entity of the subtype mark.
-------------------------
-- 3.2.2 Subtype Mark --
-- N_Expression_With_Actions has type Standard_Void_Type. However some
-- backends do not support such expression-with-actions occurring
-- outside of a proper (non-void) expression, so this should just be
- -- used as an intermediate representation within the front-end. Also
+ -- used as an intermediate representation within the front end. Also
-- note that this is really an irregularity (expressions and statements
-- are not interchangeable, and in particular an N_Null_Statement is
-- not a proper expression), and in the long term all cases of this
-- e.g. involving unconstrained array types.
-- For the case of the standard gigi backend, this means that all
- -- checks are done in the front-end.
+ -- checks are done in the front end.
-- However, in the case of specialized back-ends, notably the JVM
-- backend for JGNAT, additional requirements and restrictions apply
projects / thirdparty / gcc.git / commitdiff
