[Bug c++/103114] New: [12 Regression] ICE in build_complex, at tree.c:2470

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103114
   Summary: [12 Regression] ICE in build_complex, at tree.c:2470
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-12.0.0-alpha20211031 snapshot (g:ca84f39399fda80c770306465276ffd66d3766ed)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.c-torture/execute/complex-7.c, w/ -frounding-math:

_Complex double d5 = 10.1i;

% g++-12.0.0 -frounding-math -c yiyfoum8.c
yiyfoum8.c:1:22: internal compiler error: in build_complex, at tree.c:2470
1 | _Complex double d5 = 10.1i;
  |  ^
0x86be9c build_complex(tree_node*, tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/tree.c:2470
0xaa1373 cp_parser_userdef_numeric_literal
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:4807
0xabd70e cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:7581
0xaa50ca cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:9911
0xaa5c7a cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:10215
0xaa7fcd cp_parser_constant_expression
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:10518
0xaa80f1 cp_parser_initializer_clause
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:25070
0xaabadc cp_parser_initializer
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:25010
0xadbb3b cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:22631
0xab5d49 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:15156
0xae758b cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:14842
0xae806a cp_parser_toplevel_declaration
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:14863
0xae806a cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:4987
0xae806a c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/cp/parser.c:47840
0xc1b7ed c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211031/work/gcc-12-20211031/gcc/c-family/c-opts.c:1237

[Bug c/103113] New: Bad error message with multiply indirect pointer to struct

[elronnd at elronnd dot net via Gcc-bugs]

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

Bug ID: 103113
   Summary: Bad error message with multiply indirect pointer to
struct
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elronnd at elronnd dot net
  Target Milestone: ---

$ cat q.c
int f() {
struct { int m; } **x;
return x->m;
}
$ gcc -c q.c
q.c: In function ‘f’:
q.c:3:17: error: ‘*x’ is a pointer; did you mean to use ‘->’?
3 | return x->m;
  | ^~
  | ->

[Bug c++/103012] [11/12 Regression] ICE with #pragma GCC optimize followed by long line (4047 long)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
  Known to fail||11.1.0
   Keywords||needs-bisection
Summary|ICE with #pragma GCC|[11/12 Regression] ICE with
   |optimize followed by long   |#pragma GCC optimize
   |line|followed by long line (4047
   ||long)
  Known to work||10.1.0, 7.5.0

--- Comment #5 from Andrew Pinski  ---
So decent testcase with macros, though you need -save-temps or preprocess it
beforehand if you are invoking cc1plus directly.
#pragma GCC optimize "Og"
#define a1(a) a
#define a2(a) a1(a)a1(a)
#define a4(a) a2(a)a2(a)
#define a8(a) a4(a)a4(a)
#define a16(a) a8(a)a8(a)
#define a32(a) a16(a)a16(a)
#define a64(a) a32(a)a32(a)
#define a128(a) a64(a)a64(a)
#define a256(a) a128(a)a128(a)
#define a512(a) a256(a)a256(a)
#define a1024(a) a512(a)a512(a)
#define a2048(a) a1024(a)a1024(a)
a2048(a)
-- CUT --
What I found also is the line needs to be 4047 characters long. The above line
will a little longer around 4096ish.

Also this worked at r10-6101 but failed at r11-6338.

[Bug tree-optimization/103102] [12 Regression] pr81175.f fails since r12-4946-ga79fe53d6ce6074d083e925b6b19773e45817405

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization

--- Comment #5 from Andrew Pinski  ---
The vectorizer in a few cases keeps around MASK_LOAD for the scalar type which
is causing the crash in expand. I can't understand how it happens either.

[Bug middle-end/103102] [12 Regression] pr81175.f fails since r12-4946-ga79fe53d6ce6074d083e925b6b19773e45817405

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
(gdb) p type
$14 = 
(gdb) p maskt.typed.type
$13 = 

[Bug middle-end/103102] [12 Regression] pr81175.f fails since r12-4946-ga79fe53d6ce6074d083e925b6b19773e45817405

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
#1  0x013013a2 in maybe_gen_insn (icode=CODE_FOR_nothing, nops=3,
ops=0x7fffd500) at /home/apinski/src/upstream-gcc/gcc/gcc/optabs.c:7871
7871  gcc_assert (nops == (unsigned int) insn_data[(int)
icode].n_generator_args);
(gdb) p nops
$1 = 3
(gdb) p insn_data[(int) icode].n_generator_args
$2 = 0 '\000'
(gdb) p icode
$3 = CODE_FOR_nothing

[Bug middle-end/103102] [12 Regression] pr81175.f fails since r12-4946-ga79fe53d6ce6074d083e925b6b19773e45817405

