This avoids using an integer type for which we don't have an
approprate mode when expanding .DEFERRED_INIT to a non-memory
entity.
2021-10-11 Richard Biener <rguenther@suse.de>
PR middle-end/102683
* internal-fn.c (expand_DEFERRED_INIT): Check for mode
availability before building an integer type for storage
purposes.
The following fixes the issue of ignoring side-effects on memory
from overloaded global new/delete operators by not marking them
as effectively 'const' apart from other explicitely specified
side-effects.
This will cause
FAIL: g++.dg/warn/Warray-bounds-16.C -std=gnu++1? (test for excess errors)
because we now no longer statically see the initialization loop
never executes because the call to operator new can now clobber 'a.m'.
This seems to be an issue with the warning code and/or ranger so
I'm leaving this FAIL to be addressed as followup.
2021-10-11 Richard Biener <rguenther@suse.de>
PR middle-end/101480
* gimple.c (gimple_call_fnspec): Do not mark operator new/delete
as const.
* g++.dg/torture/pr10148.C: New testcase.
gcc/ada/
* gcc-interface/gigi.h (resolve_atomic_size): Declare.
(list_third): New inline function.
* gcc-interface/decl.c (type_for_atomic_builtin_p): New function.
(resolve_atomic_builtin): Likewise.
(gnat_to_gnu_subprog_type): Perform type resolution for most of
type-generic GCC atomic builtins and give an error for the rest.
* gcc-interface/utils2.c (resolve_atomic_size): Make public.
gcc/ada/
* gcc-interface/trans.c (gnat_to_gnu) <N_Pop_Constraint_Error_Label>:
Given the warning only if No_Exception_Propagation is active.
<N_Pop_Storage_Error_Label>: Likewise.
<N_Pop_Program_Error_Label>: Likewise.
gcc/ada/
* gcc-interface/decl.c (promote_object_alignment): Add GNU_SIZE
parameter and use it for the size of the object if not null.
(gnat_to_gnu_entity) <E_Variable>: Perform the automatic alignment
promotion for objects whose nominal subtype is of variable size.
(gnat_to_gnu_field): Adjust call to promote_object_alignment.
gcc/ada/
* gcc-interface/decl.c (gnat_to_gnu_param): Strip padding types
only if the size does not change in the process. Rename local
variable and add bypass for initialization procedures.
gcc/ada/
* sem_attr.adb (Analyze_Attribute_Old_Result): Permit an
attribute reference inside a compiler-generated _Postconditions
procedure. In this case, Subp_Decl is assigned the declaration
of the enclosing subprogram.
* exp_util.adb (Insert_Actions): When climbing up the tree
looking for an insertion point, do not climb past an
N_Iterated_Component/Element_Association, since this could
result in inserting a reference to a loop parameter at a
location outside of the scope of that loop parameter. On the
other hand, be careful to preserve existing behavior in the case
of an N_Component_Association node.
gcc/ada/
* exp_ch6.adb (Can_Fold_Predicate_Call): Do not attempt folding
if there is more than one predicate involved. Recall that
predicate aspect specification are additive, not overriding, and
that there are three different predicate
aspects (Dynamic_Predicate, Static_Predicate, and the
GNAT-defined Predicate aspect). These various ways of
introducing multiple predicates are all checked for. A new
nested function, Augments_Other_Dynamic_Predicate, is
introduced.
* sem_ch4.adb
(Analyze_Indexed_Component_Form.Process_Function_Call): When
determining whether a name like "X (Some_Discrete_Type)" might
be interpreted as a slice, the answer should be "no" if the
type/subtype name denotes the current instance of type/subtype.
gcc/ada/
* sem_ch13.adb (Validate_Unchecked_Conversion): Simplify code
for detecting conversions with Ada.Calendar.Time type and extend
it to similar types in the Ada.Real_Time package.
gcc/ada/
* ali.adb (Get_Name): Ignore_Spaces is always False.
* bindo-graphs.adb (Set_Is_Existing_Source_Target_Relation): Val
is always True.
* cstand.adb (New_Standard_Entity): New_Node_Kind is always
N_Defininig_Identifier.
* exp_ch3.adb (Predef_Stream_Attr_Spec): For_Body is always
False.
* exp_dist.adb (Add_Parameter_To_NVList): RACW_Ctrl is always
False.
* gnatls.adb (Add_Directories): Prepend is always False.
* sem_ch10.adb, sem_ch10.ads (Load_Needed_Body): Do_Analyze is
always True.
* sem_ch3.adb, sem_ch3.ads (Process_Range_Expr_In_Decl):
R_Check_Off is always False.
* sem_elab.adb: (Info_Variable_Reference): Info_Msg is always
False, In_SPARK is always True.
(Set_Is_Traversed_Body, Set_Is_Saved_Construct,
Set_Is_Saved_Relation): Val is always True.
* treepr.adb (Visit_Descendant): No_Indent is always False.
(Print_Node): Fmt does not need such a big scope.
gcc/ada/
* exp_fixd.adb (Get_Size_For_Value): New function returning a size
suitable for a non-negative integer value.
(Get_Type_For_Size): New function returning a standard type suitable
for a size.
(Build_Divide): Call both functions to compute the result type, but
make sure to pass a non-negative value to the first.
(Build_Multiply): Likewise.
(Do_Multiply_Fixed_Universal): Minor consistency tweak.
(Integer_Literal): Call both functions to compute the type.
gcc/ada/
* exp_aggr.adb (Initialize_Record_Component): Add assertion
about one of the parameters, so that illegal attempts to
initialize record components with Empty node are detected early
on.
(Build_Record_Aggr_Code): Handle boxes in aggregate component
associations just the components with no initialization in
Build_Record_Init_Proc.
* sem_aggr.adb (Resolve_Record_Aggregate): For components that
require simple initialization carry boxes from resolution to
expansion.
* sem_util.adb (Needs_Simple_Initialization): Remove redundant
paren.
The variable omp_atv_sequential was replaced by omp_atv_serialized in OpenMP
5.1. This was already implemented by Jakub (C/C++, commit ea82325afe) and
Tobias (Fortran, commit fff15bad1a).
This patch adds two tests to check if omp_atv_serialized is available (one test
for C/C++ and one for Fortran). Besides that omp_atv_sequential is marked as
deprecated in C/C++ and Fortran for OpenMP 5.1.
libgomp/ChangeLog:
* allocator.c (omp_init_allocator): Replace omp_atv_sequential with
omp_atv_serialized.
* omp.h.in: Add deprecated flag for omp_atv_sequential.
* omp_lib.f90.in: Add deprecated flag for omp_atv_sequential.
* testsuite/libgomp.c-c++-common/alloc-10.c: New test.
* testsuite/libgomp.fortran/alloc-12.f90: New test.
OpenMP 5.1 adds env vars and functions to set and query new ICVs used
as fallback if thread_limit or num_teams clauses aren't specified on
teams construct.
The following patch implements those, though further work will be needed:
1) OpenMP 5.1 also changed the num_teams clause, so that it can specify
both lower and upper limit for how many teams should be created and
changed the meaning when only one expression is provided, instead of
num_teams(expr) in 5.0 meaning num_teams(1:expr) in 5.1, it now means
num_teams(expr:expr), i.e. while previously we could create 1 to expr
teams, in 5.1 we have some low limit by default equal to the single
expression provided and may not create fewer teams.
For host teams (which we don't currently implement efficiently for
NUMA hosts) we trivially satisfy it now by always honoring what the
user asked for, but for the offloading teams I think we'll need to
rethink the APIs; currently teams construct is just a call that returns
and possibly lowers the number of teams; and whenever possible we try
to evaluate num_teams/thread_limit already on the target construct
and the GOMP_teams call just sets the number of teams to the minimum
of provided and requested teams; for some cases e.g. where target
is not combined with teams and num_teams expression calls some functions
etc., we need to call those functions in the target region and so it is
late to figure number of teams, but also hw could just limit what it
is willing to create; in that case I'm afraid we need to run the target
body multiple times and arrange for omp_get_team_num () returning the
right values
2) we need to finally implement the NUMA handling for GOMP_teams_reg
3) I now realize I haven't added some testcase coverage, will do that
incrementally
4) libgomp.texi needs updates for these new APIs, but also others like
the allocator
2021-10-11 Jakub Jelinek <jakub@redhat.com>
gcc/
* omp-low.c (omp_runtime_api_call): Handle omp_get_max_teams,
omp_[sg]et_teams_thread_limit and omp_set_num_teams.
libgomp/
* omp.h.in (omp_set_num_teams, omp_get_max_teams,
omp_set_teams_thread_limit, omp_get_teams_thread_limit): Declare.
* omp_lib.f90.in (omp_set_num_teams, omp_get_max_teams,
omp_set_teams_thread_limit, omp_get_teams_thread_limit): Declare.
* omp_lib.h.in (omp_set_num_teams, omp_get_max_teams,
omp_set_teams_thread_limit, omp_get_teams_thread_limit): Declare.
* libgomp.h (gomp_nteams_var, gomp_teams_thread_limit_var): Declare.
* libgomp.map (OMP_5.1): Export omp_get_max_teams{,_},
omp_get_teams_thread_limit{,_}, omp_set_num_teams{,_,_8_} and
omp_set_teams_thread_limit{,_,_8_}.
* icv.c (omp_set_num_teams, omp_get_max_teams,
omp_set_teams_thread_limit, omp_get_teams_thread_limit): New
functions.
* env.c (gomp_nteams_var, gomp_teams_thread_limit_var): Define.
(omp_display_env): Print OMP_NUM_TEAMS and OMP_TEAMS_THREAD_LIMIT.
(initialize_env): Handle OMP_NUM_TEAMS and OMP_TEAMS_THREAD_LIMIT env
vars.
* teams.c (GOMP_teams_reg): If thread_limit is not specified, use
gomp_teams_thread_limit_var as fallback if not zero. If num_teams
is not specified, use gomp_nteams_var.
* fortran.c (omp_set_num_teams, omp_get_max_teams,
omp_set_teams_thread_limit, omp_get_teams_thread_limit): Add
ialias_redirect.
(omp_set_num_teams_, omp_set_num_teams_8_, omp_get_max_teams_,
omp_set_teams_thread_limit_, omp_set_teams_thread_limit_8_,
omp_get_teams_thread_limit_): New functions.
This patch adds support for recognizing loops which mimic the behaviour
of functions strlen and rawmemchr, and replaces those with internal
function calls in case a target provides them. In contrast to the
standard strlen and rawmemchr functions, this patch also supports
different instances where the memory pointed to is interpreted as 8, 16,
and 32-bit sized, respectively.
gcc/ChangeLog:
* builtins.c (get_memory_rtx): Change to external linkage.
* builtins.h (get_memory_rtx): Add function prototype.
* doc/md.texi (rawmemchr<mode>): Document.
* internal-fn.c (expand_RAWMEMCHR): Define.
* internal-fn.def (RAWMEMCHR): Add.
* optabs.def (rawmemchr_optab): Add.
* tree-loop-distribution.c (find_single_drs): Change return code
behaviour by also returning true if no single store was found
but a single load.
(loop_distribution::classify_partition): Respect the new return
code behaviour of function find_single_drs.
(loop_distribution::execute): Call new function
transform_reduction_loop in order to replace rawmemchr or strlen
like loops by calls into builtins.
(generate_reduction_builtin_1): New function.
(generate_rawmemchr_builtin): New function.
(generate_strlen_builtin_1): New function.
(generate_strlen_builtin): New function.
(generate_strlen_builtin_using_rawmemchr): New function.
(reduction_var_overflows_first): New function.
(determine_reduction_stmt_1): New function.
(determine_reduction_stmt): New function.
(loop_distribution::transform_reduction_loop): New function.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ldist-rawmemchr-1.c: New test.
* gcc.dg/tree-ssa/ldist-rawmemchr-2.c: New test.
* gcc.dg/tree-ssa/ldist-strlen-1.c: New test.
* gcc.dg/tree-ssa/ldist-strlen-2.c: New test.
* gcc.dg/tree-ssa/ldist-strlen-3.c: New test.
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
So this patch make BEGIN and END accept VOIDmode, like cselib_lookup_mem did per
Jim Wilson's suggestion.
```
static cselib_val *
cselib_lookup_mem (rtx x, int create)
{
...
addr_mode = GET_MODE (XEXP (x, 0));
if (addr_mode == VOIDmode)
addr_mode = Pmode;
```
Changes v2 -> v3:
- Use gcc_assert rather than error, maybe_emit_call_builtin___clear_cache is
internal use only, and we already checked the type in other place.
Changes v1 -> v2:
- Check is CONST_INT intead of cehck mode, no new testcase, since
constant value with other type like CONST_DOUBLE will catched by
front-end.
e.g.
Code:
```c
void foo(){
__builtin___clear_cache(1.11, 0);
}
```
Error message:
```
clearcache-double.c: In function 'foo':
clearcache-double.c:2:27: error: incompatible type for argument 1 of '__builtin___clear_cache'
2 | __builtin___clear_cache(1.11, 0);
| ^~~~
| |
| double
clearcache-double.c:2:27: note: expected 'void *' but argument is of type 'double'
```
gcc/ChangeLog:
PR target/100316
* builtins.c (maybe_emit_call_builtin___clear_cache): Allow
CONST_INT for BEGIN and END, and use gcc_assert rather than
error.
gcc/testsuite/ChangeLog:
PR target/100316
* gcc.c-torture/compile/pr100316.c: New.
Since my r10-7665-g33c45e51b4914008064d9b77f2c1fc0eea1ad060 change, we get
wrong-debug on e.g. the following testcase at -O2 -g on x86_64-linux for the
x parameter:
void bar (int *r);
int
foo (int x)
{
int r = 0;
bar (&r);
return r;
}
At the start of function, we have
subq $24, %rsp
leaq 12(%rsp), %rdi
instructions. The x parameter is passed in %rdi, but isn't used in the
function and so the leaq instruction overwrites %rdi without remembering
%rdi anywhere. Before the r10-7665 change (which was trying to fix a large
(3% for 32-bit, 1% for 64-bit x86-64) debug info/loc growth introduced with
r10-7515), the leaq insn above resulted in a MO_VAL_SET micro-operation that
said that the value of sp + 12, a cselib_sp_derived_value_p, is stored into
the %rdi register. The r10-7665 change added a change to add_stores that
added no micro-operation for the leaq store, with the rationale that the sp
based values can be and will be always computable some other more compact
and primarily more stable way (cfa based expression like DW_OP_fbreg, that
is the same in the whole function). That is true. But by throwing the
micro-operation on the floor, we miss another important part of the
MO_VAL_SET, in particular that the destination of the store, %rdi in this
case, now has a different value from what it had before, so the vt_*
dataflow code thinks that even after the leaq instruction %rdi still holds
the x argument value (and changes it to DW_OP_entry_value (%rdi) only in the
middle of the call to bar). Previously and with the patches below,
the location for x changes already at the end of leaq instruction to
DW_OP_entry_value (%rdi).
My first attempt to fix this was instead of dropping the MO_VAL_SET add
a MO_CLOBBER operation:
--- gcc/var-tracking.c.jj 2021-05-04 21:02:24.196799586 +0200
+++ gcc/var-tracking.c 2021-09-24 19:23:16.420154828 +0200
@@ -6133,7 +6133,9 @@ add_stores (rtx loc, const_rtx expr, voi
{
if (preserve)
preserve_value (v);
- return;
+ mo.type = MO_CLOBBER;
+ mo.u.loc = loc;
+ goto log_and_return;
}
nloc = replace_expr_with_values (oloc);
so don't track that the value lives in the loc destination, but track
that the previous value doesn't live there anymore. That failed bootstrap
miserably, the vt_* code isn't prepared to see MO_CLOBBER of a MEM that
isn't tracked (e.g. has MEM_EXPR on it that the var-tracking code wants
to track, i.e. track_p in add_stores). On the other side, thinking about
it more, in the most common case where a cselib_sp_derived_value_p value
is stored into the sp register (and which is the reason why PR94495
testcase got larger), dropping the micro-operation on the floor is the
right thing, because we have that cselib_sp_derived_value_p tracking, any
reads from the sp hard register will be treated as
cselib_sp_derived_value_p.
Then I've tried 3 different patches described below and in the end
what is committed is patch2.
Additionally, I've gathered statistics from cc1plus by always reverting the
var-tracking.c change after finished bootstrap/regtest and rebuilding the
stage3 var-tracking.o and cc1plus, such that it would be comparable.
dwlocstat and .debug_{info,loclists} section sizes detailed below.
patch3 uses MO_VAL_SET (i.e. essentially reversion of the r10-7665
change) when destination is not a REG_P and !track_p, otherwise if
destination is sp drops the micro-operation on the floor (i.e. no change),
otherwise adds a MO_CLOBBER.
patch1 is similar, except it checks for destination not equal to sp and
!track_p, i.e. for !track_p REG_P destinations other than sp it will use
MO_VAL_SET rather than MO_CLOBBER.
Finally, patch2, the shortest patch, uses MO_VAL_SET whenever destination
is not sp and otherwise drops the micro-operation on the floor.
All the 3 patches don't affect the PR94495 testcase, all the changes
there were caused by stores of sp based values into %rsp.
While the patch2 (and patch1 which results in exactly the same sizes)
causes the largest debug loclists/info growth from the 3, it is still quite
minor (0.651% on 64-bit and 0.114% on 32-bit) compared
to the 1% and 3% PR94495 was trying to solve, and I actually think it is the
best thing to do. Because, if we have say
int q[10];
int *p = &q[0];
or similar and we load the &q[0] sp based value into some hard register,
by noting in the debug info that p lives in some hard reg for some part
of the function and a user is trying to change the p var in the debugger,
if we say it lives in some register or memory, there is some chance that
the changing of the value could work successfully (of course, nothing
is guaranteed, we don't have tracking of where each var lives at which
moment for changing purposes (i.e. what register, memory or else you need
to change in order to change behavior of the code)), while if we just say
that p's location is DW_OP_fbreg 16 DW_OP_stack_value, that is a read-only
value one can just print but not change. Now, for stores of variable
values into the sp register, I don't think we have such an issue, you don't
want debugger to change your stack pointer when user asks to change value
of some variable whose value lives in the stack pointer, that would pretty
much always result in misbehavior of the program.
So, my preference from these 3 is patch2 and that is being committed.
64-bit cc1plus
==============
vanilla
cov% samples cumul
0..10 1064665/37% 1064665/37%
11..20 35972/1% 1100637/38%
21..30 47969/1% 1148606/40%
31..40 45787/1% 1194393/42%
41..50 57529/2% 1251922/44%
51..60 53974/1% 1305896/46%
61..70 112055/3% 1417951/50%
71..80 79420/2% 1497371/52%
81..90 126225/4% 1623596/57%
91..100 1206682/42% 2830278/100%
[34] .debug_info PROGBITS 0000000000000000 2f1c74c a44949f 00 0 0 1
[38] .debug_loclists PROGBITS 0000000000000000 ff5d046 506e947 00 0 0 1
patch1 (same as patch2)
cov% samples cumul
0..10 1064685/37% 1064685/37%
11..20 36011/1% 1100696/38%
21..30 47975/1% 1148671/40%
31..40 45799/1% 1194470/42%
41..50 57566/2% 1252036/44%
51..60 54011/1% 1306047/46%
61..70 112068/3% 1418115/50%
71..80 79421/2% 1497536/52%
81..90 126171/4% 1623707/57%
91..100 1206571/42% 2830278/100%
[34] .debug_info PROGBITS 0000000000000000 2f1c74c a448f27 00 0 0 1
[38] .debug_loclists PROGBITS 0000000000000000 ff608bc 52070dd 00 0 0 1
patch3
cov% samples cumul
0..10 1064698/37% 1064698/37%
11..20 36018/1% 1100716/38%
21..30 47977/1% 1148693/40%
31..40 45804/1% 1194497/42%
41..50 57562/2% 1252059/44%
51..60 54018/1% 1306077/46%
61..70 112071/3% 1418148/50%
71..80 79424/2% 1497572/52%
81..90 126172/4% 1623744/57%
91..100 1206534/42% 2830278/100%
[34] .debug_info PROGBITS 0000000000000000 2f1c74c a449548 00 0 0 1
[38] .debug_loclists PROGBITS 0000000000000000 ff5df39 507acd8 00 0 0 1
So, size of .debug_info+.debug_loclists grows for vanilla -> patch1 (or patch2) by
0.651% and for vanilla -> patch3 by 0.020%.
32-bit cc1plus
==============
vanilla
cov% samples cumul
0..10 1061892/37% 1061892/37%
11..20 34002/1% 1095894/39%
21..30 43513/1% 1139407/40%
31..40 41667/1% 1181074/42%
41..50 59144/2% 1240218/44%
51..60 47009/1% 1287227/45%
61..70 105069/3% 1392296/49%
71..80 72990/2% 1465286/52%
81..90 125988/4% 1591274/56%
91..100 1208726/43% 2800000/100%
[33] .debug_info PROGBITS 00000000 351ab10 8b1c83d 00 0 0 1
[37] .debug_loclists PROGBITS 00000000 ebc816e 3fe44fd 00 0 0 1
patch1 (same as patch2)
cov% samples cumul
0..10 1061999/37% 1061999/37%
11..20 34065/1% 1096064/39%
21..30 43557/1% 1139621/40%
31..40 41690/1% 1181311/42%
41..50 59191/2% 1240502/44%
51..60 47143/1% 1287645/45%
61..70 105045/3% 1392690/49%
71..80 73021/2% 1465711/52%
81..90 125885/4% 1591596/56%
91..100 1208404/43% 2800000/100%
[33] .debug_info PROGBITS 00000000 351ab10 8b1c597 00 0 0 1
[37] .debug_loclists PROGBITS 00000000 ebca915 401ffad 00 0 0 1
patch3
cov% samples cumul
0..10 1062006/37% 1062006/37%
11..20 34073/1% 1096079/39%
21..30 43559/1% 1139638/40%
31..40 41693/1% 1181331/42%
41..50 59189/2% 1240520/44%
51..60 47142/1% 1287662/45%
61..70 105054/3% 1392716/49%
71..80 73027/2% 1465743/52%
81..90 125874/4% 1591617/56%
91..100 1208383/43% 2800000/100%
[33] .debug_info PROGBITS 00000000 351ab10 8b1c690 00 0 0 1
[37] .debug_loclists PROGBITS 00000000 ebca40a 4020a6e 00 0 0 1
So, size of .debug_info+.debug_loclists grows for vanilla -> patch1 (or patch2) by
0.114% and for vanilla -> patch3 by 0.116%.
2021-10-10 Jakub Jelinek <jakub@redhat.com>
PR debug/102441
* var-tracking.c (add_stores): For cselib_sp_derived_value_p values
use MO_VAL_SET if loc is not sp.
So it turns out this is kinda of a latent bug but not really latent.
In GCC 9 and 10, phi-opt would transform a?-1:0 (even for signed 1-bit integer)
to -(type)a but the type is an one bit integer which means the negation is
undefined. GCC 11 fixed the problem by checking for a?pow2cst:0 transformation
before a?-1:0 transformation.
When I added the transformations to match.pd, I had swapped the order not paying
attention and I didn't expect anything of it. Because there was no testcase failing
due to this.
Anyways this fixes the problem on the trunk by swapping the order in match.pd and
adding a comment of why the order is this way.
I will try to come up with a patch for GCC 9 and 10 series later on which fixes
the problem there too.
Note I didn't include the original testcase which requires the vectorizer and AVX-512f
as I can't figure out the right dg options to restrict it to avx-512f but I did come up
with a testcase which shows the problem and even more shows the problem with the 9/10
series as mentioned.
OK? Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/102622
gcc/ChangeLog:
* match.pd: Swap the order of a?pow2cst:0 and a?-1:0 transformations.
Swap the order of a?0:pow2cst and a?0:-1 transformations.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/bitfld-10.c: New test.
F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style
relational operators. As gfortran internally distinguishes between
these versions, we must match equivalent notations in
USE module, ONLY: OPERATOR(op)
statements when reading modules.
gcc/fortran/ChangeLog:
PR fortran/65454
* module.c (read_module): Handle old and new-style relational
operators when used in USE module, ONLY: OPERATOR(op).
gcc/testsuite/ChangeLog:
PR fortran/65454
* gfortran.dg/interface_operator_3.f90: New test.
This fixes the typos introduced by commit r12-4240.
The dg-warning format looks like:
{ dg-warning regexp
[comment [{ target/xfail selector } [line] ]] }
Some dg-warnings such as:
{ dg-warning "\\\[-Wstringop-overflow"
{ target { i?86-*-* x86_64-*-* } } }
miss the comment field, it makes target selector not take effect.
For targets which are not { i?86-*-* x86_64-*-* }, this kind of cases
fail or pass unexpectedly.
gcc/testsuite/ChangeLog:
* c-c++-common/Wstringop-overflow-2.c: Add missing comment.
* gcc.dg/Warray-bounds-51.c: Likewise.
* gcc.dg/Warray-parameter-3.c: Likewise.
* gcc.dg/Wstringop-overflow-14.c: Likewise.
* gcc.dg/Wstringop-overflow-21.c: Likewise.
* gcc.dg/Wstringop-overflow-76.c: Likewise.
