[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> Though, there is another issue, for the nelts 2 vectors
> simplify_vector_constructor created code is actually larger than old code.
> And, it might be beneficial if we one day implement clang-like
> __builtin_shufflevector or at least add to VEC_PERM_EXPR or something
> similar the possibility to say certain element is a don't care (for
> __builtin_shufflevector I think that is -1 or negative?), as e.g. on
> AVX/AVX2 when extracting 128-bit vector out of 256-bit permutation all the
> upper elements are don't care and we might get better code if the backend
> picks the best element indexes for those to get smallest/fastest permutation.

Using -1 as the don't care element also occured to me.  Should be easy
to change for the vec_perm_const hook/expander I guess.

Not sure about VEC_PERM_EXPR given it also allows non-constant permutation
vectors.  I thought about relaxing VEC_PERM_EXPR to support extract
(destination with less lanes than source(s)) and concat (destination with
more lanes than source(s)).  Plus eventually allowing sources and destinations
to be scalars (interpret as punned to 1-element vector), which would be
syntactic sugar given explicit punning would be possible.  It would be
nice to not expose that to the targets given that explodes the complexity
of vec_perm[_const] though.

Anyway, this isn't something for GCC 10, but yes, don't know would come in
handy.

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|jakub at gcc dot gnu.org   |rguenth at gcc dot 
gnu.org

--- Comment #7 from Richard Biener  ---
Will ICE

v4sf
bar (v4si x, float *p)
{
  return (v4sf) { x[0], x[1], x[2], *p };
}

testing fix.

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Hmm, I don't think it is fully correct.  Let me dig in a bit.

[Bug ipa/92801] Drop unused struct fields

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
You're repeating mistakes fromm the past.  The "dumb" approach works for a
single
benchmark (mcf) but isn't at all usable for anything in the real world which
means it is of no use for GCC (when factoring in maintainance cost).

[Bug ipa/92800] IPA escape analysis for structs

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Note there's people from Marvell working on the same thing, posting design docs
(some privately to me though).  gobl...@marvell.com was working on this.

[Bug ipa/92799] ICE: in get, at cgraph.h:1339

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|c   |ipa

--- Comment #1 from Richard Biener  ---
Not sure if maybe invalid but then we should reject it.