[aldot at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Bernhard Reutner-Fischer  ---
gfortran.dg/pr101267.f90 ICEs similar to gfortran.dg/pr81175.f

[Bug middle-end/103102] [12 Regression] pr81175.f fails since r12-4946-ga79fe53d6ce6074d083e925b6b19773e45817405

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 CC||aldot at gcc dot gnu.org

--- Comment #1 from Bernhard Reutner-Fischer  ---
maybe related:
polyhedron capacita with pristine r12-4967 on 86_64 skylake

$ gfortran -march=native -ffast-math -ftree-vectorize -funroll-loops -O3
capacita.f90 -o capacita.exe
during RTL pass: expand
capacita.f90:609:21:

  609 |   Grid(i,j)=0
  | ^
internal compiler error: in maybe_gen_insn, at optabs.c:7871
0x72b7a6 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../../src/gcc-12.orig/gcc/optabs.c:7871
0xe1d738 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../../src/gcc-12.orig/gcc/optabs.c:7915
0xe1d738 expand_insn(insn_code, unsigned int, expand_operand*)
../../../src/gcc-12.orig/gcc/optabs.c:7946
0xcb3bcf expand_partial_store_optab_fn
../../../src/gcc-12.orig/gcc/internal-fn.c:2773
0xa6f487 expand_call_stmt
../../../src/gcc-12.orig/gcc/cfgexpand.c:2749
0xa6f487 expand_gimple_stmt_1
../../../src/gcc-12.orig/gcc/cfgexpand.c:3876
0xa6f487 expand_gimple_stmt
../../../src/gcc-12.orig/gcc/cfgexpand.c:4040
0xa7536f expand_gimple_basic_block
../../../src/gcc-12.orig/gcc/cfgexpand.c:6085
0xa76df6 execute
../../../src/gcc-12.orig/gcc/cfgexpand.c:6811
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/55227] designated initializer for char array by string constant

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/583589.html

--- Comment #12 from Andrew Pinski  ---
Patch was submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583589.html

[Bug c++/100592] Bogus "qualifiers cannot be applied" error with reference type produced by dependent alias template

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12.

[Bug target/103095] Option to force no overalignment

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
   AMD x86-64 psABI says that variables with array type larger than 15 bytes
   must be aligned to 16 byte boundaries.


There is already an option:
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/x86-Options.html#index-malign-data-1
-malign-data=type
Control how GCC aligns variables. Supported values for type are ‘compat’ uses
increased alignment value compatible uses GCC 4.8 and earlier, ‘abi’ uses
alignment value as specified by the psABI, and ‘cacheline’ uses increased
alignment value to match the cache line size. ‘compat’ is the default.


You just need to supply -mabi-data=abi in this case if you want to disable over
aligning of things.

Other than that there is nothing to be done in GCC; it is up to the linker and
assembler to do the layout really.

The option was added in GCC 5 by r5-5887.

[Bug target/103095] Option to force no overalignment

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI
 Target||x86_64
  Component|other   |target

--- Comment #1 from Andrew Pinski  ---
I think the ABI actually requires this to be aligned to 32 byte.
clang might not be following the ABI.

[Bug tree-optimization/80519] optimize if(p)free(p) with -Os

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

Summary|if(p)free(p) with -Os   |optimize if(p)free(p) with
   ||-Os
 CC||dmalcolm at gcc dot gnu.org,
   ||egallager at gcc dot gnu.org,
   ||izaberina at gmail dot com

--- Comment #9 from Eric Gallager  ---
updating title to make it clearer that this one is about the optimization (as
opposed to bug 80528, which is about warning)

[Bug c++/55004] [meta-bug] constexpr issues

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Bug 97752 Summary: incorrect address to inherited object in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97752

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/100209] multiple inheritance with crtp pattern fails on sequentioal member access

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||steven.vanderschoot@nextlev
   ||el-electronics.com

--- Comment #6 from Patrick Palka  ---
*** Bug 97752 has been marked as a duplicate of this bug. ***

[Bug c++/97752] incorrect address to inherited object in constexpr context

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Patrick Palka  ---
Looks like this is a dup of PR100209 which has recently been fixed for GCC 12. 
Thanks for the bug report.

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

[Bug ada/103070] ICE in gimple_call_static_chain_flags, at gimple.c:1669

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
This has turned out to be (somewhat subtle) but in partitioning. I apologize
for blaming the front-end.

[Bug fortran/103058] [12 Regression] ICE in gimple_call_static_chain_flags, at gimple.c:1669 when building 527.cam4_r

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:6078eb7452aa89cb9aeecac30932b58967389459

commit r12-4974-g6078eb7452aa89cb9aeecac30932b58967389459
Author: Jan Hubicka 
Date:   Sat Nov 6 23:36:08 2021 +0100

Fix can_be_discarded_p wrt partitioned functions.

gcc/ChangeLog:

* cgraph.h (cgraph_node::can_be_discarded_p): Do not
return true on functions from other partition.

gcc/lto/ChangeLog:

PR ipa/103070
PR ipa/103058
* lto-partition.c (must_not_rename): Update comment.
(promote_symbol): Set resolution to LDPR_PREVAILING_DEF_IRONLY.

[Bug ada/103070] ICE in gimple_call_static_chain_flags, at gimple.c:1669

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:6078eb7452aa89cb9aeecac30932b58967389459

commit r12-4974-g6078eb7452aa89cb9aeecac30932b58967389459
Author: Jan Hubicka 
Date:   Sat Nov 6 23:36:08 2021 +0100

Fix can_be_discarded_p wrt partitioned functions.

gcc/ChangeLog:

* cgraph.h (cgraph_node::can_be_discarded_p): Do not
return true on functions from other partition.

