[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #6 from Sumit --- mstrict-align does not seems to help. Only aligning them forcefully does work. ome_CardCfgPxfp_t xfpPecInfo __attribute__((aligned(4))); ome_CardCfgPsfp_t sfpPecInfo __attribute__((aligned(4))); ome_CardCfgPcfp_t cfpPecInfo __attribute__((aligned(4))); Looks like that the base address of the structure itself is misaligned causing all its elements to be misaligned as well. In the below assembly, clearly an odd value is being pushed into r26 and r31 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:807 3b53920: 3b 21 01 27 addir25,r1,295 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:806 3b53924: 3b e1 01 23 addir31,r1,291 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:805 3b53928: 3b 41 01 1f addir26,r1,287 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:808 Later, r26 and r31 being pushed to floating point register. /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:838 3b539f0: c0 3a 00 00 lfs f1,0(r26) 3b539f4: c0 1f 00 00 lfs f0,0(r31) Can the sequence of local elements in this function can cause some issue, because there are couple of elements which are of odd bytes in size such as GBB_FAC_ROLE_t = 1 byte GBB_DISP_BasicPortInfoList_t = 117 bytes But as per my understanding, proper padding would have been added in between to nullify their effects.
[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83575 --- Comment #6 from Jan Hubicka --- Author: hubicka Date: Wed Jan 10 08:19:52 2018 New Revision: 256420 URL: https://gcc.gnu.org/viewcvs?rev=256420&root=gcc&view=rev Log: PR middle-end/83575 * predict.c (force_edge_cold): Handle in more sane way edges with no prediction. Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #21 from sergey.shalnov at intel dot com ---
Thanks Richard for your comments.
Based on our discussion I've produced the patch attached and
run it on SPEC2017intrate/fprate on skylake server (with [-Ofast -flto
-march=skylake-avx512 -mfpmath=sse -funroll-loops]).
Please note, I used your last proposed patch and changed loop trip count
calculation ("ncopies_for_cost * nunits / group_size" is always 1).
I see the following performance changes:
SPEC CPU 2017 intrate
500.perlbench_r -0.7%
525.x264_r +7.2%
Geomean: +0.8%
SPEC CPU 2017 fprate
527.cam4_r -1.1%
538.imagick_r +4.7%
544.nab_r +3.6%
Geomean: +0.6%
I believe that after appropriate cost model tweaks for other targets a gain
could be observed but I haven't checked it carefully.
It provides a good performance gain for the original case and a few other
improvements.
Can you please take a look at the patch and comment (or might propose another
method)?
Sergey
From 41e5094cbdce72d4cc5e04fc3d11c01c3c1adbb7 Mon Sep 17 00:00:00 2001
From: Sergey Shalnov
Date: Tue, 9 Jan 2018 14:37:14 +0100
Subject: [PATCH, SLP] SLP_common_algo_changes
---
gcc/config/i386/x86-tune-costs.h | 4 ++--
gcc/tree-vect-slp.c | 41 ++--
2 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index 312467d..3e0f904 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -1555,7 +1555,7 @@ struct processor_costs skylake_cost = {
{4, 4, 4}, /* cost of loading integer registers
in QImode, HImode and SImode.
Relative to reg-reg move (2). */
- {6, 6, 6}, /* cost of storing integer registers */
+ {6, 6, 4}, /* cost of storing integer registers.
*/
2, /* cost of reg,reg fld/fst */
{6, 6, 8}, /* cost of loading fp registers
in SFmode, DFmode and XFmode */
@@ -1570,7 +1570,7 @@ struct processor_costs skylake_cost = {
{6, 6, 6, 10, 20}, /* cost of loading SSE registers
in 32,64,128,256 and 512-bit */
{6, 6, 6, 10, 20}, /* cost of unaligned loads. */
- {8, 8, 8, 8, 16},/* cost of storing SSE registers
+ {8, 8, 8, 16, 32}, /* cost of storing SSE registers
in 32,64,128,256 and 512-bit */
{8, 8, 8, 8, 16},/* cost of unaligned stores. */
2, 2,/* SSE->integer and
integer->SSE moves */
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 0ca42b4..7e63a1c 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1815,18 +1815,39 @@ vect_analyze_slp_cost_1 (slp_instance instance,
slp_tree node,
enum vect_def_type dt;
if (!op || op == lhs)
continue;
- if (vect_is_simple_use (op, stmt_info->vinfo, &def_stmt, &dt))
+ if (vect_is_simple_use (op, stmt_info->vinfo, &def_stmt, &dt)
+&& (dt == vect_constant_def || dt == vect_external_def))
{
/* Without looking at the actual initializer a vector of
constants can be implemented as load from the constant pool.
-??? We need to pass down stmt_info for a vector type
-even if it points to the wrong stmt. */
- if (dt == vect_constant_def)
- record_stmt_cost (prologue_cost_vec, 1, vector_load,
- stmt_info, 0, vect_prologue);
- else if (dt == vect_external_def)
- record_stmt_cost (prologue_cost_vec, 1, vec_construct,
- stmt_info, 0, vect_prologue);
+When all elements are the same we can use a splat. */
+ unsigned group_size = SLP_TREE_SCALAR_STMTS (node).length ();
+ tree elt = NULL_TREE;
+ unsigned nelt = 0;
+ for (unsigned j = 0; j < ncopies_for_cost; ++j)
+ for (unsigned k = 0; k < group_size; ++k)
+ {
+ if (nelt == 0)
+ elt = gimple_op (SLP_TREE_SCALAR_STMTS (node)[nelt], i);
+ /* ??? We're just tracking whether all operands of a single
+ vector initializer are the same, ideally we'd check if
+ we emitted the same one already. */
+ else if (elt != gimple_op (SLP_TREE_SCALAR_STMTS (node)[nelt],
+ i))
+ elt = NULL_TREE;
+ nelt++;
+ if (nelt == group_size)
+ {
+ /* ??? We need to pass down stmt_info for a vector type
+ even if it points to the
[Bug ipa/83532] [8 Regression] ICE in apply_scale, at profile-count.h:955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83532 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka --- Does this help? Seems we omit adjustment when producing partial function clone. Index: tree-inline.c === --- tree-inline.c (revision 256324) +++ tree-inline.c (working copy) @@ -2683,7 +2683,6 @@ profile_count den = ENTRY_BLOCK_PTR_FOR_FN (src_cfun)->count; profile_count num = entry_block_map->count; - profile_count::adjust_for_ipa_scaling (&num, &den); cfun_to_copy = id->src_cfun = DECL_STRUCT_FUNCTION (callee_fndecl); @@ -2707,6 +2706,8 @@ ENTRY_BLOCK_PTR_FOR_FN (cfun)->count = den; } + profile_count::adjust_for_ipa_scaling (&num, &den); + /* Must have a CFG here at this point. */ gcc_assert (ENTRY_BLOCK_PTR_FOR_FN (DECL_STRUCT_FUNCTION (callee_fndecl)));
[Bug ada/83765] New: LTO bootstrap with Ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765
Bug ID: 83765
Summary: LTO bootstrap with Ada fails
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
At the moment it ICEs for me with
> /abuild/rguenther/obj/./prev-gcc/lto1 -quiet -dumpdir ./ -dumpbase
> gnat1.ltrans0 -mtune=generic -march=x86-64 -mtune=generic -march=x86-64
> -auxbase-strip gnat1.ltrans0.ltrans.o -g -g -O2 -O2 -O2 -Wextra -Wpedantic
> -version -fno-openmp -fno-openacc -frandom-seed=1 -fno-exceptions
> -fasynchronous-unwind-tables -fno-common -frandom-seed=1 -fltrans
> gnat1.ltrans0.o -o gnat1.ltrans0.s
GNU GIMPLE (GCC) version 8.0.0 20180109 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.5, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.2, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 8.0.0 20180109 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.5, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.2, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/space/rguenther/src/svn/trunk/gcc/ada/exp_ch4.adb: In function
‘exp_ch4__expand_n_reduction_expression’:
/space/rguenther/src/svn/trunk/gcc/ada/exp_ch4.adb:10117: warning: ‘actual’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
Reduction_Par := Expression (Actual);
/space/rguenther/src/svn/trunk/gcc/ada/exp_ch4.adb:10092: note: ‘actual’ was
declared here
Actual: Node_Id;
/space/rguenther/src/svn/trunk/gcc/ada/exp_ch3.adb: In function
‘exp_ch3__expand_n_full_type_declaration’:
/space/rguenther/src/svn/trunk/gcc/ada/atree.adb:5952:38: warning: ‘m_id’ may
be used uninitialized in this function [-Wmaybe-uninitialized]
Nodes.Table (N + 2).Field10 := Union_Id (Val);
^
/space/rguenther/src/svn/trunk/gcc/ada/exp_ch3.adb:5483: note: ‘m_id’ was
declared here
M_Id : Entity_Id;
during RTL pass: final
/space/rguenther/src/svn/trunk/gcc/ada/exp_spark.adb: In function
‘exp_spark__expand_spark_potential_renaming’:
/space/rguenther/src/svn/trunk/gcc/ada/exp_spark.adb:498: internal compiler
error: in add_dwarf_attr, at dwarf2out.c:4168
end Expand_SPARK_Potential_Renaming;
0x981cc7 add_dwarf_attr
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:4168
0x981dbc add_AT_flag
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:4207
0x9b0cb9 gen_subprogram_die
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:22243
0x9ba815 gen_decl_die
/space/rguenther/src/svn/trunk/gcc/dwarf2out.c:25490
0x9b9175 process_scope_var
where the issue is IMHO that in get_subprogram_die we have
(gdb) p decl
$7 =
$8 =
(gdb) p decl->decl_common.abstract_origin
$9 =
(gdb) p decl->decl_common.abstract_flag
$10 = 0
and thus we get origin == decl and also old_die. declaration == 1 but
due to the above we run into the if instead of the else if branch:
/* A concrete instance, tag a new DIE with DW_AT_abstract_origin. */
if (origin != NULL)
{
...
}
/* A cached copy, possibly from early dwarf generation. Reuse as
much as possible. */
else if (old_die)
{
/* A declaration that has been previously dumped needs no
additional information. */
if (declaration)
return;
and end up adding DW_AT_declaration a second time (we come here multiple
times because it looks like a function with this declaration in its
scopes was inlined multiple times into exp_ch2__expand_entity_reference).
Now the interesting part is who sets this origin to self, quite likely
set_decl_origin_self (tried to get rid of that with no success...).
And it is set this way already in the LTO bytecode for the LTRANS stage.
Of course when coming along this in a declaration context via processing
BLOCK_NONLOCALIZED_VARS this confuses the machinery :/ Note how
set_block_origin_self does _not_ recurse into BLOCK_NONLOCALIZED_VARS!
Note we "properly" pass down NULL as origin but the passing down stops
at gen_decl_die -> gen_subprogram_die who recomputes it.
So
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 256378)
+++ gcc/dwarf2out.c (working copy)
@@ -21954,9 +21954,8 @@ gen_call_site_die (tree decl, dw_die_ref
block-local). */
static void
-gen_subprogram_die (tree decl, dw_die_ref context_die)
+gen_subprogram_die (tree decl, tree origin, dw_die_ref context_die)
{
- tree origin = decl_ultimate_origin (decl);
dw_die_ref subr_die;
dw_die_ref old_die = lookup_decl_die (decl);
@@ -25199,7 +25198,7 @@ force_decl_die (tree d
[Bug ada/83765] LTO bootstrap with Ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765
--- Comment #1 from Richard Biener ---
Doesn't seem to work :/
I guess making the old_die && declaration more prevalent might work.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 256378)
+++ gcc/dwarf2out.c (working copy)
@@ -22044,6 +22044,11 @@ gen_subprogram_die (tree decl, dw_die_re
int declaration = (current_function_decl != decl
|| class_or_namespace_scope_p (context_die));
+ /* A declaration that has been previously dumped needs no
+ additional information. */
+ if (old_die && declaration)
+return;
+
/* Now that the C++ front end lazily declares artificial member fns, we
might need to retrofit the declaration into its class. */
if (!declaration && !origin && !old_die
@@ -22084,11 +22089,6 @@ gen_subprogram_die (tree decl, dw_die_re
much as possible. */
else if (old_die)
{
- /* A declaration that has been previously dumped needs no
-additional information. */
- if (declaration)
- return;
-
if (!get_AT_flag (old_die, DW_AT_declaration)
/* We can have a normal definition following an inline one in the
case of redefinition of GNU C extern inlines.
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008 --- Comment #23 from Richard Biener --- Created attachment 43084 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43084&action=edit SLP costing for constants/externs improvement
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #22 from rguenther at suse dot de ---
On Wed, 10 Jan 2018, sergey.shalnov at intel dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
>
> --- Comment #21 from sergey.shalnov at intel dot com ---
> Thanks Richard for your comments.
> Based on our discussion I've produced the patch attached and
> run it on SPEC2017intrate/fprate on skylake server (with [-Ofast -flto
> -march=skylake-avx512 -mfpmath=sse -funroll-loops]).
> Please note, I used your last proposed patch and changed loop trip count
> calculation ("ncopies_for_cost * nunits / group_size" is always 1).
>
> I see the following performance changes:
> SPEC CPU 2017 intrate
> 500.perlbench_r -0.7%
> 525.x264_r +7.2%
> Geomean: +0.8%
>
> SPEC CPU 2017 fprate
> 527.cam4_r -1.1%
> 538.imagick_r +4.7%
> 544.nab_r +3.6%
> Geomean: +0.6%
>
> I believe that after appropriate cost model tweaks for other targets a gain
> could be observed but I haven't checked it carefully.
> It provides a good performance gain for the original case and a few other
> improvements.
>
> Can you please take a look at the patch and comment (or might propose another
> method)?
It mixes several things, the last one (> to >= change in cost evaluation
clearly wrong). The skylake_cost changes look somewhat odd to me.
I'll attach my current SLP costing adjustment patch (after the SVE
changes the old didn't build anymore).
> Sergey
>
> From 41e5094cbdce72d4cc5e04fc3d11c01c3c1adbb7 Mon Sep 17 00:00:00 2001
> From: Sergey Shalnov
> Date: Tue, 9 Jan 2018 14:37:14 +0100
> Subject: [PATCH, SLP] SLP_common_algo_changes
>
> ---
> gcc/config/i386/x86-tune-costs.h | 4 ++--
> gcc/tree-vect-slp.c | 41
> ++--
> 2 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/config/i386/x86-tune-costs.h
> b/gcc/config/i386/x86-tune-costs.h
> index 312467d..3e0f904 100644
> --- a/gcc/config/i386/x86-tune-costs.h
> +++ b/gcc/config/i386/x86-tune-costs.h
> @@ -1555,7 +1555,7 @@ struct processor_costs skylake_cost = {
>{4, 4, 4}, /* cost of loading integer registers
>in QImode, HImode and SImode.
>Relative to reg-reg move (2). */
> - {6, 6, 6}, /* cost of storing integer registers
> */
> + {6, 6, 4}, /* cost of storing integer registers.
> */
>2, /* cost of reg,reg fld/fst */
>{6, 6, 8}, /* cost of loading fp registers
>in SFmode, DFmode and XFmode */
> @@ -1570,7 +1570,7 @@ struct processor_costs skylake_cost = {
>{6, 6, 6, 10, 20}, /* cost of loading SSE registers
>in 32,64,128,256 and 512-bit */
>{6, 6, 6, 10, 20}, /* cost of unaligned loads. */
> - {8, 8, 8, 8, 16},/* cost of storing SSE registers
> + {8, 8, 8, 16, 32}, /* cost of storing SSE registers
>in 32,64,128,256 and 512-bit */
>{8, 8, 8, 8, 16},/* cost of unaligned stores. */
>2, 2,/* SSE->integer and
> integer->SSE moves */
> diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
> index 0ca42b4..7e63a1c 100644
> --- a/gcc/tree-vect-slp.c
> +++ b/gcc/tree-vect-slp.c
> @@ -1815,18 +1815,39 @@ vect_analyze_slp_cost_1 (slp_instance instance,
> slp_tree node,
>enum vect_def_type dt;
>if (!op || op == lhs)
> continue;
> - if (vect_is_simple_use (op, stmt_info->vinfo, &def_stmt, &dt))
> + if (vect_is_simple_use (op, stmt_info->vinfo, &def_stmt, &dt)
> +&& (dt == vect_constant_def || dt == vect_external_def))
> {
> /* Without looking at the actual initializer a vector of
> constants can be implemented as load from the constant pool.
> -??? We need to pass down stmt_info for a vector type
> -even if it points to the wrong stmt. */
> - if (dt == vect_constant_def)
> - record_stmt_cost (prologue_cost_vec, 1, vector_load,
> - stmt_info, 0, vect_prologue);
> - else if (dt == vect_external_def)
> - record_stmt_cost (prologue_cost_vec, 1, vec_construct,
> - stmt_info, 0, vect_prologue);
> +When all elements are the same we can use a splat. */
> + unsigned group_size = SLP_TREE_SCALAR_STMTS (node).length ();
> + tree elt = NULL_TREE;
> + unsigned nelt = 0;
> + for (unsigned j = 0; j < ncopies_for_cost; ++j)
> + for (unsigned k = 0; k < group_size; ++k)
> + {
> + if (nelt == 0)
> + elt = gimple_op (SL
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #22 from rguenther at suse dot de ---
On Wed, 10 Jan 2018, sergey.shalnov at intel dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
>
> --- Comment #21 from sergey.shalnov at intel dot com ---
> Thanks Richard for your comments.
> Based on our discussion I've produced the patch attached and
> run it on SPEC2017intrate/fprate on skylake server (with [-Ofast -flto
> -march=skylake-avx512 -mfpmath=sse -funroll-loops]).
> Please note, I used your last proposed patch and changed loop trip count
> calculation ("ncopies_for_cost * nunits / group_size" is always 1).
>
> I see the following performance changes:
> SPEC CPU 2017 intrate
> 500.perlbench_r -0.7%
> 525.x264_r +7.2%
> Geomean: +0.8%
>
> SPEC CPU 2017 fprate
> 527.cam4_r -1.1%
> 538.imagick_r +4.7%
> 544.nab_r +3.6%
> Geomean: +0.6%
>
> I believe that after appropriate cost model tweaks for other targets a gain
> could be observed but I haven't checked it carefully.
> It provides a good performance gain for the original case and a few other
> improvements.
>
> Can you please take a look at the patch and comment (or might propose another
> method)?
It mixes several things, the last one (> to >= change in cost evaluation
clearly wrong). The skylake_cost changes look somewhat odd to me.
I'll attach my current SLP costing adjustment patch (after the SVE
changes the old didn't build anymore).
> Sergey
>
> From 41e5094cbdce72d4cc5e04fc3d11c01c3c1adbb7 Mon Sep 17 00:00:00 2001
> From: Sergey Shalnov
> Date: Tue, 9 Jan 2018 14:37:14 +0100
> Subject: [PATCH, SLP] SLP_common_algo_changes
>
> ---
> gcc/config/i386/x86-tune-costs.h | 4 ++--
> gcc/tree-vect-slp.c | 41
> ++--
> 2 files changed, 33 insertions(+), 12 deletions(-)
>
> diff --git a/gcc/config/i386/x86-tune-costs.h
> b/gcc/config/i386/x86-tune-costs.h
> index 312467d..3e0f904 100644
> --- a/gcc/config/i386/x86-tune-costs.h
> +++ b/gcc/config/i386/x86-tune-costs.h
> @@ -1555,7 +1555,7 @@ struct processor_costs skylake_cost = {
>{4, 4, 4}, /* cost of loading integer registers
>in QImode, HImode and SImode.
>Relative to reg-reg move (2). */
> - {6, 6, 6}, /* cost of storing integer registers
> */
> + {6, 6, 4}, /* cost of storing integer registers.
> */
>2, /* cost of reg,reg fld/fst */
>{6, 6, 8}, /* cost of loading fp registers
>in SFmode, DFmode and XFmode */
> @@ -1570,7 +1570,7 @@ struct processor_costs skylake_cost = {
>{6, 6, 6, 10, 20}, /* cost of loading SSE registers
>in 32,64,128,256 and 512-bit */
>{6, 6, 6, 10, 20}, /* cost of unaligned loads. */
> - {8, 8, 8, 8, 16},/* cost of storing SSE registers
> + {8, 8, 8, 16, 32}, /* cost of storing SSE registers
>in 32,64,128,256 and 512-bit */
>{8, 8, 8, 8, 16},/* cost of unaligned stores. */
>2, 2,/* SSE->integer and
> integer->SSE moves */
> diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
> index 0ca42b4..7e63a1c 100644
> --- a/gcc/tree-vect-slp.c
> +++ b/gcc/tree-vect-slp.c
> @@ -1815,18 +1815,39 @@ vect_analyze_slp_cost_1 (slp_instance instance,
> slp_tree node,
>enum vect_def_type dt;
>if (!op || op == lhs)
> continue;
> - if (vect_is_simple_use (op, stmt_info->vinfo, &def_stmt, &dt))
> + if (vect_is_simple_use (op, stmt_info->vinfo, &def_stmt, &dt)
> +&& (dt == vect_constant_def || dt == vect_external_def))
> {
> /* Without looking at the actual initializer a vector of
> constants can be implemented as load from the constant pool.
> -??? We need to pass down stmt_info for a vector type
> -even if it points to the wrong stmt. */
> - if (dt == vect_constant_def)
> - record_stmt_cost (prologue_cost_vec, 1, vector_load,
> - stmt_info, 0, vect_prologue);
> - else if (dt == vect_external_def)
> - record_stmt_cost (prologue_cost_vec, 1, vec_construct,
> - stmt_info, 0, vect_prologue);
> +When all elements are the same we can use a splat. */
> + unsigned group_size = SLP_TREE_SCALAR_STMTS (node).length ();
> + tree elt = NULL_TREE;
> + unsigned nelt = 0;
> + for (unsigned j = 0; j < ncopies_for_cost; ++j)
> + for (unsigned k = 0; k < group_size; ++k)
> + {
> + if (nelt == 0)
> + elt = gimple_op (SL
[Bug c++/83766] New: Bug 67632 not fixed yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83766 Bug ID: 83766 Summary: Bug 67632 not fixed yet Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: achuah at drwsg dot com Target Milestone: --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 I've tested it on gcc 6.1.0, and the same problem is still there. From the bug tracker it looks like the bug was acknowledged to be an issue, but never eventually followed up on. Target: x86_64-linux-gnu gcc version 6.1.0
[Bug libstdc++/67632] explicit instantiation omits copy constructor and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 Anthony Chuah changed: What|Removed |Added CC||achuah at drwsg dot com --- Comment #8 from Anthony Chuah --- This bug still isn't fixed as of gcc 6.1.0.
[Bug testsuite/83706] [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83706 --- Comment #6 from Jan Hubicka --- Yep, those rounding issues are anoying. It won't buy us any code quality but I guess using sreals for change prob is most consistent way around. It seems that sreals are quite prone to rounding issues :(.
[Bug libstdc++/67632] explicit instantiation omits copy constructor and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 --- Comment #9 from Anthony Chuah --- Forgot to add: this bug exists also for clang 5.0.0. % clang++ -std=c++11 --gcc-toolchain=/path/to/gcc t.o x.cc /tmp/x-063634.o: In function `copy(std::unordered_map, std::equal_to, std::allocator > > const&)': x.cc:(.text+0x18): undefined reference to `std::unordered_map, std::equal_to, std::allocator > >::unordered_map(std::unordered_map, std::equal_to, std::allocator > > const&)' clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)
[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726 --- Comment #5 from Jakub Jelinek --- Created attachment 43085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43085&action=edit gcc8-pr83726.patch Actually, because *movdi_aarch64 can handle any (DImode) CONST_INT operand, there is no reason why *movti_aarch64 would need to limit itself just to const_int_operand, it can handle const_scalar_int_operand just as well. I can't easily test this on aarch64 though, the patch is completely untested.
[Bug c++/83756] gcc (mingw64) 7.2.0 ICE in gimplify_expr on boost::call_once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83756 Richard Biener changed: What|Removed |Added Keywords||needs-reduction --- Comment #6 from Richard Biener --- usual size_t massaging is not enough to amke it compile with x86_64-linux, I run into bin/boost-win64-1.57/boost/thread/win32/shared_mutex.hpp:49:13: error: static assertion failed: sizeof(T)==sizeof(long) so likely mingw (cross?) required to reproduce. The ICE looks like we might have a dup as well.
[Bug middle-end/83764] internal compiler error: in gimple_get_virt_method_for_vtable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83764 Adam Lackorzynski changed: What|Removed |Added CC||adam at os dot inf.tu-dresden.de --- Comment #3 from Adam Lackorzynski --- This is a duplicate of #81702, which has already been fixed.
[Bug target/83760] [8 Regression] [SH] ICE in maybe_record_trace_start building glibc tst-copy_file_range.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83760 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.0
[Bug libstdc++/67632] explicit instantiation omits copy constructor and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 --- Comment #10 from Andreas Schwab --- *** Bug 83766 has been marked as a duplicate of this bug. ***
[Bug c++/83766] Bug 67632 not fixed yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83766 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 67632 ***
[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81702 Richard Biener changed: What|Removed |Added CC||lesliezhai at llvm dot org.cn --- Comment #13 from Richard Biener --- *** Bug 83764 has been marked as a duplicate of this bug. ***
[Bug middle-end/83764] internal compiler error: in gimple_get_virt_method_for_vtable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83764 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- dup. *** This bug has been marked as a duplicate of bug 81702 ***
[Bug ada/83765] LTO bootstrap with Ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- The combination Ada + LTO + debug has always been a recipe for problems.
[Bug rtl-optimization/83723] [8 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:1010
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83723 --- Comment #3 from Jakub Jelinek --- Do you perhaps have the unreduced preprocessed source + full command line?
[Bug ada/83765] LTO bootstrap with Ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765 --- Comment #3 from rguenther at suse dot de --- On Wed, 10 Jan 2018, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765 > > Eric Botcazou changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2018-01-10 > CC||ebotcazou at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #2 from Eric Botcazou --- > The combination Ada + LTO + debug has always been a recipe for problems. Yes... the patch seems to fix it though (ha!). It would be interesting as well to know if the early LTO debug work helps in debugging Ada programs compiled with LTO ;)
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #24 from sergey.shalnov at intel dot com ---
Richard,
The latest "SLP costing for constants/externs improvement" patch generates the
same code as baseline for the test example.
Are you sure that "num_vects_to_check" should 1 if vector is not constant? I
would expect "num_vects_to_check = ncopies_for_cost;" here:
1863 else
1864{
1865 num_vects_to_check = 1;
1866 nelt_limit = group_size;
1867}
Sergey
[Bug tree-optimization/83189] [8 regression] internal compiler error: in probability_in, at profile-count.h:1050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83189
--- Comment #6 from Jan Hubicka ---
The fix at updating time is to promote to non-guessed 0 when it is demanded.
Index: tree-ssa-loop-manip.c
===
--- tree-ssa-loop-manip.c (revision 256419)
+++ tree-ssa-loop-manip.c (working copy)
@@ -1378,7 +1378,8 @@ tree_transform_and_unroll_loop (struct l
{
/* Avoid dropping loop body profile counter to 0 because of zero count
in loop's preheader. */
- freq_e = freq_e.force_nonzero ();
+ if (freq_h.nonzero_p () && !(freq_e == profile_count::zero ()))
+freq_e = freq_e.force_nonzero ();
scale_loop_frequencies (loop, freq_e.probability_in (freq_h));
}
What is odd however is that predictive comonning is trying to do something
about loop executed 0 times. This should be fixed incrementally though. I will
test this change.
[Bug target/83761] bfin: ICE: in require, at machmode.h:292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761 --- Comment #1 from Sebastian Huber --- Created attachment 43086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43086&action=edit Makefile to build the cross GCC Use make clone make install/bin/bfin-rtems5-ld make install/bin/bfin-rtems5-gcc to build the cross GCC to reproduce the problem.
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #25 from rguenther at suse dot de ---
On Wed, 10 Jan 2018, sergey.shalnov at intel dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
>
> --- Comment #24 from sergey.shalnov at intel dot com ---
> Richard,
> The latest "SLP costing for constants/externs improvement" patch generates the
> same code as baseline for the test example.
>
> Are you sure that "num_vects_to_check" should 1 if vector is not constant? I
> would expect "num_vects_to_check = ncopies_for_cost;" here:
>
> 1863 else
> 1864{
> 1865 num_vects_to_check = 1;
> 1866 nelt_limit = group_size;
> 1867}
Yes, that's correct for variable length vectors (SVE)
[Bug debug/83765] LTO bootstrap with Ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765 Eric Botcazou changed: What|Removed |Added CC||derodat at adacore dot com --- Comment #4 from Eric Botcazou --- > Yes... the patch seems to fix it though (ha!). It would be interesting > as well to know if the early LTO debug work helps in debugging Ada > programs compiled with LTO ;) We have been crossing fingers about that for some time. ;-) CCing the expert.
[Bug target/83687] [6/7/8 Regression] ARM NEON invalid optimisation for vabd/vabdl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83687 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 CC||ktkachov at gcc dot gnu.org Summary|ARM NEON invalid|[6/7/8 Regression] ARM NEON |optimisation for vabd/vabdl |invalid optimisation for ||vabd/vabdl Ever confirmed|0 |1 Known to fail||4.8.5, 4.9.4, 5.4.1, 6.4.1, ||7.2.1, 8.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed on all active branches. Combining VSUB + VABS into VABD in this way is not valid for integers.
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008 --- Comment #26 from sergey.shalnov at intel dot com --- Sorry, did you meant "arm_sve.h" on ARM? In this case we have machine specific code in common part of the gcc code. Should we make it as machine dependent callback function because having "num_vects_to_check = 1" is incorrect for SSE?
[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008 --- Comment #27 from rguenther at suse dot de --- On Wed, 10 Jan 2018, sergey.shalnov at intel dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008 > > --- Comment #26 from sergey.shalnov at intel dot com --- > Sorry, did you meant "arm_sve.h" on ARM? > In this case we have machine specific code in common part of the gcc code. > Should we make it as machine dependent callback function because having > "num_vects_to_check = 1" is incorrect for SSE? TYPE_VECTOR_SUBPARTS is never non-constant for SSE.
[Bug target/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83740 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #4 from Janne Blomqvist --- Thanks for the report. I'm not able to reproduce the original ICE, but I can reproduce the ICE reported in #c3. I have a fix which I'll commit as obvious once I run through the testsuite.
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 --- Comment #31 from Martin Liška --- Author: marxin Date: Wed Jan 10 10:54:20 2018 New Revision: 256422 URL: https://gcc.gnu.org/viewcvs?rev=256422&root=gcc&view=rev Log: Clean up partitioning in try_optimize_cfg (PR bootstrap/82831). 2018-01-10 Martin Liska PR bootstrap/82831 * basic-block.h (CLEANUP_NO_PARTITIONING): New define. * bb-reorder.c (pass_reorder_blocks::execute): Do not clean up partitioning. * cfgcleanup.c (try_optimize_cfg): Fix up partitioning if CLEANUP_NO_PARTITIONING is not set. Modified: trunk/gcc/ChangeLog trunk/gcc/basic-block.h trunk/gcc/bb-reorder.c trunk/gcc/cfgcleanup.c
[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #32 from Martin Liška --- Fixed.
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 --- Comment #43 from Jan Hubicka --- Author: hubicka Date: Wed Jan 10 11:02:55 2018 New Revision: 256424 URL: https://gcc.gnu.org/viewcvs?rev=256424&root=gcc&view=rev Log: PR target/81616 * i386.c (ix86_vectorize_builtin_gather): Check TARGET_USE_GATHER. * i386.h (TARGET_USE_GATHER): Define. * x86-tune.def (X86_TUNE_USE_GATHER): New. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/x86-tune.def
[Bug c++/81918] [7/8 Regression] muddles Concept confuses compiler (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81918
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
template auto baz ();
template concept bool e = requires (C a, D f) {{ f (a)
}};
template requires e auto bar (G, G, D);
void
foo ()
{
int i { bar (baz, i, [](auto j) { return j; }); };
}
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #55 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #54 from Richard Biener --- > Created attachment 43075 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43075&action=edit > Updated patch with SHT_GROUP and extended section index handling > > More fixes accumulated. Works for the large # input section testcase now. > Also goes happily into stage2 with bootstrap-lto. Solaris ld is almost happy again with this patch :-) There's one last failure remaining: FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors) Excess errors: ld: fatal: relocation error: R_386_32: file /var/tmp//cctCq6ccdebugobjtem: section [11].rel.debug_macro: symbol .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 (section): symbol has been discarded with discarded section: [6].debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 Compiling the test with -save-temps works, however... Here's what I find: the error happens during the ld -r stage again. The invocations boil down to $ lto-wrapper pr41893-1.o pr41893-2.o $ ld -r -o ccO7nK8bdebugobj cc0vpSPddebugobjtem ccTcSAFadebugobjtem elfdump complains about those objects: cc0vpSPddebugobjtem: [2: .group%wm4.0.3a71fa84800da6806674b2243f0bb574][2]: invalid section index: 0 as can be seen with elfdump -g: Group Section: .group%wm4.0.3a71fa84800da6806674b2243f0bb574 Signature Symbol: wm4.0.3a71fa84800da6806674b2243f0bb574 Members: index flags / section [0] [ COMDAT ] [1] .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 [2] while readelf -g doesn't seem to care about the section index here: COMDAT group section [2] `.group%wm4.0.3a71fa84800da6806674b2243f0bb574' [wm4.0.3a71fa84800da6806674b2243f0bb574] contains 2 sections: [Index]Name [6] .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 [0] The input object had COMDAT group section [2] `.group%wm4.0.3a71fa84800da6806674b2243f0bb574' [wm4.0.3a71fa84800da6806674b2243f0bb574] contains 2 sections: [Index]Name [7] .gnu.debuglto_.debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 [ 25] .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 Rainer
[Bug target/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83740 --- Comment #5 from Janne Blomqvist --- Author: jb Date: Wed Jan 10 11:34:45 2018 New Revision: 256426 URL: https://gcc.gnu.org/viewcvs?rev=256426&root=gcc&view=rev Log: PR 83740 Wrong string length type in bounds check This patch fixes up the formatting and corrects the PR number in the ChangeLog for r256425. gcc/fortran/ChangeLog: 2018-01-10 Janne Blomqvist PR fortran/83740 * trans-array.c (gfc_trans_array_ctor_element): Fix formatting. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c
[Bug target/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83740 --- Comment #6 from Janne Blomqvist --- Should be fixed by r256425 (and r256426). Gerhard, can you verify whether the ICE you reported also goes away, given that neither me nor Jakub in #c3 were able to reproduce it?
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
Richard Biener changed:
What|Removed |Added
Target Milestone|8.0 |6.5
Summary|[8 regression] |[6/7/8 regression]
|gcc.dg/guality/pr41616-1.c |gcc.dg/guality/pr41616-1.c
|fail|fail, inline instances
||refer to concrete instance
||as abstract origin
--- Comment #8 from Richard Biener ---
In the end this is probably also an issue with how we represent clones (and how
we do not, and cannot, generate an "early" DIE for it).
It might be better to view a clone of F as a wrapper around an inline instance
of F which means we wouldn't add any elaborate debug for the clone itself but
its
subroutine DIE would stand on its own (no abstract origin) and the relation to
F would be fully via the inlined-subroutine DIE.
Thus avoid the abstract origin stuff tree_function_versioning does:
/* Output the inlining info for this abstract function, since it has been
inlined. If we don't do this now, we can lose the information about the
variables in the function when the blocks get blown away as soon as we
remove the cgraph node. */
(*debug_hooks->outlining_inline_function) (old_decl);
DECL_ARTIFICIAL (new_decl) = 1;
DECL_ABSTRACT_ORIGIN (new_decl) = DECL_ORIGIN (old_decl);
if (DECL_ORIGIN (old_decl) == old_decl)
old_version_node->used_as_abstract_origin = true;
DECL_FUNCTION_PERSONALITY (new_decl) = DECL_FUNCTION_PERSONALITY (old_decl);
it might be even possible to implicitely hack things up by adding a
inlined_function_outer_scope_p () scope containing the abstract origin instead.
A quick hack shows it doesn't really resolve the issue here and I'm not sure
the same issue doesn't exist with regular inlines if a concrete instance
prevails as well. Indeed. The following small C testcase shows the exact
same issue at -O2 -g:
int foo (int i)
{
volatile int boring = 1;
return boring + i;
}
int bar()
{
int tem = 1;
return tem + foo (0);
}
<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e> DW_AT_external: 1
<2e> DW_AT_name: bar
...
<2><5c>: Abbrev Number: 4 (DW_TAG_inlined_subroutine)
<5d> DW_AT_abstract_origin: <0xa2>
<61> DW_AT_low_pc : 0x10
<69> DW_AT_high_pc : 0xc
<71> DW_AT_call_file : 1
<72> DW_AT_call_line : 10
<73> DW_AT_call_column : 16
<3><74>: Abbrev Number: 5 (DW_TAG_formal_parameter)
<75> DW_AT_abstract_origin: <0xb3>
<79> DW_AT_location: 0x0 (location list)
<3><7d>: Abbrev Number: 6 (DW_TAG_lexical_block)
<7e> DW_AT_low_pc : 0x10
<86> DW_AT_high_pc : 0xc
<4><8e>: Abbrev Number: 7 (DW_TAG_variable)
<8f> DW_AT_abstract_origin: <0xe8> // refers to concrete instance!
...
<1>: Abbrev Number: 10 (DW_TAG_subprogram)// abstract instance
DW_AT_external: 1
DW_AT_name: foo
...
<2>: Abbrev Number: 11 (DW_TAG_formal_parameter)
DW_AT_name: i
DW_AT_decl_file : 1
DW_AT_decl_line : 1
DW_AT_decl_column : 14
DW_AT_type: <0x96>
<2>: Abbrev Number: 12 (DW_TAG_variable)
DW_AT_name: (indirect string, offset: 0x8e): boring
DW_AT_decl_file : 1
DW_AT_decl_line : 3
DW_AT_decl_column : 16
DW_AT_type: <0x9d>
<2>: Abbrev Number: 0
<1>: Abbrev Number: 13 (DW_TAG_subprogram) // concrete instance
DW_AT_abstract_origin: <0xa2>
DW_AT_low_pc : 0x0
DW_AT_high_pc : 0xf
DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
DW_AT_GNU_all_call_sites: 1
<2>: Abbrev Number: 14 (DW_TAG_formal_parameter)
DW_AT_abstract_origin: <0xb3>
DW_AT_location: 1 byte block: 55 (DW_OP_reg5 (rdi))
<2>: Abbrev Number: 15 (DW_TAG_variable)
DW_AT_abstract_origin: <0xbd>
DW_AT_location: 2 byte block: 91 74 (DW_OP_fbreg: -12)
<2>: Abbrev Number: 0
The same behavior already exists with GCC 7 and GCC 6 but not GCC 5.
[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726 --- Comment #6 from Wilco --- (In reply to Steve Ellcey from comment #4) > This looks like the same thing as PR 83632. It likely is, I don't see it failing with my patch. Older compilers don't appear to like the Fortran syntax...
[Bug ipa/83532] [8 Regression] ICE in apply_scale, at profile-count.h:955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83532 --- Comment #2 from Martin Liška --- (In reply to Jan Hubicka from comment #1) > Does this help? Seems we omit adjustment when producing partial function > clone. > > Index: tree-inline.c > === > --- tree-inline.c (revision 256324) > +++ tree-inline.c (working copy) > @@ -2683,7 +2683,6 @@ >profile_count den = ENTRY_BLOCK_PTR_FOR_FN (src_cfun)->count; >profile_count num = entry_block_map->count; > > - profile_count::adjust_for_ipa_scaling (&num, &den); > >cfun_to_copy = id->src_cfun = DECL_STRUCT_FUNCTION (callee_fndecl); > > @@ -2707,6 +2706,8 @@ >ENTRY_BLOCK_PTR_FOR_FN (cfun)->count = den; > } > > + profile_count::adjust_for_ipa_scaling (&num, &den); > + >/* Must have a CFG here at this point. */ >gcc_assert (ENTRY_BLOCK_PTR_FOR_FN > (DECL_STRUCT_FUNCTION (callee_fndecl))); Let me test it.
[Bug fortran/83762] ICE on variable declaration with undefined PDT parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83762 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 Blocks||82173 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug fortran/83763] PDT variable sees content deallocated if variable is passed as an input to a function, and the function result is assigned to that same variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83763 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 Blocks||82173 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 [Bug 82173] [meta-bug] Parameterized derived type errors
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
--- Comment #9 from Richard Biener ---
A workaround might be in dwarf2out_function_decl push/pop the decl_die_table
like with a "simple" undo stack:
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 256378)
+++ gcc/dwarf2out.c (working copy)
@@ -3159,6 +3159,7 @@ struct decl_die_hasher : ggc_ptr_hash *decl_die_table;
+static vec > *decl_die_table_undo_stack;
struct GTY ((for_user)) variable_value_struct {
unsigned int decl_id;
@@ -5762,7 +5763,10 @@ equate_decl_number_to_die (tree decl, dw
{
unsigned int decl_id = DECL_UID (decl);
- *decl_die_table->find_slot_with_hash (decl, decl_id, INSERT) = decl_die;
+ dw_die_ref *slot = decl_die_table->find_slot_with_hash (decl, decl_id,
INSERT);
+ if (*slot && decl_die_table_undo_stack)
+decl_die_table_undo_stack->safe_push (std::make_pair (decl, *slot));
+ *slot = decl_die;
decl_die->decl_id = decl_id;
}
@@ -26044,6 +26048,10 @@ dwarf2out_decl (tree decl)
static void
dwarf2out_function_decl (tree decl)
{
+ vec > *undo_stack
+= new vec > ();
+ decl_die_table_undo_stack = undo_stack;
+
dwarf2out_decl (decl);
call_arg_locations = NULL;
call_arg_loc_last = NULL;
@@ -26051,6 +26059,15 @@ dwarf2out_function_decl (tree decl)
tail_call_site_count = -1;
decl_loc_table->empty ();
cached_dw_loc_list_table->empty ();
+
+ decl_die_table_undo_stack = NULL;
+ while (! undo_stack->is_empty ())
+{
+ std::pair op = undo_stack->pop ();
+ equate_decl_number_to_die (op.first, op.second);
+}
+
+ delete undo_stack;
}
/* Output a marker (i.e. a label) for the beginning of the generated code for
[Bug testsuite/83706] [8 regression] gcc.dg/ipa/inline-2.c and gcc.dg/ipa/inline-3.c fail starting with r256279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83706 --- Comment #7 from Martin Liška --- (In reply to Jan Hubicka from comment #6) > Yep, those rounding issues are anoying. It won't buy us any code quality but > I guess using sreals for change prob is most consistent way around. It > seems that sreals are quite prone to rounding issues :(. May I do it or will you do it yourselves? Is it fine to do it right now in ending stage3?
[Bug fortran/83744] ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093 while using -fc-prototypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83744 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed. For the first two tests the ICE comes from a gcc_assert (rok != T_ERROR);.
[Bug fortran/83746] Errors using the max intrinsic in a PDT length parameter expression for a function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83746 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed.
[Bug fortran/83745] New: Errors using the max intrinsic in a PDT length parameter expression for a function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83745 Bug ID: 83745 Summary: Errors using the max intrinsic in a PDT length parameter expression for a function result Product: gcc Version: 8.0 Status: RESOLVED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: berke.durak at gmail dot com Target Milestone: --- Status: RESOLVED Resolution: DUPLICATE Found another one. When a length parameter for a function result is dynamically computed from argument parameters, the max() intrinsic causes spurious warnings and the parameter is set incorrectly, possibly uninitialized at run time: module pdt_m implicit none type :: vec(k) integer, len :: k=0 integer :: foo(k) end type vec contains elemental function diy_max(a,b) result(c) integer, intent(in) :: a,b integer :: c c=max(a,b) end function diy_max function add(a,b) result(c) type(vec(k=*)), intent(in) :: a,b type(vec(k=max(a%k,b%k))) :: c ! Fails !type(vec(k=diy_max(a%k,b%k))) :: c ! Works with diy_max !type(vec(k=a%k+b%k)) :: c ! Works with + c%foo=0 c%foo(1:a%k)=a%foo c%foo(1:b%k)=c%foo(1:b%k)+b%foo print *,'c%k=',c%k end function add end module pdt_m program test_pdt use pdt_m implicit none type(vec(k=2)) :: u type(vec(k=3)) :: v,w print *,'w%k=',w%k print *,'size(w%foo)=',size(w%foo) u%foo=[1,2] v%foo=[10,20,30] w=add(u,v) print *,'w%k=',w%k print *,'size(w%foo)=',size(w%foo) end program test_pdt % /usr/local/gfortran-bin/bin/gfortran pdt.f90 -o pdt -Wall -Wextra -g pdt.f90:25:0: end function add Warning: ‘M.4’ is used uninitialized in this function [-Wuninitialized] pdt.f90:25:0: end function add note: ‘M.4’ was declared here pdt.f90:25:0: end function add Warning: ‘M.5’ is used uninitialized in this function [-Wuninitialized] pdt.f90:25:0: end function add note: ‘M.5’ was declared here % ./pdt w%k= 3 size(w%foo)= 3 c%k= 329917520 w%k= 329917520 size(w%foo)= 0 And with -fcheck=all: w%k= 3 size(w%foo)= 3 At line 21 of file pdt.f90 Fortran runtime error: Index '1' of dimension 1 of array 'c' outside of expected range (1:0) Error termination. Backtrace: #0 0x400ded in __pdt_m_MOD_add at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:21 #1 0x40183d in test_pdt at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:39 #2 0x401a61 in main at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:29 Version: % /usr/local/gfortran-bin/bin/gfortran --version GNU Fortran (GCC) 8.0.0 20180109 (experimental) [trunk revision 256361] Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. --- Comment #1 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 83746 ***
[Bug fortran/83746] Errors using the max intrinsic in a PDT length parameter expression for a function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83746 --- Comment #3 from Dominique d'Humieres --- *** Bug 83745 has been marked as a duplicate of this bug. ***
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
--- Comment #10 from Richard Biener ---
I'm quite sure older GCC must be somehow affected - or I'm really curious how
they are not.
While the patch fixes the dwarf for the small C testcase it doesn't fix the
pr41616-1.c execute fail. The dwarf looks "fine" there as well though,
what we lack is a call-site parameter for the 2nd gual_checkval:
<4><6e5>: Abbrev Number: 39 (DW_TAG_GNU_call_site)
<6e6> DW_AT_low_pc : 0x19d
<6ee> DW_AT_abstract_origin: <0x859>
<6f2> DW_AT_sibling : <0x70a>
<5><6f6>: Abbrev Number: 38 (DW_TAG_GNU_call_site_parameter)
<6f7> DW_AT_location: 1 byte block: 55(DW_OP_reg5 (rdi))
<6f9> DW_AT_GNU_call_site_value: 9 byte block: 3 78 0 0 0 0 0 0 0
(DW_OP_addr: 78)
<5><703>: Abbrev Number: 38 (DW_TAG_GNU_call_site_parameter)
<704> DW_AT_location: 1 byte block: 54(DW_OP_reg4 (rsi))
<706> DW_AT_GNU_call_site_value: 2 byte block: 9 ff (DW_OP_const1s:
-1)
<5><709>: Abbrev Number: 0
<4><70a>: Abbrev Number: 37 (DW_TAG_GNU_call_site)
<70b> DW_AT_low_pc : 0x1b6
<713> DW_AT_abstract_origin: <0x859>
<5><717>: Abbrev Number: 38 (DW_TAG_GNU_call_site_parameter)
<718> DW_AT_location: 1 byte block: 55(DW_OP_reg5 (rdi))
<71a> DW_AT_GNU_call_site_value: 9 byte block: 3 78 0 0 0 0 0 0 0
(DW_OP_addr: 78)
<5><724>: Abbrev Number: 0
<4><725>: Abbrev Number: 0
and the location list for the decl itself is
0365 0198 01ae (DW_OP_const1s: -1;
DW_OP_stack_value)
which covers too many instructions(?). We expand from
# DEBUG b => -1
# DEBUG BEGIN_STMT
guality_check.constprop ("b", -1);
# DEBUG BEGIN_STMT
if (_35 > 0)
goto ; [64.00%]
else
goto ; [36.00%]
;;succ: 18
;;19
;; basic block 18, loop depth 0
;;pred: 17
;;succ: 19
;; basic block 19, loop depth 0
;;pred: 17
;;18
# b_88 = PHI <-1(17), 1(18)>
# DEBUG b => b_88
# DEBUG BEGIN_STMT
_89 = (long int) b_88;
guality_check.constprop ("b", _89);
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 --- Comment #11 from Jakub Jelinek --- Isn't that related to PR68860, where because of LTO breaking DECL_ABSTRACT_ORIGINs we don't emit the more advanced DWARF extensions (or DWARF5) stuff, like DW_OP_GNU_parameter_ref etc.?
[Bug middle-end/83718] [8 Regression] ICE: Floating point exception in profile_count::apply_scale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718 --- Comment #4 from Martin Liška --- Created attachment 43087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43087&action=edit test-case
[Bug middle-end/83718] [8 Regression] ICE: Floating point exception in profile_count::apply_scale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|marxin at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Martin Liška --- Nice, fixed by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83532#c1. Honza please test-case which I'm going to attach to the PR.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
--- Comment #56 from rguenther at suse dot de ---
On Wed, 10 Jan 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968
>
> --- Comment #55 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
> > --- Comment #54 from Richard Biener ---
> > Created attachment 43075
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43075&action=edit
> > Updated patch with SHT_GROUP and extended section index handling
> >
> > More fixes accumulated. Works for the large # input section testcase now.
> > Also goes happily into stage2 with bootstrap-lto.
>
> Solaris ld is almost happy again with this patch :-)
>
> There's one last failure remaining:
>
> FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors)
> Excess errors:
> ld: fatal: relocation error: R_386_32: file /var/tmp//cctCq6ccdebugobjtem:
> section [11].rel.debug_macro: symbol
> .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574 (section): symbol has been
> discarded with discarded section:
> [6].debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
>
> Compiling the test with -save-temps works, however...
>
> Here's what I find: the error happens during the ld -r stage again. The
> invocations boil down to
>
> $ lto-wrapper pr41893-1.o pr41893-2.o
> $ ld -r -o ccO7nK8bdebugobj cc0vpSPddebugobjtem ccTcSAFadebugobjtem
>
> elfdump complains about those objects:
>
> cc0vpSPddebugobjtem: [2: .group%wm4.0.3a71fa84800da6806674b2243f0bb574][2]:
> invalid section index: 0
>
> as can be seen with elfdump -g:
>
> Group Section: .group%wm4.0.3a71fa84800da6806674b2243f0bb574
> Signature Symbol: wm4.0.3a71fa84800da6806674b2243f0bb574
> Members:
> index flags / section
> [0] [ COMDAT ]
> [1] .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
> [2]
>
> while readelf -g doesn't seem to care about the section index here:
>
> COMDAT group section [2] `.group%wm4.0.3a71fa84800da6806674b2243f0bb574'
> [wm4.0.3a71fa84800da6806674b2243f0bb574] contains 2 sections:
>[Index]Name
>[6] .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
>[0]
>
> The input object had
>
> COMDAT group section [2] `.group%wm4.0.3a71fa84800da6806674b2243f0bb574'
> [wm4.0.3a71fa84800da6806674b2243f0bb574] contains 2 sections:
>[Index]Name
>[7] .gnu.debuglto_.debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
>[ 25] .debug_macro%wm4.0.3a71fa84800da6806674b2243f0bb574
>
> Rainer
I can reproduce that with -ffat-lto-objects where indeed we somehow
get confused when we should preserve only part of a SHT_GROUP given
we don't "prune" groups. The question to me is why do we put
both macro sections in a single group ... but that's probably
an artifact on how things are supposed to work in the end...
[I wonder if SHF_EXCLUDE works "properly" for group members when
doing a non-LTO link]
Anyway, this should be "easy" to fix with sth like
else if (sh_type == SHT_GROUP)
{
/* Remap section indices in groups and remove removed members.
*/
unsigned char *ent, *dst;
for (dst = ent = buf + 4; ent < buf + length - 4; ent += 4)
{
unsigned shndx = type_functions->fetch_Elf_Word (ent);
if (pfnret[shndx - 1] == -1)
;
else
{
type_functions->set_Elf_Word (dst, sh_map[shndx]);
dst += 4;
}
}
/* Adjust the length. */
length = dst - buf;
}
in the group handling.
That fixes -ffat-lto-objects handling for me with the testcase.
Will re-test with that.
[Bug debug/83157] [6/7/8 regression] gcc.dg/guality/pr41616-1.c fail, inline instances refer to concrete instance as abstract origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 --- Comment #12 from rguenther at suse dot de --- On Wed, 10 Jan 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157 > > --- Comment #11 from Jakub Jelinek --- > Isn't that related to PR68860, where because of LTO breaking > DECL_ABSTRACT_ORIGINs we don't emit the more advanced DWARF extensions (or > DWARF5) stuff, like DW_OP_GNU_parameter_ref etc.? Maybe it is related but this issue happens without LTO.
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #34 from Eric Gallager --- (In reply to Eric Gallager from comment #33) > gcc no longer carries its own copy of the boehm-gc sources. Is there any > reason to keep this bug open? WAITING on a response
[Bug tree-optimization/83753] ICE: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83753 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed Jan 10 13:07:54 2018 New Revision: 256427 URL: https://gcc.gnu.org/viewcvs?rev=256427&root=gcc&view=rev Log: Don't use permutes for single-element accesses (PR83753) After cunrolling the inner loop, the remaining loop in the testcase has a single 32-bit access and a group of 64-bit accesses. We first try to vectorise at 128 bits (VF 4), but decide not to for cost reasons. We then try with 64 bits (VF 2) instead. This means that the group of 64-bit accesses uses a single-element vector, which is deliberately supported as of r251538. We then try to create "permutes" for these single-element vectors and fall foul of: for (i = 0; i < 6; i++) sel[i] += exact_div (nelt, 2); in vect_grouped_store_supported, since nelt==1. Maybe we shouldn't even be trying to vectorise statements in the single-element case, and instead just copy the scalar statement for each member of the group. But until then, this patch treats non-strided grouped accesses as VMAT_CONTIGUOUS if no permutation is necessary. 2018-01-10 Richard Sandiford gcc/ PR tree-optimization/83753 * tree-vect-stmts.c (get_group_load_store_type): Use VMAT_CONTIGUOUS for non-strided grouped accesses if the number of elements is 1. gcc/testsuite/ PR tree-optimization/83753 * gcc.dg/torture/pr83753.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr83753.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/83753] ICE: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83753 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug rtl-optimization/81791] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81791 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed by r256420.
[Bug rtl-optimization/83475] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 3 reachable only by paths crossing the cold partition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83475 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Also fixed in r256420.
[Bug c++/81997] [7/8 Regression] segfault while instantiating constrained function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81997
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
template void foo ();
namespace std {
template struct initializer_list {
int *b;
unsigned long c;
int begin ();
int m ();
};
}
template concept bool g = requires(E x) { x (foo );
};
template requires g)> I bar (H, H,
I);
void
baz ()
{
auto l = {5};
bar (l.begin (), l.m (), [](auto m) { m; });
}
Probably related to PR81918, at least the error is the same, just error
recovery different.
[Bug target/83687] [6/7/8 Regression] ARM NEON invalid optimisation for vabd/vabdl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83687 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Testing a patch.
[Bug c++/83767] New: -Wsuggest-override suggests to mark as override in methods marked as final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83767
Bug ID: 83767
Summary: -Wsuggest-override suggests to mark as override in
methods marked as final
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: albert.astals.cid at kdab dot com
Target Milestone: ---
Created attachment 43088
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43088&action=edit
example code
I know that final does not always imply override but in the attached code it
does.
I think it would be great if -Wsuggest-override did not show a warning in this
case.
Code both here and attached.
struct A
{
virtual void foo()
{
}
};
struct B : public A
{
void foo() final
{
}
};
int main(int, char**)
{
B b;
return 0;
}
[Bug c++/83767] -Wsuggest-override suggests to mark as override in methods marked as final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83767 Albert Astals Cid changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Albert Astals Cid --- I just saw it's a duplicate, sorry for the noise *** This bug has been marked as a duplicate of bug 78010 ***
[Bug c++/78010] --Wsuggest-override reports a redundant warning on a 'final' method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010 Albert Astals Cid changed: What|Removed |Added CC||albert.astals.cid at kdab dot com --- Comment #7 from Albert Astals Cid --- *** Bug 83767 has been marked as a duplicate of this bug. ***
[Bug c++/81067] [8 regression] g++.dg/template/nontype10.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81067 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/81167] [8 Regression] ICE on valid C++ code in deferred_printed_type, at cp/error.c:118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81167 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81327 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81550 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/81184] [8 regression] gcc.dg/pr21643.c and gcc.dg/tree-ssa/phi-opt-11.c fail starting with r249450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81184 --- Comment #6 from Christophe Lyon --- Note that I posted a related patch some time ago: https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01477.html
[Bug tree-optimization/83753] ICE: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83753 --- Comment #4 from Vidya Praveen --- Thanks for fixing this, Richard!
[Bug debug/83765] LTO bootstrap with Ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Jan 10 14:23:29 2018 New Revision: 256428 URL: https://gcc.gnu.org/viewcvs?rev=256428&root=gcc&view=rev Log: 2018-01-10 Richard Biener PR debug/83765 * dwarf2out.c (gen_subprogram_die): Hoist old_die && declaration early out so it also covers the case where we have a non-NULL origin. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug tree-optimization/81635] [8 Regression] nvptx SLP test cases regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81635 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/83054] [8 Regression] ICE in operator>, at profile-count.h:823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83054 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-10 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I have patch for it.
[Bug tree-optimization/83055] [8 Regression] ICE in operator>, at profile-count.h:834
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83055 --- Comment #5 from Martin Liška --- (In reply to Martin Liška from comment #4) > One another test-case with a bit different back-trace: > > $ g++ > /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.mike/p789a.C > /dev/null -Wsuggest-final-types -Ofast > during IPA pass: devirt > /home/marxin/Programming/gcc/gcc/testsuite/g++.old-deja/g++.mike/p789a.C:44: > 1: internal compiler error: in operator>, at profile-count.h:827 > } > ^ > 0xba372c profile_count::operator>(long) const > ../../gcc/profile-count.h:827 > 0xba372c ipa_devirt > ../../gcc/ipa-devirt.c:3750 > 0xba372c execute > ../../gcc/ipa-devirt.c:3892 This one is dup of PR83054, however https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83055#c1 is a different story.
[Bug c++/81843] [8 Regression] ICE on valid C++11 code with variadic templates: in tsubst_pack_expansion, at cp/pt.c:11524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81843 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/81917] [6/7/8 Regression] internal compiler error: in finish_member_declaration, at cp/semantics.c:3004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81917 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249
Richard Biener changed:
What|Removed |Added
Keywords|diagnostic |rejects-valid
Priority|P3 |P1
Known to work||7.2.1
--- Comment #4 from Richard Biener ---
GCC 7 accepts the code. My version of clang rejects it with
t.C:5:6: error: constexpr variable 'calc' must be initialized by a constant
expression
[](auto n, auto dim)noexcept{ return dim; };
^~~
[Bug middle-end/82362] [8 Regression] SPEC CPU2006 436.cactusADM ~7% performance deviation with trunk@251713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82362 Richard Biener changed: What|Removed |Added CC||wilco at gcc dot gnu.org Component|fortran |middle-end Severity|enhancement |normal
[Bug debug/82425] [8 regression] gcc.dg/guality/inline-params-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82425 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug debug/82425] [8 regression] gcc.dg/guality/inline-params-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82425 --- Comment #3 from Richard Biener --- Author: rguenth Date: Wed Jan 10 14:41:34 2018 New Revision: 256429 URL: https://gcc.gnu.org/viewcvs?rev=256429&root=gcc&view=rev Log: 2018-01-10 Richard Biener PR debug/82425 * gcc.dg/guality/inline-params-2.c: Un-XFAIL for slim LTO. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/guality/inline-params-2.c
[Bug c++/82514] [8 Regression] ICE: in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82514 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82604 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 Ever confirmed|0 |1 --- Comment #9 from Richard Biener --- Confirmed at least.
[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82682 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/82728] [8 regression] Incorrect -Wunused-but-set-variable warning with a const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82728 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug testsuite/82770] [8 regression] gcc.dg/pr78768.c xpass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82770 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- With -v you can clearly see the warnings are emitted from lto1. If you'd use fat LTO objects you'd see them twice but the testcase requires a linker plugin. So I think the XFAIL needs to simply be removed. Will commit that change now.
[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78768 --- Comment #13 from Richard Biener --- Author: rguenth Date: Wed Jan 10 14:51:07 2018 New Revision: 256430 URL: https://gcc.gnu.org/viewcvs?rev=256430&root=gcc&view=rev Log: 2018-01-10 Richard Biener PR testsuite/78768 * gcc.dg/pr78768.c: Un-XFAIL. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr78768.c
[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249 --- Comment #5 from Benjamin Buch --- The code is accepted by clang since version 4.0. Older versions probably don't support constexpr lambdas.
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #30 from Jakub Jelinek --- Any progress on this? Or shall we just disable completely hot/cold function partitioning on darwin till then?
[Bug tree-optimization/82965] [8 regression][armeb] gcc.dg/vect/pr79347.c starts failing after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 Component|other |tree-optimization Ever confirmed|0 |1
[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-10 Ever confirmed|0 |1