[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342

[dimhen at gmail dot com]

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

--- Comment #11 from Dmitry G. Dyachenko  ---
Original test case from c#0 crash in trunk
gcc version 10.0.0 20191204 (experimental) [trunk revision 278972] (GCC)

$ g++ -fpreprocessed -fsyntax-only a.ii 
a.ii:5:1: error: types may not be defined in template arguments
5 | {
  | ^
a.ii:6:1: error: ISO C++ forbids declaration of ‘f’ with no type [-fpermissive]
6 | f () :
  | ^
a.ii:6:6: error: expected ‘}’ at end of input
6 | f () :
  |  ^
a.ii:5:1: note: to match this ‘{’
5 | {
  | ^
a.ii:6:6: error: expected template-argument at end of input
6 | f () :
  |  ^
a.ii:6:6: error: expected ‘>’ at end of input
a.ii:4:1: error: expected unqualified-id at end of input
4 | A < struct
  | ^~
5 | {
  | ~
6 | f () :
  | ~~
a.ii:4:1: error: expected ‘}’ at end of input
a.ii:3:1: note: to match this ‘{’
3 | {
  | ^
a.ii:4:1: internal compiler error: in cp_lexer_new_from_tokens, at
cp/parser.c:698
4 | A < struct
  | ^~
5 | {
  | ~
6 | f () :
  | ~~
0x6541ef cp_parser_push_lexer_for_tokens
/home/dimhen/src/gcc_current/gcc/cp/parser.c:698
0xbb3005 cp_parser_late_parsing_for_member
/home/dimhen/src/gcc_current/gcc/cp/parser.c:29559
0xb91ee7 cp_parser_class_specifier_1
/home/dimhen/src/gcc_current/gcc/cp/parser.c:23942
0xb92e83 cp_parser_class_specifier
/home/dimhen/src/gcc_current/gcc/cp/parser.c:23966
0xb92e83 cp_parser_type_specifier
/home/dimhen/src/gcc_current/gcc/cp/parser.c:17576
0xb93f0f cp_parser_decl_specifier_seq
/home/dimhen/src/gcc_current/gcc/cp/parser.c:14249
0xbb95a5 cp_parser_single_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:29075
0xbb992b cp_parser_template_declaration_after_parameters
/home/dimhen/src/gcc_current/gcc/cp/parser.c:28738
0xbba080 cp_parser_explicit_template_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:29004
0xbbd3e9 cp_parser_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:13271
0xbbda0a cp_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/cp/parser.c:4721
0xbbda0a c_parse_file()
/home/dimhen/src/gcc_current/gcc/cp/parser.c:43048
0xccf60b c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1185
Please submit a full bug report,

[Bug middle-end/91582] missing heap overflow detection for strcpy

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Part 2 of the patch series was committed in r278983.  Part 1 and part 3 are
still waiting for review and approval:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00429.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02340.html

[Bug middle-end/91582] missing heap overflow detection for strcpy

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  5 01:28:11 2019
New Revision: 278983

URL: https://gcc.gnu.org/viewcvs?rev=278983=gcc=rev
Log:
PR middle-end/91582 - missing heap overflow detection for strcpy

gcc/ChangeLog:

PR middle-end/91582
* builtins.c (gimple_call_alloc_size): New function.
(compute_objsize): Add argument.  Call gimple_call_alloc_size.
Handle variable offsets and indices.
* builtins.h (gimple_call_alloc_size): Declare.
(compute_objsize): Add argument.
* gcc/gimple-ssa-warn-restrict.c: Remove assertions.
* tree-ssa-strlen.c (handle_store): Handle calls to allocated objects.

gcc/testsuite/ChangeLog:

PR middle-end/91582
* c-c++-common/Wstringop-truncation.c: Remove xfails.
* g++.dg/warn/Wstringop-overflow-4.C: New test.
* g++.dg/ext/attr-alloc_size.C: Suppress -Warray-bounds.
* gcc.dg/Warray-bounds-56.c: New test.
* gcc.dg/Wstringop-overflow-22.c: New test.
* gcc.dg/attr-alloc_size.c: Suppress -Warray-bounds.
* gcc.dg/attr-copy-2.c: Same.
* gcc.dg/builtin-stringop-chk-5.c: Remove xfails.
* gcc.dg/builtin-stringop-chk-8.c: Same.  Correct the text of expected
warnings.
* gcc.target/i386/pr82002-2a.c: Prune expected warning.
* gcc.target/i386/pr82002-2b.c: Same.


Added:
trunk/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
trunk/gcc/testsuite/gcc.dg/Warray-bounds-56.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-25.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.h
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation.c
trunk/gcc/testsuite/g++.dg/ext/attr-alloc_size.C
trunk/gcc/testsuite/gcc.dg/attr-alloc_size.c
trunk/gcc/testsuite/gcc.dg/attr-copy-2.c
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-5.c
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-8.c
trunk/gcc/testsuite/gcc.target/i386/pr82002-2a.c
trunk/gcc/testsuite/gcc.target/i386/pr82002-2b.c
trunk/gcc/tree-ssa-strlen.c

[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||56456

--- Comment #2 from Martin Sebor  ---
With -Warray-bounds GCC issues:

t.c:7:3: warning: ‘__builtin_memcpy’ offset [4, 7] is out of the bounds [0, 4]
of object ‘s’ with type ‘struct S’ [-Warray-bounds]
7 |   __builtin_strcpy (s.ax, "123");
  |   ^~
t.c:3:17: note: ‘s’ declared here
3 | extern struct S s /* = { 5, { 1, 2, 3, 4, 5 } } */;
  | ^

The -Warray-bounds warning was in turn introduced in r255755 (in GCC 8.0):

r255755 | msebor | 2017-12-16 18:58:34 -0500 (Sat, 16 Dec 2017) | 81 lines

PR tree-optimization/78918 - missing -Wrestrict on memcpy copying over self

gcc/c-family/ChangeLog:

PR tree-optimization/78918
* c-common.c (check_function_restrict): Avoid checking built-ins.
* c.opt (-Wrestrict): Include in -Wall.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-05
 Blocks||88443
Summary|spurious|[8/9/10 Regression]
   |-Wstringop-overflow writing |spurious
   |into a flexible array of an |-Wstringop-overflow writing
   |extern struct   |into a flexible array of an
   ||extern struct
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
The full test case is:

struct S { int n; char ax[]; };

extern struct S s /* = { 5, { 1, 2, 3, 4, 5 } } */;

void g (void)
{
  __builtin_strcpy (s.ax, "123"); 
}


The false positive warning has been issued since r243419 (GCC 7.0):

r243419 | msebor | 2016-12-07 19:01:33 -0500 (Wed, 07 Dec 2016) | 68 lines

PR c/53562 - Add -Werror= support for -D_FORTIFY_SOURCE /
__builtin___memcpy_chk
PR middle-end/77784 - duplicate warning for snprintf when n > object size
PR middle-end/78149 - missing warning on strncpy buffer overflow due to an
excessive bound
PR middle-end/78138 - missing warnings on buffer overflow with non-constant
source length


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug middle-end/92815] New: spurious -Wstringop-overflow writing into a flexible array of an extern struct

[msebor at gcc dot gnu.org]

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

Bug ID: 92815
   Summary: spurious -Wstringop-overflow writing into a flexible
array of an extern struct
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Diagnosing the strcpy call below isn't justified because the flexible array
into which it writes is a member of an extern object that could be initialized
to be large enough to fit the string (e.g., as shown in the comment).

$ cat t.c && gcc -O2 -S -Wall -Wno-array-bounds t.c
extern struct S s /* = { 5, { 1, 2, 3, 4, 5 } } */;

void g (void)
{
  __builtin_strcpy (s.ax, "123");   // bogus warning
}
t.c: In function ‘g’:
t.c:7:3: warning: ‘__builtin_memcpy’ writing 4 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]
7 |   __builtin_strcpy (s.ax, "123");   // bogus warning
  |   ^~

[Bug middle-end/92814] New: missing -Wstringop-overflow writing into a dynamically allocated flexible array member

[msebor at gcc dot gnu.org]

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

Bug ID: 92814
   Summary: missing -Wstringop-overflow writing into a dynamically
allocated flexible array member
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With the first patch for pr91582 applied
(https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html) and with
-Wno-array-bounds, GCC 10 issues -Wstringop-overflow for the buffer overflow in
g() but not in h().  Both should be diagnosed by -Wstringop-overflow.

$ cat t.c && gcc -O2 -S -Wall -Wno-array-bounds t.c
void f (void*);

struct S { int n; char ax[]; };

struct S s = { 3, { 1, 2, 3 } };

void g (void)
{
  __builtin_strcpy (s.ax, "123");   // -Wstringop-overflow (good)
}

void h (void)
{
  struct S *p = (struct S*)__builtin_malloc (sizeof *p + 3);

  __builtin_strcpy (p->ax, "123");   // no warning (w/o -Warray-bounds)

  f (p);
}
t.c: In function ‘g’:
t.c:9:3: warning: ‘__builtin_memcpy’ writing 4 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
9 |   __builtin_strcpy (s.ax, "123");   // -Wstringop-overflow (good)
  |   ^~

[Bug demangler/83495] Segmentation Fault - 63915465

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #6 from Christian Biesinger  ---
The attachment contains a testcase: _ZZmmFoREES_

Current c++filt does not crash for me on that, but I don't know if it requires
a specific setup or this is fixed.

[Bug demangler/87241] A hang problem for c++filt

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #5 from Christian Biesinger  ---
This seems to be fixed on binutils trunk (in that it doesn't allocate lots of
memory and just returns early), but not in 2.31.1

[Bug demangler/82026] Undemanglable symbol

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #2 from Christian Biesinger  ---
No longer crashes on binutils trunk, though it does crash 2.31.1. Trunk doesn't
demangle it, though

[Bug demangler/69094] erroneous demangling

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #2 from Christian Biesinger  ---
Still happening.

[Bug demangler/68700] demangler failed with signal 11

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #3 from Christian Biesinger  ---
This does not seem to crash on binutils trunk, but it does not demangle either.

[Bug demangler/68159] Demangler crash (GDB PR 19190)

[cbiesinger at google dot com]

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

--- Comment #17 from Christian Biesinger  ---
Sorry, rather, none of these testcases seem to crash anymore but the one from
comment 0 still does not demangle.

[Bug c/88827] Rejects valid program using &* operator combination.

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #2 from Joseph S. Myers  ---
Fixed for GCC 10.

[Bug demangler/68159] Demangler crash (GDB PR 19190)

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #16 from Christian Biesinger  ---
Looks like the answer is yes, based on my testing.

[Bug c/36941] gcc does not reject invalid cast

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #10 from Joseph S. Myers  ---
Fixed for GCC 10.

[Bug c/88827] Rejects valid program using &* operator combination.

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Dec  4 23:26:10 2019
New Revision: 278976

URL: https://gcc.gnu.org/viewcvs?rev=278976=gcc=rev
Log:
Fix C handling of use of lvalues of incomplete types (PR c/36941, PR c/88827).

Bug 88827 points out that GCC should not be rejecting C code that
dereferences a pointer to an incomplete type in the case that uses &*
to take the address of the resulting lvalue, because no constraint is
violated in that case (other than for C90 when the incomplete type is
unqualified void, which we already handle correctly) and as the lvalue
never gets converted to an rvalue there is no undefined behavior
either.

This means that the diagnostic for such a dereference is bogus and
should be removed; if the lvalue gets converted to an rvalue, there
should be an appropriate error later for the use of the incomplete
type.  In most cases, there is, but bug 36941 points out the lack of a
diagnostic when the incomplete (non-void) type gets cast to void
(where a diagnostic seems appropriate for this undefined behavior as a
matter of quality of implementation).

This patch removes the bogus diagnostic (and C_TYPE_ERROR_REPORTED
which was only used in the code that is removed - only that one, bogus
diagnostic had this duplicate suppression, not any of the other, more
legitimate diagnostics for use of incomplete types) and makes
convert_lvalue_to_rvalue call require_complete_type for arguments not
of void types, so that all relevant code paths (possibly except some
for ObjC) get incomplete types diagnosed.  It's possible that this
makes some other checks for incomplete types obsolete, but no attempt
is made to remove any such checks.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/36941
PR c/88827
gcc/c:
* c-typeck.c (convert_lvalue_to_rvalue): Call
require_complete_type for arguments not of void types.
(build_indirect_ref): Do not diagnose dereferencing pointers to
incomplete types.
* c-tree.h (C_TYPE_ERROR_REPORTED): Remove.

gcc/testsuite:
* gcc.dg/lvalue-9.c, gcc.dg/lvalue-10.c: New tests.
* gcc.dg/array-8.c, gcc.dg/enum-incomplete-1.c,
gcc.dg/enum-incomplete-3.c, gcc.dg/noncompile/incomplete-3.c,
gcc.dg/pr48552-1.c, gcc.dg/pr48552-2.c, gcc.dg/pr63543.c,
gcc.dg/pr69796.c: Update expected diagnostics.

Added:
trunk/gcc/testsuite/gcc.dg/lvalue-10.c
trunk/gcc/testsuite/gcc.dg/lvalue-9.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/array-8.c
trunk/gcc/testsuite/gcc.dg/enum-incomplete-1.c
trunk/gcc/testsuite/gcc.dg/enum-incomplete-3.c
trunk/gcc/testsuite/gcc.dg/noncompile/incomplete-3.c
trunk/gcc/testsuite/gcc.dg/pr48552-1.c
trunk/gcc/testsuite/gcc.dg/pr48552-2.c
trunk/gcc/testsuite/gcc.dg/pr63543.c
trunk/gcc/testsuite/gcc.dg/pr69796.c

[Bug c/36941] gcc does not reject invalid cast

[jsm28 at gcc dot gnu.org]

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

--- Comment #9 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Dec  4 23:26:10 2019
New Revision: 278976

URL: https://gcc.gnu.org/viewcvs?rev=278976=gcc=rev
Log:
Fix C handling of use of lvalues of incomplete types (PR c/36941, PR c/88827).

Bug 88827 points out that GCC should not be rejecting C code that
dereferences a pointer to an incomplete type in the case that uses &*
to take the address of the resulting lvalue, because no constraint is
violated in that case (other than for C90 when the incomplete type is
unqualified void, which we already handle correctly) and as the lvalue
never gets converted to an rvalue there is no undefined behavior
either.

This means that the diagnostic for such a dereference is bogus and
should be removed; if the lvalue gets converted to an rvalue, there
should be an appropriate error later for the use of the incomplete
type.  In most cases, there is, but bug 36941 points out the lack of a
diagnostic when the incomplete (non-void) type gets cast to void
(where a diagnostic seems appropriate for this undefined behavior as a
matter of quality of implementation).

This patch removes the bogus diagnostic (and C_TYPE_ERROR_REPORTED
which was only used in the code that is removed - only that one, bogus
diagnostic had this duplicate suppression, not any of the other, more
legitimate diagnostics for use of incomplete types) and makes
convert_lvalue_to_rvalue call require_complete_type for arguments not
of void types, so that all relevant code paths (possibly except some
for ObjC) get incomplete types diagnosed.  It's possible that this
makes some other checks for incomplete types obsolete, but no attempt
is made to remove any such checks.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/36941
PR c/88827
gcc/c:
* c-typeck.c (convert_lvalue_to_rvalue): Call
require_complete_type for arguments not of void types.
(build_indirect_ref): Do not diagnose dereferencing pointers to
incomplete types.
* c-tree.h (C_TYPE_ERROR_REPORTED): Remove.

gcc/testsuite:
* gcc.dg/lvalue-9.c, gcc.dg/lvalue-10.c: New tests.
* gcc.dg/array-8.c, gcc.dg/enum-incomplete-1.c,
gcc.dg/enum-incomplete-3.c, gcc.dg/noncompile/incomplete-3.c,
gcc.dg/pr48552-1.c, gcc.dg/pr48552-2.c, gcc.dg/pr63543.c,
gcc.dg/pr69796.c: Update expected diagnostics.

Added:
trunk/gcc/testsuite/gcc.dg/lvalue-10.c
trunk/gcc/testsuite/gcc.dg/lvalue-9.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/array-8.c
trunk/gcc/testsuite/gcc.dg/enum-incomplete-1.c
trunk/gcc/testsuite/gcc.dg/enum-incomplete-3.c
trunk/gcc/testsuite/gcc.dg/noncompile/incomplete-3.c
trunk/gcc/testsuite/gcc.dg/pr48552-1.c
trunk/gcc/testsuite/gcc.dg/pr48552-2.c
trunk/gcc/testsuite/gcc.dg/pr63543.c
trunk/gcc/testsuite/gcc.dg/pr69796.c

[Bug demangler/84668] c++filt: out of memory allocating 18446744071696285694 bytes after a total of 135168 bytes

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #3 from Christian Biesinger  ---
Hmm this seems to be fixed on trunk for me, though still reproducible on 2.31.1

[Bug tree-optimization/92813] sprintf result not used by strlen pass

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Blocks||83819

--- Comment #1 from Martin Sebor  ---
Implementing this optimization will also make it possible to detect buffer
overflow in such cases:

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
char a[8];

void f (void)
{
  __builtin_strcpy (a, "1234");
  __builtin_sprintf (a + 4, "%s", "5678");   // warning (good)
}

void g (void)
{
  __builtin_sprintf (a, "%s", "1234");
  __builtin_strcat (a, "5678");  // missing warning
}
t.c: In function ‘f’:
t.c:6:32: warning: ‘__builtin_sprintf’ writing a terminating nul past the end
of the destination [-Wformat-overflow=]
6 |   __builtin_sprintf (a + 4, "%s", "5678");   // warning (good)
  |^
t.c:6:3: note: ‘__builtin_sprintf’ output 5 bytes into a destination of size 4
6 |   __builtin_sprintf (a + 4, "%s", "5678");   // warning (good)
  |   ^~~

;; Function f (f, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=1)

f ()
{
   [local count: 1073741824]:
  __builtin_memcpy (, "1234", 5);
  __builtin_sprintf (  [(void *) + 4B], "%s", "5678"); [tail
call]
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1934, cgraph_uid=2, symbol_order=2)

g ()
{
  long unsigned int _3;
  char[8] * _4;

   [local count: 1073741824]:
  __builtin_memcpy (, "1234", 5);
  _3 = __builtin_strlen ();
  _4 =  + _3;
  __builtin_memcpy (_4, "5678", 5); [tail call]
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug demangler/92453] write buffer overflow in cplus_demangle()

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #2 from Christian Biesinger  ---
Could you send your patch to gcc-patches per
https://gcc.gnu.org/contribute.html#patches ? Thanks!

[Bug tree-optimization/92813] New: sprintf result not used by strlen pass

[msebor at gcc dot gnu.org]

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

Bug ID: 92813
   Summary: sprintf result not used by strlen pass
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With the integration of the sprintf pass into strlen, GCC 10 makes use of
string lengths computed by the strlen pass to also compute the size of sprintf
(and snprintf) output.  This makes it possible to optimize calls like the one
if function f() below.  But the integration exposes string lengths only in one
direction, and doesn't also make the lengths computed by the sprintf pass
available to the strlen pass.  This can be seen in the dump for function g()
below which should be optimized away just like f() but isn't.

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
void f (void)
{
  char a[8];
  __builtin_strcpy (a, "1234");
  if (__builtin_snprintf (0, 0, "%s", a) != 4)
__builtin_abort ();
}

void g (void)
{
  char a[8];
  __builtin_sprintf (a, "1234");
  if (__builtin_strlen (a) != 4)
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1930, cgraph_uid=1, symbol_order=0)

f ()
{
   [local count: 1073741824]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1934, cgraph_uid=2, symbol_order=1)

g ()
{
  char a[8];
  long unsigned int _1;

   [local count: 1073741824]:
  __builtin_memcpy (, "1234", 5);
  _1 = __builtin_strlen ();
  if (_1 != 4)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  return;

}

[Bug demangler/89671] Demangling segfault

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #2 from Christian Biesinger  ---
Hmm, this one crashes for me in c++filt 2.31.1 but not on today's trunk (though
it doesn't demangle it into anything, either)

[Bug c++/92812] New: Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

[mpolacek at gcc dot gnu.org]

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

Bug ID: 92812
   Summary: Implement P1975R0: Fixing the wording of parenthesized
aggregate-initialization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1975r0.html

This wasn't included in my patch for P0960.

[Bug demangler/88629] Regression lead to Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #6 from Christian Biesinger  ---
I can't reproduce this on any of the three testcases with today's binutils
built with ASAN

[Bug demangler/85309] demangler failed with signal 11

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #1 from Christian Biesinger  ---
This seems to not crash in GDB from today:
GNU gdb (GDB) 9.0.50.20191204-git

(gdb) set lang c++
(gdb) demangle
_ZSt7forwardIRZN3ftz6Engine20ClientNetworkHandler13ProcessEventsEvEUlRT_E_EOS3_RNSt16remove_referenceIS3_E4typeE
ftz::Engine::ClientNetworkHandler::ProcessEvents()::{lambda(auto:1&)#1}&
std::forward(std::remove_reference::type&)
quit)

[Bug demangler/81682] Timeout in demangler

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #3 from Christian Biesinger  ---
In today's binutils, both those testcases run really quick in c++filt
(cxxfilt).

[Bug demangler/70517] c++filt crashes when demangling a symbol

[cbiesinger at google dot com]

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

Christian Biesinger  changed:

   What|Removed |Added

 CC||cbiesinger at google dot com

--- Comment #5 from Christian Biesinger  ---
Using binutils from a month ago or so, this does not crash but also does not
demangle...

[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
The following variant of the patch in comment#3 regtests cleanly and handles
more complex cases, like

  integer, parameter :: b(a(1)+a(2)) = 3

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (Revision 278972)
+++ gcc/fortran/decl.c  (Arbeitskopie)
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "parse.h"
 #include "constructor.h"
 #include "target.h"
+#include "arith.h"

 /* Macros to access allocate memory for gfc_data_variable,
gfc_data_value and gfc_data.  */
@@ -2587,8 +2588,20 @@ variable_decl (int elem)
  if (e->expr_type != EXPR_CONSTANT)
{
  n = gfc_copy_expr (e);
+ switch (n->expr_type)
+   {
+   case EXPR_VARIABLE:
+   case EXPR_FUNCTION:
+   case EXPR_OP:
+ gfc_resolve_expr (n);
+ break;
+
+   default:
+ break;
+   }
  gfc_simplify_expr (n, 1);
- if (n->expr_type == EXPR_CONSTANT)
+ if (n->expr_type == EXPR_CONSTANT
+ && gfc_range_check (n) == ARITH_OK)
gfc_replace_expr (e, n);
  else
gfc_free_expr (n);
@@ -2597,8 +2610,20 @@ variable_decl (int elem)
  if (e->expr_type != EXPR_CONSTANT)
{
  n = gfc_copy_expr (e);
+ switch (n->expr_type)
+   {
+   case EXPR_VARIABLE:
+   case EXPR_FUNCTION:
+   case EXPR_OP:
+ gfc_resolve_expr (n);
+ break;
+
+   default:
+ break;
+   }
  gfc_simplify_expr (n, 1);
- if (n->expr_type == EXPR_CONSTANT)
+ if (n->expr_type == EXPR_CONSTANT
+ && gfc_range_check (n) == ARITH_OK)
gfc_replace_expr (e, n);
  else
gfc_free_expr (n);

Given the clumsiness to circumvent the issue with type-bound procedures,
I feel that the simplifications involved should be done at an earlier stage.
Anybody knows where that might be?

[Bug c/84919] [8/9/10 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
The patch below avoids the warning.  Unfortunately, as a result of bug 92666,
it triggers another bogus warning during bootstrap.

Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 278975)
+++ gcc/c-family/c-common.c (working copy)
@@ -5763,8 +5763,26 @@ check_function_arguments (location_t loc, const_tr
   if (warn_format)
 check_function_sentinel (fntype, nargs, argarray);

-  if (warn_restrict)
-warned_p |= check_function_restrict (fndecl, fntype, nargs, argarray);
+  if (fndecl && fndecl_built_in_p (fndecl, BUILT_IN_NORMAL))
+{
+  switch (DECL_FUNCTION_CODE (fndecl))
+   {
+   case BUILT_IN_SPRINTF:
+   case BUILT_IN_SPRINTF_CHK:
+   case BUILT_IN_SNPRINTF:
+   case BUILT_IN_SNPRINTF_CHK:
+ /* Let the sprintf pass handle these.  */
+ return warned_p;
+
+   default:
+ break;
+   }
+}
+
+  /* check_function_restrict sets the DECL_READ_P for arguments
+ so it must be called unconiditionally.  */
+  warned_p |= check_function_restrict (fndecl, fntype, nargs, argarray);
+
   return warned_p;
 }

[Bug c++/92811] New: Odd optimisation differences with lambdas

[david at westcontrol dot com]

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

Bug ID: 92811
   Summary: Odd optimisation differences with lambdas
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at westcontrol dot com
  Target Milestone: ---

While playing with lambdas for higher order functions (in particular, functions
that manipulate functions and return new ones), I saw some differences in the
optimisations depending on seemingly minor changes to how functions are
defined.  This is my sample code:

template 
auto twice(F f)
{
return [f](int v) { return f(f(v)); };
};

int g1(int i)
{
return i + 3;
};

auto g2 = [](int i) { return i + 3; };

int test(int i) {
auto tw = twice(g1);
return tw(i);
}

int test2(int i) {
auto tw = twice(g1);
auto tw2 = twice(tw);
return tw2(i);
}

int test3(int i) {
auto tw = twice(g2);
return tw(i);
}

int test4(int i) {
auto tw = twice(g2);
auto tw2 = twice(tw);
return tw2(i);
}


The generated assembly (x86-64) with -O2 or -O3 is:

g1(int):
leal3(%rdi), %eax
ret
test(int):
leal6(%rdi), %eax
ret
test2(int):
addl$6, %edi
callg1(int)
movl%eax, %edi
jmp g1(int)
test3(int):
leal6(%rdi), %eax
ret
test4(int):
leal12(%rdi), %eax
ret

With -O1, test3 and test4 (where the original function is a lambda) were still
fully optimised, while test1 and test2 had 2 and 4 calls to g1.

(For comparison, clang requires -O2 to get good code, but fully optimises all 4
test functions.)

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Tim Ruehsen from comment #1)
> BTW, llvm-cxxfilt does not show this behavior.

Could it because it does not implement the D demangler?

[Bug go/92810] New: Compiling GCC go for aarch64_be-marvell-linux-gnu fails

[pinskia at gcc dot gnu.org]

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

Bug ID: 92810
   Summary: Compiling GCC go for aarch64_be-marvell-linux-gnu
fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: pinskia at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---
Target: aarch64_be-marvell-linux-gnu

cpugen.go:3:1: error: expected operand
3 | const FunctionDescriptors = false
  | ^
cpugen.go:3:1: error: expected ‘;’ or newline after top level declaration
version.go:67:13: error: expected ‘;’ or ‘)’ or newline
   67 |   BigEndian =
  | ^
version.go:67:3: error: reference to undefined name ‘BigEndian’
   67 |   BigEndian =
  |   ^
libtool: compile: 
/home/apinski/src/toolchain-10/build-aarch64_be-marvell-linux-gnu/./gcc/gccgo
-B/home/apinski/src/toolchain-10/build-aarch64_be-marvell-linux-gnu/./gcc/
-B/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/bin/
-B/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/lib/
-isystem
/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/include
-isystem
/bajas/pinskia/src/toolchain-10/scripts/../marvell-tools-be/aarch64_be-marvell-linux-gnu/sys-include
-L/home/apinski/src/toolchain-10/build-aarch64_be-marvell-linux-gnu/./ld -O2 -g
-I . -c -fgo-pkgpath=crypto/subtle
/bajas/pinskia/src/toolchain-10/scripts/../src/libgo/go/crypto/subtle/constant_time.go
 -fPIC -o crypto/.libs/subtle.o
Makefile:2826: recipe for target 'runtime/internal/sys.lo' failed
make[5]: *** [runtime/internal/sys.lo] Error 1
make[5]: *** Waiting for unfinished jobs


 CUT ---
This is because aarch64_be is not detected at all in libgo/configure .
Currently only aarch64-*-* is detected:
  aarch64-*-*)
GOARCH=arm64
;;

Even though arm64be is listed in ALLGOARCH.

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #13 from Peter Bergner  ---
Ok, second patch to fix the overloaded builtin issue has been committed to
trunk, so I'm marking this as resolved.

We are discussing about disabling the running of the powerpc/dfp/ tests when
DFP is disabled, but that isn't required for this bugzilla.

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

--- Comment #12 from Peter Bergner  ---
Author: bergner
Date: Wed Dec  4 19:53:26 2019
New Revision: 278973

URL: https://gcc.gnu.org/viewcvs?rev=278973=gcc=rev
Log:
Do not define builtins that overload disabled builtins.

PR bootstrap/92661
* config/rs6000/rs6000-c.c (struct altivec_builtin_types): Move to
rs6000.h.
(altivec_overloaded_builtins): Move to rs6000-call.c.
* config/rs6000/rs6000.h (struct altivec_builtin_types): Moved from
rs6000-c.c.
* config/rs6000/rs6000-call.c (rs6000_builtin_info): Make static.
(altivec_overloaded_builtins): Moved from rs6000-c.c.
(rs6000_common_init_builtins): Do no define builtins that overload
builtins that have been disabled.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/rs6000/rs6000-call.c
trunk/gcc/config/rs6000/rs6000.h

[Bug ipa/92801] Drop unused struct fields

[christoph.muell...@theobroma-systems.com]

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

--- Comment #2 from Christoph Müllner 
 ---
Yes, our current approach is all or nothing (i.e. all uses of a struct are
changed or none).

Optimizing individual uses of a type would allow a more tailored optimization.
We decided to defer such an approach in our first shot because it would
make the analysis more complex as we would make individual struct uses
incompatible and we would have to track these uses of the structs
(across compilation units).

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
It has been updated.  I'll have a look.

[Bug ipa/92809] New: [10 regression] error: calls_comdat_local is set outside of a comdat group

[dimhen at gmail dot com]

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

Bug ID: 92809
   Summary: [10 regression] error: calls_comdat_local is set
outside of a comdat group
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

r278936 PASS
r278958 FAIL

Maybe dup PR86905?

$ $ cat x.ii
struct a {
  int operator!=(a);
};
template  struct c : a {
  b operator*();
  void operator++();
};
template  struct e {
  using f = c;
  f begin();
  f end();
};
struct g {
  virtual void anchor();
};
struct h {
  e i;
  virtual void j(int &);
  void k();
};
struct l : g, h {
  void j(int &) {}
};
void h::k() {
  for (auto m : i)
j(*m);
}

$ g++ -fpreprocessed -O2 -std=c++11 -fchecking=1 -c x.ii
x.ii:27:1: error: calls_comdat_local is set outside of a comdat group
   27 | }
  | ^
_ZThn8_N1l1jERi/2 (virtual void l::_ZThn8_N1l1jERi(int&)) @0x7f578fca12d0
  Type: function
  Body removed by symtab_remove_unreachable_nodes
  Visibility: externally_visible public weak comdat comdat_group:_ZN1l1jERi
one_only section:.text._ZN1l1jERi (implicit_section) virtual artificial
  References: 
  Referring: 
  Availability: not_available
  Function flags: calls_comdat_local indirect_call_target
  Former thunk fixed offset -8 virtual value 0 indirect_offset 0 has virtual
offset 0
  Called by: 
  Calls: 
during IPA pass: inline
x.ii:27:1: internal compiler error: verify_cgraph_node failed
0xd7a956 cgraph_node::verify_node()
/home/dimhen/src/gcc_current/gcc/cgraph.c:3444
0xd6ea94 symtab_node::verify()
/home/dimhen/src/gcc_current/gcc/symtab.c:1279
0xd6fbbe symtab_node::verify_symtab_nodes()
/home/dimhen/src/gcc_current/gcc/symtab.c:1299
0xff0290 symtab_node::checking_verify_symtab_nodes()
/home/dimhen/src/gcc_current/gcc/cgraph.h:650
0xff0290 symbol_table::remove_unreachable_nodes(_IO_FILE*)
/home/dimhen/src/gcc_current/gcc/ipa.c:672
0x1b893f6 ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2695
0x1b893f6 execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:3088
Please submit a full bug report,

g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191204 (experimental) [trunk revision 278958] (GCC)

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 47424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47424=edit
A patch

[Bug ipa/92801] Drop unused struct fields

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Removal based on modification of DECL_CHAIN() of TYPE_FIELDS(t)

would mean you have to convert either all uses of such types or none.  Wouldn't
it be better to rather do it just on particular uses of the types and replace
the types with a new shorter or reordered type instead?  I mean, if you in a
couple of functions never access some fields or just write only access them,
but in another spot those fields are used, there is no reason to punt.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Well, lea has to be used in case the flags are live across it.  Not the case of
this PR though of course.

[Bug target/92808] New: GCC sets BTI flag in .note.gnu.property section even though not all functions are compiled with BTI

[momchil.velikov at gmail dot com]

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

Bug ID: 92808
   Summary: GCC sets BTI flag in .note.gnu.property section even
though not all functions are compiled with BTI
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: momchil.velikov at gmail dot com
  Target Milestone: ---

When GCC compiles the following source
```
__attribute__((target("branch-protection=pac-ret"))) int f() { return 0; }
__attribute__((target("branch-protection=bti"))) int g() { return 0; }
```

with

  aarch64-none-linux-gnu-gcc -c x7.c

the `.note.gnu.property` section has the BTI flag set:

```
$ llvm-readelf --notes x7.o
Displaying notes found at file offset 0x0090 with length 0x0020:
  OwnerData size Description
  GNU  0x0010NT_GNU_PROPERTY_TYPE_0 (property note)
Properties:aarch64 feature: BTI

```

IMHO, the flag should be clear, since not all of the functions are compiled
with BTI.

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Christian N from comment #2)
> It didn't occur to me that basically everything needs recompilation with
> -fshort-enums, but it makes perfect sense.

Read the fabulous manual:

  Warning: the -fshort-enums switch causes GCC to generate code that is not
  binary compatible with code generated without that switch.  Use it to conform
  to a non-default application binary interface.

> I suppose this report can be closed as invalid then!?

OK, done.

[Bug target/92767] [m68k]: Random ICE: verify_flow_info failed

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson  ---
I've been doing many gcc-10 native bootstraps on m68k (Aranym) (roughly one per
week), and haven't hit any m68k-specific bootstrap failures.  In particular,
r278681 (post-CC0 conversion) bootstrapped fine with c,ada,c++.  My builds use
pristine sources, save for a local patch to disable a few test cases known to
time out on m68k.

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 47423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47423=edit
gcc10-pr92803.patch

Full untested patch for the ICE.

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
Shouldn't

leal(%rdi,%rax), %eax

be changed to

addl %edi, %eax

unconditionally?

[Bug target/92807] gcc generate extra move for the snippet code along with lea instruction.

[skpgkp2 at gmail dot com]

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

Sunil Pandey  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||skpgkp2 at gmail dot com
Summary|gcc generate extra move for |gcc generate extra move for
   |the snippet code|the snippet code along with
   ||lea instruction.

--- Comment #1 from Sunil Pandey  ---
$ cat t1.c
#include
uint32_t abs2( uint32_t a )
{
uint32_t s = ((a>>15)&0x10001)*0x;
return (a+s)^s;
}

$ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ gcc -Ofast -S t1.c -o t1.s.gcc.9
$ cat t1.s.gcc.9
.file   "t1.c"
.text
.p2align 4
.globl  abs2
.type   abs2, @function
abs2:
.LFB0:
.cfi_startproc
movl%edi, %edx
shrl$15, %edx
andl$65537, %edx
movl%edx, %eax
sall$16, %eax
subl%edx, %eax
movl%eax, %edx
leal(%rdi,%rax), %eax
xorl%edx, %eax
ret
.cfi_endproc
.LFE0:
.size   abs2, .-abs2
.ident  "GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)"
.section.note.GNU-stack,"",@progbits


Intel compiler generate add instead of lea as well as 1 less mov instruction
for same code.

$ icc -Ofast -S t1.c -o t1.s.icc

$ cat t1.s.icc

.L_2__routine_start_abs2_0:
# -- Begin  abs2
.text
# mark_begin;
   .align16,0x90
.globl abs2
# --- abs2(uint32_t)
abs2:
# parameter 1: %edi
..B1.1: # Preds ..B1.0
# Execution count [1.00e+00]
.cfi_startproc
..___tag_value_abs2.1:
..L2:
  #3.1
movl  %edi, %edx#4.23
shrl  $15, %edx #4.23
andl  $65537, %edx  #4.27
movl  %edx, %eax#4.36
shll  $16, %eax #4.36
subl  %edx, %eax#4.36
addl  %eax, %edi#5.19
xorl  %edi, %eax#5.22
ret #5.22
.align16,0x90
# LOE
.cfi_endproc
# mark_end;
.type   abs2,@function
.size   abs2,.-abs2
..LNabs2.0:
.data
# -- End  abs2
.data
.section .note.GNU-stack, ""
# End

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Untested fix:
--- gcc/tree-ssa-forwprop.c.jj  2019-12-03 20:21:30.554464396 +0100
+++ gcc/tree-ssa-forwprop.c 2019-12-04 17:48:36.351450274 +0100
@@ -2283,11 +2283,11 @@ simplify_vector_constructor (gimple_stmt
   gimple_seq stmts = NULL;
   if (!orig[1])
orig[1] = orig[0];
-  else if (orig[1] == error_mark_node
-  && one_nonconstant)
+  else if (orig[1] == error_mark_node && one_nonconstant)
{
  orig[1] = gimple_build_vector_from_val (, UNKNOWN_LOCATION,
- type, one_nonconstant);
+ TREE_TYPE (orig[0]),
+ one_nonconstant);
  /* ???  We can see if we can safely convert to the original
 element type.  */
  converted_orig1 = conv_code != ERROR_MARK;
Though, there is another issue, for the nelts 2 vectors
simplify_vector_constructor created code is actually larger than old code.
And, it might be beneficial if we one day implement clang-like
__builtin_shufflevector or at least add to VEC_PERM_EXPR or something similar
the possibility to say certain element is a don't care (for
__builtin_shufflevector I think that is -1 or negative?), as e.g. on AVX/AVX2
when extracting 128-bit vector out of 256-bit permutation all the upper
elements are don't care and we might get better code if the backend picks the
best element indexes for those to get smallest/fastest permutation.

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

[fc9vqetne38 at temp dot mailbox.org]

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

--- Comment #2 from Christian N  ---
To be honest, I'm not sure when and why it came to be. The build instructions
are partially from an old project and weren't cleaned properly. The immediate
code base actually only uses scoped enums. The problem just came up and upon
investigating, removing the flag fixed it.

It didn't occur to me that basically everything needs recompilation with
-fshort-enums, but it makes perfect sense.

I suppose this report can be closed as invalid then!?

Thanks!

[Bug target/92807] New: gcc generate extra move for the snippet code

[skpgkp2 at gmail dot com]

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

Bug ID: 92807
   Summary: gcc generate extra move for the snippet code
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
  Target Milestone: ---

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #5)
> 
> I'll investigate this problem more.

Hi, Andreas.  The rtlanal code (!lra_in_progress) was added to GCC since the
first patch introducing LRA.  As I wrote it was for x86/x86-64 insn
descriptions which match operands of different modes one of which is XFmode. 
After that I introduced LRA_SUBREG_P for solving this problem.  So I believe we
can remove the code in rtlanal.  Here is the patch I'd like to commit.  I
checked it on variety of targets.  Is the patch ok for you?  I am specially
interesting in your opinion about the test.  It is hard for me get z13 machine,
so I decided to use scan-assembler-not instead of running you test.

Index: ../../gcc/gcc/ChangeLog
===
--- ../../gcc/gcc/ChangeLog (revision 278865)
+++ ../../gcc/gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2019-12-04  Andreas Krebbel  
+   Vladimir Makarov  
+
+   PR rtl-optimization/92176
+   * lra.c (simplify_subreg_regno): Don't permit unconditional
+   changing mode for LRA too.
+
 2019-11-29  Vladimir Makarov  

PR rtl-optimization/92283
Index: ../../gcc/gcc/rtlanal.c
===
--- ../../gcc/gcc/rtlanal.c (revision 278413)
+++ ../../gcc/gcc/rtlanal.c (working copy)
@@ -4009,9 +4009,7 @@ simplify_subreg_regno (unsigned int xreg
   /* Give the backend a chance to disallow the mode change.  */
   if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
   && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
-  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode)
-  /* We can use mode change in LRA for some transformations.  */
-  && ! lra_in_progress)
+  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode))
 return -1;

   /* We shouldn't simplify stack-related registers.  */
Index: ../../gcc/gcc/testsuite/ChangeLog
===
--- ../../gcc/gcc/testsuite/ChangeLog   (revision 278770)
+++ ../../gcc/gcc/testsuite/ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2019-12-04  Andreas Krebbel  
+   Vladimir Makarov  
+
+   PR rtl-optimization/92176
+   * gcc.target/s390/pr92176.c: New test.
+
 2019-11-27  Vladimir Makarov  

PR rtl-optimization/90007
Index: ../../gcc/gcc/testsuite/gcc.target/s390/pr92176.c
===
--- ../../gcc/gcc/testsuite/gcc.target/s390/pr92176.c   (nonexistent)
+++ ../../gcc/gcc/testsuite/gcc.target/s390/pr92176.c   (working copy)
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z13" } */
+
+int a = 5, b, c, d, g, h, k, l, m, o;
+static int e[7];
+int *volatile i = 
+long j;
+
+short p(int f, int dummy) {
+  k = 0 != (*e = m);
+  j = 0;
+  for (; j < 59; j = j + 1)
+*i |= b;
+  g = 1;
+  for (; g <= 4; g++) {
+o = 0;
+for (; o <= 4; o++)
+  i = (int * volatile)(long)l;
+  }
+  return 42;
+}
+
+void
+q() {
+  char *n = (char*)
+
+  (*n = a) == p(e[6], c);
+  for (; h;)
+for (;;)
+  ;
+}
+
+/* { dg-final { scan-assembler-not "\tvsteb" } } */

[Bug fortran/92805] gfortran: blanks within literal constants should not be allowed

[ripero84 at gmail dot com]

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

ripero84 at gmail dot com changed:

   What|Removed |Added

 CC||ripero84 at gmail dot com

--- Comment #1 from ripero84 at gmail dot com ---
Created attachment 47422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47422=edit
Test source files

I believe all attached tests should fail to compile, but currently only
char_*_var.f90 tests do so.

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[asolokha at gmx dot com]

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

--- Comment #19 from Arseny Solokha  ---
I believe this is fixed on both affected branches for over a month, thus the PR
can be closed.

[Bug c++/92806] New: Suboptimal diagnostic for concept that depends on non-bool value

[redi at gcc dot gnu.org]

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

Bug ID: 92806
   Summary: Suboptimal diagnostic for concept that depends on
non-bool value
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

template
struct trait
{
  enum { value = 1 };
};

template
concept foo = trait::value;

static_assert(foo);


Compiled with -std=gnu++2a:

nonbool.cc:8:9:   required by the constraints of 'template concept
foo'
nonbool.cc:10:24: error: constraint does not have type 'bool'
   10 | static_assert(foo);
  |^
nonbool.cc:10:15: error: non-constant condition for static assertion
   10 | static_assert(foo);
  |   ^~~~
nonbool.cc:8:9:   required by the constraints of 'template concept
foo'
nonbool.cc:10:15: error: constraint does not have type 'bool'


It's not clear from the diagnostic that the problem is trait::value on line
8, so the user is left thinking "how can a concept not have type 'bool'?!"

The fix is something like:

template
concept foo = (bool)trait::value;
  ^~

so it would be helpful to diagnose the non-bool type at the location of the
concept definition, not its use.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/81178] [concepts] poor (partial?) diagnostic for alias substitution failure in a concept body

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Huh, trunk now accepts the program.