gcc/lto/ChangeLog:

PR ipa/103070
PR ipa/103058
* lto-partition.c (must_not_rename): Update comment.
(promote_symbol): Set resolution to LDPR_PREVAILING_DEF_IRONLY.

[Bug target/103094] [12 Regression] Incorrect codegen from uint8x8x2_t function arguments

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[12 Regression] Incorrect   |[12 Regression] Incorrect
   |codegen from AArch64|codegen from uint8x8x2_t
   |intrinsics  |function arguments
   Severity|normal  |blocker

[Bug target/103106] PPC: Missing builtin for P9 vmsumudm

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Fixed in GCC 11 by r11-1946.

Namespace inside module partition not exported

[Alexander Christensen via Gcc-bugs]

Hi,

This is a rather strange thing, which suspiciously looks like bug. I have a 
file like this:

```
export module engine.memory : align_type;
export import engine.core;

export I32 get_5()
{
return 5;
}

export namespace engine::memory
{
enum class AlignType : I32
{
align_1   = 1,
align_2   = 2,
align_4   = 4,
align_8   = 8,
align_16  = 16,
align_32  = 32,
align_64  = 64,
align_128 = 128,
align_256 = 256
};
}
```

I have another translation unit which then imports the module engine.memory. 
That file can use the function get_5(), but whenever I try to use the namespace 
engine.memory I get an error that that namespace has not been defined.

If I remove the `export import engine.core` then the namespace is suddenly 
exported. (!)

So there is an issue with namespaces being hidden (ie. non-exported) whenever a 
module partition unit imports another module. It does not make any difference 
if the imported module is export-import'ed or just imported.

Best,
Alexander

[Bug fortran/103112] ICE in gfc_get_descriptor_field for gfortran.dg/coarray_alloc_comp_4.f08 caf single

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-11-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug c++/102928] Template argument deduction when mixing variadic template with C-style variadic function

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-11-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
temp.deduct.call

For a function parameter pack that occurs at the end of the
parameter-declaration-list,
deduction is performed for each remaining argument of the call, taking the type
P of the declarator-id of the
function parameter pack as the corresponding function template parameter type.
Each deduction deduces
template arguments for subsequent positions in the template parameter packs
expanded by the function
parameter pack.


parameter-declaration-list does not include the ... variadic arguments part.

So Confirmed.

As far as I read in the standard, the template variadic deduction should be
greedy (deduction is performed for each remaining argument of the call).

[Bug fortran/103112] New: ICE in gfc_get_descriptor_field for gfortran.dg/coarray_alloc_comp_4.f08 caf single

