Disable expansion of Enum_Rep into a type conversion as it is incorrect
in SPARK.
2019-08-12 Yannick Moy <moy@adacore.com>
gcc/ada/
* exp_spark.adb (Expand_SPARK_N_Attribute_Reference): Only
expand Enum_Rep attribute when its parameter is a literal.
From-SVN: r274289
This patch corrects several bugs within the compiler which led to
inconsistent handling of compile time Constraint_Errors. Notibly,
subtype out of range checks which are only out of range of the subtype
must be warnings while out of range checks where the value is out of
range of the base type must be an error. Also, type conversions and
qualified expressions on literals constitute errors on any out of range
value. The compiler needed many of these cases clarified.
------------
-- Source --
------------
-- main.ads
with System;
package Main is
type T_Enum is (Enum_1, Enum_2, Unknown)
with Default_Value => Unknown;
subtype T_Valid_Enum is T_Enum range Enum_1 .. Enum_2;
Value : T_Valid_Enum; -- WARNING
generic
type T_Element is (<>);
Init : T_Element;
package Generic_Test is
Value : T_Element := Init;
end;
package titi is new Generic_Test (T_Valid_Enum, Unknown); -- WARNING
type My_Float is digits System.Max_Base_Digits;
My_Float_Last : constant := My_Float'Last;
Out_Of_Range : constant := My_Float_Last + 1.0;
Flt1 : My_Float := Out_Of_Range; -- ERROR
A : Positive := Positive (16#9999_9999_9999#); -- ERROR
B : Positive := 16#9999_9999_9999#; -- ERROR
C : Positive := 0; -- WARNING
D : Positive := Positive (0); -- ERROR
E : Positive := Positive'(16#9999_9999_9999#); -- ERROR
F : Positive := Positive'(0); -- ERROR
end;
-----------------
-- Compilation --
-----------------
$ gnatmake -q -gnatw_a main.adb
main.ads:9:12: warning: value not in range of type "T_Valid_Enum" defined at
line 7
main.ads:9:12: warning: "Constraint_Error" will be raised at run time
main.ads:18:52: warning: value not in range of type "T_Element" defined at
line 12, instance at line 18
main.ads:18:52: warning: "Constraint_Error" will be raised at run time
main.ads:25:23: value not in range of type "My_Float" defined at line 20
main.ads:25:23: static expression fails Constraint_Check
main.ads:27:19: value not in range of type "Standard.Positive"
main.ads:27:19: static expression fails Constraint_Check
main.ads:28:19: value not in range of type "Standard.Positive"
main.ads:28:19: static expression fails Constraint_Check
main.ads:29:19: warning: value not in range of type "Standard.Positive"
main.ads:29:19: warning: "Constraint_Error" will be raised at run time
main.ads:30:19: value not in range of type "Standard.Positive"
main.ads:30:19: static expression fails Constraint_Check
main.ads:31:27: value not in range of type "Standard.Positive"
main.ads:31:27: static expression fails Constraint_Check
main.ads:32:27: value not in range of type "Standard.Positive"
main.ads:32:27: static expression fails Constraint_Check
gnatmake: "main.ads" compilation error
2019-08-12 Justin Squirek <squirek@adacore.com>
gcc/ada/
* sem_eval.adb (Check_Non_Static_Context): Add a condition to
determine if a range violation constitues a warning or an error.
(Out_Of_Range): Add a condition to determine if a range
violation constitues a warning or an error.
From-SVN: r274288
This gets rid of redundant range checks generated in 5 out of the 9
cases of scalar conversions, i.e. (integer, fixed-point, floating-point)
converted to (integer, fixed-point, floating-point).
The problem is that the Real_Range_Check routine rewrites the conversion
node into a conversion to the base type so, when its parent node is
analyzed, a new conversion to the subtype may be introduced, depending
on the context, giving rise to a second range check against the subtype
bounds.
This change makes Real_Range_Check rewrite the expression of the
conversion node instead of the node, so that the type of the node is
preserved and no new conversion is introduced. As a matter of fact,
this is exactly what happens in the float-to-float case which goes to
the Generate_Range_Check circuit instead and does not suffer from the
duplication of range checks.
For the following procedure, the compiler must now generate exactly one
range check per nested function:
procedure P is
type I1 is new Integer range -100 .. 100;
type I2 is new Integer range -200 .. 200;
type D1 is delta 0.5 range -100.0 .. 100.0;
type D2 is delta 0.5 range -200.0 .. 200.0;
type F1 is new Long_Float range -100.0 .. 100.0;
type F2 is new Long_Float range -200.0 .. 200.0;
function Conv (A : I2) return I1 is
begin
return I1 (A);
end;
function Conv (A : D2) return I1 is
begin
return I1 (A);
end;
function Conv (A : F2) return I1 is
begin
return I1 (A);
end;
function Conv (A : I2) return D1 is
begin
return D1 (A);
end;
function Conv (A : D2) return D1 is
begin
return D1 (A);
end;
function Conv (A : F2) return D1 is
begin
return D1 (A);
end;
function Conv (A : I2) return F1 is
begin
return F1 (A);
end;
function Conv (A : D2) return F1 is
begin
return F1 (A);
end;
function Conv (A : F2) return F1 is
begin
return F1 (A);
end;
begin
null;
end;
2019-08-12 Eric Botcazou <ebotcazou@adacore.com>
gcc/ada/
* exp_ch4.adb (Real_Range_Check): Do not rewrite the conversion
node but its expression instead, after having fetched its
current value. Clear the Do_Range_Check flag on entry. Return
early for a rewritten float-to-float conversion. Remove
redundant local variable. Suppress all checks when inserting
the temporary and do not reanalyze the node.
From-SVN: r274287
This fixes a small glitch in Insert_Valid_Check, which needs to
propagate the Do_Range_Check flag onto the rewritten expression, but
uses its Original_Node as the source of the copy. Now Original_Node
does not necessarily point to the node that was just rewritten, but to
the ultimately original node, which is not the same node if the
expression was rewritten multiple times. The end result is that a
stalled Do_Range_Check flag can be wrongly resintated and leak to the
code generator.
2019-08-12 Eric Botcazou <ebotcazou@adacore.com>
gcc/ada/
* checks.adb (Insert_Valid_Check): Do not retrieve the
Do_Range_Check flag from the Original_Node but from the
Validated_Object. Remove useless bypass for floating-point
types.
gcc/testsuite/
* gnat.dg/range_check7.adb: New testcase.
From-SVN: r274285
GNATprove needs traversal subprograms that do not simply traverse
syntactic nodes like Atree.Traverse_Func and Atree.Traverse_Proc, but
also traverse semantic nodes which are logically children of the nodes.
Now available through Sem_Util.Traverse_More_Func and
Sem_Util.Traverse_More_Proc.
There is no impact on compilation.
2019-08-12 Yannick Moy <moy@adacore.com>
gcc/ada/
* sem_util.adb, sem_util.ads (Traverse_More_Func,
Traverse_More_Proc): New traversal subprograms.
From-SVN: r274284
This routine would not return if range checks are suppressed.
2019-08-12 Eric Botcazou <ebotcazou@adacore.com>
gcc/ada/
* exp_ch4.adb (Discrete_Range_Check): Return if checks are
suppressed.
From-SVN: r274282
This change prevents the analysis phase of the front-end from setting
the Do_Range_Check flag in the very peculiar case of the source of a
conversion whose result is passed by reference to a "valued procedure",
because the expansion phase would not be able to generate the check.
This pattern appears in the ancient DEC Starlet package and it doesn't
seem to be useful at this point to change the expander to deal with it,
so instead the analysis phase is adjusted. Morever the compiler already
issues a warning in this case so this is probably good enough.
2019-08-12 Eric Botcazou <ebotcazou@adacore.com>
gcc/ada/
* sem_res.adb: Add with & use clause for Sem_Mech and
alphabetize.
(Resolve_Actuals): Do not apply a scalar range check for the
source of a conversion whose result is passed by reference to a
valued procedure.
From-SVN: r274281
This plugs another small loophole in the front-end which fails to
generate a range check for a scalar In/Out parameter when -gnatVa is
specified. This also fixes a few more leaks of the Do_Range_Check flag
on actual parameters, both in regular and -gnatVa modes, as well as a
leak specific to expression function in -gnatp mode.
2019-08-12 Eric Botcazou <ebotcazou@adacore.com>
gcc/ada/
* checks.adb (Insert_Valid_Check): Reset the Do_Range_Check flag
on the validated object.
* exp_ch6.adb (Add_Call_By_Copy_Code): Reset the Do_Range_Check
flag on the actual here, as well as on the Expression if the
actual is a N_Type_Conversion node.
(Add_Validation_Call_By_Copy_Code): Generate the incoming range
check if needed and reset the Do_Range_Check flag on the
Expression if the actual is a N_Type_Conversion node.
(Expand_Actuals): Do not reset the Do_Range_Check flag here.
Generate the incoming range check for In parameters here instead
of...
(Expand_Call_Helper): ...here. Remove redudant condition.
* sem_res.adb (Resolve_Actuals): Use local variable A_Typ and
remove obsolete comments.
(Resolve_Type_Conversion): Do not force the Do_Range_Check flag
on the operand if range checks are suppressed.
gcc/testsuite/
* gnat.dg/range_check6.adb: New testcase.
From-SVN: r274280
This gets rid of another leak of the Do_Range_Check flag to the back-end
which is specific to expression functions. No functional changes.
2019-08-12 Eric Botcazou <ebotcazou@adacore.com>
gcc/ada/
* checks.adb (Activate_Range_Check): Remove redundant argument.
(Generate_Range_Check): Likewise.
(Apply_Float_Conversion_Check): Reset the Do_Range_Check flag on
entry and remove redundant condition.
From-SVN: r274279
When moving a local variable from the stack to static storage, the
procedure is no longer safe to be called recursively or concurrently
from multiple threads. Thus generate a warning when this is done.
Also double the default limit for switching from stack to static.
Regtested on x86_64-pc-linux-gnu.
gcc/fortran/ChangeLog:
2019-08-11 Janne Blomqvist <jb@gcc.gnu.org>
PR fortran/91413
* invoke.texi (-fmax-stack-var-size): Document increased default.
* options.c (gfc_post_options): Increase default stack var size to
65536 bytes.
* trans-decl.c (gfc_finish_var_decl): Generate warning when local
array moved to static storage.
From-SVN: r274264
The expression that caused the ICE
++(a += 1.0);
The D front-end rewrites and applies implicit type conversions so the
expression gets simplified as
(int)((double) a += 1.0) += 1
The codegen pass would subsequently generate the following invalid code
(int)(double) a = (int)((double) a + 1.0) + 1
The LHS expression `(int)(double) a', represented as a FIX_TRUNC_EXPR
being what trips as it is not a valid lvalue for assignment.
While LHS casts are stripped away, convert_expr adds a double cast
because it converts the expression to its original type before
converting it to its target type. There is no valid reason why this is
done, so it has been removed.
gcc/d/ChangeLog:
PR d/90601
* d-convert.cc (convert_expr): Don't convert an expression to its
original front-end type before converting to its target type.
gcc/testsuite/ChangeLog:
PR d/90601
* gdc.dg/pr90601.d: New test.
From-SVN: r274263
2019-08-10 Steven G. Kargl <kargl@gcc.gnu.org>
* decl.c (match_old_style_init): Use a clearer error message.
* expr.c (gfc_check_assign): Update BOZ checking to provide a stricter
adherence to the Fortran standard. Use gfc_invalid_boz () to
relax errors into warnings.
* gfortran.h (gfc_isym_id): Add new ids GFC_ISYM_DFLOAT,
GFC_ISYM_FLOAT, GFC_ISYM_REALPART, and GFC_ISYM_SNGL
* intrinsic.c (add_functions): Use new ids to split REAL generic into
REAL, FLOAT, DFLOAT, SNGL, and REALPART generics.
(gfc_intrinsic_func_interface): Allow new intrinsics in an
initialization expression
* resolve.c (resolve_operator): Deal with BOZ as operands.
Use gfc_invalid_boz to allow for errors or warnings via the
-fallow-invalid-boz option. A BOZ cannot be an operand to an
unary operator. Both operands of a binary operator cannot be BOZ.
For binary operators, convert a BOZ operand into the type and
kind of the other operand for REAL or INTEGER operand.
* trans-intrinsic.c: Use new ids to cause conversions to happen.
2019-08-10 Steven G. Kargl <kargl@gcc.gnu.org>
* gfortran.dg/boz_8.f90: Adjust error messages.
* gfortran.dg/nan_4.f90: Ditto.
* gfortran.dg/boz_1.f90: Add -fallow-invalid-boz to dg-options,
and test for warnings.
* gfortran.dg/boz_3.f90: Ditto.
* gfortran.dg/boz_4.f90: Ditto.
* gfortran.dg/dec_structure_6.f90: Ditto.
* gfortran.dg/ibits.f90: Ditto.
From-SVN: r274257
gcc/d/ChangeLog:
PR d/91238
* d-codegen.cc (build_address): If taking the address of a CALL_EXPR,
wrap it in a TARGET_EXPR.
gcc/testsuite/ChangeLog:
PR d/91238
* gdc.dg/pr91238.d: New test.
From-SVN: r274253
This fixes two minor problems with the new testcases. The first is
that almost all other tests, including all vec* tests, for powerpc use
names with dashes, not underscores. The more important one is the the
vec-rotate-1.c and vec-rotate-3.c tests need the -maltivec flag.
gcc/testsuite/
* gcc.target/powerpc/vec_rotate-1.c: Rename to ...
* gcc.target/powerpc/vec-rotate-1.c: ... this. Add -maltivec option.
* gcc.target/powerpc/vec_rotate-2.c: Rename to ...
* gcc.target/powerpc/vec-rotate-2.c: ... this.
* gcc.target/powerpc/vec_rotate-3.c: Rename to ...
* gcc.target/powerpc/vec-rotate-3.c: ... this. Add -maltivec option.
* gcc.target/powerpc/vec_rotate-4.c: Rename to ...
* gcc.target/powerpc/vec-rotate-4.c: ... this.
From-SVN: r274239
PR target/91386 is a situation where a peephole2 pattern substitution
is discarded late because the selected instructions contain
frame-related notes that we cannot redistribute (because the pattern
has more than one insn in the output). Unfortunately, the original
insns were being modified during the generation, so after the undo we
are left with corrupt RTL.
We avoid this by ensuring that the modifications are always made on a
copy, so that the original insns are never changed.
PR target/91386
* config/aarch64/aarch64.c (aarch64_gen_adjusted_ldpstp): Use copy_rtx
to preserve the contents of the original insns.
From-SVN: r274238
The addsi3_compare_op[12] patterns currently only have constraints to
pick the 32-bit variants of the instructions. Although the assembler
may sometimes opportunistically match a 16-bit t2 instruction, there's
no real control over that within the compiler. Consequently we might
emit a 32-bit adds instruction with a 16-bit subs instruction would
serve equally well. We do, of course still have to be careful about
the small number of boundary cases by controlling the order quite
carefully.
This patch adds the constraints and templates to match the t2 16-bit
variants of these instructions. Now, for example, we can generate
subs r0, r0, #1 // 16-bit instruction
instead of
adds r0, r0, #1 // 32-bit instruction.
*confit/arm/arm.md (addsi3_compare_op1): Add 16-bit thumb-2 variants.
(addsi3_compare_op2): Likewise.
From-SVN: r274237
In this PR we have two return paths from a function "map". The common
code sets <result> to the value returned by one path, while the other
path does:
<retval> = map (&<retval>, ...);
We treated this call as tail recursion, losing the copy semantics
on the value returned by the recursive call.
We'd correctly reject the same thing for variables:
local = map (&local, ...);
The problem is that RESULT_DECLs didn't get the same treatment.
2019-08-09 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR middle-end/90313
* tree-tailcall.c (find_tail_calls): Reject calls that might
read from an escaped RESULT_DECL.
gcc/testsuite/
PR middle-end/90313
* g++.dg/torture/pr90313.cc: New test.
From-SVN: r274234
normal_mv_distribution maintains the variance-covariance matrix param
in Cholesky-decomposed form. Existing param_type constructors, when
taking a full or lower-triangle varcov matrix, perform Cholesky
decomposition to convert it to the internal representation. This
internal representation is visible both in the varcov() result, and in
the streamed-out representation of a normal_mv_distribution object.
The problem is that when that representation is streamed back in, the
read-back decomposed varcov matrix is used as a lower-triangle
non-decomposed varcov matrix, and it undergoes Cholesky decomposition
again. So, each cycle of stream-out/stream-in changes the varcov
matrix to its "square root", instead of restoring the original
params.
This patch includes Corentin's changes that introduce verification in
testsuite/ext/random/normal_mv_distribution/operators/serialize.cc and
other similar tests that the object read back in compares equal to the
written-out object: the modified tests pass only if (u == v).
This patch also fixes the error exposed by his change, introducing an
alternate private constructor for param_type, used only by operator>>.
for libstdc++-v3/ChangeLog
* include/ext/random
(normal_mv_distribution::param_type::param_type): New private
ctor taking a decomposed varcov matrix, for use by...
(operator>>): ... this, befriended.
* include/ext/random.tcc (operator>>): Use it.
(normal_mv_distribution::param_type::_M_init_lower): Adjust
member function name in exception message.
for libstdc++-v3/ChangeLog
from Corentin Gay <gay@adacore.com>
* testsuite/ext/random/beta_distribution/operators/serialize.cc,
testsuite/ext/random/hypergeometric_distribution/operators/serialize.cc,
testsuite/ext/random/normal_mv_distribution/operators/serialize.cc,
testsuite/ext/random/triangular_distribution/operators/serialize.cc,
testsuite/ext/random/von_mises_distribution/operators/serialize.cc:
Add call to `VERIFY`.
From-SVN: r274233
2019-08-09 Martin Liska <mliska@suse.cz>
* doc/invoke.texi: Document the option value.
* lto-wrapper.c (run_gcc): Set auto_parallel
only with -flto=auto.
2019-08-09 Martin Liska <mliska@suse.cz>
* g++.dg/lto/devirt-19_0.C: Add -flto=auto.
From-SVN: r274232
2019-08-09 Martin Liska <mliska@suse.cz>
* opts.c (common_handle_option): Error for an invalid argument
to -flto=.
2019-08-09 Martin Liska <mliska@suse.cz>
* gcc.dg/spellcheck-options-21.c: New test.
From-SVN: r274231
c/
* c-parser.c (check_no_duplicate_clause): Simplify using
omp_find_clause.
(c_parser_omp_clause_if): Fix up printing of target {enter,exit} data
directive name modifiers.
(c_parser_omp_clause_proc_bind): Check for duplicate proc_bind clause.
cp/
* parser.c (check_no_duplicate_clause): Simplify using
omp_find_clause.
(cp_parser_omp_clause_if): Fix up printing of target {enter,exit} data
directive name modifiers.
testsuite/
* c-c++-common/gomp/if-4.c: New test.
* c-c++-common/gomp/clause-dups-1.c: New test.
From-SVN: r274227
PR c/91401
c/
* c-parser.c (c_parser_omp_clause_dist_schedule): Fix up typos in the
check_no_duplicate_clause call. Comment it out, instead emit a
warning for duplicate dist_schedule clauses.
cp/
* parser.c (cp_parser_omp_clause_dist_schedule): Comment out the
check_no_duplicate_clause call, instead emit a warning for duplicate
dist_schedule clauses.
testsuite/
* c-c++-common/gomp/pr91401-1.c: New test.
* c-c++-common/gomp/pr91401-2.c: New test.
From-SVN: r274226
rand is in ISO C, whereas random is only in POSIX, so it makes sense
to use the more portable function everywhere instead of falling back
from one to the other on systems that miss the less portable one.
for gcc/testsuite/ChangeLog
* gcc.target/i386/sse2-mul-1.c: Use rand. Drop fallback.
* gcc.target/i386/sse4_1-blendps-2.c: Likewise.
* gcc.target/i386/sse4_1-blendps.c: Likewise.
* gcc.target/i386/xop-vshift-1.c: Likewise.
* gcc.target/powerpc/direct-move.h: Likewise.
From-SVN: r274225
This is more in line with the other iterators we have, and a bit easier
to read and write.
* config/rs6000/dfp.md (D64_D128): Rename to ...
(DDTD): ... this, throughout.
(dfp_suffix): Rename to ...
(q): ... this, throughout.
From-SVN: r274218
I noticed some patterns in dfp.md could use the D64_D128 iterator but
don't yet. This converts all remaining simple cases.
* config/rs6000/dfp.md (D64_D128): Move earlier in the file.
(dfp_suffix): Ditto.
(adddd3, addtd3): Merge to ...
(add<mode>3 for D64_D128): ... this.
(subdd3, subtd3): Merge to ...
(sub<mode>3 for D64_D128): ... this.
(muldd3, multd3): Merge to ...
(mul<mode>3 for D64_D128): ... this.
(divdd3, divtd3): Merge to ...
(div<mode>3 for D64_D128): ... this.
(*cmpdd_internal1, *cmptd_internal1): Merge to ...
(*cmp<mode>_internal1 for D64_D128): ... this.
(ftruncdd2, ftrunctd2): Merge to ...
(ftrunc<mode>2 for D64_D128): ... this.
(fixdddi2, fixtddi2): Merge to ...
(fix<mode>di2 for D64_D128): ... this.
From-SVN: r274217
gcc/
PR target/91229
* config/riscv/riscv.c (riscv_flatten_aggregate_field): New arg
ignore_zero_width_bit_field_p. Skip zero size bitfields when true.
Pass into recursive call.
(riscv_flatten_aggregate_argument): New arg. Pass to
riscv_flatten_aggregate_field.
(riscv_pass_aggregate_in_fpr_pair_p): New local warned. Call
riscv_flatten_aggregate_argument twice, with false and true as last
arg. Process result twice. Compare results and warn if different.
(riscv_pass_aggregate_in_fpr_and_gpr_p): Likewise.
gcc/testsuite/
* gcc.target/riscv/flattened-struct-abi-1.c: New test.
* gcc.target/riscv/flattened-struct-abi-2.c: New test.
From-SVN: r274215
For:
enum a { A };
enum a { B };
we emit a bogus error about nested definitions before the real error:
foo.c:2:6: error: nested redefinition of ‘enum a’
2 | enum a { B };
| ^
foo.c:2:6: error: redeclaration of ‘enum a’
foo.c:1:6: note: originally defined here
1 | enum a { A };
| ^
This is because we weren't clearing C_TYPE_BEING_DEFINED once the
definition was over.
I think it's OK to clear C_TYPE_BEING_DEFINED even for a definition
that actually is nested (and so whose outer definition is still open),
since we'll already have given an error by then. It means that second
and subsequent attempts to define a nested enum will usually get the
redeclaration error instead of the nested error, but that seems just
as accurate (nested_first and nested_second in the test). The only
exception is if the first nested enum was also invalid by being empty,
but then the enum as a whole has already produced two errors
(nested_empty in the test).
2019-08-08 Richard Sandiford <richard.sandiford@arm.com>
gcc/c/
* c-decl.c (finish_enum): Clear C_TYPE_BEING_DEFINED.
gcc/testsuite/
* gcc.dg/pr79983.c (enum E): Don't allow an error about nested
definitions.
* gcc.dg/enum-redef-1.c: New test.
From-SVN: r274213