[Bug tree-optimization/92738] [10 regression] Large code size growth for -O2 binaries between 2019-05-19...2019-05-29

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #12)
> People who have problems can then enable

I meant disable, of course.

> that option for
> the specific files they have the problems with.

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase with -O2 -mavx:
typedef double v4df __attribute__((vector_size (32)));
typedef double v2df __attribute__((vector_size (16)));

v2df
foo (v4df x, double *p, v2df y)
{
  return (v2df) { x[3], *p };
}

[Bug fortran/92805] New: gfortran: blanks within literal constants should not be allowed

[ripero84 at gmail dot com]

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

Bug ID: 92805
   Summary: gfortran: blanks within literal constants should not
be allowed
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ripero84 at gmail dot com
  Target Milestone: ---

I belive that when writing free source form and using kind parameters as part
of integer, real, logical or character literal constants, there cannot be any
blanks between the underscore and the kind-param, or between the underscore and
the rest of characters that are part of the same literal constant.  This means
that, e.g.,

3.1415_4

is a valid real literal constant (if 4 is a valid real kind), but

3.1415 _4
3.1415_ 4

are not - and these don't have an possible interpretations as valid Fortran.

My interpretation is based on the following sections and rules of the Fortran
2018 standard:
* 6.2.1: "A lexical token is a keyword, name, literal constant other than a
complex literal constant [...]"
* 6.3.2.2: "In free source form blank characters shall not appear within
lexical tokens other than in a character context or in a format specification."
* R708, R714, and R725 establish that a trailing _kind-param is an optional
part of int-literal-constants, real-literal-constants, and
logical-literal-constants, respectively.
* R724 establishes that a leading kind-param_ is an optional part of a
char-literal-constant.

