[Bug c++/89630] New: [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

Bug ID: 89630
   Summary: [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64, r269472 gave

[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -mrtm
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/cpp0x/alias-decl-64.C
-S  -std=c++14  -march=skylake-avx512
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/cpp0x/alias-decl-64.C:14:37:
internal compiler error: canonical types differ for identical types
‘A<#‘using_decl’ not supported by dump_expr# >’ and
‘A<#‘using_decl’ not supported by dump_expr# >’
   14 |   void operator()(typename C>::i);
  | ^~
0xba75ff comptypes(tree_node*, tree_node*, int)
/export/gnu/import/git/sources/gcc/gcc/cp/typeck.c:1479
0xaca892 template_args_equal(tree_node*, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:8732
0xacaae9 comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:8780
0xaab4ad spec_hasher::equal(spec_entry*, spec_entry*)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:1701
0xacc948 lookup_template_class_1
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:9388
0xaced4c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:9715
0xb52ed4 finish_template_type(tree_node*, tree_node*, int)
/export/gnu/import/git/sources/gcc/gcc/cp/semantics.c:3290
0xa5cc0a cp_parser_template_id
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:16422
0xa69e5b cp_parser_class_name
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:23208
0xa48a5f cp_parser_qualifying_entity
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:6693
0xa47aff cp_parser_nested_name_specifier_opt
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:6379
0xa487ef cp_parser_nested_name_specifier
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:6619
0xa6017e cp_parser_elaborated_type_specifier
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:18260
0xa5e7a2 cp_parser_type_specifier
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:17398
0xa58ca0 cp_parser_decl_specifier_seq
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:14065
0xa68077 cp_parser_parameter_declaration
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:22296
0xa67acb cp_parser_parameter_declaration_list
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:22119
0xa67996 cp_parser_parameter_declaration_clause
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:22046
0xa64ff2 cp_parser_direct_declarator
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:20744
0xa64e5d cp_parser_declarator
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:20612
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-cfl-2 gcc]$

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-08
 CC||jakub at redhat dot com
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
This is caused by r269467.

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
How could it be related?  Is the compiler miscompiled?
Do you get this with stage1, stage2 or stage3?

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

--- Comment #3 from Jakub Jelinek  ---
In a non-bootstrapped compiler I certainly can't reproduce, nor reproduced it
in bootstrap when I've tested the patch.  How exactly have you configured your
compiler?

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

--- Comment #4 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #3)
> In a non-bootstrapped compiler I certainly can't reproduce, nor reproduced
> it in bootstrap when I've tested the patch.  How exactly have you configured
> your compiler?

No special configuration is needed. Please
try

-mrtm -march=skylake-avx512 -std=c++14

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

--- Comment #5 from Jakub Jelinek  ---
Ah, ok, I was trying -march=skylake-avx512, but not -mrtm, now I can reproduce.
As this is not a bootstrapped compiler, it can't be miscompiled, so I bet all
my patch changed is adding a few DECL_UIDs (for the new builtins) and thus
changing exact DECL_UIDs used on the testcase.

[Bug target/89578] [9 Regression] 5% runtime regression for 481.wrf at -Ofast -flto

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89578

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 89578, which changed state.

Bug 89578 Summary: [9 Regression] 5% runtime regression for 481.wrf at -Ofast 
-flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89578

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/89578] [9 Regression] 5% runtime regression for 481.wrf at -Ofast -flto

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89578

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Mar  8 10:20:12 2019
New Revision: 269484

URL: https://gcc.gnu.org/viewcvs?rev=269484&root=gcc&view=rev
Log:
2019-03-08  Richard Biener  

PR middle-end/89578
* cfgloop.h (struct loop): Add owned_clique field.
* cfgloopmanip.c (copy_loop_info): Copy it.
* tree-cfg.c (gimple_duplicate_bb): Do not remap owned_clique
cliques.
* tree-inline.c (copy_loops): Remap owned_clique.
* lto-streamer-in.c (input_cfg): Stream owned_clique.
* lto-streamer-out.c (output_cfg): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.h
trunk/gcc/cfgloopmanip.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-inline.c

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624

--- Comment #2 from Richard Biener  ---
Why do we care for -fshort-enums?  Aren't those outside of the standard?

[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #23 from Jakub Jelinek  ---
Created attachment 45926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45926&action=edit
rh1686696.c

r269302 also fixed the following testcase that has been miscompiled on
s390x-linux with -march=zEC12 -O2 -fno-strict-aliasing at least (or
-march=zEC12 -O2, -fno-strict-aliasing just because the testcase isn't
completely kosher, as it initializes malloced memory through long long array
and then accesses it as a struct containing long long and long long array
fields).
Is it worth adding this into the testsuite?

[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497

--- Comment #24 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #23)
> Created attachment 45926 [details]
> rh1686696.c
> 
> r269302 also fixed the following testcase that has been miscompiled on
> s390x-linux with -march=zEC12 -O2 -fno-strict-aliasing at least (or
> -march=zEC12 -O2, -fno-strict-aliasing just because the testcase isn't
> completely kosher, as it initializes malloced memory through long long array
> and then accesses it as a struct containing long long and long long array
> fields).
> Is it worth adding this into the testsuite?

Hmm, the patch doesn't contain a wrong-code fix - at least not that I know of.
As we've seen it may change generated code so are you sure the reason the
testcase was miscompiled didn't go latent?

[Bug target/89627] Miscompiled constructor call

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89627

--- Comment #2 from Andreas Schwab  ---
FWIW this has been extracted from the swig testsuite.

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/swig/standard/riscv64

[ 3650s]
["/home/abuild/rpmbuild/BUILD/swig-3.0.12/Examples/test-suite/ruby/swig_assert.rb:138:in
`block in swig_assert_each_line'"]: FAILED EQUALITY: halved.to_a == dv.to_a was
[0.0, 0.25, 0.75, 1.25, 1.5, 1.75, 2.0, 2.25] not [0.0, Infinity, Infinity,
Infinity, Infinity, Infinity, Infinity, Infinity]
[ 3650s]from
/home/abuild/rpmbuild/BUILD/swig-3.0.12/Examples/test-suite/ruby/swig_assert.rb:135:in
`each'
[ 3650s]
/home/abuild/rpmbuild/BUILD/swig-3.0.12/Examples/test-suite/ruby/swig_assert.rb:135:in
`swig_assert_each_line'
[ 3650s] ./li_std_vector_runme.rb:224:in `'
[ 3650s] make[1]: *** [Makefile:48: li_std_vector.cpptest] Error 1

[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497

--- Comment #25 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #24)
> (In reply to Jakub Jelinek from comment #23)
> > Created attachment 45926 [details]
> > rh1686696.c
> > 
> > r269302 also fixed the following testcase that has been miscompiled on
> > s390x-linux with -march=zEC12 -O2 -fno-strict-aliasing at least (or
> > -march=zEC12 -O2, -fno-strict-aliasing just because the testcase isn't
> > completely kosher, as it initializes malloced memory through long long array
> > and then accesses it as a struct containing long long and long long array
> > fields).
> > Is it worth adding this into the testsuite?
> 
> Hmm, the patch doesn't contain a wrong-code fix - at least not that I know
> of.
> As we've seen it may change generated code so are you sure the reason the
> testcase was miscompiled didn't go latent?

I'm not sure.  The testcase uses a weird technique where poor man's flexible
array member structure is nested in a poor man's flexible array member of
another structure, so not even sure how valid it is.  See the foo function
which is give me pointer to next structure.
Anyway, what I see in the dumps, thread3 is still the same, but dom3 is
significantly different, r269301 to r269302 diff shows:
-Removing basic block 12
-Removing basic block 13
-Removing basic block 14
...
+h_5 -> { h_16 }
 _10 -> { _13 }
 c_12 -> { c_27 }
 f_14 -> { f_50 }
-c_15 -> { c_27 }
+_15 -> { _13 }
 e_17 -> { e_33 }
-_18 -> { _13 }
+d_18 -> { d_11 }
 h_19 -> { h_16 }
+c_28 -> { c_27 }
+e_42 -> { e_33 }
 d_53 -> { d_11 }
 Incremental SSA update started at block: 2
-Number of blocks in CFG: 14
-Number of blocks to update: 8 ( 57%)
+Number of blocks in CFG: 17
+Number of blocks to update: 9 ( 53%)


+Merging blocks 6 and 16
+Removing basic block 12
+Removing basic block 14
...
@@ -216,7 +219,12 @@ bar (const struct V * x)

[local count: 105119324]:
   # _54 = PHI <_40(5)>
-  goto ; [100.00%]
+  c_12 = MEM[(const struct U *)_40].u1;
+  _10 = d_45 * 2;
+  if (c_12 == 2)
+goto ; [34.00%]
+  else
+goto ; [66.00%]

[local count: 12992277]:
   # f_50 = PHI <_36(4)>
...
(and various other changes), but I think the above hunk looks most important,
it simply

[Bug tree-optimization/89550] [8/9 Regression] Spurious array-bounds warning when using __PRETTY_FUNCTION__ as a string_view

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89550

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 10:46:39 2019
New Revision: 269485

URL: https://gcc.gnu.org/viewcvs?rev=269485&root=gcc&view=rev
Log:
PR tree-optimization/89550
* builtins.c (c_strlen): Only set TREE_NO_WARNING if warning_at
returned true.  Formatting fixes.
(expand_builtin_strnlen): Formatting fixes.
* tree-vrp.c (vrp_prop::check_mem_ref): Only set TREE_NO_WARNING
if warning_at returned true.
* tree-cfg.c (pass_warn_function_return::execute): Likewise.
c-family/
* c-common.c (c_common_truthvalue_conversion): Only set
TREE_NO_WARNING if warning_at returned true.
* c-warn.c (overflow_warning, warn_logical_operator): Likewise.
c/
* c-decl.c (finish_function): Only set TREE_NO_WARNING if warning_at
returned true.
(c_write_global_declarations_1): Only set TREE_NO_WARNING if pedwarn
or warning returned true.
cp/
* semantics.c (maybe_convert_cond): Only set TREE_NO_WARNING if
warning_at returned true.
* decl2.c (c_parse_final_cleanups): Likewise.
* typeck.c (convert_for_assignment): Likewise.
* decl.c (finish_function): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-warn.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-vrp.c

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87875

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #11 from Martin Liška  ---
Unassigning as it's quite rare situation and one can use
detect_stack_use_after_return=false to handle such error.

[Bug other/80058] fix double spaces in string literals everywhere

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80058

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 10:51:28 2019
New Revision: 269487

URL: https://gcc.gnu.org/viewcvs?rev=269487&root=gcc&view=rev
Log:
PR other/80058
* lra-constraints.c (process_alt_operands): Avoid one space before
" at the end of line and another after " on another line in a string
literal.
* attribs.c (handle_dll_attribute): Likewise.
* config/avr/avr-devices.c (avr_texinfo): Likewise.
cp/
* parser.c (cp_parser_template_declaration_after_parameters): Avoid
one space before " at the end of line and another after " on another
line in a string literal.
fortran/
* arith.c (gfc_complex2complex): Avoid two spaces in the middle of
diagnostics.
* resolve.c (resolve_allocate_expr): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/attribs.c
trunk/gcc/config/avr/avr-devices.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/fortran/resolve.c
trunk/gcc/lra-constraints.c

[Bug target/79846] s390: untranslatable diagnostic in s390.c

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79846

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 10:53:27 2019
New Revision: 269489

URL: https://gcc.gnu.org/viewcvs?rev=269489&root=gcc&view=rev
Log:
PR target/79846
* config/s390/s390.c (s390_const_operand_ok): Use %wu instead of
HOST_WIDE_INT_PRINT_UNSIGNED and %wd instead of
HOST_WIDE_INT_PRINT_DEC.  Formatting fixes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c

[Bug ipa/80000] diagnostics: trailing spaces in "one definition rule "

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 10:52:38 2019
New Revision: 269488

URL: https://gcc.gnu.org/viewcvs?rev=269488&root=gcc&view=rev
Log:
PR ipa/8
* ipa-devirt.c (compare_virtual_tables): Remove two trailing spaces
from diagnostics.  Formatting fixes.

PR target/85665
* ipa-devirt.c (odr_types_equivalent_p): Fix grammar in
warn_odr diagnostics.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug target/85665] Multiple typos in diagnostics

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 10:52:38 2019
New Revision: 269488

URL: https://gcc.gnu.org/viewcvs?rev=269488&root=gcc&view=rev
Log:
PR ipa/8
* ipa-devirt.c (compare_virtual_tables): Remove two trailing spaces
from diagnostics.  Formatting fixes.

PR target/85665
* ipa-devirt.c (odr_types_equivalent_p): Fix grammar in
warn_odr diagnostics.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug other/80058] fix double spaces in string literals everywhere

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80058

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
I've fixed what I found.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 80058, which changed state.

Bug 80058 Summary: fix double spaces in string literals everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80058

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug ipa/80000] diagnostics: trailing spaces in "one definition rule "

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 79846, which changed state.

Bug 79846 Summary: s390: untranslatable diagnostic in s390.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79846

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/79846] s390: untranslatable diagnostic in s390.c

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79846

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 8, which changed state.

Bug 8 Summary: diagnostics: trailing spaces in "one definition rule  "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/85665] Multiple typos in diagnostics

[jasonwucj at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665

Chung-Ju Wu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jasonwucj at gcc dot 
gnu.org

--- Comment #11 from Chung-Ju Wu  ---
(In reply to Jakub Jelinek from comment #9)
> Most of this is nds32 target related, so should be fixed by the
> corresponding maintainer.  As for two spaces after ., that is standard GCC
> convention and I believe it is used in many other spots.  I'll handle the
> ipa-devirt.c issue.

Thanks for the reminder.  I will deal with nds32 part to fix typos. :)

[Bug tree-optimization/89049] [8/9 Regression] Unexpected vectorization

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049

--- Comment #11 from Richard Biener  ---
Just an update on costs:

t.c:1:35: note:   === vect_compute_single_scalar_iteration_cost ===
0x483e120 *_3 1 times scalar_load costs 12 in body
0x483e120 _4 + r_16 1 times scalar_stmt costs 12 in body

and the vector body cost:

0x492f9d0 *_3 1 times unaligned_load (misalign -1) costs 20 in body
0x492f9d0 _4 + r_16 8 times vec_to_scalar costs 32 in body
0x492f9d0 _4 + r_16 8 times scalar_stmt costs 96 in body

That results in the overall (and sensible)

t.c:1:35: note:  Cost model analysis:
  Vector inside of loop cost: 148
  Vector prologue cost: 0
  Vector epilogue cost: 0
  Scalar iteration cost: 24
  Scalar outside cost: 0
  Vector outside cost: 0
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 0

where for one vector iteration we have 8 scalar iterations, thus 24 * 8 = 192

As mentioned elsewhere the vectorizer cost model does not care for
pipeline latency or dependency issues nor execution resources competition.
It also does not care for loop size (the vector loop has one stmt more than
the unrolled scalar loop for example).  I once played with limiting the
vectorization loop growth with the unroll parameters, but we're far from
hitting those here.

Btw, a microbenchmark shows the loops execute in about the same time
vectorized with -mavx2 compared to scalar and not unrolled.  When
the scalar loop is unrolled 8 times the runtime is the same again
(this is all benchmarked on a Haswell machine).  If you disregard noise
then the scalar unrolled loop is maybe a tid bit faster than the other
cases.

I believe the limiting factor is the dependence chain of the adds,
there's plenty of parallel execution resources to cope for uglyness
and friends.

This leaves the code bloat as regression I think.

[Bug debug/89631] New: gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

Bug ID: 89631
   Summary: gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of
two values with different enumeration types in switch
statement ('enum rtx_code' and 'tree_code'):
-Wenum-compare-switch
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2019-3-8
 CC||rth at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug go/63560] __go_set_defer_retaddr shouldn't be split by IPA split

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Fri Mar  8 12:37:54 2019
New Revision: 269491

URL: https://gcc.gnu.org/viewcvs?rev=269491&root=gcc&view=rev
Log:
Restrict IPA split (PR go/63560).

2019-03-08  Jan Hubicka  

PR go/63560
* ipa-split.c (execute_split_functions): Do not split
'noinline' or 'section' function.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-split.c

[Bug go/63560] __go_set_defer_retaddr shouldn't be split by IPA split

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Martin Liška  ---
Fixed now.

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952

--- Comment #22 from Martin Liška  ---
Author: marxin
Date: Fri Mar  8 12:55:40 2019
New Revision: 269492

URL: https://gcc.gnu.org/viewcvs?rev=269492&root=gcc&view=rev
Log:
x86: Disable jump tables when retpolines are used (PR target/86952).

2019-03-08  Martin Liska  

PR target/86952
* config/i386/i386.c (ix86_option_override_internal): Disable
jump tables when retpolines are used.
2019-03-08  Martin Liska  

PR target/86952
* gcc.target/i386/pr86952.c: New test.
* gcc.target/i386/indirect-thunk-7.c: Use jump tables to match
scanned pattern.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr86952.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c
trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c

[Bug target/86952] Avoid jump table for switch statement with -mindirect-branch=thunk

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952

Martin Liška  changed:

   What|Removed |Added

  Known to work||9.0
  Known to fail||8.2.0

--- Comment #23 from Martin Liška  ---
Fixed on trunk so far.

[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497

--- Comment #26 from Jakub Jelinek  ---
More simplified testcase:
/* PR middle-end/89497 */

static unsigned long *
foo (unsigned long *x)
{
  return x + (1 + *x);
}

__attribute__((noipa)) unsigned long
bar (unsigned long *x)
{
  unsigned long c, d = 1, e, *f, g, h = 0, i;
  for (e = *x - 1; e > 0; e--)
{
  f = foo (x + 1);
  for (i = 1; i < e; i++)
f = foo (f);
  c = *f;
  if (c == 2)
d *= 2;
  else
{
  i = (c - 1) / 2 - 1;
  g = (2 * i + 1) * (d + 1) + (2 * d + 1);
  if (g > h)
h = g;
  d *= c;
}
}
  return h;
}

int
main ()
{
  unsigned long a[18] = { 4, 2, -200, 200, 2, -400, 400, 3, -600, 0, 600, 5,
-100, -66, 0, 66, 100, __LONG_MAX__ / 8 + 1 };
  if (bar (a) != 17)
__builtin_abort ();
  return 0;
}

[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497

--- Comment #27 from rguenther at suse dot de  ---
On Fri, 8 Mar 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
> 
> --- Comment #26 from Jakub Jelinek  ---
> More simplified testcase:
> /* PR middle-end/89497 */
> 
> static unsigned long *
> foo (unsigned long *x)
> {
>   return x + (1 + *x);
> }
> 
> __attribute__((noipa)) unsigned long
> bar (unsigned long *x)
> {
>   unsigned long c, d = 1, e, *f, g, h = 0, i;
>   for (e = *x - 1; e > 0; e--)
> {
>   f = foo (x + 1);
>   for (i = 1; i < e; i++)
> f = foo (f);
>   c = *f;
>   if (c == 2)
> d *= 2;
>   else
> {
>   i = (c - 1) / 2 - 1;
>   g = (2 * i + 1) * (d + 1) + (2 * d + 1);
>   if (g > h)
> h = g;
>   d *= c;
> }
> }
>   return h;
> }
> 
> int
> main ()
> {
>   unsigned long a[18] = { 4, 2, -200, 200, 2, -400, 400, 3, -600, 0, 600, 5,
> -100, -66, 0, 66, 100, __LONG_MAX__ / 8 + 1 };
>   if (bar (a) != 17)
> __builtin_abort ();
>   return 0;
> }

But when I look at the GIMPLE differences on x86_64 I see nothing
besides BB and SSA numbering being slightly different at RTL
expansion time.  Possibly enough to trigger later RTL optimization
issues of course.  One key difference is a loop latch fallthru
vs. non-fallthru for example.

So I stand by the assertion the rev. just hides a problem elsewhere
(on RTL I think).

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I guess it's

case REG:
  switch (GET_CODE (src))
{
...
  /* Rule 6 */
case CONST_INT:
case POLY_INT_CST:

because POLY_INT_CST is a tree code.  Should be CONST_POLY_INT instead.
Richard - care to fix/test this?

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

--- Comment #2 from Richard Biener  ---
POLY_INT_CST == USE so no actual harm done I guess (besides not handling
CONST_POLY_INT).

[Bug fortran/89632] New: documentation bug

[kay.diederi...@uni-konstanz.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89632

Bug ID: 89632
   Summary: documentation bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kay.diederi...@uni-konstanz.de
  Target Milestone: ---

At https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html in the section
-fno-underscoring, it says 
"is implemented as something akin to:
i = j_() + max_count__(&my_var__, &lvar);"
but the last line should surely be
i = j_() + max_count__(&my_var_, &lvar_);

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #1)
> I guess it's
> 
> case REG:
>   switch (GET_CODE (src))
> {
> ...
>   /* Rule 6 */
> case CONST_INT:
> case POLY_INT_CST:
> 
> because POLY_INT_CST is a tree code.  Should be CONST_POLY_INT instead.
> Richard - care to fix/test this?
Sure.  Fix is easy, test not so much. :-)  This probably won't get
much coverage until we have ACLE support.

[Bug c/85870] [7/8 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||9.0
Summary|[7/8/9 Regression][LTO1]|[7/8 Regression][LTO1] ICE
   |ICE in linemap_line_start,  |in linemap_line_start, at
   |at libcpp/line-map.c:794|libcpp/line-map.c:794
  Known to fail||7.4.0, 8.3.0

--- Comment #15 from Martin Liška  ---
Dup of PR88147.
I'm going to install Jakub's testcase.
And I'll open this we'll need backports.

[Bug libstdc++/64135] Allocator base classes should use reserved names

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135

--- Comment #1 from Jonathan Wakely  ---
One option would be to just rename the base class (possibly only the default
new_allocator one, as selecting a different allocator implementation is an
explicit choice, and so users can deal with the consequences).

Another option would be to drop the base class from std::allocator when
configured to derive from new_allocator, and just inline that code into
std::allocator. That's an ABI break, because it would no longer have a base
class of type __gnu_cxx::new_allocator, but maybe it's one that wouldn't cause
any problems in practice.

[Bug c/85870] [7/8 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870

--- Comment #16 from Martin Liška  ---
Author: marxin
Date: Fri Mar  8 14:04:27 2019
New Revision: 269495

URL: https://gcc.gnu.org/viewcvs?rev=269495&root=gcc&view=rev
Log:
Add tests for resolved PR (PR c/85870).

2019-03-08  Jakub Jelinek  

PR c/85870
* gcc.dg/lto/pr85870_0.c: New test.
* gcc.dg/lto/pr85870_1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr85870_0.c
trunk/gcc/testsuite/gcc.dg/lto/pr85870_1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/87553] [9 regression] g++.dg/tree-prof/inline_mismatch_args.C etc. FAIL

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553

--- Comment #10 from Martin Liška  ---
Any progress on this please?

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Shouldn't we add -Wenum-compare and -Wenum-compare-switch warnings for GCC10?

[Bug driver/67062] -no-pie check breaks cross compilation of GCC [OS X -> Windows]

[lukeallardyce at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67062

--- Comment #2 from Luke Allardyce  ---
--host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 or i686-w64-mingw32

I can't remember if it broke on either or both of the above targets and don't
have access to an OSX machine any more. --build was left unspecified, the auto
detection worked.

[Bug ipa/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341

--- Comment #6 from Martin Liška  ---
David: Are you planning to send for it?

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=87404

--- Comment #5 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #4)
> Shouldn't we add -Wenum-compare and -Wenum-compare-switch warnings for GCC10?

That's bug 87404.

[Bug c++/89633] New: Inner class cannot pass a lambda to a template function in outer class

[raphael.kubo.da.costa at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89633

Bug ID: 89633
   Summary: Inner class cannot pass a lambda to a template
function in outer class
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raphael.kubo.da.costa at intel dot com
  Target Milestone: ---

The following excerpt builds fine on MSVC, ICC and clang:

struct S {
  template 
  void frob(const Function&);

  struct T {
T(S* s) {
  s->frob([]() {});
}
  };
};

but GCC fails with

:3:8: error: 'void S::frob(const Function&) [with Function =
S::T::T(S*)::]', declared using local type 'const
S::T::T(S*)::', is used but never defined [-fpermissive]
3 |   void frob(const Function&);
  |^~~~

Passing anything other than a lambda to S::frob(), or making it take a function
pointer rather than a template argument, works.

[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87404

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Marek, would you like to implement this for GCC 10?

[Bug gcov-profile/87553] [9 regression] g++.dg/tree-prof/inline_mismatch_args.C etc. FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #10 from Martin Liška  ---
> Any progress on this please?

I haven't seen this after 20181116 and the last gcc-testresults posting
showing the failure on AIX 7.2 is from 20181119.

[Bug target/84328] [7/8/9 Regression] -finline-small-functions and inline keyword lead to slowdown since version 6

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84328

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #2)
> The only change I see is with r233211, before that user time is around
> 0m5.233s and after that around 0m5.404s, which is more like 3% than 10% and
> there is nothing wrong on the actual change.

Knowing that, can we Jakub close it?

[Bug gcov-profile/87553] [9 regression] g++.dg/tree-prof/inline_mismatch_args.C etc. FAIL

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Martin Liška  ---
Good, then let's close it.

[Bug middle-end/89497] [8 Regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497

--- Comment #28 from Jakub Jelinek  ---
Yeah, I've also found that it doesn't fail on x86_64 with r269301 even when the
optimized dump is identical to s390x.  Debugging now, in the third iteration of
the outer loop the inner loop doesn't stop where it should.  Will file a latent
PR once debugged.

[Bug ipa/89341] [7/8/9 Regression] ICE in get, at cgraph.h:1332

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89341

--- Comment #7 from David Malcolm  ---
(In reply to Martin Liška from comment #6)
> David: Are you planning to send for it?
I'm not sure what you mean by this, sorry.

[Bug c++/87404] Implement -Wenum-compare and -Wenum-compare-switch

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87404

--- Comment #4 from Marek Polacek  ---
I can try, sure.

[Bug rtl-optimization/89634] New: gmp-ecm miscompilation on s390x with -march=zEC12 -m64 -O2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89634

Bug ID: 89634
   Summary: gmp-ecm miscompilation on s390x with -march=zEC12 -m64
-O2
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: darkkirb at darkkirb dot de, dimhen at gmail dot com,
jakub at gcc dot gnu.org, marxin at gcc dot gnu.org,
nheghathivhistha at gmail dot com, rguenth at gcc dot 
gnu.org
Depends on: 89497, 89551
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #89497 +++

/* PR middle-end/89497 */

static unsigned long *
foo (unsigned long *x)
{
  return x + (1 + *x);
}

__attribute__((noipa)) unsigned long
bar (unsigned long *x)
{
  unsigned long c, d = 1, e, *f, g, h = 0, i;
  for (e = *x - 1; e > 0; e--)
{
  f = foo (x + 1);
  for (i = 1; i < e; i++)
f = foo (f);
  c = *f;
  if (c == 2)
d *= 2;
  else
{
  i = (c - 1) / 2 - 1;
  g = (2 * i + 1) * (d + 1) + (2 * d + 1);
  if (g > h)
h = g;
  d *= c;
}
}
  return h;
}

int
main ()
{
  unsigned long a[18] = { 4, 2, -200, 200, 2, -400, 400, 3, -600, 0, 600, 5,
-100, -66, 0, 66, 100, __LONG_MAX__ / 8 + 1 };
  if (bar (a) != 17)
__builtin_abort ();
  return 0;
}

used to be miscompiled on s390x with -march=zEC12 -m64 -O2 in r269301 and
earlier, the bug went latent with r269302 change.

Still, to me this looks like a postreload_jump pass bug.

Before that, we have (for simplicity using -march=zEC12 -m64 -O2
-fno-reorder-blocks{,-and-partition}):
;; basic block 4, loop depth 0, count 118111600 (estimated locally), maybe hot
;;  prev block 3, next block 5, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:   12 [84.2% (guessed)]  count:69378754 (estimated locally)
(DFS_BACK)
;;  3 [always]  count:12992275 (estimated locally) (FALLTHRU)
;;  15 [always]  count:35740571 (estimated locally) (DFS_BACK)
...
(code_label 23 6 24 4 3 (nil) [2 uses])
(note 24 23 25 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 25 24 26 4 NOTE_INSN_DELETED)
(jump_insn 26 25 87 4 (parallel [
(set (pc)
(if_then_else (eq (reg/v:DI 5 %r5 [orig:74 e ] [74])
(const_int 1 [0x1]))
(label_ref 43)
(pc)))
(clobber (reg:CC 33 %cc))
]) "rh1686696.c":16:7 1263 {*cmp_and_br_signed_di}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 43)
;;  succ:   5 [89.0% (guessed)]  count:105119324 (estimated locally)
(FALLTHRU)
;;  9 [11.0% (guessed)]  count:12992276 (estimated locally)
...
;; basic block 5, loop depth 0, count 105119324 (estimated locally), maybe hot
;;  prev block 4, next block 6, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:   4 [89.0% (guessed)]  count:105119324 (estimated locally)
(FALLTHRU)
...
(jump_insn 68 67 134 12 (parallel [
(set (pc)
(if_then_else (ne (reg/v:DI 5 %r5 [orig:74 e ] [74])
(const_int 1 [0x1]))
(label_ref:DI 23)
(pc)))
(set (reg/v:DI 5 %r5 [orig:74 e ] [74])
(plus:DI (reg/v:DI 5 %r5 [orig:74 e ] [74])
(const_int -1 [0x])))
(clobber (scratch:DI))
(clobber (reg:CC 33 %cc))
]) "rh1686696.c":13:3 1922 {doloop_di}
 (int_list:REG_BR_PROB 904381916 (nil))
 -> 23)
;;  succ:   4 [84.2% (guessed)]  count:69378754 (estimated locally)
(DFS_BACK)
;;  13 [15.8% (guessed)]  count:12992276 (estimated locally)
(FALLTHRU)
but postreload_jump makes:
;; basic block 4, loop depth 0, count 48732846 (estimated locally), maybe hot
;;  prev block 3, next block 5, flags: (RTL)
;;  pred:   15 [always]  count:35740571 (estimated locally) (DFS_BACK)
;;  3 [always]  count:12992275 (estimated locally) (FALLTHRU)
...
(code_label 23 6 24 4 3 (nil) [1 uses])
(note 24 23 25 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 25 24 26 4 NOTE_INSN_DELETED)
(jump_insn 26 25 146 4 (parallel [
(set (pc)
(if_then_else (eq (reg/v:DI 5 %r5 [orig:74 e ] [74])
(const_int 1 [0x1]))
(label_ref 43)
(pc)))
(clobber (reg:CC 33 %cc))
]) "rh1686696.c":16:7 1263 {*cmp_and_br_signed_di}
 (int_list:REG_BR_PROB 355222868 (nil))
 -> 43)
;;  succ:   5 [66.9% (guessed)]  count:32610701 (estimated locally)
(FALLTHRU)
;;  9 [33.1% (guessed)]  count:16122145 (estimated locally)
;; basic block 5, loop depth 0, count 105119324 (estimated locally), maybe hot
;; Invalid sum of incoming counts 101989455 (estimated 

[Bug rtl-optimization/89634] gmp-ecm miscompilation on s390x with -march=zEC12 -m64 -O2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89634

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-03-08
Version|8.3.0   |9.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug other/89635] New: More ANSI SGR codes in diagnostics?

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635

Bug ID: 89635
   Summary: More ANSI SGR codes in diagnostics?
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: other
  Assignee: dmalcolm at redhat dot com
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In the discussion on my GCC 9 usability blog post, reddit user "evaned" said:

> I wonder how plausible it is to cut out one of the lines in each
> "block" and use ANSI escapes to underline the relevant part of code
> instead of putting in the ~s on its own line?

(in
https://www.reddit.com/r/programming/comments/ayp3gu/usability_improvements_in_gcc_9/ei2n8al/
)

I'm filing this bug to record that idea (possible GCC 10 material).

I wonder if there are other SGR codes that are worth using?  Maybe the
strikethrough code for deletion fix-it hints?

[Bug other/89635] More ANSI SGR codes in diagnostics?

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89635

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug target/68924] No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68924

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Mar  8 15:53:47 2019
New Revision: 269497

URL: https://gcc.gnu.org/viewcvs?rev=269497&root=gcc&view=rev
Log:
PR target/68924
PR target/78782
PR target/87558
* config/i386/emmintrin.h (_mm_loadu_si64): New intrinsic.
(_mm_storeu_si64): Ditto.

testsuite/ChangeLog:

PR target/68924
PR target/78782
PR target/87558
* gcc.target/i386/pr78782.c: New test.
* gcc.target/i386/pr87558.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78782.c
trunk/gcc/testsuite/gcc.target/i386/pr87558.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/testsuite/ChangeLog

[Bug target/87558] Missing _mm_storeu_si64() intrinsic

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87558

--- Comment #1 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Mar  8 15:53:47 2019
New Revision: 269497

URL: https://gcc.gnu.org/viewcvs?rev=269497&root=gcc&view=rev
Log:
PR target/68924
PR target/78782
PR target/87558
* config/i386/emmintrin.h (_mm_loadu_si64): New intrinsic.
(_mm_storeu_si64): Ditto.

testsuite/ChangeLog:

PR target/68924
PR target/78782
PR target/87558
* gcc.target/i386/pr78782.c: New test.
* gcc.target/i386/pr87558.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78782.c
trunk/gcc/testsuite/gcc.target/i386/pr87558.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/testsuite/ChangeLog

[Bug target/78782] [x86] _mm_loadu_si64 intrinsic missing

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78782

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Mar  8 15:53:47 2019
New Revision: 269497

URL: https://gcc.gnu.org/viewcvs?rev=269497&root=gcc&view=rev
Log:
PR target/68924
PR target/78782
PR target/87558
* config/i386/emmintrin.h (_mm_loadu_si64): New intrinsic.
(_mm_storeu_si64): Ditto.

testsuite/ChangeLog:

PR target/68924
PR target/78782
PR target/87558
* gcc.target/i386/pr78782.c: New test.
* gcc.target/i386/pr87558.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78782.c
trunk/gcc/testsuite/gcc.target/i386/pr87558.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/emmintrin.h
trunk/gcc/testsuite/ChangeLog

[Bug target/68924] No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68924

--- Comment #5 from Uroš Bizjak  ---
_mm_loadu_si64 intrinsic can now be used in the example from #Description:

#include 
#include 
__m256 load_bytes_to_m256(uint8_t *p)
{
  __m128i small_load = _mm_loadu_si64( (void *)p );
  __m256i intvec = _mm256_cvtepu8_epi32( small_load );
return _mm256_cvtepi32_ps(intvec);
}

-O2 -mavx2 now compiles on 32bit targets to:

...
vpmovzxbd   (%eax), %ymm0
vcvtdq2ps   %ymm0, %ymm0

[Bug target/68924] No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68924

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #6 from Uroš Bizjak  ---
(In reply to Peter Cordes from comment #3)
> For the reverse, we get:
> 
> long long extract(__m128i v) {
> return ((__v2di)v)[0];
> }
> 
> subl$28, %esp
> vmovq   %xmm0, 8(%esp)
> movl8(%esp), %eax
> movl12(%esp), %edx
> addl$28, %esp
> ret
> 
> MOVD / PEXTRD might be better, but gcc does handle it.  It's all using
> syntax that's available in 32-bit mode, not a special built-in.

Please report this problem in the another PR (it is the case of missing v->r
alternative in *vec_extractv2di_0_sse pattern for SSE4+, where we can split
directly to movd/pextrd).

The original problem is fixed for gcc-9.

[Bug target/88918] [meta-bug] x86 intrinsic issues

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88918
Bug 88918 depends on bug 68924, which changed state.

Bug 68924 Summary: No intrinsic for x86  `MOVQ m64, %xmm`  in 32bit mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68924

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/78782] [x86] _mm_loadu_si64 intrinsic missing

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78782

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |9.0

--- Comment #4 from Uroš Bizjak  ---
Implemented for gcc-9.

[Bug target/88918] [meta-bug] x86 intrinsic issues

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88918
Bug 88918 depends on bug 78782, which changed state.

Bug 78782 Summary: [x86] _mm_loadu_si64 intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78782

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/87558] Missing _mm_storeu_si64() intrinsic

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87558

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |9.0

--- Comment #2 from Uroš Bizjak  ---
Implemented for gcc-9.

[Bug target/88918] [meta-bug] x86 intrinsic issues

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88918
Bug 88918 depends on bug 87558, which changed state.

Bug 87558 Summary: Missing _mm_storeu_si64() intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87558

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/51820] [doc] underscoring documentation incorrect

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kay.diederichs@uni-konstanz
   ||.de

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 89632 has been marked as a duplicate of this bug. ***

[Bug fortran/89632] documentation bug

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89632

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Severity|normal  |enhancement

--- Comment #1 from Dominique d'Humieres  ---
This is a partial duplicate of pr51820. I have posted a patch needing
improvement in pr51820 comment 2.

*** This bug has been marked as a duplicate of bug 51820 ***

[Bug rtl-optimization/89634] gmp-ecm miscompilation on s390x with -march=zEC12 -m64 -O2

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89634

--- Comment #1 from Jakub Jelinek  ---
Created attachment 45927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45927&action=edit
gcc9-pr89634.patch

Untested fix.

[Bug target/89628] aarch64_vector_pcs does not use v24-v31 as temp regs

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89628

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-08
 Ever confirmed|0   |1

--- Comment #1 from Steve Ellcey  ---
I think the problem here is that we are not setting REG_ALLOC_ORDER and/or
ADJUST_REG_ALLOC_ORDER on aarch64.

I am not sure which one we should use, but I will look into it.

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #6 from janus at gcc dot gnu.org ---
Here is a reduced variant of comment #0:


module m_vstring
  implicit none

  public :: vstring_length

contains

  subroutine vstring_cast()
character ( len = vstring_length() ) :: char_string
  end subroutine

  pure integer function vstring_length ()
  end function

end module


It compiles with 5.5.0, ICEs in is_illegal_recursion with 6.5.0, 7.3.0, 8.2.0
and is rejected with trunk (as mentioned in comment #5):

   12 |   pure integer function vstring_length ()
  |  1
Error: MODULE-PROC procedure at (1) is already declared as EXTERNAL-PROC
procedure

[Bug ada/89493] Stack smashing on armv7hl

[matmal01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89493

Matthew Malcomson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-08
 CC||matmal01 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Matthew Malcomson  ---
I've reproduced manually using the reproducer and a bootstrapped gcc at r268766

gcc r265397 does not reproduce the problem.

Hence I'm marking this as a regression.

Between these two versions bootstrap with the configure line below fails.

../gcc-source/configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,lto
--prefix=${HOME}/gcc-install --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-gnu-indirect-function
--disable-sjlj-exceptions --with-tune=generic-armv7-a --with-arch=armv7-a
--with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux
--build=armv7hl-redhat-linux-gnueabi

(mostly taken from the configure shown in `gcc -v` from the given package
version)

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734

--- Comment #7 from janus at gcc dot gnu.org ---
Here is another variant, possibly illegal:


module m_vstring
  implicit none

  public :: vstring_length

  character ( len = vstring_length() ) :: char_string

contains

  pure integer function vstring_length ()
  end function

end module


This is rejected by 5.5.0 via:

   character ( len = vstring_length() ) :: char_string
 ^
Error: size of variable ‘char_string’ is too large


While it is rejected by 6, 7, 8 and trunk with the bogus error message:

   10 |   pure integer function vstring_length ()
  |  1
Error: MODULE-PROC procedure at (1) is already declared as EXTERNAL-PROC
procedure


The latter error message is certainly bogus because nothing is declared as
EXTERNAL at all.

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #5)
> The test case is now rejected with trunk, looks like a recent 9 regression:
> 
> ig25@linux-p51k:/tmp> gfortran m_vstring.f90 
> m_vstring.f90:24:30:
> 
>24 |   pure function vstring_length ( this ) result ( length )
>   |  1
> Error: MODULE-PROC procedure at (1) is already declared as EXTERNAL-PROC
> procedure


In light of comment #7, I rather suspect that the ICE has been fixed on trunk,
which leaves us with a (previously hidden) rejects-valid problem (6/7/8/9
regression?).

Would be useful to find out which commit triggered this change ...

[Bug c++/82075] structured binding fails with empty base class

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82075

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at redhat dot com,
   ||nathan at acm dot org

--- Comment #2 from Eric Gallager  ---
cc-ing C++ FE maintainers for their interpretation

[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=40054

[Bug c++/89630] [9 Regression] FAIL: g++.dg/cpp0x/alias-decl-64.C

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89630

Jakub Jelinek  changed:

   What|Removed |Added

 CC|jakub at redhat dot com|jason at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Seems like a latent issue before, with the added new ia32 builtins we end up
with lookup_template_class_1 looking up in type_specializations something with
hash
40565706 and have already an entry with the same tmpl and hash 3584195152 in
the table, but both of these % 61 are 35 and so spec_hasher::equal is invoked.
e1->args is
 
full-name "class A<#‘using_decl’ not supported by dump_expr# >"
no-binfo use_template=1 interface-unknown
chain >>
and e2->args is:
 
full-name "class A<#‘using_decl’ not supported by dump_expr# >"
no-binfo use_template=1 interface-unknown
chain >>
Both are itself their own canonical types and template_args_equal calls
same_type_p which ICEs on these.  Before my r269472 change, DECL_UID of the
*->tmpl was different, so different hashes and we were lucky that those two
weren't compared.

Jason, any ideas?

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734

--- Comment #9 from Dominique d'Humieres  ---
> Would be useful to find out which commit triggered this change ...

Revision r267783 (pr88376) seems to be a good suspect.

[Bug tree-optimization/70390] [7/8/9 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70390

--- Comment #14 from Eric Gallager  ---
(In reply to Arseny Solokha from comment #13)
> Actually, I cannot reproduce it on the trunk anymore as of r265575.

So can this be closed then?

[Bug tree-optimization/70390] [7/8/9 Regression] internal compiler error: in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70390

--- Comment #15 from Jakub Jelinek  ---
The usual procedure would be to bisect when it stopped ICEing, note it here and
see if that was a real fix, if yes and the corresponding testcase of the fix is
very different from this one add the testsuite to the testsuite and close.
Our bisect seeds can't do graphite though, dunno if the SUSE one can.

[Bug target/78380] [7 regression] GCC crash with internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78380

--- Comment #8 from Eric Gallager  ---
(In reply to Richard Biener from comment #7)
> Without bisection it's hard to identify what fix to backport.  Note the
> original issue doesn't reproduce for me with a cross to
> x86_64-apple-darwin15.6.0 from
> x86_64-linux either (from the tip of the gcc 7 branch).

Besides backporting something to the gcc 7 branch, there's also the matter of
adding the testcase to the testsuite on 8/trunk, to ensure it doesn't regress
in the future, and the adding the testcase part doesn't require bisection like
backporting would.

[Bug c++/82075] structured binding fails with empty base class

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82075

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
This is accepted in 8.x and on the trunk starting with r257057 aka PR84031 fix
and it has been backported to 7.x too.

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Fri Mar  8 18:18:23 2019
New Revision: 269500

URL: https://gcc.gnu.org/viewcvs?rev=269500&root=gcc&view=rev
Log:
Fix POLY_INT_CST/CONST_POLY_INT typo (PR 89631)

2019-03-08  Richard Sandiford  

gcc/
PR debug/89631
* dwarf2cfi.c (dwarf2out_frame_debug_expr): Use CONST_POLY_INT
instead of POLY_INT_CST.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2cfi.c

[Bug debug/89631] gcc/dwarf2cfi.c:1647:15:Semantic Issue: comparison of two values with different enumeration types in switch statement ('enum rtx_code' and 'tree_code'): -Wenum-compare-switch

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89631

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.  Will backport to GCC 8 too.

[Bug c++/88183] [8 Regression] Fold expression with operator .* inside an polymorphic lambda

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88183

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Fri Mar  8 18:19:55 2019
New Revision: 269501

URL: https://gcc.gnu.org/viewcvs?rev=269501&root=gcc&view=rev
Log:
PR c++/88183 - ICE with .* fold-expression.

build_m_component_ref can't handle type-dependent operands, so let's use the
default case; tsubst_copy_and_build also uses build_x_binary_op for
substituting a DOTSTAR_EXPR.

* pt.c (fold_expression) [DOTSTAR_EXPR]: Remove special handling.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/fold-lambda3.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/87513] [8 Regression] ICE in write_expression, at cp/mangle.c:3050

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87513

--- Comment #13 from Jason Merrill  ---
Author: jason
Date: Fri Mar  8 18:21:02 2019
New Revision: 269502

URL: https://gcc.gnu.org/viewcvs?rev=269502&root=gcc&view=rev
Log:
PR c++/87513 - 'sorry' mangling PMF template-id.

Here build_offset_ref calls build_qualified_name to make a SCOPE_REF because
the dependent template arguments make type_dependent_expression_p (member)
true.  We could probably work hard to prevent this, but it doesn't seem
necessary, and it's easy to fix write_expression to handle the result.

* mangle.c (write_expression): Handle SCOPE_REF to BASELINK.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/decltype-tid1.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/mangle.c

[Bug c++/89422] [8 Regression] ICE in field_byte_offset, at dwarf2out.c:19086

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89422

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Mar  8 18:22:20 2019
New Revision: 269503

URL: https://gcc.gnu.org/viewcvs?rev=269503&root=gcc&view=rev
Log:
PR c++/89422 - ICE with -g and lambda in default arg in template.

Here, we were trying to instantiate the default argument before setting
DECL_FRIEND_CONTEXT, so that the instantiated lambda ended up being treated
as part of the S template, which confused dwarf2out.

* pt.c (tsubst_function_decl): SET_DECL_FRIEND_CONTEXT sooner.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-defarg9.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/82075] structured binding fails with empty base class

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82075

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  8 18:31:27 2019
New Revision: 269504

URL: https://gcc.gnu.org/viewcvs?rev=269504&root=gcc&view=rev
Log:
PR c++/82075
* g++.dg/cpp1z/decomp49.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/decomp49.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #9)
> > Would be useful to find out which commit triggered this change ...
> 
> Revision r267783 (pr88376) seems to be a good suspect.

You mean r267793. Yes, that's certainly what fixed the ICE.

[Bug translation/79477] Please write code more translator-friendly

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79477

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jakub Jelinek  ---
The powerpc diagnostic messages were fixed in r251092.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 79477, which changed state.

Bug 79477 Summary: Please write code more translator-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79477

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug libstdc++/89624] HLE acquire/release bits in std::memory_order don't work with -fshort-enums or -fstrict-enums

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624

--- Comment #3 from Jonathan Wakely  ---
No, it's just a different, but still conforming, interpretation of the
standard.

> For an enumeration whose underlying type is not fixed, the underlying type
> is an integral type that can represent all the enumerator values defined
> in the enumeration. If no integral type can represent all the enumerator
> values, the enumeration is ill-formed. It is implementation-defined which
> integral type is used as the underlying type except that the underlying
> type shall not be larger than int unless the value of an enumerator
> cannot fit in an int or unsigned int.

By default GCC uses int or unsigned int, even if a smaller type would suffice.
I think that is required by the psABI. The -fshort-enums switch says to ignore
the platform ABI and make the type as small as possible, i.e. use a different
implementation-defined integral type.

The HLE bits are outside the standard though, so if we were to stop caring
about things outside the standard, we could just remove the constants for the
HLE bits, instead of trying to make them work with -fshort-enums :-)

[Bug c++/85936] GCC incorrectly implements [expr.prim.lambda.capture]/10.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85936

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-03-08
 Ever confirmed|0   |1

[Bug c++/59655] incorrect diagnostic on templatized function with lambda parameter

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59655

Jonathan Wakely  changed:

   What|Removed |Added

 CC||raphael.kubo.da.costa@intel
   ||.com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 89633 has been marked as a duplicate of this bug. ***

[Bug c++/89633] Inner class cannot pass a lambda to a template function in outer class

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89633

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
THis looks like an even smaller version of Bug 59655 comment 1.

*** This bug has been marked as a duplicate of bug 59655 ***

[Bug c++/59655] incorrect diagnostic on templatized function with lambda parameter

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59655

Jonathan Wakely  changed:

   What|Removed |Added

 CC||lebedev.ri at gmail dot com

--- Comment #3 from Jonathan Wakely  ---
*** Bug 85936 has been marked as a duplicate of this bug. ***