[aldot at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103112
   Summary: ICE in gfc_get_descriptor_field for
gfortran.dg/coarray_alloc_comp_4.f08 caf single
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

gfortran.dg/coarray_alloc_comp_4.f08 compiles fine with -fcoarray=lib
but ICEs with -fcoarray=single in pristine trunk


$ gfortran -O2 -fcoarray=single -g -g3 -ggdb3 -fdump-tree-original
-fdump-tree-optimized coarray_alloc_comp_4.f08 -c; echo $?
coarray_alloc_comp_4.f08:38:22:

   38 |   deallocate(obj%link)
  |  1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.c:245
0x67b8e8 gfc_get_descriptor_field
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:245
0x97d53a gfc_conv_descriptor_data_get(tree_node*)
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:264
0x97aa64 gfc_deallocate_with_status(tree_node*, tree_node*, tree_node*,
tree_node*, tree_node*, bool, gfc_expr*, int, tree_node*, tree_node*)
../../../src/gcc-12.orig/gcc/fortran/trans.c:1427
0x98e539 structure_alloc_comps
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:9291
0x9904da gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../../src/gcc-12.orig/gcc/fortran/trans-array.c:10081
0x97b196 gfc_deallocate_scalar_with_status(tree_node*, tree_node*, tree_node*,
bool, gfc_expr*, gfc_typespec, bool)
../../../src/gcc-12.orig/gcc/fortran/trans.c:1646
0xa1189d gfc_trans_deallocate(gfc_code*)
../../../src/gcc-12.orig/gcc/fortran/trans-stmt.c:7380
0x977597 trans_code
../../../src/gcc-12.orig/gcc/fortran/trans.c:2092
0x9a9c2f gfc_generate_function_code(gfc_namespace*)
../../../src/gcc-12.orig/gcc/fortran/trans-decl.c:7666
0x9220ee translate_all_program_units
../../../src/gcc-12.orig/gcc/fortran/parse.c:6629
0x9220ee gfc_parse_file()
../../../src/gcc-12.orig/gcc/fortran/parse.c:6916
0x97434f gfc_be_parse_file
../../../src/gcc-12.orig/gcc/fortran/f95-lang.c:216
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
1
$ gfortran --version
GNU Fortran (GCC) 12.0.0 20211105 (experimental) [master r12-4967-gbcf3728abe8]

[Bug tree-optimization/103111] bogus stringop overflow warning

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
So if I add:

if (savepath->s_sz <= 0) __builtin_unreachable();
Before the check/setting of ->n. I get no warning.


If I unconditional set n to 0 rather than checking to see if it is greater than
0, I get no warning.

I think the warning might be correct due to GCC not being able to see all
pathes and knowing that n will never be negative.

[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
As a first step we could just parse and accept the attribute.

[Bug c/103111] New: bogus stringop overflow warning

[k.melekhin at gmail dot com via Gcc-bugs]

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

Bug ID: 103111
   Summary: bogus stringop overflow warning
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k.melekhin at gmail dot com
  Target Milestone: ---

Created attachment 51743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51743=edit
test sample

Hello, please see the attachment.

Why is this warning being generated, it is clearly seen that there will only be
1 allocation and savepath->s_n is being set to 0. I know if I use unsigned
values warning goes away, but this warning still seems not right, because in
this case we are not even dealing with anything close to being considered
integer overflow.

I think this is a gcc bug, my appologies if this is known bug there seems to be
some similar open for c++ but not sure.

[Bug fortran/102727] Warning for guaranteed interoperable type kind

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Last reconfirmed||2021-11-06
 Ever confirmed|0   |1
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

F2018, section 18 has the interesting

NOTE 1
A Fortran entity can be interoperable with more than one C entity.

but also in 18.3.1

A Fortran intrinsic type with particular type parameter values is interoperable
with a C type if the type and kind type parameter value are listed in the
table (18.2) on the same row as that C type. ...

Assuming the standard as normative, we're potentially trying to see a conflict
where there is possibly none.

And if kind(1), c_int, c_int32_t, and the kind of an enum are the same on
x86_64,
one could argue that these can be interoperable.

[Bug c++/103110] templated operator auto is ignored

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Fedor Chelnokov  ---
Thanks for the explanation! I reported Clang bug:
https://bugs.llvm.org/show_bug.cgi?id=52434

[Bug c++/103110] templated operator auto is ignored

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Fedor Chelnokov from comment #4)
> Actually you changed the example, and if T is void, then T{} is ill-formed.
> But I do not see how it relates to the original program.

I know I changed the example to show that clang is considering all templated
operator auto rather than not considering any of them.  This is why I am saying
clang is just plain out wrong of the way it handles templated operator auto.


class.conv.fct/6 is very explicit about this too:
A conversion function template shall not have a deduced return type (10.1.7.4).
[ Example:
struct S {
operator auto() const { return 10; } // OK
template
operator auto() const { return 1.2; } // error: conversion function template
};

- CUT 
So again clang is wrong.

[Bug c++/103110] templated operator auto is ignored

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Fedor Chelnokov  ---
Actually you changed the example, and if T is void, then T{} is ill-formed. But
I do not see how it relates to the original program.

[Bug c++/103110] templated operator auto is ignored

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Andrew Pinski  ---
clang gets it fully wrong anyways, take:
struct S {
template
operator auto() const  { return T{}; }
};

int main() {
S s;
[[maybe_unused]] int d = (int)s;
}
- CUT 
clang produces:
:3:38: error: illegal initializer type 'void'
operator auto() const  { return T{}; }
 ^
:8:35: note: in instantiation of function template specialization
'S::operator auto' requested here
[[maybe_unused]] int d = (int)s;
  ^
:8:30: error: no matching conversion for C-style cast from 'S' to 'int'
[[maybe_unused]] int d = (int)s;
 ^~
:3:5: note: candidate template ignored: substitution failure [with T =
void]
operator auto() const  { return T{}; }
^

- CUT 
There should be no instantiation of the template here at all.

[Bug fortran/101602] [F2018] local and local_init are not supported in DO CONCURRENT

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2021-11-06
 CC||anlauf at gcc dot gnu.org
Summary|local and local_init are|[F2018] local and
   |not supported in DO |local_init are not
   |CONCURRENT  |supported in DO CONCURRENT
   Keywords||rejects-valid
   Priority|P3  |P4
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

See also F2018:R1130.

Note that Intel warns that locality information is ignored unless OpenMP or
other form of parallelization is active.

[Bug c++/103110] templated operator auto is ignored

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Fedor Chelnokov  ---
I think the program must be equivalent to
```
struct S {
operator auto() const { return 2; }
};

int main() {
S s;
[[maybe_unused]] int d = s;
}
```
and `auto` here is deduced from `return 2` and not from `template`

[Bug c++/103110] templated operator auto is ignored

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
I think this is a bug in clang as GCC, ICC (EDG) and MSVC all reject the code
for the same reason.
GCC even warns about it:
:3:14: warning: use of 'auto' in member template conversion operator
can never be deduced
3 | operator auto() const { return 2; }
  |  ^~~~

[Bug ipa/103107] [12 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (constructor) in prepare_debug_expressions, at ipa-param-manipulation.c:1189

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug target/101529] [11/12 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og caused by r11-2192

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/583584.html
   Keywords||patch

--- Comment #7 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583584.html

[Bug c++/96517] ICE in is_this_parameter when accessing constexpr method of a field inside coroutine lambda (with optimization)

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||visual2017cpp at hotmail dot 
com

--- Comment #2 from Andrew Pinski  ---
*** Bug 103108 has been marked as a duplicate of this bug. ***

[Bug c++/103108] compiler ICE for lambda coroutines that captures this when optimization is used

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 96517.

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

[Bug c++/103110] New: templated operator auto is ignored

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103110
   Summary: templated operator auto is ignored
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This code should be valid:
```
struct S {
template
operator auto() const { return 2; }
};

int main() {
S s;
[[maybe_unused]] int d = s;
}
```
and Clang accepts it, while GCC does not. Demo:
https://gcc.godbolt.org/z/rMK4zboEd

[Bug target/103109] New: madd not used for multiply add on POWER9

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103109
   Summary: madd not used for multiply add on POWER9
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following code

#include 

void Long_multiplication( uint64_t multiplicand[],
  uint64_t multiplier[],
  uint64_t sum[],
  uint64_t ilength, uint64_t jlength )
{
  uint64_t acarry, mcarry, product;

  for( uint64_t i = 0;
   i < (ilength + jlength);
   i++ )
sum[i] = 0;

  acarry = 0;
  for( uint64_t j = 0; j < jlength; j++ )
{
  mcarry = 0;
  for( uint64_t i = 0; i < ilength; i++ )
{
  __uint128_t mcarry_prod;
  __uint128_t acarry_sum;
  mcarry_prod = ((__uint128_t) multiplicand[i]) * ((__uint128_t)
multiplier[j])
+ (__uint128_t) mcarry;
  mcarry = mcarry_prod >> 64;
  product = mcarry_prod;
  acarry_sum = ((__uint128_t) sum[i+j]) + ((__uint128_t) acarry) +
product;
  sum[i+j] += acarry_sum;
  acarry = acarry_sum >> 64;
  //  {mcarry, product} = multiplicand[i]*multiplier[j]
  //+ mcarry;
  //  {acarry,sum[i+j]} = {sum[i+j]+acarry} + product;

}
}
}

is translated by

$ gcc -mcpu=power9 -mtune=power9 -S -O3 big_int.c

to (assembler output of the loop)

.L4:
mtctr 25
mr 12,23
add 3,24,4
li 5,0
.p2align 4,,15
.L5:
ldu 10,8(12)
ldx 11,29,4
ldu 9,8(3)
mulld 8,10,11
mulhdu 10,10,11
addc 30,8,5
addze 31,10
and 21,30,6
and 22,31,7
addc 10,21,9
mr 5,31
adde 8,22,28
addc 10,10,0
add 9,9,10
addze 0,8
std 9,0(3)
bdnz .L5
addi 27,27,1
addi 4,4,8
cmpld 0,26,27
bne 0,.L4

For the idiom to calculate mcarry_prod, I would have expected
a pair of maddhdu and maddld instructions.

This is with

gcc-Version 12.0.0 20211028 (experimental) (GCC)

[Bug fortran/102715] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184 since r12-4278-g74ccca380cde5e79

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:df2135e88a8f78c853b35246ad426b01b6d08378

commit r12-4973-gdf2135e88a8f78c853b35246ad426b01b6d08378
Author: Harald Anlauf 
Date:   Sat Nov 6 19:42:01 2021 +0100

Fortran: error recovery on rank mismatch of array and its initializer

gcc/fortran/ChangeLog:

PR fortran/102715
* decl.c (add_init_expr_to_sym): Reject rank mismatch between
array and its initializer.

gcc/testsuite/ChangeLog:

PR fortran/102715
* gfortran.dg/pr68019.f90: Adjust error message.
* gfortran.dg/pr102715.f90: New test.

[Bug middle-end/102906] [12 regression] gcc.target/arm/ivopts-4.c fails since r12-4526

[aldyh at redhat dot com via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at redhat dot com

--- Comment #3 from Aldy Hernandez  ---
I'm going to need more specific instructions here.

Looking at the link provided, there's a target of arm-none-linux-gnueabihf
--with-arch=default --with-cpu=cortex-a9 --with-cpu=vfp -march=armv5t... that
has a a red "REGRESSED" column.

I tried to simulate that with a cross --target=arm-none-linux-gnueabihf:

diff --git a/gcc/testsuite/gcc.target/arm/ivopts-4.c
b/gcc/testsuite/gcc.target/arm/ivopts-4.c
index 2e866c01823..cb81d010bb5 100644
--- a/gcc/testsuite/gcc.target/arm/ivopts-4.c
+++ b/gcc/testsuite/gcc.target/arm/ivopts-4.c
@@ -1,5 +1,5 @@
 /* { dg-do assemble } */
-/* { dg-options "-Os -fdump-tree-ivopts -save-temps" } */
+/* { dg-options "-Os -fdump-tree-ivopts -save-temps -S -mcpu=cortex-a9
-mfpu=vfp -march=armv5t" } */

 extern unsigned int foo (int*) __attribute__((pure));

$ make check-gcc RUNTESTFLAGS=arm.exp=ivopts-4.c
=== gcc Summary ===

# of expected passes4

Can you provide specific flags to pass to cc1 on a cross to
arm-none-linux-gnueabihf in order to reproduce?

[Bug c++/103108] New: compiler ICE for lambda coroutines that captures this when optimization is used

[visual2017cpp at hotmail dot com via Gcc-bugs]

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

Bug ID: 103108
   Summary: compiler ICE for lambda coroutines that captures this
when optimization is used
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: visual2017cpp at hotmail dot com
  Target Milestone: ---

I encountered this ICE now for the code given below

code and error on godbolt : https://godbolt.org/z/x55xn18va

it only happens with optimization enabled starting from -O1 to -O3

code:

```
#include 
#include 

struct simple_task
{
struct promise_type
{
public:
simple_task get_return_object() { return {}; }

constexpr std::suspend_never initial_suspend() noexcept {
return {}; }

constexpr std::suspend_never final_suspend() noexcept { return
{}; }

void unhandled_exception() noexcept
{
std::terminate();
}

constexpr void return_void() const noexcept {}
};
};

// in debug builds it is a checked pointer
template
class pointer_wrapper
{
public:

constexpr pointer_wrapper() noexcept = default;

constexpr pointer_wrapper(T* p) noexcept : p{ p } {}

constexpr T* operator->() const noexcept { return p; }

constexpr T& operator*() const noexcept { return *p; }

constexpr bool operator==(std::nullptr_t) const noexcept { return p ==
nullptr; }

constexpr bool operator==(const pointer_wrapper& other) const noexcept
{ return p == other.p; }

constexpr operator bool() const noexcept { return p != nullptr; }

operator pointer_wrapper() const noexcept
{
return pointer_wrapper{ p };
}

private:
T* p = nullptr;
};

struct some_struct
{
int i = 0;
pointer_wrapper other;

void do_ice()
{
auto ice_fn = [this]() -> simple_task { other->i = 1;
co_return; };
}
};
```

error message:

In function ‘void
some_struct::do_ice()_ZZN11some_struct6do_iceEvENKUlvE_clEv.actor(some_struct::do_ice()_ZZN11some_struct6do_iceEvENKUlvE_clEv.frame*)’:
ice.cpp:60:82: internal compiler error: in is_this_parameter, at
cp/semantics.c:10683
   60 | auto ice_fn = [this]() -> simple_task { other->i = 1;
co_return; };
  |
 ^
0x1702697 internal_error(char const*, ...)
???:0
0x64082b fancy_abort(char const*, int, char const*)
???:0
0x67ce76 is_nondependent_constant_expression(tree_node*)
???:0
0x67d6cf maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0x69c27c cp_fold_maybe_rvalue(tree_node*, bool)
???:0
0xf32953 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xf32b30 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xf32b30 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xf32eaf walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xf32eaf walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xf32b30 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xf32eaf walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xf32eaf walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x697df0 cp_fold_function(tree_node*)
???:0
0x6c4740 finish_function(bool)
???:0
0x6ec766 finish_lambda_function(tree_node*)
???:0
0x7888ee c_parse_file()
???:0
0x85988d c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for 

[Bug libstdc++/103005] experimental simd sin and cos with big arguments returns values bigger than 1

[andreas_roever at web dot de via Gcc-bugs]

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

--- Comment #3 from Andreas Röver  ---
I think the source of the problem is function

__fold_input(const simd& __x)

in simd_math.h

this function should return values between -pi/4 and pi/4 but doesn't for the
big argument. E.g for 

2985064393126969344

it returns

27.678747

according to wolfram alpha it should return 

0.189812

This "big" value throws off the calculation of the power series that is
performed after this


the 27.678646 is the result of a rounding error

2985064393126969344 / (pi/2) is (according to wolfram alpha again) 

1900351014455063569.620838

but the CPU gets

1900351014455063552

This seems to be the closest value that the CPU can get to the real value.

the difference between those 2 times pi/2 is the above mentioned 27.67...

... now my numerics skills are not good enough to find a cure for that problem.

[Bug libstdc++/103005] experimental simd sin and cos with big arguments returns values bigger than 1

[andreas_roever at web dot de via Gcc-bugs]

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

--- Comment #2 from Andreas Röver  ---
I think the source of the problem is function

__fold_input(const simd& __x)

in simd_math.h

this function should return values between -pi/4 and pi/4 but doesn't for the
big argument. E.g for 

2985064393126969344

it returns

27.678747

according to wolfram alpha it should return 

0.189812

This "big" value throws off the calculation of the power series that is
performed after this


the 27.678646 is the result of a rounding error

2985064393126969344 / (pi/2) is (according to wolfram alpha again) 

1900351014455063569.620838

but the CPU gets

1900351014455063552

This seems to be the closest value that the CPU can get to the real value.

the difference between those 2 times pi/2 is the above mentioned 27.67...

... now my numerics skills are not good enough to find a cure for that problem.

[Bug target/103066] __sync_val_compare_and_swap/__sync_bool_compare_and_swap aren't optimized

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #10 from Thiago Macieira  ---
You're right that emitting more penalises those who have done their job and
written proper code.

The problem we're seeing is that such code appears to be the minority. Or,
maybe put differently, the bad code is showing up a lot in our benchmarks,
especially on very big multi-core and multi-socket systems. "Fixing" the
compiler would make a broad update to the industry -- so long as the code is
recompiled with new compilers. Fixing the actual code would make it better even
if used with old ones.

Does anyone have a suggestion on how to get best "bang for buck"? (Biggest
benefit for smallest effort) This is a sincere question. I'm not trying to be
ironic or sarcastic. How can we help the most, the quickest, for the limited
amount of resources we can marshal?

Also, and I've been hitting this key for a few years, how can we do better at
teaching people how to use the tools at their disposal at the proper way? A
very good counter-example is C++11's std::atomic_flag: you MUST NEVER use it
(at least until C++20, where it got a test() member).

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

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

Bug 103061 Summary: [12 Regression] 527.cam4_r miscompiled with -O2 
-march=znver1 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061

   What|Removed |Added

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

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[aldyh at gcc dot gnu.org via Gcc-bugs]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #18 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:4856699eeb2809c50930bafe341a96470877195d

commit r12-4971-g4856699eeb2809c50930bafe341a96470877195d
Author: Aldy Hernandez 
Date:   Fri Nov 5 22:25:19 2021 +0100

path oracle: Do not look at root oracle for killed defs.

The problem here is that we are incorrectly threading 41->20->21 here:

   [local count: 56063504182]:
  _134 = M.10_120 + 1;
  if (_71 <= _134)
goto ; [11.00%]
  else
goto ; [89.00%]
...
...
...
   [local count: 49896518755]:

   [local count: 56063503181]:
  # lb_75 = PHI <_134(41), 1(18)>
  _117 = mstep_49 + lb_75;
  _118 = _117 + -1;
  _119 = mstep_49 + _118;
  M.10_120 = MIN_EXPR <_119, _71>;
  if (lb_75 > M.10_120)
goto ; [11.00%]
  else
goto ; [89.00%]

First, lb_17 == _134 because of the PHI.
Second, _134 > M.10_120 because of _134 = M.10_120 + 1.

We then assume that lb_75 > M.10_120, but this is incorrect because
M.10_120 was killed along the path.

This incorrect thread causes the miscompilation in 527.cam4_r.

Tested on x86-64 and ppc64le Linux.

gcc/ChangeLog:

PR tree-optimization/103061
* value-relation.cc (path_oracle::path_oracle): Initialize
m_killed_defs.
(path_oracle::killing_def): Set m_killed_defs.
(path_oracle::query_relation): Do not look at the root oracle for
killed defs.
* value-relation.h (class path_oracle): Add m_killed_defs.

[Bug c++/103105] [11/12 Regression] ICE iterative_hash_template_arg with concepts and varagrs template since r11-3261-gb28b621ac67beee8

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug ipa/103107] New: [12 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (constructor) in prepare_debug_expressions, at ipa-param-manipulation.c:1189

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103107
   Summary: [12 Regression] ICE: tree check: expected class
'expression', have 'exceptional' (constructor) in
prepare_debug_expressions, at
ipa-param-manipulation.c:1189
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 51742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51742=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -g -fipa-sra -fno-tree-dce testcase.c
In function 'bar.isra':
cc1: internal compiler error: tree check: expected class 'expression', have
'exceptional' (constructor) in prepare_debug_expressions, at
ipa-param-manipulation.c:1189
0x7e2a2b tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/repo/gcc-trunk/gcc/tree.c:8739
0x7037bd expr_check(tree_node*, char const*, int, char const*)
/repo/gcc-trunk/gcc/tree.h:3602
0x7037bd ipa_param_body_adjustments::prepare_debug_expressions(tree_node*)
/repo/gcc-trunk/gcc/ipa-param-manipulation.c:1189
0x11162c2 ipa_param_body_adjustments::prepare_debug_expressions(tree_node*)
/repo/gcc-trunk/gcc/ipa-param-manipulation.c:1164
0x111725d ipa_param_body_adjustments::common_initialization(tree_node*,
tree_node**, vec*)
/repo/gcc-trunk/gcc/ipa-param-manipulation.c:1365
0x13dc391 tree_function_versioning(tree_node*, tree_node*,
vec*, ipa_param_adjustments*, bool,
bitmap_head*, basic_block_def*)
/repo/gcc-trunk/gcc/tree-inline.c:6307
0xe8dfcd cgraph_node::materialize_clone()
/repo/gcc-trunk/gcc/cgraphclones.c:1141
0xe7c7f5 cgraph_node::get_untransformed_body()
/repo/gcc-trunk/gcc/cgraph.c:3907
0xe87f0d cgraph_node::expand()
/repo/gcc-trunk/gcc/cgraphunit.c:1799
0xe87f0d cgraph_node::expand()
/repo/gcc-trunk/gcc/cgraphunit.c:1781
0xe89597 expand_all_functions
/repo/gcc-trunk/gcc/cgraphunit.c:1992
0xe89597 symbol_table::compile()
/repo/gcc-trunk/gcc/cgraphunit.c:2356
0xe8c067 symbol_table::compile()
/repo/gcc-trunk/gcc/cgraphunit.c:2269
0xe8c067 symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.c:2537
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-4968-20211106001624-g851dff042a2-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-4968-20211106001624-g851dff042a2-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211106 (experimental) (GCC)

[Bug target/103106] New: PPC: Missing builtin for P9 vmsumudm

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 103106
   Summary: PPC: Missing builtin for P9 vmsumudm
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

I can't find builtin for vmsumudm instruction.

I also found nothing in the Power vector instrinsic programming reference.
https://openpowerfoundation.org/?resource_lib=power-vector-intrinsic-programming-reference

[Bug c++/58798] class with a class reference member generates a warning that ought to be disableable with -Wpacked

[olafvdspek at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Olaf van der Spek  ---
(In reply to Eric Gallager from comment #10)
> Updating the title accordingly.

The title doesn't reflect the original issue anymore, should a new issue be
filed for that?

[Bug tree-optimization/103061] [12 Regression] 527.cam4_r miscompiled with -O2 -march=znver1 since r12-4790-g4b3a325f07acebf4

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Martin Liška  ---
(In reply to Aldy Hernandez from comment #15)
> Created attachment 51740 [details]
> untested patch
> 
> This should do it.  Martin, can you verify this fixes it on your end?

Yes, it does! Thanks a lot.

[Bug c++/103105] [11/12 Regression] ICE iterative_hash_template_arg with concepts and varagrs template since r11-3261-gb28b621ac67beee8

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

Summary|[11/12 Regression] ICE  |[11/12 Regression] ICE
   |iterative_hash_template_arg |iterative_hash_template_arg
   |with concepts and varagrs   |with concepts and varagrs
   |template|template since
   ||r11-3261-gb28b621ac67beee8
   Keywords|needs-bisection |
 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r11-3261-gb28b621ac67beee8.

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Bug 103073 Summary: [12 Regression] ICE in insert_access, at 
ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073

   What|Removed |Added

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

[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b

[hubicka at gcc dot gnu.org via Gcc-bugs]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #15 from Jan Hubicka  ---
Fixed.

[Bug target/86388] Enhancement: sort "valid arguments to '-march=' switch" suggestions alphabetically

[egallager at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Alexander Monakov from comment #1)
> > I'd prefer existing ordering relative to alphabetical: the list produced by
> > GCC is mostly ordered first by manufacturer, then by
> > generation/capabilities. Placement of the 'x86-64' entry seems odd, but,
> > other than that, I like the order.
> > 
> > The manual also orders -march entries in this "manufacturer-capabilities"
> > style.
> 
> See I don't know my CPU generations/capabilities, all I want to do is find
> the one I meant to type, and the easiest way to do that would be to look for
> where it would be placed alphabetically

Alternatively, the suggestion could use the Levenshtein distance calculator
that spellchecking suggestions use elsewhere in GCC, instead of just listing
all the values.

[Bug bootstrap/9968] Prefix ending in "/" causes trouble in prefix.c

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||neroden at gcc dot gnu.org
   Assignee|neroden at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #12 from Eric Gallager  ---
(In reply to Eric Gallager from comment #11)
> (In reply to Nathanael C. Nerode from comment #9)
> > Resummarizing.
> 
> Are you still working on this?

Guess not; unassigning...

[Bug target/101529] [11/12 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og caused by r11-2192

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Andrew Pinski  ---
Created attachment 51741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51741=edit
patch which is testing including testcases

Full patch which is in testing right now. Added the testcases for this bug and
the dup bug too.

[Bug c/103104] missing warning about superfluous forward declaration -Wsuperfluous-forward-declaration

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Keywords||diagnostic
 Blocks||87403

--- Comment #1 from Eric Gallager  ---
-Wredundant-decls doesn't catch this?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug fortran/89078] [meta-bug] Improve the gfortran manual

[egallager at gcc dot gnu.org via Gcc-bugs]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||sandra at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Sandra has been working on improving the gfortran manual lately; maybe some of
these got fixed in the process?

[Bug target/101529] [11/12 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og caused by r11-2192

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Patch which I am testing:

My original patch before Dmitrij took it over, actually had the correct
behavior and the used a gen_reg_rtx. :(

[Bug target/101529] [11/12 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
Patch which I am testing:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2c00583e12c..d5b0cb7ae2f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -23084,11 +23084,15 @@ aarch64_evpc_ins (struct expand_vec_perm_d *d)
 }
   gcc_assert (extractindex < nelt);

-  emit_move_insn (d->target, insv);
+  /* Use a new reg instead of target as one of the
+ operands might be target. */
+  rtx original = gen_reg_rtx (GET_MODE (insv));
+
+  emit_move_insn (original, insv);
   insn_code icode = code_for_aarch64_simd_vec_copy_lane (mode);
   expand_operand ops[5];
   create_output_operand ([0], d->target, mode);
-  create_input_operand ([1], d->target, mode);
+  create_input_operand ([1], original, mode);
   create_integer_operand ([2], 1 << idx);
   create_input_operand ([3], extractv, mode);
   create_integer_operand ([4], extractindex);

[Bug target/101529] [11/12 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug target/101529] [11/12 Regression] wrong code with __builtin_convertvector() and __builtin_shufflevector() at -Og

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
Summary|wrong code with |[11/12 Regression] wrong
   |__builtin_convertvector()   |code with
   |and |__builtin_convertvector()
   |__builtin_shufflevector()   |and
   |at -Og  |__builtin_shufflevector()
   ||at -Og

--- Comment #3 from Andrew Pinski  ---
Mine, a regression from GCC 10 really.
aarch64_evpc_ins is where the problem is.
I have a fix.