As far as I can see, these requirements go back all the way to the first
version of the standard that supported free source form, Fortran 90.

Unfortunately, all the versions of gfortran I've tried so far (9.2.1 20191109,
8.3.0, 7.5.0, 6.4.0 20181019), irrespective of the use of one of the -std=
flags or none, fail to detect the presence of blanks at one or both of the
sides of the underscore, and happily compile the source code.  This happens
also irrespective of whether the kind-param is numeric (3.1415_4) or an integer
variable with the parameter attribute

INTEGER, PARAMETER :: k = KIND(1.0)
WRITE(*,*) 3.1415_k ! valid Fortran
WRITE(*,*) 3.1415 _k ! invalid Fortran not detected by gfortran

with the only exception of character literal constants, where gfortran actually
produces an error if one attempts to compile code where spaces are present and
the kind-param is given by a variable:

WRITE(*,*) 4_ 'b' ! invalid Fortran not detected by gfortran
INTEGER, PARAMETER :: k = KIND('a')
WRITE(*,*) k_ 'b' ! invalid Fortran detected by gfortran

[Bug tree-optimization/92738] [10 regression] Large code size growth for -O2 binaries between 2019-05-19...2019-05-29

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
(In reply to Wilco from comment #11)

> Would using -frepack-arrays solve this issue? I proposed making that the
> default a while back. It would do any repacking that is necessary at call
> sites rather than creating multiple copies of all loops in every function.

I'm not convinced that that is the answer - this would penalize (at runtime)
programs which use non-contiguous memory when _not_ passing them to
an explicit size or assumed size paramter. For example, all the optimizations
for passing a transposed argument would then no longer work.

What we could do instead is to introduce another option, -frepack-inline
(or whatever we want to call it) and enable this by default at all -O
except at -Os. People who have problems can then enable that option for
the specific files they have the problems with.

[Bug c++/92804] [10 Regression] ICE trying to use concept as a nested-name-specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||9.2.1
  Known to fail||10.0

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> With -std=gnu++17 -fconcepts on gcc-9-branch we get an inaccurate error
> (it's not a variable template) but no ICE:

Oh, and the same on trunk. It only ICEs with -std=gnu++2a


So arguably, not a regression, because GCC 9 doesn't support C++2a concepts.

[Bug c++/92804] New: [10 Regression] ICE trying to use concept as a nested-name-specifier

[redi at gcc dot gnu.org]

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

Bug ID: 92804
   Summary: [10 Regression] ICE trying to use concept as a
nested-name-specifier
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

template
concept foo = true;

template
void bar(T t)
{
  if constexpr (foo::value)
  {
  }
}

int main()
{
  bar(1);
}


Compiled with -std=gnu++2a on trunk:

iced.cc: In function 'void bar(T)':
iced.cc:7:22: internal compiler error: in cp_parser_nested_name_specifier_opt,
at cp/parser.c:6467
7 |   if constexpr (foo::value)
  |  ^
0x9edca7 cp_parser_nested_name_specifier_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:6467
0x9ea58b cp_parser_simple_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17994
0x9d8ee0 cp_parser_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:17652
0x9d9ea6 cp_parser_decl_specifier_seq
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:14249
0x9f6e6f cp_parser_condition
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:12128
0x9dce0e cp_parser_selection_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11883
0x9dce0e cp_parser_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11258
0x9de1f2 cp_parser_statement_seq_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11742
0x9de2c8 cp_parser_compound_statement
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:11696
0x9f6755 cp_parser_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22867
0x9f6755 cp_parser_ctor_initializer_opt_and_function_body
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22918
0x9f9a91 cp_parser_function_definition_after_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28675
0x9fa831 cp_parser_function_definition_from_specifiers_and_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28591
0x9fa831 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:20496
0x9ff004 cp_parser_single_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29166
0x9ff171 cp_parser_template_declaration_after_parameters
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:28738
0x9ffc89 cp_parser_explicit_template_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29004
0x9ffc89 cp_parser_template_declaration_after_export
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:29023
0xa02999 cp_parser_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:13271
0xa02fe7 cp_parser_translation_unit
/home/jwakely/src/gcc/gcc/gcc/cp/parser.c:4721
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


With -std=gnu++17 -fconcepts on gcc-9-branch we get an inaccurate error (it's
not a variable template) but no ICE:

iced.cc: In function 'void bar(T)':
iced.cc:7:17: error: variable template-id 'foo' in nested-name-specifier
7 |   if constexpr (foo::value)
  | ^~
iced.cc:2:9: note: 'template concept const bool foo' declared here
2 | concept foo = true;
  | ^~~
iced.cc:7:30: error: expected initializer before ')' token
7 |   if constexpr (foo::value)
  |  ^
iced.cc:7:30: error: the value of 'value' is not usable in a constant
expression
iced.cc: In instantiation of 'void bar(T) [with T = int]':
iced.cc:14:8:   required from here
iced.cc:7:3: error: the value of 'value' is not usable in a constant expression
7 |   if constexpr (foo::value)
  |   ^~
iced.cc:5:12: warning: unused parameter 't' [-Wunused-parameter]
5 | void bar(T t)
  |  ~~^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug target/92791] [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
We have in the documentation:
 For a named pattern, the condition may not depend on the data in
 the insn being matched, but only the target-machine-type flags.
 The compiler needs to test these conditions during initialization
 in order to learn exactly which named instructions are available in
 a particular run.
and while optimize_function_for_size_p (cfun) doesn't depend on data in the
insn being matched, it can't be said to be target-machine-type flags either.
As -m32 -O2 -march=i686 testcase below shows, while I can't reproduce the ICE
on a short testcase yet (i.e. the case when init_all_optabs is called while
optimize_function_for_size_p (cfun) is true, but this_fn_optabs is later used
in a function where it is full, this testcase shows the other case, where the
optab is initialized while it is false, but is used when it is true, so this
testcase doesn't use movstrictqi even when it should.
struct S { S (void *a, bool b) : x (a), y (b) {} void *x; bool y; };
void bar (S);

__attribute__((noipa, cold, optimize ("Os"))) void
foo (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}

__attribute__((noipa, hot)) void
bar (S x)
{
  asm volatile ("" : : "r" (x.x), "q" (x.y) : "memory");
}

__attribute__((noipa, hot)) void
baz (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}

__attribute__((noipa, cold, optimize ("Os"))) void
qux (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}

int
main ()
{
  foo (nullptr);
  for (int i = 0; i < 10; i++)
baz (nullptr);
  qux (nullptr);
  return 0;
}

Seems movstrict{qi,hi} are the only i386 patterns that in init_all_optabs (as
verified by preprocessing insn-opinit.c) where something depends on size or
speed optimization of current function.

Thus, I think we should go with a patch like:
2019-12-04  Jakub Jelinek  

PR target/92791
* config/i386/i386.md (movstrict): Move test for
TARGET_PARTIAL_REG_STALL and not optimizing for size from
expander's condition to the body - FAIL; in that case.

--- gcc/config/i386/i386.md.jj  2019-12-03 09:22:17.421777187 +0100
+++ gcc/config/i386/i386.md 2019-12-04 16:35:34.193669660 +0100
@@ -2801,10 +2801,11 @@ (define_peephole2
 (define_expand "movstrict"
   [(set (strict_low_part (match_operand:SWI12 0 "register_operand"))
(match_operand:SWI12 1 "general_operand"))]
-  "!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun)"
+  ""
 {
   gcc_assert (SUBREG_P (operands[0]));
-  if (GET_MODE_CLASS (GET_MODE (SUBREG_REG (operands[0]))) != MODE_INT)
+  if ((TARGET_PARTIAL_REG_STALL && optimize_function_for_speed_p (cfun))
+  || GET_MODE_CLASS (GET_MODE (SUBREG_REG (operands[0]))) != MODE_INT)
 FAIL;
 })


which fixes the #c0 ICE and improves the above testcase (makes the Os optimized
functions shorter).

[Bug c/92773] GCC compilation with big array / header is infinite

[renault at fedoraproject dot org]

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

--- Comment #6 from Charles-Antoine Couret  
---
Ok with a friend we identified a bit more what is the issue.

So in fact I built (manually):

$ gcc -Wall sound/soc/codecs/tas5756m.i -o sound/soc/codecs/tas5756m.o

In that case, no output and it does not stop.

But with:

$ gcc sound/soc/codecs/tas5756m.i

It finished very quickly with some linker errors.

And with:

$ gcc -Wall sound/soc/codecs/tas5756m.i

There are a lot of outputs (warning for each line of my big arrays). And the
process is really slow, some minutes to display the first 1000 lines. It seems
slower over the time (the beginning seems really faster than the end).

I assume that's the issue that I got with Linux build system.

>From my point of view there is a performance regression somewhere. I don't
think this behaviour is normal.

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
-fshort-enums is an ABI-changing option, which means you should recompile the
entire toolchain including the standard libraries.

Why are you using it anyway? In C++ you can specify a fixed underlying type, so
you can control the exact size of each enumeration type.

[Bug libgomp/85463] [nvptx] "exit" in offloaded region doesn't terminate process

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  ---
(In reply to Martin Liška from comment #2)
> Tom: Can the bug be marked as resolved?

One has
! { dg-output "libgomp: cuStreamSynchronize error.*" { target
openacc_nvidia_accel_selected } }

That's for the output:

  ERROR STOP (possibly followed by a number or message string)

  libgomp: cuStreamSynchronize error: an illegal instruction was encountered

Which is not that nice. Also the error code is not propagated. (It is the value
of the integer used with 'error stop' or one when using nothing or a string.)

I assume the illegal instruction was a way to cause terminations with non-zero
exit code …

In my opinion: I think that's the only issue with the current implementation;
if one regards this part as WONTFIX – then the commit in comment 1 has FIXED
it. Otherwise, one can leave this bug OPEN until a better solution is found.

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 47421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47421=edit
test-case

[Bug tree-optimization/92803] New: [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

Bug ID: 92803
   Summary: [10 Regression] error: type mismatch in
'vec_perm_expr' since r278764
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu

I see the following ICE reduced from 465.tonto:

$ gcc -O3 -flto=16 -march=haswell realmat.fppized.f90 realmat3.fppized.f90
-shared
realmat3.fppized.f90:7:15:

7 |   do n = 1,order
  |   1
Warning: Deleted feature: End expression in DO loop at (1) must be integer
realmat3.fppized.f90: In function 'gaussian_f_xyz_matrices':
realmat3.fppized.f90:4: error: type mismatch in 'vec_perm_expr'
4 |function gaussian_f_xyz_matrices(self) result(ftr)
  | 
vector(4) double
vector(4) double
vector(2) double
vector(4) unsigned long
_433 = VEC_PERM_EXPR ;
during GIMPLE pass: forwprop
realmat3.fppized.f90:4: internal compiler error: verify_gimple failed
0xd16001 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5445
0xbf458f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1983
0xbf533e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/tmp/ccEdrkBy.mk:2: /tmp/ccDaF6lu.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug tree-optimization/92803] [10 Regression] error: type mismatch in 'vec_perm_expr' since r278764

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 47420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47420=edit
test-case

[Bug ipa/92802] New: Struct field reordering

[christoph.muell...@theobroma-systems.com]

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

Bug ID: 92802
   Summary: Struct field reordering
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.muell...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Non-escaping structs [1] can be rearranged such that
they have a smaller memory footprint and thus allow
a more efficient cache utilisation.

We are currently working on such a pass and want to use this
ticket to further publish details and patches, and to collect
feedback from the community.

First implementation details:

* Reordering is based on modification of DECL_CHAIN()s of TYPE_FIELDS(t)
* Reordering based on size (biggest to smallest)

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800

[Bug ipa/92538] Proposal for IPA init() constant propagation

[christoph.muell...@theobroma-systems.com]

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

--- Comment #4 from Christoph Müllner 
 ---
Early tests with this pass showed that a bunch of SPEC CPU2017 benchmarks
benefit from this. For example, the written-once global variable TTSize of
sjeng
is eliminated by this pass.

[Bug ipa/92801] New: Drop unused struct fields

[christoph.muell...@theobroma-systems.com]

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

Bug ID: 92801
   Summary: Drop unused struct fields
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.muell...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Non-escaping structs [1] can have their unused fields removed such that
they have a smaller memory footprint and thus allow
a more efficient cache utilisation.

We are currently working on such a pass and want to use this
ticket to further publish details and patches, and to collect
feedback from the community.

First implementation details:

* Iterate with gsi over function bodies to find field accesses
  (e.g. in assignment, call, cond or switch statements).
* Allowed for removal if never accessed
* Allowed for removal if write-only (incl. removal of write statements)
* Removal based on modification of DECL_CHAIN() of TYPE_FIELDS(t)

Early tests showed, that this has the potential to eliminate
struct fields nextout and nextin from struct arc of CPU2017's mcf benchmark.
As elements of an struct arc array are accessed for the main calculation in
the hot loop, this benchmark is a good example, where this pass will help.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92800

[Bug ipa/92800] New: IPA escape analysis for structs

[christoph.muell...@theobroma-systems.com]

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

Bug ID: 92800
   Summary: IPA escape analysis for structs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christoph.muell...@theobroma-systems.com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Having GCC infrastructure code to detect non-escaping
structs during whole-program analysis opens the door
for the field of struct reorganisation optimisations.

We are currently working on such infrastructure
and want to use this ticket to further publish
details and patches, and to collect feedback from
the community.

First implementation details:

* escape analysis for RECORD_TYPE types
* supporting code for IPA passes
* running after IPA visibility
* checking all externally visible symbols/signatures
* checking all type casts

[Bug target/92791] [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
So:
struct S { S (void *a, bool b) : x (a), y (b) {} void *x; bool y; };
void bar (S);

void
foo (void *x)
{
  S sbuf_it (x, x == nullptr);
  bar (sbuf_it);
}
with -O2 -m32 -march=i686 -mtune=i586
gives the same insn, but is actually recognized.
>From what I can see, the problem is that this_fn_optabs points to something
that has been initialized in a function that has been optimized for size, but
this function is not.  So, the question is, is it invalid to use
optimize_function_for_size_p (cfun) in optab conditions?

[Bug c/92799] New: ICE: in get, at cgraph.h:1339

[anbu1024.me at gmail dot com]

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

Bug ID: 92799
   Summary: ICE: in get, at cgraph.h:1339
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anbu1024.me at gmail dot com
  Target Milestone: ---

$ cat test.c 

static void __attribute__ ( ( weakref ( "bar" ) ) ) foo ( void ) { } 

extern void foo ( void ) ;



$ gcc-snapshot10 --version
gcc (GCC) 10.0.0 20191201 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-snapshot10 test.c 
test.c:2:53: internal compiler error: in get, at cgraph.h:1339
2 | static void __attribute__ ( ( weakref ( "bar" ) ) ) foo ( void ) { }
  | ^~~
0x618bad cgraph_node::get(tree_node const*)
../../gcc-10-20191201/gcc/cgraph.h:1339
0x619c7a cgraph_node::get(tree_node const*)
../../gcc-10-20191201/gcc/tree.h:3387
0x619c7a cgraph_node::analyze()
../../gcc-10-20191201/gcc/cgraphunit.c:622
0x9268ef analyze_functions
../../gcc-10-20191201/gcc/cgraphunit.c:1212
0x9274a2 symbol_table::finalize_compilation_unit()
../../gcc-10-20191201/gcc/cgraphunit.c:2925
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



$ gcc-snapshot9 --version
gcc (GCC) 9.2.1 20191123
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



$ gcc-snapshot9 test.c 
test.c:2:53: internal compiler error: Segmentation fault
2 | static void __attribute__ ( ( weakref ( "bar" ) ) ) foo ( void ) { }
  | ^~~
0xa8c89f crash_signal
../../gcc-9-20191123/gcc/toplev.c:326
0x71f7c2 cgraph_node* dyn_cast(symtab_node*)
../../gcc-9-20191123/gcc/is-a.h:227
0x71f7c2 cgraph_node::get(tree_node const*)
../../gcc-9-20191123/gcc/cgraph.h:1339
0x71f7c2 cgraph_node::analyze()
../../gcc-9-20191123/gcc/cgraphunit.c:640
0x721e77 analyze_functions
../../gcc-9-20191123/gcc/cgraphunit.c:1126
0x722a62 symbol_table::finalize_compilation_unit()
../../gcc-9-20191123/gcc/cgraphunit.c:2837
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063

[zhroma at gcc dot gnu.org]

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

--- Comment #6 from Roman Zhuykov  ---
Patches are still testing.  Arm (both 32 and 64 bit) cross compilers are OK,
and I want to test some additional scenarios for powerpc.  Probably I'll post
patches next week.

[Bug libstdc++/92798] New: -fshort-enums can break iterators of std::map

[fc9vqetne38 at temp dot mailbox.org]

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

Bug ID: 92798
   Summary: -fshort-enums can break iterators of std::map
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fc9vqetne38 at temp dot mailbox.org
  Target Milestone: ---

Hi,

I'm having problems with iterators of std::map when -fshort-enums is enabled.
It somehow depends on the combination of compiler, stdlib and optimizations
(tested g++ and clang++, libstdc++ and libc++). The size of key (int vs. long)
and map also seem to matter. My layman guess is, that it's somehow related to
operator--.

Short example that shows the (to me unexpected) behavior, used versions of g++
and clang++ at the end:

#include 
#include 
int main() {
  auto m = std::map{{0,0}, {1,1}, {2,2}};
  std::cout << std::boolalpha;
  std::cout << (&(*m.begin()) == &(*m.rbegin())) << ' ';
  std::cout << (m.begin() == --m.end()) << ' ';
  std::cout << (++m.rbegin() == m.rend()) << ' ';
  std::cout << (++m.begin() == m.end()) << ' ';
  std::cout << (++(--m.end()) == m.end()) << '\n';
}

Compiling with g++ -fshort-enums main.cpp gives

true true true false false

while g++ main.cpp gives

false false false false true

I also tried compiling with clang++, libc++ and optimizations enabled in
various combinations.

1) g++ -nostdinc++ -I/usr/include/c++/v1 main.cpp -nodefaultlibs -lc++ -lc++abi
-lm -lc -lgcc_s -lgcc -fshort-enums

2) g++ -nostdinc++ -I/usr/include/c++/v1 main.cpp -nodefaultlibs -lc++ -lc++abi
-lm -lc -lgcc_s -lgcc -fshort-enums -O

3) clang++ -stdlib=libstdc++ -fshort-enums main.cpp

4) clang++ -O -stdlib=libstdc++ -fshort-enums main.cpp

5) clang++ -stdlib=libc++ -fshort-enums main.cpp

6) clang++ -O -stdlib=libc++ -fshort-enums main.cpp

All 1)-6) give

false false false false true

though 4) sometimes produces

true true true false false

e.g. when doing a range-based loop over the map before the comparisons.

Hope the report is legit and not too messy.

Cheers,
Christian

PS:

opensuse tumbleweed
g++ (SUSE Linux) 9.2.1 20190903 [gcc-9-branch revision 275330]
clang version 9.0.0 (tags/RELEASE_900/final 372316)

[Bug fortran/92775] [8/9/10 Regression] Incorrect expression in DW_AT_byte_stride on an array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.5.0
   Target Milestone|--- |8.4
Summary|Incorrect expression in |[8/9/10 Regression]
   |DW_AT_byte_stride on an |Incorrect expression in
   |array   |DW_AT_byte_stride on an
   ||array

[Bug fortran/92775] Incorrect expression in DW_AT_byte_stride on an array

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
That means the get_array_descr_info langhook wasn't updated I guess.

[Bug fortran/92775] Incorrect expression in DW_AT_byte_stride on an array

[andrew.burgess at embecosm dot com]

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

--- Comment #1 from Andrew Burgess  ---
I ran a bisect and this is the commit where GCC stops producing the DWARF I
would expect to see:

In GIT:
 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=47e6a59aedf4b114c2b4865c97a91a7b700cd991

In SVN:
  https://gcc.gnu.org/viewcvs/gcc?view=revision=251949

[Bug c/92773] GCC compilation with big array / header is infinite

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Hmm, compilation finishes instantly for me.  I tried, -O2, -Os and -O3.

[Bug demangler/92797] cplus_demangle() produces huge amount of output (on trunk)

[tim.ruehsen at gmx dot de]

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

--- Comment #1 from Tim Ruehsen  ---
BTW, llvm-cxxfilt does not show this behavior.

[Bug c/92773] GCC compilation with big array / header is infinite

[renault at fedoraproject dot org]

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

Charles-Antoine Couret  changed:

   What|Removed |Added

  Attachment #47408|0   |1
is obsolete||
  Attachment #47409|0   |1
is obsolete||
  Attachment #47410|0   |1
is obsolete||

--- Comment #4 from Charles-Antoine Couret  
---
Created attachment 47419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47419=edit
module driver after preprocessor

[Bug demangler/92797] New: cplus_demangle() produces huge amount of output (on trunk)

[tim.ruehsen at gmx dot de]

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

Bug ID: 92797
   Summary: cplus_demangle() produces huge amount of output (on
trunk)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

Created attachment 47418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47418=edit
700mb output reproducer

c++file `cat slow-unit-150de9e10e6b2b6e62a6bac5b4c1fc87602ef3c6` (the attached
reproducer file) creates output of >700Mb.

[Bug rtl-optimization/92796] New: [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[doko at debian dot org]

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

Bug ID: 92796
   Summary: [10 Regression] ICE in lra_assign, at
lra-assigns.c:1646 on powerpc64le-linux-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

Created attachment 47417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47417=edit
preprocessed source

seen with r278959 on powerpc64le-linux-gnu, trunk:

// during RTL pass: reload
// ../../../src/libquadmath/math/acosq.c: In function 'acosq':
// ../../../src/libquadmath/math/acosq.c:317:1: internal compiler error: in
lra_assign, at lra-assigns.c:1646
//   317 | }
//   | ^
// 0x106652fb lra_assign(bool&)
//  ../../src/gcc/lra-assigns.c:1646
// 0x1065e353 lra(_IO_FILE*)
//  ../../src/gcc/lra.c:2487
// 0x1060345b do_reload
//  ../../src/gcc/ira.c:5518
// 0x1060345b execute
//  ../../src/gcc/ira.c:5704
// Please submit a full bug report,
// with preprocessed source if appropriate.

[Bug demangler/92795] New: Another slowness issue in the demangler (on trunk)

[tim.ruehsen at gmx dot de]

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

Bug ID: 92795
   Summary: Another slowness issue in the demangler (on trunk)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim.ruehsen at gmx dot de
  Target Milestone: ---

c++filt
'_ZZ1_DO1z1psp1VEz1VE2On'

takes ~1200s to finish.

Relevant part of the callback
#6 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#7 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#8 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#9 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#10 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#11 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#12 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#13 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#14 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#15 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#16 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#17 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#18 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#19 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#20 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#21 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#22 0x514263 in d_find_pack
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4479:11
#23 0x50d514 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5685:33
#24 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#25 0x514138 in d_print_subexpr
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4540:3
#26 0x51150c in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5514:4
#27 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#28 0x512ce5 in d_print_mod
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c
#29 0x50f6d4 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5155:4
#30 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#31 0x50edc2 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5331:2
#32 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#33 0x51384c in d_print_function_type
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6084:5
#34 0x510d8d in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5216:4
#35 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#36 0x510628 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4813:2
#37 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#38 0x50dda3 in d_print_comp_inner
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4708:7
#39 0x503a44 in d_print_comp
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:5781:3
#40 0x50335e in cplus_demangle_print_callback
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:4352:5
#41 0x504a5e in d_demangle_callback
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6345:16
#42 0x504325 in d_demangle
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6367:12
#43 0x504209 in cplus_demangle_v3
/home/tim/src/binutils-gdb/libiberty/./cp-demangle.c:6524:10
#44 0x4fbc44 in cplus_demangle
/home/tim/src/binutils-gdb/libiberty/./cplus-dem.c:166:13

[Bug c++/92743] doc: -Wattribute-alias improperly indexed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed with r272672.

[Bug target/92791] [10 Regression] ICE in extract_insn, at recog.c:2311 since r278645

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Reproduced, looking at it now.

[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |fxue at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #2 from Martin Liška  ---
Started with r278193.

[Bug ipa/92794] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5186

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-04
  Known to work||9.2.0
   Host||x86_64-linux-gnu
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, let me bisect that, one can see it with a cross-compiler as well.

[Bug fortran/92754] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:693

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #5 from Tobias Burnus  ---
FIXED on the GCC 10 trunk – not a (real) regression and potentially fragile
(cf. email); hence, no backporting.

Thanks for the bug report!

[Bug fortran/92754] ICE in gfc_finish_var_decl, at fortran/trans-decl.c:693

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Author: burnus
Date: Wed Dec  4 12:19:55 2019
New Revision: 278961

URL: https://gcc.gnu.org/viewcvs?rev=278961=gcc=rev
Log:
Fortran] PR92754 - fix an issue with resolving intrinsic functions

gcc/fortran/
PR fortran/92754
* intrinsic.c (gfc_intrinsic_func_interface): Set
sym's flavor, intrinsic and function attribute if
unset.

gcc/testsuite/
PR fortran/92754
gfortran.dg/intrinsic_9.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog