[Bug other/92396] -ftime-trace support

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Thank you Alexander for the pointer. I've just read the article and I must
confirm that compiler uses demand for something that we can't currently support
easily. I'm leaving that unassigned.

[Bug tree-optimization/95679] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6231

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
SCEV info is wrecked by copyprop in this case which does

 u1 (int hu, int nd)
 {
   int ex.0_1;
@@ -36,10 +41,9 @@
[local count: 64191087]:

[local count: 118111600]:
-  # hu_10 = PHI 

[local count: 1073741824]:
-  # hu_4 = PHI 
+  # hu_4 = PHI 
   _2 = (long int) hu_4;
   _3 = (void (*) (int, int)) _2;
   if (_3 < u1)

caused by Aldys refactoring which lost a "changed" setting by too much
C++-ification.  Also looks like propagating into PHI args is now done twice?!

Testing patch.

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[aros at gmx dot com]

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

--- Comment #12 from Artem S. Tashkinov  ---
Michael has admitted that might be a specific CPU relate regression:

> Been running some more tests today:
> - Tried on a i9-10980XE Cascade Lake and Cascade Lake Xeon systems and did 
> not reproduce...
> - I went back to the i9-10900K and picked just a few of the tests where it 
> was impacted the hardest, but then surprisingly the results were similar that 
> run.

Source:
https://www.phoronix.com/forums/forum/software/programming-compilers/1196789-gcc-benchmarks-at-varying-optimization-levels-with-core-i9-10900k-show-an-unexpected-surprise?p=1197196#post1197196

The plot thickens.

[Bug tree-optimization/95679] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6231

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
And the ICE was mitigated by g:8fb4d1d58362b77da78c09740c6b5562124a369e but
the 'changed' flag still is missing.

[Bug preprocessor/95889] [10 regression] __has_include broken with -traditional-cpp (and therefore with Fortran)

[t...@dev-zero.ch]

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

Tiziano Müller  changed:

   What|Removed |Added

Summary|__has_include evaluated |[10 regression]
   |even if disabled (with cpp  |__has_include broken with
   |in traditional-mode)|-traditional-cpp (and
   ||therefore with Fortran)
 CC||jakub at gcc dot gnu.org,
   ||nathan at acm dot org

--- Comment #4 from Tiziano Müller  ---
Link to patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550832.html

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 28 Jul 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354
> 
> --- Comment #9 from Jakub Jelinek  ---
> (In reply to rguent...@suse.de from comment #8)
> > We could allow this in debug stmts but pretty much any (or very many)
> > workers on MEM_REFs will be quite unhappy about this. Of course we're not
> > likely to run them on debug stmts. But then, we do have debug Temps for
> > this...
> 
> I was wondering if we are ok with even MEM_REF with DEBUG_EXPR_DECL as the
> address, but seems at least this routine is ok with that one.
> The question is what we would do with that at cfgexpand.c time.
> But I guess I can look at where this is folded into it and see if I can break
> it out into a debug expr decl and then see what expansion does for it.

It wouldn't be an address of a DEBUG_EXPR_DECL but the DEBUG_EXPR
defining the DEBUG_EXPR_DECL would be the address itself, thus

# DEBUG D.12 = &a[i_3];
# DEBUG a = MEM_REF[D.12];

[Bug c++/96282] [8/9/10/11 Regression] internal compiler error: in output_constructor_regular_field

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection,|
   |needs-reduction |
 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Reduced test-case:

#include 

template 
class Pen : std::array {
  typedef std::array arr;
public:
  // Removing either "constexpr" or ": arr()" from the following
  // line seems to work around the problem.
  constexpr Pen() : arr() { }
};

class Farm {
public:
  enum Sheep { BAA, ZZZ };

  template
  using SheepPen = Pen;
};

class Fence {
public:
  constexpr Fence() { length = 12; }
  int length = 0;
};

void
cull() {
  static Farm::SheepPen s;
}

Will you look at it Richi?

[Bug target/96206] internal compiler error: in convert_move, at expr.c:218

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Martin Liška  ---
(In reply to Enrico Zini from comment #2)
> Unfortunately I do not have access to gcc 8.4.0.
> 
> I also found a workaround for the ICE that allowed me to unblock the next
> step of an immense yak shaving quest to compile Qt5:
> https://www.enricozini.org/blog/2020/qt5/build-qt5-cross-builder-with-
> raspbian-sysroot-compiling-with-the-sysroot/
> 
> I can try to provide help here if I can, but if it's fixed in 9.x and
> apparently also in 8.4.x, and the case where it happens (building a Qt5
> cross-build environment including qtwebengine on Debian stable) can be
> worked around that easily, I might not have that much energy to invest
> following this up.

Agree. I'm pretty sure the issue is fixed in newer versions of the GCC.
Feel free to reopen the issue if that isn't the case.

[Bug tree-optimization/95679] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6231

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Just for the record, it started with .

[Bug tree-optimization/95679] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6231

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
r11-1146-g1396fa5b91cfa0b3

[Bug c/96365] New: GCC report impossible constraint on possible inline assembly output constraints

[141242068 at smail dot nju.edu.cn]

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

Bug ID: 96365
   Summary: GCC report impossible constraint on possible inline
assembly output constraints
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

$ cat a.c
int main() {
  int x = 0, y = 0, z = 0;
  asm("" : "=ab"(x), "=bc"(y), "=c"(z));
  return 0;
}

Inline assembly at line 3 is a possible constraint, compiler can allocate eax
for x, ebx for y, ecx for z, but GCC report that this asm has impossible
constraint as below:

-> tmp $ gcc a.c
asm.c: In function ‘main’:
asm.c:3:3: error: ‘asm’ operand has impossible constraints
3 |   asm("" : "=ab"(x), "=bc"(y), "=c"(z));
  |   ^~~

My gcc version:

-> tmp $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-10ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)

[Bug c/96365] GCC report impossible constraint on possible inline assembly output constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Any reason why you can't just write "=a"(x), "=b"(y), "=c"(z) if you mean that
as the only possibility?

[Bug tree-optimization/96075] [8/9 Regression] bogus alignment for negative step grouped access

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Likely started with r8-568-gf9f69dd651b2f103.

after:

.L7:
movapd  y+8176(%rax), %xmm0
movq%rax, %rdx
subq$16, %rax
negq%rdx
cmpq$-8192, %rax
unpcklpd%xmm0, %xmm0
movaps  %xmm0, x(%rdx)
jne .L7
xorl%edx, %edx
.p2align 4,,10
.p2align 3

before:

movapd  (%rax), %xmm0
addq$16, %rdx
leaq-16(%rax), %rcx
unpcklpd%xmm0, %xmm0
movaps  %xmm0, -16(%rdx)
cmpq$y, %rax
jne .L11
xorl%edx, %edx
.p2align 4,,10
.p2align 3

[Bug tree-optimization/96075] [8/9 Regression] bogus alignment for negative step grouped access

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
(In reply to Martin Liška from comment #10)
> Likely started with r8-568-gf9f69dd651b2f103.

Very unlikely (IVOPTS runs after vectorization)

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Created attachment 48949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48949&action=edit
gcc11-pr96354.patch

Untested fix.

[Bug c++/95823] [coroutines] compiler internal error in captures_temporary,

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-8545-gf43a1b1d1718969423337190ddbbbc9037c67783
Author: Iain Sandoe 
Date:   Sun Jul 19 18:39:21 2020 +0100

coroutines: Correct frame capture of compiler temps [PR95591+4].

When a full expression contains a co_await (or co_yield), this means
that it might be suspended; which would destroy temporary variables
(on a stack for example).  However the language guarantees that such
temporaries are live until the end of the expression.

In order to preserve this, we 'promote' temporaries where necessary
so that they are saved in the coroutine frame (which allows them to
remain live potentially until the frame is destroyed).  In addition,
sub-expressions that produce control flow (such as TRUTH_AND/OR_IF
or COND_EXPR) must be handled specifically to ensure that await
expressions are properly expanded.

This patch corrects two mistakes in which we were (a) failing to
promote some temporaries and (b) we we failing to sequence DTORs for
the captures properly. This manifests in a number of related (but not
exact duplicate) PRs.

The revised code collects the actions into one place and maps all the
control flow into one form - a benefit of this is that co_returns are
now expanded earlier (which provides an opportunity to address PR95517
in some future patch).

We replace a statement that contains await expression(s) with a bind
scope that has a variable list describing the temporaries that have
been 'promoted' and a statement list that contains a series of cleanup
expressions for each of those.  Where we encounter nested conditional
expressions, these are wrapped in a try-finally block with a guard var
for each sub-expression variable that needs a DTOR.  The guards are all
declared and initialized to false before the first conditional sub-
expression.  The 'finally' block contains a series of if blocks (one
per guard variable) enclosing the relevant DTOR.

Variables listed in a bind scope in this manner are automatically moved
to a coroutine frame version by existing code (so we re-use that rather
than having a separate mechanism).

gcc/cp/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* coroutines.cc (struct coro_ret_data): Delete.
(coro_maybe_expand_co_return): Delete.
(co_return_expander): Delete.
(expand_co_returns): Delete.
(co_await_find_in_subtree): Remove unused name.
(build_actor_fn): Remove unused parm, remove handling
for co_return expansion.
(register_await_info): Demote duplicate info message to a
warning.
(coro_make_frame_entry): Move closer to use site.
(struct susp_frame_data): Add fields for final suspend label
and a flag to indicate await expressions with initializers.
(captures_temporary): Delete.
(register_awaits): Remove unused code, update comments.
(find_any_await): New.
(tmp_target_expr_p): New.
(struct interesting): New.
(find_interesting_subtree): New.
(struct var_nest_node): New.
(flatten_await_stmt): New.
(handle_nested_conditionals): New.
(process_conditional): New.
(replace_statement_captures): Rename to...
(maybe_promote_temps): ... this.
(maybe_promote_captured_temps): Delete.
(analyze_expression_awaits): Check for await expressions with
initializers.  Simplify handling for truth-and/or-if.
(expand_one_truth_if): Simplify (map cases that need expansion
to COND_EXPR).
(await_statement_walker): Handle CO_RETURN_EXPR. Simplify the
handling for truth-and/or-if expressions.
(register_local_var_uses): Ensure that we create names in the
implementation namespace.
(morph_fn_to_coro): Add final suspend label to suspend frame
callback data and remove it from the build_actor_fn call.

gcc/testsuite/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* g++.dg/coroutines/pr95591.C: New test.
* g++.dg/coroutines/pr95599.C: New test.
* g++.dg/coroutines/pr95823.C: New test.
* g++.dg/coroutines/pr95824.C: New test.

(cherry picked from commit 0f66b8486cea8668020e4bd48f261b760cb579be)

[Bug c++/95591] [coroutines] ICE when co_yielding string literal from generator coroutine

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-8545-gf43a1b1d1718969423337190ddbbbc9037c67783
Author: Iain Sandoe 
Date:   Sun Jul 19 18:39:21 2020 +0100

coroutines: Correct frame capture of compiler temps [PR95591+4].

When a full expression contains a co_await (or co_yield), this means
that it might be suspended; which would destroy temporary variables
(on a stack for example).  However the language guarantees that such
temporaries are live until the end of the expression.

In order to preserve this, we 'promote' temporaries where necessary
so that they are saved in the coroutine frame (which allows them to
remain live potentially until the frame is destroyed).  In addition,
sub-expressions that produce control flow (such as TRUTH_AND/OR_IF
or COND_EXPR) must be handled specifically to ensure that await
expressions are properly expanded.

This patch corrects two mistakes in which we were (a) failing to
promote some temporaries and (b) we we failing to sequence DTORs for
the captures properly. This manifests in a number of related (but not
exact duplicate) PRs.

The revised code collects the actions into one place and maps all the
control flow into one form - a benefit of this is that co_returns are
now expanded earlier (which provides an opportunity to address PR95517
in some future patch).

We replace a statement that contains await expression(s) with a bind
scope that has a variable list describing the temporaries that have
been 'promoted' and a statement list that contains a series of cleanup
expressions for each of those.  Where we encounter nested conditional
expressions, these are wrapped in a try-finally block with a guard var
for each sub-expression variable that needs a DTOR.  The guards are all
declared and initialized to false before the first conditional sub-
expression.  The 'finally' block contains a series of if blocks (one
per guard variable) enclosing the relevant DTOR.

Variables listed in a bind scope in this manner are automatically moved
to a coroutine frame version by existing code (so we re-use that rather
than having a separate mechanism).

gcc/cp/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* coroutines.cc (struct coro_ret_data): Delete.
(coro_maybe_expand_co_return): Delete.
(co_return_expander): Delete.
(expand_co_returns): Delete.
(co_await_find_in_subtree): Remove unused name.
(build_actor_fn): Remove unused parm, remove handling
for co_return expansion.
(register_await_info): Demote duplicate info message to a
warning.
(coro_make_frame_entry): Move closer to use site.
(struct susp_frame_data): Add fields for final suspend label
and a flag to indicate await expressions with initializers.
(captures_temporary): Delete.
(register_awaits): Remove unused code, update comments.
(find_any_await): New.
(tmp_target_expr_p): New.
(struct interesting): New.
(find_interesting_subtree): New.
(struct var_nest_node): New.
(flatten_await_stmt): New.
(handle_nested_conditionals): New.
(process_conditional): New.
(replace_statement_captures): Rename to...
(maybe_promote_temps): ... this.
(maybe_promote_captured_temps): Delete.
(analyze_expression_awaits): Check for await expressions with
initializers.  Simplify handling for truth-and/or-if.
(expand_one_truth_if): Simplify (map cases that need expansion
to COND_EXPR).
(await_statement_walker): Handle CO_RETURN_EXPR. Simplify the
handling for truth-and/or-if expressions.
(register_local_var_uses): Ensure that we create names in the
implementation namespace.
(morph_fn_to_coro): Add final suspend label to suspend frame
callback data and remove it from the build_actor_fn call.

gcc/testsuite/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* g++.dg/coroutines/pr95591.C: New test.
* g++.dg/coroutines/pr95599.C: New test.
* g++.dg/coroutines/pr95823.C: New test.
* g++.dg/coroutines/pr95824.C: New test.

(cherry picked from commit 0f66b8486cea8668020e4bd48f261b760cb579be)

[Bug c++/95599] [coroutines] destructor for temporary operand to co_yield expression called before end of full-expression

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-8545-gf43a1b1d1718969423337190ddbbbc9037c67783
Author: Iain Sandoe 
Date:   Sun Jul 19 18:39:21 2020 +0100

coroutines: Correct frame capture of compiler temps [PR95591+4].

When a full expression contains a co_await (or co_yield), this means
that it might be suspended; which would destroy temporary variables
(on a stack for example).  However the language guarantees that such
temporaries are live until the end of the expression.

In order to preserve this, we 'promote' temporaries where necessary
so that they are saved in the coroutine frame (which allows them to
remain live potentially until the frame is destroyed).  In addition,
sub-expressions that produce control flow (such as TRUTH_AND/OR_IF
or COND_EXPR) must be handled specifically to ensure that await
expressions are properly expanded.

This patch corrects two mistakes in which we were (a) failing to
promote some temporaries and (b) we we failing to sequence DTORs for
the captures properly. This manifests in a number of related (but not
exact duplicate) PRs.

The revised code collects the actions into one place and maps all the
control flow into one form - a benefit of this is that co_returns are
now expanded earlier (which provides an opportunity to address PR95517
in some future patch).

We replace a statement that contains await expression(s) with a bind
scope that has a variable list describing the temporaries that have
been 'promoted' and a statement list that contains a series of cleanup
expressions for each of those.  Where we encounter nested conditional
expressions, these are wrapped in a try-finally block with a guard var
for each sub-expression variable that needs a DTOR.  The guards are all
declared and initialized to false before the first conditional sub-
expression.  The 'finally' block contains a series of if blocks (one
per guard variable) enclosing the relevant DTOR.

Variables listed in a bind scope in this manner are automatically moved
to a coroutine frame version by existing code (so we re-use that rather
than having a separate mechanism).

gcc/cp/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* coroutines.cc (struct coro_ret_data): Delete.
(coro_maybe_expand_co_return): Delete.
(co_return_expander): Delete.
(expand_co_returns): Delete.
(co_await_find_in_subtree): Remove unused name.
(build_actor_fn): Remove unused parm, remove handling
for co_return expansion.
(register_await_info): Demote duplicate info message to a
warning.
(coro_make_frame_entry): Move closer to use site.
(struct susp_frame_data): Add fields for final suspend label
and a flag to indicate await expressions with initializers.
(captures_temporary): Delete.
(register_awaits): Remove unused code, update comments.
(find_any_await): New.
(tmp_target_expr_p): New.
(struct interesting): New.
(find_interesting_subtree): New.
(struct var_nest_node): New.
(flatten_await_stmt): New.
(handle_nested_conditionals): New.
(process_conditional): New.
(replace_statement_captures): Rename to...
(maybe_promote_temps): ... this.
(maybe_promote_captured_temps): Delete.
(analyze_expression_awaits): Check for await expressions with
initializers.  Simplify handling for truth-and/or-if.
(expand_one_truth_if): Simplify (map cases that need expansion
to COND_EXPR).
(await_statement_walker): Handle CO_RETURN_EXPR. Simplify the
handling for truth-and/or-if expressions.
(register_local_var_uses): Ensure that we create names in the
implementation namespace.
(morph_fn_to_coro): Add final suspend label to suspend frame
callback data and remove it from the build_actor_fn call.

gcc/testsuite/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* g++.dg/coroutines/pr95591.C: New test.
* g++.dg/coroutines/pr95599.C: New test.
* g++.dg/coroutines/pr95823.C: New test.
* g++.dg/coroutines/pr95824.C: New test.

(cherry picked from commit 0f66b8486cea8668020e4bd48f261b760cb579be)

[Bug c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-8545-gf43a1b1d1718969423337190ddbbbc9037c67783
Author: Iain Sandoe 
Date:   Sun Jul 19 18:39:21 2020 +0100

coroutines: Correct frame capture of compiler temps [PR95591+4].

When a full expression contains a co_await (or co_yield), this means
that it might be suspended; which would destroy temporary variables
(on a stack for example).  However the language guarantees that such
temporaries are live until the end of the expression.

In order to preserve this, we 'promote' temporaries where necessary
so that they are saved in the coroutine frame (which allows them to
remain live potentially until the frame is destroyed).  In addition,
sub-expressions that produce control flow (such as TRUTH_AND/OR_IF
or COND_EXPR) must be handled specifically to ensure that await
expressions are properly expanded.

This patch corrects two mistakes in which we were (a) failing to
promote some temporaries and (b) we we failing to sequence DTORs for
the captures properly. This manifests in a number of related (but not
exact duplicate) PRs.

The revised code collects the actions into one place and maps all the
control flow into one form - a benefit of this is that co_returns are
now expanded earlier (which provides an opportunity to address PR95517
in some future patch).

We replace a statement that contains await expression(s) with a bind
scope that has a variable list describing the temporaries that have
been 'promoted' and a statement list that contains a series of cleanup
expressions for each of those.  Where we encounter nested conditional
expressions, these are wrapped in a try-finally block with a guard var
for each sub-expression variable that needs a DTOR.  The guards are all
declared and initialized to false before the first conditional sub-
expression.  The 'finally' block contains a series of if blocks (one
per guard variable) enclosing the relevant DTOR.

Variables listed in a bind scope in this manner are automatically moved
to a coroutine frame version by existing code (so we re-use that rather
than having a separate mechanism).

gcc/cp/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* coroutines.cc (struct coro_ret_data): Delete.
(coro_maybe_expand_co_return): Delete.
(co_return_expander): Delete.
(expand_co_returns): Delete.
(co_await_find_in_subtree): Remove unused name.
(build_actor_fn): Remove unused parm, remove handling
for co_return expansion.
(register_await_info): Demote duplicate info message to a
warning.
(coro_make_frame_entry): Move closer to use site.
(struct susp_frame_data): Add fields for final suspend label
and a flag to indicate await expressions with initializers.
(captures_temporary): Delete.
(register_awaits): Remove unused code, update comments.
(find_any_await): New.
(tmp_target_expr_p): New.
(struct interesting): New.
(find_interesting_subtree): New.
(struct var_nest_node): New.
(flatten_await_stmt): New.
(handle_nested_conditionals): New.
(process_conditional): New.
(replace_statement_captures): Rename to...
(maybe_promote_temps): ... this.
(maybe_promote_captured_temps): Delete.
(analyze_expression_awaits): Check for await expressions with
initializers.  Simplify handling for truth-and/or-if.
(expand_one_truth_if): Simplify (map cases that need expansion
to COND_EXPR).
(await_statement_walker): Handle CO_RETURN_EXPR. Simplify the
handling for truth-and/or-if expressions.
(register_local_var_uses): Ensure that we create names in the
implementation namespace.
(morph_fn_to_coro): Add final suspend label to suspend frame
callback data and remove it from the build_actor_fn call.

gcc/testsuite/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* g++.dg/coroutines/pr95591.C: New test.
* g++.dg/coroutines/pr95599.C: New test.
* g++.dg/coroutines/pr95823.C: New test.
* g++.dg/coroutines/pr95824.C: New test.

(cherry picked from commit 0f66b8486cea8668020e4bd48f261b760cb579be)

[Bug c++/95824] [coroutines] compiler crash

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

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

commit r10-8545-gf43a1b1d1718969423337190ddbbbc9037c67783
Author: Iain Sandoe 
Date:   Sun Jul 19 18:39:21 2020 +0100

coroutines: Correct frame capture of compiler temps [PR95591+4].

When a full expression contains a co_await (or co_yield), this means
that it might be suspended; which would destroy temporary variables
(on a stack for example).  However the language guarantees that such
temporaries are live until the end of the expression.

In order to preserve this, we 'promote' temporaries where necessary
so that they are saved in the coroutine frame (which allows them to
remain live potentially until the frame is destroyed).  In addition,
sub-expressions that produce control flow (such as TRUTH_AND/OR_IF
or COND_EXPR) must be handled specifically to ensure that await
expressions are properly expanded.

This patch corrects two mistakes in which we were (a) failing to
promote some temporaries and (b) we we failing to sequence DTORs for
the captures properly. This manifests in a number of related (but not
exact duplicate) PRs.

The revised code collects the actions into one place and maps all the
control flow into one form - a benefit of this is that co_returns are
now expanded earlier (which provides an opportunity to address PR95517
in some future patch).

We replace a statement that contains await expression(s) with a bind
scope that has a variable list describing the temporaries that have
been 'promoted' and a statement list that contains a series of cleanup
expressions for each of those.  Where we encounter nested conditional
expressions, these are wrapped in a try-finally block with a guard var
for each sub-expression variable that needs a DTOR.  The guards are all
declared and initialized to false before the first conditional sub-
expression.  The 'finally' block contains a series of if blocks (one
per guard variable) enclosing the relevant DTOR.

Variables listed in a bind scope in this manner are automatically moved
to a coroutine frame version by existing code (so we re-use that rather
than having a separate mechanism).

gcc/cp/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* coroutines.cc (struct coro_ret_data): Delete.
(coro_maybe_expand_co_return): Delete.
(co_return_expander): Delete.
(expand_co_returns): Delete.
(co_await_find_in_subtree): Remove unused name.
(build_actor_fn): Remove unused parm, remove handling
for co_return expansion.
(register_await_info): Demote duplicate info message to a
warning.
(coro_make_frame_entry): Move closer to use site.
(struct susp_frame_data): Add fields for final suspend label
and a flag to indicate await expressions with initializers.
(captures_temporary): Delete.
(register_awaits): Remove unused code, update comments.
(find_any_await): New.
(tmp_target_expr_p): New.
(struct interesting): New.
(find_interesting_subtree): New.
(struct var_nest_node): New.
(flatten_await_stmt): New.
(handle_nested_conditionals): New.
(process_conditional): New.
(replace_statement_captures): Rename to...
(maybe_promote_temps): ... this.
(maybe_promote_captured_temps): Delete.
(analyze_expression_awaits): Check for await expressions with
initializers.  Simplify handling for truth-and/or-if.
(expand_one_truth_if): Simplify (map cases that need expansion
to COND_EXPR).
(await_statement_walker): Handle CO_RETURN_EXPR. Simplify the
handling for truth-and/or-if expressions.
(register_local_var_uses): Ensure that we create names in the
implementation namespace.
(morph_fn_to_coro): Add final suspend label to suspend frame
callback data and remove it from the build_actor_fn call.

gcc/testsuite/ChangeLog:

PR c++/95591
PR c++/95599
PR c++/95823
PR c++/95824
PR c++/95895
* g++.dg/coroutines/pr95591.C: New test.
* g++.dg/coroutines/pr95599.C: New test.
* g++.dg/coroutines/pr95823.C: New test.
* g++.dg/coroutines/pr95824.C: New test.

(cherry picked from commit 0f66b8486cea8668020e4bd48f261b760cb579be)

[Bug c/96365] GCC report impossible constraint on possible inline assembly output constraints

[141242068 at smail dot nju.edu.cn]

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

--- Comment #2 from wierton <141242068 at smail dot nju.edu.cn> ---
(In reply to Jakub Jelinek from comment #1)
> Any reason why you can't just write "=a"(x), "=b"(y), "=c"(z) if you mean
> that as the only possibility?

Emm, I was studying the inline assembly by reading the manual on
https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html#Using-Assembly-Language-with-C.
This example was accidently found because I wondered that if GCC really
considers constraints allocation as constraint solving problem. It seems that
GCC takes simpler strategy such as greedy algorithm and this may violate the
specification. I was not very sure if it is really inconsistent with
specification (I failed in finding accurate description), but I thought posting
this example may help improve the quality of GCC (or specification).

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

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

commit r11-2398-gc2e99836a2751b6d970ca6e50c1a368f5d2a2375
Author: Mark Eggleston 
Date:   Fri Jul 17 14:22:48 2020 +0100

Fortran  : ICE in gfc_conv_scalarized_array_ref PR53298

When an array of characters is an argument to a subroutine and
is accessed using (:)(1:) an ICE occurs.  The upper bound of the
substring does not have an expression and such should not have
a Scalarization State structure added to the Scalarization State
chain.

2020-07-29  Mark Eggleston  

gcc/fortran/

PR fortran/53298
* trans-array.c (gfc_walk_array_ref): If ref->ss.end is set
call gfc_get_scalar_ss.

2020-07-29  Mark Eggleston  

gcc/testsuite/

PR fortran/53298
* gfortran.dg/pr53298.f90: New test.

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[markeggleston at gcc dot gnu.org]

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

Bug 53298 Summary: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298

   What|Removed |Added

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

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[markeggleston at gcc dot gnu.org]

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

Bug 53298 Summary: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298

   What|Removed |Added

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

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from markeggleston at gcc dot gnu.org ---
Committed to master.

[Bug tree-optimization/95679] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6231

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:8e8792a347c87dbb82b4cf75ec3452bc5cd1d3db

commit r11-2400-g8e8792a347c87dbb82b4cf75ec3452bc5cd1d3db
Author: Richard Biener 
Date:   Wed Jul 29 09:59:01 2020 +0200

tree-optimization/95679 - properly signal changes from
propagate_into_phi_args

This restores a lost setting of something_changed with the
recent refactoring of the substitute and fold engine.  The
reported ICE in the PR was meanwhile mitigated in other ways
but the issue can still result in missed optimizations via
failed runs of CFG cleanup.

2020-07-29  Richard Biener  

PR tree-optimization/95679
* tree-ssa-propagate.h
(substitute_and_fold_engine::propagate_into_phi_args): Return
whether anything changed.
* tree-ssa-propagate.c
(substitute_and_fold_engine::propagate_into_phi_args): Likewise.
(substitute_and_fold_dom_walker::before_dom_children): Update
something_changed.

[Bug tree-optimization/95679] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6231

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #12)
> Created attachment 48949 [details]
> gcc11-pr96354.patch
> 
> Untested fix.

So I wonder where exactly we get this non-invariant address from and what
makes substitution into regular stmts fixed up?

Looks like the substitution is for & which we deal with
separately for regular stmts.  I guess we do not share the ADDR_EXPR
tree so we can't put a remap of that here.  But we may be able to
detect this case up in copy_debug_stmt itself?  The debug stmt seems to be

# DEBUG D#2 => MEM[(double *)&]

and retval maps to D.2566[_9].  And I guess in regular code we never end
up with & anywhere.  So not sure how we ended up with that DEBUG
stmt in the first place...

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
OK, looks like inlining C<3>::C into foo<3, 3> produces this debug stmt.

foo<3, 3> (struct D D.2506, struct C D.2507)
{
   :
  C<3>::C (&);
  return ;

and inlined from

C<3>::C (struct C * const this)
{
   [local count: 1073741824]:
  *this_2(D) ={v} {CLOBBER};
  # DEBUG D#1 => &this_2(D)->d
  # DEBUG this => D#1
  # DEBUG INLINE_ENTRY baz
  # DEBUG this => NULL
  # DEBUG D#2 => MEM[(double *)this_2(D)]
  # DEBUG c => D#2
  return;

so if the MEM wouldn't be dead we'd face the same situation in regular
stmts I guess.  And we do.  But then the inliner sees

  _10 = &D.2565[_9];
  C<3>::C (_10);
  _12 = &D.2564[_9];
  C<3>::C (_12);

so value-substitution shouldn't happen here anyway...  which means
it is eventually a over-eager mapping registered due to debug for
unused decls or so?

So we should fix this more "upstream" I bet.  In declare_return_variable
we're doing insert_decl_map (id, result, var) with var == D.2567[_9]
which is problematic.  We might want to gimplify this there into
ptr_42 = &D.2567[_9] and map  to MEM[ptr_42] instead?
That might simplify code elsewhere but eventually affects code generation.
Note this will only happen for return slots I think.

[Bug tree-optimization/96349] [10 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 3 which are marked as MUST COALESCE.) [in fail_abnormal_edge_coalesce]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[10/11 Regression] ICE: SSA |[10 Regression] ICE: SSA
   |corruption (Unable to   |corruption (Unable to
   |coalesce ssa_names 2 and 3  |coalesce ssa_names 2 and 3
   |which are marked as MUST|which are marked as MUST
   |COALESCE.) [in  |COALESCE.) [in
   |fail_abnormal_edge_coalesce |fail_abnormal_edge_coalesce
   |]   |]
  Known to work||11.0

[Bug tree-optimization/96349] [10/11 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 3 which are marked as MUST COALESCE.) [in fail_abnormal_edge_coalesce]

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:2b2f3867c09c8977268b8ffbd646ac242188b335

commit r11-2402-g2b2f3867c09c8977268b8ffbd646ac242188b335
Author: Richard Biener 
Date:   Tue Jul 28 09:45:52 2020 +0200

tree-optimization/96349 - avoid abnormal coalescing issues in loop split

This avoids splitting a loop when the entry value of a loop PHI is
involved with abnormal coalescing.

2020-07-28  Richard Biener  

PR tree-optimization/96349
* tree-ssa-loop-split.c (stmt_semi_invariant_p_1): When the
condition runs into a loop PHI with an abnormal entry value give
up.

* gcc.dg/torture/pr96349.c: New testcase.

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
We have indeed:
  # DEBUG D#2 => MEM[(double *)&]
and on the caller side:
  D.2566[_9] = foo<3, 3> (D.2559, D.2572); [return slot optimization]
So, that is why to & &D.2566[_9] is propagated.
Now, if I add to foo a call to some function template that takes &t as
argument, this is handled correctly because id->regimplify is set to true and
the
qux > (&D.2572[_9]);
call is fixed up by gimple_regimplify_operands.  That function really isn't
called on debug stmts though (and not prepared to be called for them).
If I use
template  C foo (D, C) { C t; double d = 1.25;
__builtin_memcpy (&t, &d, sizeof (double)); return t; }
instead so that before that inlining we get
  MEM  [(char * {ref-all})&] = _4;
then it is indeed again gimple_regimplify_operands that fixes up the
MEM  [(char * {ref-all})&D.2569[_9]] = 4608308318706860032;
into:
  _21 = &D.2569[_9];
  MEM  [(char * {ref-all})_21] = 4608308318706860032;

[Bug fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:6af8284719d151087a1c1e4da210cc5a9fa4a478

commit r11-2403-g6af8284719d151087a1c1e4da210cc5a9fa4a478
Author: Mark Eggleston 
Date:   Mon Jul 27 15:28:50 2020 +0100

Fortran  : Don't warn for LOGICAL kind conversion PR96319

LOGICAL values will always fit regardless of kind so there
is no need for warnings.

2020-07-29  Mark Eggleston  

gcc/fortran/

PR fortran/96319
* intrinsic.c (gfc_convert_type_warn):  Add check for
LOGICAL type so that warnings are not output.

2020-07-29  Mark Eggleston  

gcc/testsuite/

PR fortran/96319
* gfortran.dg/pr96319.f90: New test.

[Bug c++/96363] bogus error with constrained partial specialization

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
PR92944 looks related.

[Bug target/96366] New: [AArch64] ICE due to lack of support for VNx2SI sub instruction

[bule1 at huawei dot com]

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

Bug ID: 96366
   Summary: [AArch64] ICE due to lack of support for VNx2SI sub
instruction
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bule1 at huawei dot com
CC: richard.sandiford at arm dot com
  Target Milestone: ---

Created attachment 48950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48950&action=edit
preprocessed source code for recurent the problem

Hi, 

The test case bb-slp-20.c in the gcc testsuit will cause an ICE in the expand
pass because the gcc lack of a pattern for subtraction of the VNx2SI mode.

The preprocessed file is attached and the problem will be triggered when
compiled with -march=armv8.5-a+sve -msve-vector-bits=256 -O3 -fno-tree-forwprop
options.

By tracing the debug infomation, it is found that the error is due to a
vectorized subtraction gimple with VNx2SI mode cannot find its pattern during
the expand pass.

I tried to extend the mode of this pattern from SVE_FULL_I to SVE_I as
following, after which the problem is solved. 

diff -Nurp a/gcc/config/aarch64/aarch64-sve.md
b/gcc/config/aarch64/aarch64-sve.md
--- a/gcc/config/aarch64/aarch64-sve.md 2020-07-29 15:54:39.36000 +0800
+++ b/gcc/config/aarch64/aarch64-sve.md 2020-07-29 14:37:21.93200 +0800
@@ -3644,10 +3644,10 @@
 ;; -

 (define_insn "sub3"
-  [(set (match_operand:SVE_FULL_I 0 "register_operand" "=w, w, ?&w")
-   (minus:SVE_FULL_I
- (match_operand:SVE_FULL_I 1 "aarch64_sve_arith_operand" "w, vsa,
vsa")
- (match_operand:SVE_FULL_I 2 "register_operand" "w, 0, w")))]
+  [(set (match_operand:SVE_I 0 "register_operand" "=w, w, ?&w")
+   (minus:SVE_I
+ (match_operand:SVE_I 1 "aarch64_sve_arith_operand" "w, vsa, vsa")
+ (match_operand:SVE_I 2 "register_operand" "w, 0, w")))]
   "TARGET_SVE"
   "@
sub\t%0., %1., %2.

I noticed that this mode iterator was changed from SVE_I to SVE_FULL_I in Nov
2019 by richard to support partial SVE vectors. However, in the following patch
the addition pattern is supported by changing SVE_FULL_I to SVE_I but not the
subtraction pattern. Is there any specific reason why this pattern is not
supported?

Thanks.

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Wed, 29 Jul 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354
> 
> --- Comment #15 from Jakub Jelinek  ---
> We have indeed:
>   # DEBUG D#2 => MEM[(double *)&]
> and on the caller side:
>   D.2566[_9] = foo<3, 3> (D.2559, D.2572); [return slot optimization]
> So, that is why to & &D.2566[_9] is propagated.
> Now, if I add to foo a call to some function template that takes &t as
> argument, this is handled correctly because id->regimplify is set to true and
> the
> qux > (&D.2572[_9]);
> call is fixed up by gimple_regimplify_operands.  That function really isn't
> called on debug stmts though (and not prepared to be called for them).
> If I use
> template  C foo (D, C) { C t; double d = 1.25;
> __builtin_memcpy (&t, &d, sizeof (double)); return t; }
> instead so that before that inlining we get
>   MEM  [(char * {ref-all})&] = _4;
> then it is indeed again gimple_regimplify_operands that fixes up the
> MEM  [(char * {ref-all})&D.2569[_9]] = 4608308318706860032;
> into:
>   _21 = &D.2569[_9];
>   MEM  [(char * {ref-all})_21] = 4608308318706860032;

So we could avoid (some) regimplification if we'd dealt with this
gimplification step during return value setup.  We then only might
not re-propagate things and so

 .b;

might be forever

 tem_1 = &D.123[j_3];
 MEM[tem_1].b;

instead of

 D.123[j_3].b;

doing the re-gimplification when we replace things from the
decl map might be possible as well of course (and we then
would have "context" and could do special things when in
ADDR_EXPR context).  Not sure how ugly that is.

Not sure how bad the non-propagation above is either and how
often it triggers.

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
But we need to do the regimplification for several other reasons, so what would
be the advantage of doing it that way?

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Wed, 29 Jul 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354
> 
> --- Comment #17 from Jakub Jelinek  ---
> But we need to do the regimplification for several other reasons, so what 
> would
> be the advantage of doing it that way?

The advantage is removing the special casing for debug stmts and fixing
the bug?

[Bug debug/88878] .debug_pubnames/types empty with -flto

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 CC||jan.kratochvil at redhat dot 
com

--- Comment #7 from Jan Kratochvil  ---
Hello, @rguenth could you suggest what problem does -fdebug-types-section -flto
still have?
When I remove the use_debug_types's "&& !in_lto_p" part it looks to me as
working fine. (I haven't done any non-trivial debuginfo testing.)

Contents of the .debug_info section:
  Compilation Unit @ offset 0x0:
   Version:   4
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x0): GNU GIMPLE 10.2.1
20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g -g -fno-openmp
-fno-openacc -fno-pie -fdebug-types-section -fltrans
<11>   DW_AT_name: (indirect string, offset: 0xa8): 
  Compilation Unit @ offset 0xc9:
   Version:   4
 <0>: Abbrev Number: 11 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x35a): GNU C++14
10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g
-fdebug-types-section -flto
   DW_AT_name: (indirect string, offset: 0x20e): main.C
 <1>: Abbrev Number: 12 (DW_TAG_class_type)
   DW_AT_signature   : signature: 0xf1df7e53d0fa1d2e
  Compilation Unit @ offset 0x15a:
   Version:   4
 <0><165>: Abbrev Number: 11 (DW_TAG_compile_unit)
<166>   DW_AT_producer: (indirect string, offset: 0x35a): GNU C++14
10.2.1 20200723 (Red Hat 10.2.1-1) -mtune=generic -march=x86-64 -g
-fdebug-types-section -flto
<16b>   DW_AT_name: (indirect string, offset: 0x479): lib.C
Contents of the .debug_types section:
  Compilation Unit @ offset 0x0:
   Version:   4
   Signature: 0xf1df7e53d0fa1d2e
   Type Offset:   0x25
 <0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
<19>   DW_AT_GNU_odr_signature: 0xddd94cb16fdd687a
 <1><25>: Abbrev Number: 2 (DW_TAG_class_type)

[Bug c/96367] New: bogus format truncation error on armhf when building perf with gcc 10

[andrea.righi at canonical dot com]

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

Bug ID: 96367
   Summary: bogus format truncation error on armhf when building
perf with gcc 10
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrea.righi at canonical dot com
  Target Milestone: ---

After moving to gcc-10 (in Ubuntu Groovy) we're getting an error during the
perf build (only on the armhf architecture) when compiling the Linux kernel:

  util/map.c:124:5: error: ‘%s’ directive output may be truncated writing
between 1 and 2147483645 bytes into a region of size 4096
[-Werror=format-truncation=]

Source code:

https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/groovy/tree/tools/perf/util/map.c?h=master-next#n117

Looking at the source code it seems to be a false positive: the snprintf()
should never exceed the size of 4096 as reported by the error (the new length
is checked immediately before calling snprintf).

Moreover, it is quite strange that we are getting this error only on armhf. At
least I'm expecting to get this error across all architectures and not just
armhf.

Do you think it's a bug or am I missing something obvious? Thanks!

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
But doing that would mean pretty much the same amount of code at the expense of
making the IL larger even when not needed (and perhaps risking some
optimization opportunities).
Yet another possibility would be instead of doing that in this function clear
id->regimplify at the start of copy_debug_stmt, and if it is set after
processing the value, do something like regimplification for the debug stmts,
i.e. walk_tree which would handle the cases we consider invalid, perhaps for
now just the MEM_REF case with non-is_gimple_mem_ref_addr/DEBUG_EXPR_DECL as
first operand and in the future perhaps something else too.

[Bug debug/88878] .debug_pubnames/types empty with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Jan Kratochvil from comment #7)
> Hello, @rguenth could you suggest what problem does -fdebug-types-section
> -flto still have?
> When I remove the use_debug_types's "&& !in_lto_p" part it looks to me as
> working fine. (I haven't done any non-trivial debuginfo testing.)

The .debug_types section isn't supposed to be output when in_lto_p
(that's for the LTRANS units where we generally do not output any
types into DWARF).  Instead .debug_types has to be output during
dwarf2out_early_finish when we write the declaration dwarf units,
the "early" debug info.  That should now be done.  What's still missing
is pubnames/pubtypes I think, -fdebug-types-section works fine now.
But -gpubnames is not.

You can verify with a small testcase and -gpubnames [-flto] where
with -flto both .debug_pubtype and .debug_pubnames are missing.

But nobody complained in years so I gues -gpubnames is unused.

[Bug preprocessor/95889] [10 regression] __has_include broken with -traditional-cpp (and therefore with Fortran)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
   Last reconfirmed||2020-07-29
 Status|UNCONFIRMED |ASSIGNED
 CC||nathan at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Nathan Sidwell  ---
thanks for the patch, taking so I don't forget

[Bug c/96368] New: False negative with maybe-uninitialized with goto

[felix at piedallu dot me]

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

Bug ID: 96368
   Summary: False negative with maybe-uninitialized with goto
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix at piedallu dot me
  Target Milestone: ---

Created attachment 48951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48951&action=edit
minimal code for missing maybe-uninitialized warning

There are cases where GCC should warn about maybe-uninitialized variables but
doesn't.

In the attached minimal code, the `goto` may prevent the eth.pktio to be
initialized, but GCC doesn't warn about it.

Weirdly enough, if the pktio_read() call is uncommented, GCC warns that
eth.pktio may be uninitialized.

Of course the fix is to initialize eth.pktio before the goto.

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #11 from Tom de Vries  ---
FTR, this PR is linked to from here (
https://lemire.me/blog/2020/06/26/gcc-not-nearest/ ).

[Bug c++/64194] [C++14] for function template with auto return

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/96361] return type not deduced for a function template specialization given as argument of a template function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
This is a dup of PR64194 I think.

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

[Bug c++/64194] [C++14] for function template with auto return

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||okannen at gmail dot com

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

[Bug debug/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On Wed, 29 Jul 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354
> 
> --- Comment #19 from Jakub Jelinek  ---
> But doing that would mean pretty much the same amount of code at the expense 
> of
> making the IL larger even when not needed (and perhaps risking some
> optimization opportunities).
> Yet another possibility would be instead of doing that in this function clear
> id->regimplify at the start of copy_debug_stmt, and if it is set after
> processing the value, do something like regimplification for the debug stmts,
> i.e. walk_tree which would handle the cases we consider invalid, perhaps for
> now just the MEM_REF case with non-is_gimple_mem_ref_addr/DEBUG_EXPR_DECL as
> first operand and in the future perhaps something else too.

Meh.  I guess let's try not ICEing during maybe_canonicalize_mem_ref_addr
instead, thus make it "best effort" for GIMPLE_DEBUG stmts.  Or not
fold it at all.  But I guess that we do and only do 
maybe_canonicalize_mem_ref_addr means we've run into problems before...
like PR45056?

[Bug debug/88878] .debug_pubnames/types empty with -flto

[jan.kratochvil at redhat dot com]

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

--- Comment #9 from Jan Kratochvil  ---
(In reply to Richard Biener from comment #8)
> The .debug_types section isn't supposed to be output when in_lto_p
> (that's for the LTRANS units where we generally do not output any
> types into DWARF).  Instead .debug_types has to be output during
> dwarf2out_early_finish when we write the declaration dwarf units,
> the "early" debug info.  That should now be done.

Thanks for the explanation, I see -fdebug-types-section -flto does work with
trunk without any patch, great!


> You can verify with a small testcase and -gpubnames [-flto] where
> with -flto both .debug_pubtype and .debug_pubnames are missing.

I do not think anyone is interested in those, for DWARF-5 they are officially
removed:
http://www.dwarfstd.org/doc/DWARF5.pdf
 * Replace the .debug_pubnames and .debug_pubtypes sections with a single and
   more functional name index section, .debug_names .

And for DWARF-4 those were replaced by GNU .gdb_index .

[Bug c++/96363] bogus error with constrained partial specialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-29
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92944
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Blocks||67491


Referenced Bugs:

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

[Bug c++/92944] [concepts] redefinition error when using constrained structure template inside namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-29
 Blocks||67491
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1


Referenced Bugs:

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

[Bug c++/59254] confusing diagnostic for undefined template shadowed by declaration in inline namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2015-03-23 00:00:00 |2020-7-29

--- Comment #2 from Jonathan Wakely  ---
If I add a declaration of an explicit specialization A we get another
unhelpful error:

namespace outer {
  inline namespace inner {
template struct A;
  }

  template struct A;

  template struct A;

  template<> struct A;
}

n.cc:8:19: error: 'A' is not a class template
8 |   template struct A;
  |   ^
n.cc:8:19: error: template argument required for 'struct A'
n.cc:10:21: error: 'A' is not a class template
   10 |   template<> struct A;
  | ^
n.cc:10:21: error: template specifiers not specified in declaration of
'template struct outer::A'


I have no idea what "template specifiers not specified in declaration" means.

Clang is more clear about the problem (the class template is declared twice and
so causes ambiguities):


n.cc:8:19: error: reference to 'A' is ambiguous
  template struct A;
  ^
n.cc:6:31: note: candidate found by name lookup is 'outer::A'
  template struct A;
  ^
n.cc:3:33: note: candidate found by name lookup is 'outer::inner::A'
template struct A;
^
n.cc:8:19: error: explicit instantiation of undefined template 'outer::A'
  template struct A;
  ^
n.cc:6:31: note: template is declared here
  template struct A;
  ^
n.cc:10:21: error: reference to 'A' is ambiguous
  template<> struct A;
^
n.cc:6:31: note: candidate found by name lookup is 'outer::A'
  template struct A;
  ^
n.cc:3:33: note: candidate found by name lookup is 'outer::inner::A'
template struct A;
^

EDG does well too:

"n.cc", line 8: error: "outer::A" is ambiguous
template struct A;
^

"n.cc", line 8: error: invalid explicit instantiation declaration
template struct A;
 ^

"n.cc", line 10: error: "outer::A" is ambiguous
template<> struct A;
  ^

3 errors detected in the compilation of "n.cc".

[Bug debug/95096] Feature request: add -fsplit-dwarf

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-2407-gc8d3f2b6d1d81535ac3b71fd8dd1def12f8d03b3
Author: Fangrui Song 
Date:   Wed May 13 08:27:29 2020 -0700

Don't make -gsplit-dwarf imply -g

-gsplit-dwarf introduces order dependency: it overrides previous -g0 and
-g1.

Don't imply -g so that it can be plugged into a build without worrying
that unnecessary debugging information may be generated.

2020-05-13  Fangrui Song  

PR debug/95096
* opts.c (common_handle_option): Don't make -gsplit-dwarf imply -g.
* doc/invoke.texi (-gsplit-dwarf): Update documentation.

[Bug target/96366] [AArch64] ICE due to lack of support for VNx2SI sub instruction

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
(In reply to Bu Le from comment #0)
> Created attachment 48950 [details]
> preprocessed source code for recurent the problem
> 
> Hi, 
> 
> The test case bb-slp-20.c in the gcc testsuit will cause an ICE in the
> expand pass because the gcc lack of a pattern for subtraction of the VNx2SI
> mode.
> 
> The preprocessed file is attached and the problem will be triggered when
> compiled with -march=armv8.5-a+sve -msve-vector-bits=256 -O3
> -fno-tree-forwprop options.
> 
> By tracing the debug infomation, it is found that the error is due to a
> vectorized subtraction gimple with VNx2SI mode cannot find its pattern
> during the expand pass.

Hmm.  In general, the lack of a vector pattern shouldn't case ICEs,
but I suppose the add/sub pairing is somewhat special because of
the canonicalisation rules.  It would be worth looking at exactly
why we generate the subtract though, just to confirm that this is
an “expected” ICE rather than a symptom of a deeper problem.

> I tried to extend the mode of this pattern from SVE_FULL_I to SVE_I as
> following, after which the problem is solved. 
> 
> diff -Nurp a/gcc/config/aarch64/aarch64-sve.md
> b/gcc/config/aarch64/aarch64-sve.md
> --- a/gcc/config/aarch64/aarch64-sve.md 2020-07-29 15:54:39.36000 +0800
> +++ b/gcc/config/aarch64/aarch64-sve.md 2020-07-29 14:37:21.93200 +0800
> @@ -3644,10 +3644,10 @@
>  ;; -
> 
>  (define_insn "sub3"
> -  [(set (match_operand:SVE_FULL_I 0 "register_operand" "=w, w, ?&w")
> -   (minus:SVE_FULL_I
> - (match_operand:SVE_FULL_I 1 "aarch64_sve_arith_operand" "w, vsa,
> vsa")
> - (match_operand:SVE_FULL_I 2 "register_operand" "w, 0, w")))]
> +  [(set (match_operand:SVE_I 0 "register_operand" "=w, w, ?&w")
> +   (minus:SVE_I
> + (match_operand:SVE_I 1 "aarch64_sve_arith_operand" "w, vsa, vsa")
> + (match_operand:SVE_I 2 "register_operand" "w, 0, w")))]
>"TARGET_SVE"
>"@
> sub\t%0., %1., %2.
> 
> I noticed that this mode iterator was changed from SVE_I to SVE_FULL_I in
> Nov 2019 by richard to support partial SVE vectors. However, in the
> following patch the addition pattern is supported by changing SVE_FULL_I to
> SVE_I but not the subtraction pattern. Is there any specific reason why this
> pattern is not supported?

The idea was for that patch to add the bare minimum needed
to support the “unpacked vector” infrastructure.  Then, once the
infrastructure was in place, we could add support for other
unpacked vector operations too.

However, the infrastructure went in late during the GCC 10
cycle, so the idea was to postpone any new unpacked vector
support to GCC 11.  So far the only additional operations
has been Joe Ramsay's patches for logical operations
(g:bb3ab62a8b4a108f01ea2eddfe31e9f733bd9cb6 and
g:6802b5ba8234427598abfd9f0163eb5e7c0d6aa8).

The reason for not changing many operations at once is that,
in each case, a decision needs to be made whether the
operation should use the container mode (as for INDEX),
the element mode (as for right shifts, once they're
implemented) or whether it doesn't matter (as for addition).
Each operation also needs tests.  So from that point of view,
it's more convenient to have a separate patch for each
operation (or at least closely-related groups of operations).

[Bug debug/95096] Feature request: add -fsplit-dwarf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
  Known to work||11.0

--- Comment #3 from Richard Biener  ---
Fixed in different ways.

[Bug debug/93951] [8/9/10/11 Regression] ICE with '-flto -g -femit-struct-debug-baseonly'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c/96369] New: Wrong evaluation order of || operator

[frank_yzg at outlook dot com]

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

Bug ID: 96369
   Summary: Wrong evaluation order of || operator
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frank_yzg at outlook dot com
  Target Milestone: ---

The following code snippet:

#include  
int main(void)
{
const long ONE = 1L;
long y = 0L;
long x = ((long) (ONE || (y = 1L)) % 8L);
printf("x = %ld, y = %ld\n", x, y);// with -O1/-O2/-O3 flag, gcc prints
x = 1, y = 1 where clang prints x = 1, y = 0
}

> $ /usr/gcc-trunk/bin/gcc -O2 -Wall -Wextra bug.c -o a.out
> $ ./a.out
> x = 1, y = 1

If the first operand of a logical-OR operation has a nonzero value, the second
operand is not evaluated. Therefore (y = 1L) should not be evaluated. It should
print y = 0 instead of y = 1.

This bug appears in GCC-4.8, GCC-6.4.0, GCC-7.5.0, GCC-8.4.0, GCC-9.3.0,
GCC-10.2.0 and GCC-11.0.0 20200501.

[Bug fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:3c4d2b867666464fad2dc5732940beaae48d8628

commit r10-8549-g3c4d2b867666464fad2dc5732940beaae48d8628
Author: Mark Eggleston 
Date:   Mon Jul 27 15:28:50 2020 +0100

Fortran  : Don't warn for LOGICAL kind conversion PR96319

LOGICAL values will always fit regardless of kind so there
is no need for warnings.

2020-07-29  Mark Eggleston  

gcc/fortran/

PR fortran/96319
* intrinsic.c (gfc_convert_type_warn):  Add check for
LOGICAL type so that warnings are not output.

2020-07-29  Mark Eggleston  

gcc/testsuite/

PR fortran/96319
* gfortran.dg/pr96319.f90: New test.

(cherry picked from commit 6af8284719d151087a1c1e4da210cc5a9fa4a478)

[Bug fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from markeggleston at gcc dot gnu.org ---
Committed to master. The problem also occurs with gcc-10 but not gcc-9 or 8 so
it has been backported to gcc-10.

[Bug c/96370] New: ice with -ffast-math

[dcb314 at hotmail dot com]

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

Bug ID: 96370
   Summary: ice with -ffast-math
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Recent gcc trunk, with this C source code:

a() {
  _Decimal128 b;
  c(-b * b);
}

and compiler flag -O2 -ffast-math, does this:

during GIMPLE pass: reassoc
bug633.c: In function ‘a’:
bug633.c:1:1: internal compiler error: in gimple_build_assign_1, at
gimple.c:455
1 | a() {
  | ^
0x96e82e gimple_build_assign_1(tree_node*, tree_code, tree_node*, tree_node*,
tr
ee_node*)
../../trunk.git/gcc/gimple.c:455
0xec0a0b rewrite_expr_tree(gimple*, unsigned int, vec, bool, bool)
../../trunk.git/gcc/tree-ssa-reassoc.c:4963
0xec0828 rewrite_expr_tree(gimple*, unsigned int, vec, bool, bool)
../../trunk.git/gcc/tree-ssa-reassoc.c:5007
0xeb6d9e reassociate_bb(basic_block_def*)
../../trunk.git/gcc/tree-ssa-reassoc.c:6480

The bug seems to have existed since sometime before 20200630.

Thanks to cvise for reducing the code quickly.

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Dominique d'Humieres  ---
The original test in comment 0 and the test in commnent 7 are giving an ICE

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x0)
frame #0: 0x000100110dd9
f951`::gfc_conv_scalarized_array_ref(se=0x7ffeefbfdfd0,
ar=0x00014560c498) at trans-array.c:3490:14
   3487   int n;
   3488 
   3489   ss = se->ss;
-> 3490   expr = ss->info->expr;
   3491   info = &ss->info->data.array;
   3492   if (ar)
   3493 n = se->loop->order[0];
Target 0: (f951) stopped.

because ss is NULL:

(gfc_se) $5 = {
  pre = {
head = 0x
has_scope = 0
  }
  post = {
head = 0x
has_scope = 0
  }
  expr = 0x000142fb3ea0
  string_length = 0x
  class_vptr = 0x
  descriptor_only = 0
  want_pointer = 0
  direct_byref = 0
  byref_noassign = 0
  ignore_optional = 0
  data_not_needed = 0
  no_function_call = 0
  force_tmp = 0
  force_no_tmp = 0
  use_offset = 0
  want_coarray = 0
  parent = 0x7ffeefbfe7c0
  ss = 0x
  loop = 0x
}

[Bug fortran/56818] [meta-bug] fortran-dev bugs

[dominiq at lps dot ens.fr]

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

Bug 53298 Summary: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[dominiq at lps dot ens.fr]

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

Bug 53298 Summary: ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug c++/93295] ICE in alias_ctad_tweaks

[oficsu at gmail dot com]

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

ofee oficsu  changed:

   What|Removed |Added

 CC||oficsu at gmail dot com

--- Comment #7 from ofee oficsu  ---
I think there is another example of the same bug. This can be pretty common
code in C++20:

#include 

template
using p = std::pair;

auto x = p{int{}, int{}};

[Bug target/96371] New: [nvptx] frounding-math support

[vries at gcc dot gnu.org]

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

Bug ID: 96371
   Summary: [nvptx] frounding-math support
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Floating-point ops like f.i. div:
...
(define_insn "div3"
  [(set (match_operand:SDFM 0 "nvptx_register_operand" "=R")
(div:SDFM (match_operand:SDFM 1 "nvptx_register_operand" "R")
  (match_operand:SDFM 2 "nvptx_nonmemory_operand" "RF")))]
  ""
  "%.\\tdiv%#%t0\\t%0, %1, %2;")
...
have a bit '%#' with according to nvptx_print_operand the semantics:
...
   # -- print a rounding mode for the instruction  
  ...
but which is hardcoded to .rn (round to nearest):
...
  else if (code == '#')
{
  fputs (".rn", file);
  return;
}
...

According to this ( https://gcc.gnu.org/wiki/FloatingPointMath ), round to
nearest is the rounding mode for div by default, but when -frounding-math is
specified, that can no longer be assumed.

The way this normally works is that a cpu has a status register describing the
current state of rounding mode.  By specifying -frounding-math, we make sure
the compiler makes no assumptions about rounding mode, such that the status
register will take effect at runtime. And at runtime, we use a libc function
from fenv.h to manipulate the status register.

Nvptx has no such status register.

Newlib has fenv.h support since version 3.2.0 (Jan 2020), but the nvptx port
has no implementation.  It could add one, implementing a fake status register
(perhaps there is another architecture that has something similar), which could
then be tested in the assembly for div3 to determine whether to execute
div.rn, div.rz, div.rm or div.rp.

The standalone implementation only supports scalar execution, so we only need a
scalar status register, but in the offloading and parallel context, each thread
can have set a different rounding mode, so we'll need thread-specific status
registers.  Perhaps that's too expensive, and we'll have to limit fesetround to
using constants (which I guess will be the case anyway for typical numerical
code).

Anyway, in absence of all this, without fenv.h support there's no way to set
the rounding mode, meaning that we can assume default rounding mode, as the
current implementation of "div3" does.  OTOH, we don't take that
assumption further, f.i. we don't ignore frounding-math.

It would be nice if we'd warn about making the assumption when emitting a div
with .rn hardcoded and frounding-math, something like:
...
Assuming fenv.h not supported, so using default rounding mode for float op.
...

Or, we could just error out when specifying frounding-math, or when
encountering a float op with frounding-math or some such.

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #12 from Paul Thomas  ---
(In reply to kargl from comment #10)
> (In reply to jvdelisle from comment #9)
> > I regression tested the patch in comment 8 and see these failures.
> > 
> > FAIL: gfortran.dg/pr93423.f90   -O  (test for excess errors)
> > FAIL: gfortran.dg/typebound_call_31.f90   -O   (test for errors, line 14)
> > FAIL: gfortran.dg/typebound_call_31.f90   -O  (test for excess errors)
> 
> Thanks for testing.  Does the patch that follows fix the regressions?
> gfortran treats components and type bound procedures separately.  I've
> (hopefully) adapted the patch to whether foo is either.
> 
> Index: gcc/fortran/primary.c
> ===
> --- gcc/fortran/primary.c (revision 280157)
> +++ gcc/fortran/primary.c (working copy)
> @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, 
> inquiry = is_inquiry_ref (name, &tmp);
> if (inquiry)
>   sym = NULL;
> +   else
> + {
> +   component = gfc_find_component (sym, name, false, false, &tmp);
> +   tbp = gfc_find_typebound_proc (sym, &t, name, false,
> &gfc_current_locus);
> +   if (!component && !tbp)
> + {
> +   gfc_error ("%qs at %C is neither a component nor a type "
> +  "bound procedure of the derived "
> +  "type %qs", name, sym->name);
> +   return MATCH_ERROR;
> + }
> + }
>  
> if (sep == '%' && primary->ts.type != BT_UNKNOWN)
>   intrinsic = true;

Hi Steve,

Given your comment 6, I set too first thing this morning and located the bug by
searching the ChangeLogs for candidates. That I was the culprit is galling to
say the least of it. My version of the fix is:

index d73898473df..6f032fbabfd 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
bool sub_flag,
   else
component = NULL;

-  /* In some cases, returning MATCH_NO gives a better error message. Most
-cases return "Unclassifiable statement at..."  */
   if (intrinsic && !inquiry)
-   return MATCH_NO;
+   {
+ gfc_error ("%qs at %C is not an inquiry reference to an "
+"intrinsic type", name);
+ return MATCH_ERROR;
+   }
   else if (component == NULL && !inquiry)
return MATCH_ERROR;


Just a couple of nits concerning your patch: The false typebound call appears
after the 'r1' components ref, which is not a derived type or class type. That
is why the test for an inquiry reference is appropriate and is tested for in
this block. Your error message comes up with t2 as being the type.

I suggest:
> +   gfc_error ("%qs at %C is not an inquiry reference to an "
> +  "intrinsic type", name);

or some such.

Also, you have to get rid of the comment and the dead code that was modified in
my patch.

Thanks for the patch. OK for trunk when the error message is corrected and the
comment plus dead code removed.

Cheers

Paul

[Bug preprocessor/95889] [10 regression] __has_include broken with -traditional-cpp (and therefore with Fortran)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
Fixed trunk f6fe3bbf9f6
Fixed gcc-10 5e66b6c0103

[Bug target/96372] New: [11 regression] arm/ivopts.c fails since r11-2012

[clyon at gcc dot gnu.org]

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

Bug ID: 96372
   Summary: [11 regression] arm/ivopts.c fails since r11-2012
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Since r11-2012-gd2ed233cb940aa3eecc163d98b47979dd81dbc0a, I've noticed that
FAIL: gcc.target/arm/ivopts.c object-size text <= 20

depending on how GCC is configured.

For instance:
* target arm-none-eabi with target-board=-mcpu=cortex-a7/-mfloat-abi=hard
or
* target arm-none-linux-gnueabi --with-mode arm --with-cpu cortex-a9

The log says:
spawn -ignore SIGHUP arm-none-linux-gnueabi-size ivopts.o
   textdata bss dec hex filename
 32   0   0  32  20 ivopts.o
text size is 32
FAIL: gcc.target/arm/ivopts.c object-size text <= 20

[Bug target/96373] New: SVE miscompilation on vectorized division loop, leading to FP exception

[matz at gcc dot gnu.org]

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

Bug ID: 96373
   Summary: SVE miscompilation on vectorized division loop,
leading to FP exception
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matz at gcc dot gnu.org
  Target Milestone: ---

I believe gcc-10 miscompiles the following program when SVE and vectorization
are enabled.  You need glibc to show this, or a different way to enable traps
on floating point exceptions:

% cat x.c
#define _GNU_SOURCE
#include 
void __attribute__((noinline, noclone)) div (double *d, double *s, int n)
{
  for (;n; n--, d++, s++)
*d = *d / *s;
}

extern int printf(const char*, ...);

int main()
{
  int i;
  double d[] = {1,2,3,4,5,6,7,8,9,10,11};
  double s[] = {11,10,9,8,7,6,5,4,3,2,1};
  //fesetenv(FE_NOMASK_ENV);
  feenableexcept(FE_DIVBYZERO|FE_INVALID);
  div(d, s, 11);
  for (i = 0; i < 11; i++)
printf(" %f", d[i]);
  printf("\n");
  return 0;
}

% gcc-10 --version
gcc-10 (SUSE Linux) 10.2.1 20200723 [revision
677b80db41f5345b32ce18cd000e45ea39b80d8f]

% gcc-10 -g -march=armv8.2-a -O2 -ftree-vectorize x.c -lm && ./a.out
 0.090909 0.20 0.33 0.50 0.714286 1.00 1.40 2.00
3.00 5.00 11.00

% gcc-10 -g -march=armv8.2-a+sve -O2 -ftree-vectorize  x.c -lm && ./a.out 
Floating point exception (core dumped)

I think the code speaks for itself, excerpt from div():

whilelo p0.d, wzr, w2
ptrue   p1.b, all
.p2align 3,,7
.L4:
ld1dz0.d, p0/z, [x0, x3, lsl 3]
ld1dz1.d, p0/z, [x1, x3, lsl 3]
fdivz0.d, p1/m, z0.d, z1.d
st1dz0.d, p0, [x0, x3, lsl 3]
incdx3
whilelo p0.d, w3, w2
b.any   .L4

So, it enables all lanes in p1, while the active lanes in the loop are tracked
in p0.  In particular non-active lanes from the load are zeroed.  The
division uses p1 and hence divides all lanes, including those that were zeroed.

Indeed that's what happens when the exception is thrown:

% gdb ./a.out
...
Program received signal SIGFPE, Arithmetic exception.
(gdb) x/i $pc
=> 0x400848 :   fdivz0.d, p1/m, z0.d, z1.d
(gdb) p $p1
$1 = {255, 255, 255, 255, 255, 255, 255, 255}
(gdb) p $z1.d.f
$2 = {3, 2, 1, 0, 0, 0, 0, 0}

When traps aren't enabled (the default is disabled) then these zero divisions
simply lead to NaNs in the respective lanes, and as in further instructions
the p0 predicate is used that's of no issue as those are ignored then.

But if traps are enabled this leads to an incorrect FPE trap.

The same behaviour occurs already with gcc-9.  I haven't tested master.

We noticed this within OpenFOAM on SVE capable hardware, but divisions in
vectorizable contexts should occur reasonably often for this to be a serious
problem.  (traps on exceptions aren't enabled very often, though, so this
bug will be hidden often).

[Bug analyzer/96374] New: Analyzer erroneously rejects certain diagnostics due to path-feasibility being used on shortest path

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 96374
   Summary: Analyzer erroneously rejects certain diagnostics due
to path-feasibility being used on shortest path
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Analyzer fails to find a path to the __analyzer_dump_path call:

#include "analyzer-decls.h"

int test_6 (int a, int b)
{
  int problem = 0;
  if (a)
problem = 1;
  if (b)
{
  if (!problem)
problem = 2;
  __analyzer_dump_path (); /* { dg-message "path" "" { xfail *-*-* } } */
}
  return problem;
}

It's rejecting the path due to picking the shortest path, and then a bad
interaction with feasibility-checking.

If feasibility-checking is hacked out, it picks this path (with
-fanalyzer-verbosity=3 for clarity):

  ‘test_6’: events 1-7
|
|6 |   if (a)
|  |  ^
|  |  |
|  |  (1) following ‘false’ branch (when ‘a == 0’)...
|7 | problem = 1;
|8 |   if (b)
|  |  ~
|  |  |
|  |  (2) ...to here
|  |  (3) following ‘true’ branch (when ‘b != 0’)...
|9 | {
|   10 |   if (!problem)
|  |  ~
|  |  |
|  |  (4) ...to here
|  |  (5) following ‘false’ branch (when ‘problem != 0’)...
|   11 |  problem = 2;
|   12 |   __analyzer_dump_path ();
|  |   ~~~
|  |   |
|  |   (6) ...to here
|  |   (7) here
|

However, with feasibility-checking, "problem" is still 0 at event (5) (due to
the shortest path skipping the "problem = 1" suite), and hance the "problem !=
0" edge is invalid, and the edge from (5) to (6) is rejected, and the
diagnostic rejected.

We want the shortest feasible path if one exists, and are currently
approximating this by picking the shortest path, and checking if it's feasible,
which isn't the same thing.

Am not sure how best to fix this, but need a PR to mark this as XFAIL.

[Bug target/96375] New: [11 regression] arm/lob[2-5].c fail on some configurations

[clyon at gcc dot gnu.org]

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

Bug ID: 96375
   Summary: [11 regression] arm/lob[2-5].c fail on some
configurations
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

Since these new tests were introduced, I've noticed that they fail on some
configurations.

For instance, with target arm-none-linux-gnueabi --with-mode arm --with-cpu
cortex-a9:
spawn -ignore SIGHUP
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/gcc/xgcc
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/gcc/
/gcc/testsuite/gcc.target/arm/lob2.c -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -march=armv8.1-m.main -O3 --save-temps
-ffat-lto-objects -fno-ident -S -o lob2.s
cc1: error: target CPU does not support ARM mode
compiler exited with status 1
FAIL: gcc.target/arm/lob2.c (test for excess errors)
Excess errors:
cc1: error: target CPU does not support ARM mode

gcc.target/arm/lob2.c: output file does not exist

The current dg-skip-if is not sufficient.

Note that lob1.c is UNSUPPORTED in this case, because arm_v8_1_lob_hw_available
fails to compile:
cc1: error: target CPU does not support ARM mode

You probably want to make sure that -mthumb is also used when compiling these
tests.

Sadly, all these new tests are skipped in all my arm-eabi configurations
because I always override -mcpu :-(

[Bug tree-optimization/96369] Wrong evaluation order of || operator

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-29
   Keywords||wrong-code
  Component|c   |tree-optimization
 Status|UNCONFIRMED |NEW

[Bug analyzer/96374] Analyzer erroneously rejects certain diagnostics due to path-feasibility being used on shortest path

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
This is likely to be associated with "merger" exploded_nodes (where we have
merged state to help the exploded graph converge).  Perhaps if we fail to find
a feasible path on the first try we could retry, finding the shortest path that
doesn't include each merger node in turn, and if any of those are feasible,
find the shortest one.

[Bug tree-optimization/96376] New: [11 regression] vect/vect-alias-check.c and vect/vect-live-5.c fail on armeb

[clyon at gcc dot gnu.org]

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

Bug ID: 96376
   Summary: [11 regression] vect/vect-alias-check.c and
vect/vect-live-5.c fail on armeb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I've noticed regressions on target armeb-none-linux-gnueabihf --with-mode arm
--with-cpu cortex-a9 --with-fpu neon-fp16:
gcc.dg/vect/vect-alias-check.c -flto -ffat-lto-objects  scan-tree-dump-times
vect "vectorized 1 loops" 1
gcc.dg/vect/vect-alias-check.c scan-tree-dump-times vect "vectorized 1 loops" 1
gcc.dg/vect/vect-live-5.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1
gcc.dg/vect/vect-live-5.c scan-tree-dump-times vect "vectorized 1 loops" 1

In my logs I can see:
PASS: gcc.dg/vect/vect-live-5.c execution test
gcc.dg/vect/vect-live-5.c: pattern found 0 times
FAIL: gcc.dg/vect/vect-live-5.c scan-tree-dump-times vect "vectorized 1 loops"
1

PASS: gcc.dg/vect/vect-alias-check.c (test for excess errors)
gcc.dg/vect/vect-alias-check.c: pattern found 0 times
FAIL: gcc.dg/vect/vect-alias-check.c scan-tree-dump-times vect "vectorized 1
loops" 1

This appeared between r11-1908 and r11-1952.

[Bug tree-optimization/18501] [8/9/10/11 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||felix at piedallu dot me

--- Comment #94 from Manuel López-Ibáñez  ---
*** Bug 96368 has been marked as a duplicate of this bug. ***

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[manu at gcc dot gnu.org]

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

Bug 96368 Summary: False negative with maybe-uninitialized with goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96368

   What|Removed |Added

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

[Bug c/96368] False negative with maybe-uninitialized with goto

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
I'm pretty sure this is PR18501. 

pktio_read() creates a PHI node and prevents CCP deleting the undefined value.

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

[Bug c/96368] False negative with maybe-uninitialized with goto

[felix at piedallu dot me]

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

Salamandar  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #2 from Salamandar  ---
I just tried with GCC 9.3 and the bug is still present.

https://godbolt.org/z/TYarqe

[Bug target/96377] New: [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[jakub at gcc dot gnu.org]

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

Bug ID: 96377
   Summary: [10/11 Regression] GCC 10.2/11 doesn't build Linux
kernel anymore
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase reduced from Linux kernel's crypto/aegis128-neon-inner.c
started to be rejected with r11-1741-g31427b974ed7b7dd54e28fec595e731bf6eea8ba
and r10-8501-g932e9140d3268cf2033c1c3e93219541c53fcd29

#include 

struct aegis128_state {
 uint8x16_t v[5];
};

void foo(const void *key, const void *iv, const void *const0, const void
*const1)
{
 uint8x16_t k = vld1q_u8(key);
 uint8x16_t kiv = k ^ vld1q_u8(iv);
 struct aegis128_state st = {{
  kiv,
  vld1q_u8(const1),
  vld1q_u8(const0),
  k ^ vld1q_u8(const0),
  k ^ vld1q_u8(const1),
 }};
}

The error is:
error: incompatible types when initializing type ‘unsigned char’ using type
‘uint8x16_t’ {aka ‘__Uint8x16_t’}
(twice)

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Last reconfirmed||2020-07-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Priority|P3  |P1
   Target Milestone|--- |10.3

[Bug middle-end/96300] missing -Wuninitialized reading a struct member by a conditionally assigned pointer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||manu at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-29

--- Comment #2 from Manuel López-Ibáñez  ---
This seems some kind of weird missed optimization because this variant does
warn:


struct S { int i; };

int g (int i, int yy)
{
  struct S x, y={yy}, *p = i ? &x : &y;
  return p->i;   // missing -Wuninitialized
}

[Bug c/96368] False negative with maybe-uninitialized with goto

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|VERIFIED|RESOLVED

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Salamandar from comment #2)
> I just tried with GCC 9.3 and the bug is still present.
> 
> https://godbolt.org/z/TYarqe

Yes, PR18501 is still open (and it won't be fixed anytime soon, it is too
difficult).

[Bug tree-optimization/96367] bogus -Wformat-truncation in ILP32

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |tree-optimization
 Ever confirmed|0   |1
 Blocks||85741
  Known to fail||10.2.0, 11.0
   Last reconfirmed||2020-07-29
Summary|bogus format truncation |bogus -Wformat-truncation
   |error on armhf when |in ILP32
   |building perf with gcc 10   |
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
The mention of armhf was a helpful clue.  With it I was able to reproduce an
unintended inconsistency between ILP32 and LP64 on the following test case. 
Otherwise, reports without test cases to reproduce the problem are hard to
analyze.  An error alone, without the context and the notes that might follow,
also isn't sufficient.  Especially in this case because it doesn't show which
of the four %s directives it refers to.  In the future please provide the
details requested here: https://gcc.gnu.org/bugs/#need.

$ (set -x && cat t.c && gcc -O2 -S -Wall t.c && gcc -O2 -S -Wall -m32 t.c)
+ cat t.c
char a[8];

void f (const char *s)
{
  __SIZE_TYPE__ n = __builtin_strlen (s);
  if (n < 3) return;

  __builtin_snprintf (a, 8, "%s", s);
}
+ gcc -O2 -S -Wall t.c
+ gcc -O2 -S -Wall -m32 t.c
t.c: In function ‘f’:
t.c:8:30: warning: ‘%s’ directive output may be truncated writing between 3 and
2147483645 bytes into a region of size 8 [-Wformat-truncation=]
8 |   __builtin_snprintf (a, 8, "%s", s);
  |  ^~
t.c:8:3: note: ‘__builtin_snprintf’ output between 4 and 2147483646 bytes into
a destination of size 8
8 |   __builtin_snprintf (a, 8, "%s", s);
  |   ^~


Referenced Bugs:

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

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
I think the problem is that c_common_type does:
742   if (TYPE_ATTRIBUTES (t1) != NULL_TREE)
743 t1 = build_type_attribute_variant (t1, NULL_TREE);
744 
745   if (TYPE_ATTRIBUTES (t2) != NULL_TREE)
746 t2 = build_type_attribute_variant (t2, NULL_TREE);
which strips off the "Advanced SIMD type" attribute from both of the types.
C++ FE doesn't do anything like that.

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl  ---
On Wed, Jul 29, 2020 at 02:54:59PM +, pault at gcc dot gnu.org wrote:
> --- Comment #12 from Paul Thomas  ---
> (In reply to kargl from comment #10)
> > (In reply to jvdelisle from comment #9)
> > > I regression tested the patch in comment 8 and see these failures.
> > > 
> > > FAIL: gfortran.dg/pr93423.f90   -O  (test for excess errors)
> > > FAIL: gfortran.dg/typebound_call_31.f90   -O   (test for errors, line 14)
> > > FAIL: gfortran.dg/typebound_call_31.f90   -O  (test for excess errors)
> > 
> > Thanks for testing.  Does the patch that follows fix the regressions?
> > gfortran treats components and type bound procedures separately.  I've
> > (hopefully) adapted the patch to whether foo is either.
> > 
> > Index: gcc/fortran/primary.c
> > ===
> > --- gcc/fortran/primary.c   (revision 280157)
> > +++ gcc/fortran/primary.c   (working copy)
> > @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int 
> > equiv_flag, 
> >   inquiry = is_inquiry_ref (name, &tmp);
> >   if (inquiry)
> > sym = NULL;
> > + else
> > +   {
> > + component = gfc_find_component (sym, name, false, false, &tmp);
> > + tbp = gfc_find_typebound_proc (sym, &t, name, false,
> > &gfc_current_locus);
> > + if (!component && !tbp)
> > +   {
> > + gfc_error ("%qs at %C is neither a component nor a type "
> > +"bound procedure of the derived "
> > +"type %qs", name, sym->name);
> > + return MATCH_ERROR;
> > +   }
> > +   }
> >  
> >   if (sep == '%' && primary->ts.type != BT_UNKNOWN)
> > intrinsic = true;
> 
> Hi Steve,
> 
> Given your comment 6, I set too first thing this morning and
> located the bug by searching the ChangeLogs for candidates. That
> I was the culprit is galling to say the least of it.

Don't be too galled (is that a word?).  You've contributed to so
many areas of the compiler and the Fortran language is only getting
more complicated!

For my patch, I noted that is_inquiry_ref tested for %re, %im,
%len, and %kind.  As that returns false, the only thing that
%foo(i) can be is either a component (which happens to be an
array) or type-bound procedure. 

> My version of the fix is:
> 
> index d73898473df..6f032fbabfd 100644
> --- a/gcc/fortran/primary.c
> +++ b/gcc/fortran/primary.c
> @@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
> bool sub_flag,
>else
> component = NULL;
> 
> -  /* In some cases, returning MATCH_NO gives a better error message. Most
> -cases return "Unclassifiable statement at..."  */
>if (intrinsic && !inquiry)
> -   return MATCH_NO;
> +   {
> + gfc_error ("%qs at %C is not an inquiry reference to an "
> +"intrinsic type", name);
> + return MATCH_ERROR;
> +   }

This works for me.  Note, jerryd is in the process of committing
my patch as I do not use git (and currently no one is paying me
to learn git).

> > + gfc_error ("%qs at %C is not an inquiry reference to an "
> > +"intrinsic type", name);
> 
> or some such.

I suppose the above error message works.  The message I came up
with is due to the (i) in %foo(i).  Is this a typo for an array
or TBP?   Either way the error is now detected.

> 
> Also, you have to get rid of the comment and the dead code that
> was modified in my patch.
> 
> Thanks for the patch. OK for trunk when the error message is
> corrected and the comment plus dead code removed.

I do not know git.  I do not use git for my personal projects,
so there is no incentive for me to waste my time learning what
has become a bane.  I am stuck at svn r280157 (Jan 2020 or so).
AFAICT, from reading gcc mailing list arhives, the switch from
subversion to git was not publically discussed.  All discussion
(from a very small group of people) makes it clear the conversion
was going to happen.  It seems there was no consideration for
the negative impact the switch will have.  But, then again, 
gfortran is an after thought for most.

You'll find a bunch of patches attached to PRs, which need a
(hopefully new) gfortran committer to look:

mobile:kargl[204] ls pr*diff
pr30371.diffpr95586.diff
pr30371_umask.diff  pr95612.diff
pr30371_umask_sub.diff  pr95613.diff
pr30371_unlink_sub.diff pr95614.diff
pr69101.diffpr95647.diff
pr85796.diffpr95708.diff
pr93635.diffpr95709.diff
pr95038.diffpr95710.diff
pr95340.diffpr95829.diff
pr95342.diffpr95980.diff
pr95352.diffpr95981.diff
pr95372.diffpr96013.diff
pr95446.diffpr96025.diff
pr9

[Bug bootstrap/96378] New: ICE: Solaris/SPARCv9 bootstrap stage2 segfault compiling stdc++.h.gch/O2ggnu++0x.gch

[nicholas.h.briggs at gmail dot com]

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

Bug ID: 96378
   Summary: ICE: Solaris/SPARCv9 bootstrap stage2 segfault
compiling stdc++.h.gch/O2ggnu++0x.gch
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicholas.h.briggs at gmail dot com
  Target Milestone: ---

Created attachment 48952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48952&action=edit
Failing preprocessed source

Configured as:

~/gcc-10.2-objdir$ ../gcc/configure prefix=/opt/gcc-10.2 --disable-werror
--disable-checking CC=gcc CXX=g++ --disable-multilib
--build=sparcv9-sun-solaris2.11 --with-gnu-as --with-as=/opt/binutils/bin/as
--without-gnu-ld --with-ld=/usr/bin/ld --enable-languages=c,c++,lto

$ gcc --version
gcc (GCC) 7.3.0
Copyright (C) 2017 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.

$ /opt/binutils/bin/as --version
GNU assembler (GNU Binutils) 2.35
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `sparc-sun-solaris2.11'.
$ /usr/bin/ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.3159

Bootstrap fails at

/export/home/briggs/gcc-10.2-objdir/./gcc/xgcc -shared-libgcc
-B/export/home/briggs/gcc-10.2-objdir/./gcc -nostdinc++
-L/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/src
-L/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/src/.libs
-L/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/opt/gcc-10.2/sparcv9-sun-solaris2.11/bin/
-B/opt/gcc-10.2/sparcv9-sun-solaris2.11/lib/ -isystem
/opt/gcc-10.2/sparcv9-sun-solaris2.11/include -isystem
/opt/gcc-10.2/sparcv9-sun-solaris2.11/sys-include   -fno-checking -x c++-header
-nostdinc++ -g -O2 
-I/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/sparcv9-sun-solaris2.11
-I/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include
-I/export/home/briggs/gcc/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x
/export/home/briggs/gcc/libstdc++-v3/include/precompiled/stdc++.h \
-o sparcv9-sun-solaris2.11/bits/stdc++.h.gch/O2ggnu++0x.gch

with

In file included from
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/bits/localefwd.h:40,
 from
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/ios:41,
 from
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/istream:38,
 from
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/sstream:38,
 from
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/complex:45,
 from
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/ccomplex:39,
 from
/export/home/briggs/gcc/libstdc++-v3/include/precompiled/stdc++.h:54:
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/sparcv9-sun-solaris2.11/bits/c++locale.h:
In function ‘int std::__convert_from_v(int* const&, char*, int, const char*,
...)’:
/export/home/briggs/gcc-10.2-objdir/sparcv9-sun-solaris2.11/libstdc++-v3/include/sparcv9-sun-solaris2.11/bits/c++locale.h:60:47:
internal compiler error: Segmentation Fault
   60 | char* __old = std::setlocale(LC_NUMERIC, 0);
  |   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gmake[5]: *** [Makefile:1825:
sparcv9-sun-solaris2.11/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
gmake[4]: *** [Makefile:563: all-recursive] Error 1
gmake[3]: *** [Makefile:488: all] Error 2
gmake[2]: *** [Makefile:20026: all-stage2-target-libstdc++-v3] Error 2
gmake[1]: *** [Makefile:27159: stage2-bubble] Error 2
gmake: *** [Makefile:27403: bootstrap] Error 2

[Bug c++/96379] New: [ 10/11 Regression ] GCC accepts totally invalid template declaration

[haoxintu at gmail dot com]

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

Bug ID: 96379
   Summary: [ 10/11 Regression ] GCC accepts totally invalid
template declaration
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

Input:
//small.cc
const int a = 0;
const long b = 1 ;
enum struct c;
template  enum struct c : union enum class c { e = b, f = a }; 
enum class c {};

Output (GCC-10.1):
:4:23: warning: elaborated-type-specifier for a scoped enum must not
use the 'struct' keyword
4 | template  enum struct c : union enum class c { e = b, f = a };
  |   ^~
  |   --
:4:32: error: expected unqualified-id before ':' token
4 | template  enum struct c : union enum class c { e = b, f = a };
  |^
:5:12: error: multiple definition of 'enum class c'
5 | enum class c {};
  |^
:4:51: note: previous definition here
4 | template  enum struct c : union enum class c { e = b, f = a };
  |

GCC-trunk and GCC-10.2 accept this code, while GCC-10.1 downwards versions
reject this. I am sure the code is totally invalid, so I guess there might be
something wrong with GCC-trunk.

Reproduced in Godbolt : https://godbolt.org/z/jTejTT

Thanks,
Haoxin

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This dates back to
https://gcc.gnu.org/legacy-ml/gcc-patches/2004-06/msg00288.html
Dunno, do we want to never strip attributes from VECTOR_TYPEs and only strip
them that way from non-VECTOR_TYPEs?  Or only strip some attributes and keep
others?
Or just add a if (t1 == t2) return t1; before the attribute stripping (perhaps
for VECTOR_TYPEs only)?
Note, due to the typedef __Uint8x16_t uint8x16_t; on this testcase t1 and t2
are equal and are the typedef file, and because they are unqualified, we don't
use TYPE_MAIN_VARIANT (which is the __Uint8x16_t type).
What is the desirable behavior for the common type if one is the aarch64
specific vector and the other generic vector with the same mode?
The C++ behavior for vector types in cp_common_type is that it will merge
attributes from both types, and if one is TYPE_UNSIGNED, pick that one,
otherwise pick the other one.  So in that case the ARM specific vector type
wins.

I must say I'm surprised that the 10.2 version of the patch also matters,
perhaps the FE isn't using the target hook to compare attributes, but rather
just compares TYPE_MAIN_VARIANT or something similar to determine if the
initializer is initializing a whole vector or an element of the vector.

[Bug c++/96310] Ignoring Wnonnull via pragma gcc diagnostics still produces a unwanted note

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
I've been thinking about that too but not really coming up with anything given
the current design.  One idea is to change warning() to return a unique "token"
and have inform() take it as an argument and do its thing based on its value. 
The code would then go back to the original:

warntok = warning_at (loc, OPT_Wnonnull,
  "%qs pointer null", "this");
if (pctx->fndecl)
inform (warntok,
DECL_SOURCE_LOCATION (pctx->fndecl),
"in a call to non-static member function %qD",
pctx->fndecl);

A more object-oriented alternative is to extend the auto_diagnostic_group class
to create a series of related messages, starting with an error or warning, and
followed by any number of notes, and have it either issue all of them or none
in a single call.  That might look like this:

  auto_diagnostic_group adg;
  adg.warning_at (loc, OPT_Wnonnull,
  "%qs pointer null", "this");
  if (pctx->fndecl)
  adg.inform (DECL_SOURCE_LOCATION (pctx->fndecl),
  "in a call to non-static member function %qD",
  pctx->fndecl);
  adg.do_it ();

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
For those that need a quick workaround for the kernel, I think
  (uint8x16_t) (k ^ vld1q_u8(const0)),
  (uint8x16_t) (k ^ vld1q_u8(const1)),
instead of
  k ^ vld1q_u8(const0),
  k ^ vld1q_u8(const1),
will do the job.  And it is a question if portable code can use binary
operators on the ARM specific vector types rather than intrinsics or the normal
generic vectors instead.

[Bug c++/96380] New: [10/11 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954

[haoxintu at gmail dot com]

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

Bug ID: 96380
   Summary: [10/11 Regression] ICE in tree check: expected
integer_cst, have view_convert_expr in get_len, at
tree.h:5954
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This invalid code makes GCC-trunk and GCC-10.2 ICE, and GCC-10 downwards
versions compile it well without ICE.

Input:
//small.cc
const int a;
const long b;
enum struct c;
template  enum struct c : union enum class c { e = b, f = a }; 
enum class c {};

Command:
g++ -fermissive -w small.cc

Output:
small.cc:5:15: internal compiler error: tree check: expected integer_cst, have
view_convert_expr in get_len, at tree.h:5954
5 | enum class c {};
  |   ^
0x7eb991 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9687
0x8aeffa tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3559
0x8aeffa wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5954
0x8aeffa wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:985
0x8aeffa wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1034
0x8aeffa generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:790
0x8aeffa bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:1901
0x93bc08 wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
 >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:3248
0x93bc08 tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/tree.h:6110
0x93bc08 finish_enum_value_list(tree_node*)
../../gcc/cp/decl.c:15573
0x9cc89b cp_parser_enum_specifier
../../gcc/cp/parser.c:19483
0x9cc89b cp_parser_type_specifier
../../gcc/cp/parser.c:17769
0x9cd17e cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14436
0x9cdf31 cp_parser_simple_declaration
../../gcc/cp/parser.c:13690
0x9f929e cp_parser_declaration
../../gcc/cp/parser.c:13510
0x9f998b cp_parser_translation_unit
../../gcc/cp/parser.c:4793
0x9f998b c_parse_file()
../../gcc/cp/parser.c:44081
0xb144fd c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reproduced in Godbolt : https://godbolt.org/z/YGPxsj

Thanks,
Haoxin

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[paul.richard.thomas at gmail dot com]

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

--- Comment #14 from paul.richard.thomas at gmail dot com  ---
Hi Steve,

Your opinion of git and the change over to it is much the same as mine. I
have given it a go but had several "accidents" which put me off for a bit.
As for working on the branches well, I won't even begin to describe
what a dog's dinner that is. ChangeLogs are stuffed (or were) and I still
haven't found out how to update Bugzilla automatically. I haven't had the
energy to try again these last few months, largely because I am finding
home working so knackering. Sitting in front of the screen all day is
causing me irritated eyes and the occasional blinder of a headache.

I have taken note of your PRs with fixes on them - I'll maybe use them as
an adventure into gitland :-)

I see that Washington is just above the threshold of testing positivity and
that it is increasing. Has that resulted in a response yet? My younger son
lives in Mountain View and is going crazy with the new statewide
restrictions. They have two kids in a relatively small house and are both
trying to work from home. With no summer camps they are heading to another
bout of cabin fever.

galling
/ˈɡɔːlɪŋ/
Learn to pronounce

*adjective*

   1. causing annoyance or resentment; annoying.
   "it would be galling to lose your job because of a dispute with a
   customer"

Cheers

Paul

On Wed, 29 Jul 2020 at 17:19, sgk at troutmask dot apl.washington.edu <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
>
> --- Comment #13 from Steve Kargl 
> ---
> On Wed, Jul 29, 2020 at 02:54:59PM +, pault at gcc dot gnu.org wrote:
> > --- Comment #12 from Paul Thomas  ---
> > (In reply to kargl from comment #10)
> > > (In reply to jvdelisle from comment #9)
> > > > I regression tested the patch in comment 8 and see these failures.
> > > >
> > > > FAIL: gfortran.dg/pr93423.f90   -O  (test for excess errors)
> > > > FAIL: gfortran.dg/typebound_call_31.f90   -O   (test for errors,
> line 14)
> > > > FAIL: gfortran.dg/typebound_call_31.f90   -O  (test for excess
> errors)
> > >
> > > Thanks for testing.  Does the patch that follows fix the regressions?
> > > gfortran treats components and type bound procedures separately.  I've
> > > (hopefully) adapted the patch to whether foo is either.
> > >
> > > Index: gcc/fortran/primary.c
> > > ===
> > > --- gcc/fortran/primary.c   (revision 280157)
> > > +++ gcc/fortran/primary.c   (working copy)
> > > @@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int
> equiv_flag,
> > >   inquiry = is_inquiry_ref (name, &tmp);
> > >   if (inquiry)
> > > sym = NULL;
> > > + else
> > > +   {
> > > + component = gfc_find_component (sym, name, false, false,
> &tmp);
> > > + tbp = gfc_find_typebound_proc (sym, &t, name, false,
> > > &gfc_current_locus);
> > > + if (!component && !tbp)
> > > +   {
> > > + gfc_error ("%qs at %C is neither a component nor a type "
> > > +"bound procedure of the derived "
> > > +"type %qs", name, sym->name);
> > > + return MATCH_ERROR;
> > > +   }
> > > +   }
> > >
> > >   if (sep == '%' && primary->ts.type != BT_UNKNOWN)
> > > intrinsic = true;
> >
> > Hi Steve,
> >
> > Given your comment 6, I set too first thing this morning and
> > located the bug by searching the ChangeLogs for candidates. That
> > I was the culprit is galling to say the least of it.
>
> Don't be too galled (is that a word?).  You've contributed to so
> many areas of the compiler and the Fortran language is only getting
> more complicated!
>
> For my patch, I noted that is_inquiry_ref tested for %re, %im,
> %len, and %kind.  As that returns false, the only thing that
> %foo(i) can be is either a component (which happens to be an
> array) or type-bound procedure.
>
> > My version of the fix is:
> >
> > index d73898473df..6f032fbabfd 100644
> > --- a/gcc/fortran/primary.c
> > +++ b/gcc/fortran/primary.c
> > @@ -2327,10 +2327,12 @@ gfc_match_varspec (gfc_expr *primary, int
> equiv_flag,
> > bool sub_flag,
> >else
> > component = NULL;
> >
> > -  /* In some cases, returning MATCH_NO gives a better error
> message. Most
> > -cases return "Unclassifiable statement at..."  */
> >if (intrinsic && !inquiry)
> > -   return MATCH_NO;
> > +   {
> > + gfc_error ("%qs at %C is not an inquiry reference to an "
> > +"intrinsic typ

[Bug fortran/96381] New: gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)

[matmal01 at gcc dot gnu.org]

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

Bug ID: 96381
   Summary: gfc_find_vtab can use a character type typespec as a
derived type (causing invalid access)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matmal01 at gcc dot gnu.org
  Target Milestone: ---

When running the testsuite with a compiler sanitized with -fsanitize=hwaddress
(HWASAN sanitizer which is not yet committed upstream) I saw the error below.

The error comes from the testsuite running `pr93337.f90`.

It is complaining that `gfc_find_derived_vtab` is attempting to access an 8
byte chunk of data 88 bytes after a region that is only 48 bytes long.
That seems to be coming from the access of `derived->attr.pdt_template` (which
is a one-bit field in the byte 92 bytes into a `gfc_symbol` structure).

According to the dump the 48 byte long structure is allocated in
`gfc_new_charlen`.
This function only ever sets the `cl` alternative of the union in a
`gfc_typespec`.
I've inlined a GDB session demonstrating the mis-use under the HWASAN dump.





==25394==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefdf79d8 at
pc 0x006a8560
READ of size 8 at 0xefdf79d8 tags: 58/ff (ptr/mem) in thread T0
#0 0x6a855c in SigTrap<3>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:27
#1 0x6a855c in CheckAddress<(__hwasan::ErrorAction)0,
(__hwasan::AccessType)0, 3>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:88
#2 0x6a855c in __hwasan_load8
../../../../gcc-source/libsanitizer/hwasan/hwasan.cpp:454
#3 0x6ff654 in gfc_find_derived_vtab(gfc_symbol*)
../../gcc-source/gcc/fortran/class.c:2269
#4 0x707498 in gfc_find_vtab(gfc_typespec*)
../../gcc-source/gcc/fortran/class.c:2908
#5 0x707498 in gfc_find_vtab(gfc_typespec*)
../../gcc-source/gcc/fortran/class.c:2898
#6 0x7a7578 in gfc_match_assignment()
../../gcc-source/gcc/fortran/match.c:1393
#7 0x80d53c in match_word ../../gcc-source/gcc/fortran/parse.c:65
#8 0x80d53c in decode_statement ../../gcc-source/gcc/fortran/parse.c:361
#9 0x812f28 in next_free ../../gcc-source/gcc/fortran/parse.c:1280
#10 0x812f28 in next_statement ../../gcc-source/gcc/fortran/parse.c:1512
#11 0x816190 in parse_spec ../../gcc-source/gcc/fortran/parse.c:3923
#12 0x819948 in parse_progunit ../../gcc-source/gcc/fortran/parse.c:5853
#13 0x81c02c in gfc_parse_file() ../../gcc-source/gcc/fortran/parse.c:6394
#14 0x898d98 in gfc_be_parse_file
../../gcc-source/gcc/fortran/f95-lang.c:212
#15 0x152ac7c in compile_file ../../gcc-source/gcc/toplev.c:458
#16 0x69d114 in do_compile ../../gcc-source/gcc/toplev.c:2320
#17 0x69d114 in toplev::main(int, char**)
../../gcc-source/gcc/toplev.c:2459
#18 0x6a0218 in main ../../gcc-source/gcc/main.c:39
#19 0xa03c38dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)

[0xefdf79c0,0xefdf7a00) is a small allocated heap chunk; size: 64
offset: 24
0xefdf79d8 is located 40 bytes to the right of 48-byte region
[0xefdf7980,0xefdf79b0)
allocated here:
#0 0x6a9d40 in __sanitizer_calloc
../../../../gcc-source/libsanitizer/hwasan/hwasan_interceptors.cpp:138
#1 0x2d1ebbc in xcalloc ../../gcc-source/libiberty/xmalloc.c:162
#2 0x8831a0 in gfc_new_charlen(gfc_namespace*, gfc_charlen*)
../../gcc-source/gcc/fortran/symbol.c:3964
#3 0x7146ec in gfc_match_char_spec(gfc_typespec*)
../../gcc-source/gcc/fortran/decl.c:3478
#4 0x71e324 in gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc-source/gcc/fortran/decl.c:4169
#5 0x7220d8 in gfc_match_data_decl()
../../gcc-source/gcc/fortran/decl.c:6129
#6 0x80d6b0 in match_word ../../gcc-source/gcc/fortran/parse.c:65
#7 0x80d6b0 in decode_statement ../../gcc-source/gcc/fortran/parse.c:376
#8 0x812f28 in next_free ../../gcc-source/gcc/fortran/parse.c:1280
#9 0x812f28 in next_statement ../../gcc-source/gcc/fortran/parse.c:1512
#10 0x816600 in parse_derived ../../gcc-source/gcc/fortran/parse.c:3343
#11 0x816600 in parse_spec ../../gcc-source/gcc/fortran/parse.c:3884
#12 0x819948 in parse_progunit ../../gcc-source/gcc/fortran/parse.c:5853
#13 0x81c02c in gfc_parse_file() ../../gcc-source/gcc/fortran/parse.c:6394
#14 0x898d98 in gfc_be_parse_file
../../gcc-source/gcc/fortran/f95-lang.c:212
#15 0x152ac7c in compile_file ../../gcc-source/gcc/toplev.c:458
#16 0x69d114 in do_compile ../../gcc-source/gcc/toplev.c:2320
#17 0x69d114 in toplev::main(int, char**)
../../gcc-source/gcc/toplev.c:2459
#18 0x6a0218 in main ../../gcc-source/gcc/main.c:39
#19 0xa03c38dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
#20 0x6a3e5c 
(/home/ubuntu/working-directory/gcc-hwasan-install/libexec/gcc/aarch64-unknown-linux-gnu/11.0.0/f9

[Bug target/96371] [nvptx] frounding-math support

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Wed, 29 Jul 2020, vries at gcc dot gnu.org wrote:

> Anyway, in absence of all this, without fenv.h support there's no way to set
> the rounding mode, meaning that we can assume default rounding mode, as the
> current implementation of "div3" does.  OTOH, we don't take that
> assumption further, f.i. we don't ignore frounding-math.

Ignoring -frounding-math and -ftrapping-math would generically make sense 
for most software floating-point configurations (not powerpc-linux-gnu) as 
well because those don't support rounding modes and exceptions.  It would 
probably require various testsuite updates to mark testcases that depend 
on rounding mode / exception support and test assumptions that are only 
valid when those are available.  (Tests requiring such support at 
execution time should already be appropriately conditional.  But 
compile-time tests of optimzations may well just assume the particular set 
of optimizations enabled that the given options yield at present.)

Compile-time warning for such options seems less helpful, e.g. glibc just 
builds with -frounding-math everywhere including configurations with 
software floating point (and the handful of libm functions that depend on 
being able to set FE_TOWARDZERO internally have different implementations 
used in the software floating point case).  Calling fesetround in such a 
glibc configuration results in a link-time warning for the unimplemented 
function (which succeeds at runtime when FE_TONEAREST is passed, fails if 
any other value is passed).

When an instruction set supports rounding modes specified in instructions, 
that's a natural match for the TS 18661 / C2x FENV_ROUND pragma (but note 
the complications around how that's supposed to affect calls to certain 
standard library functions only, only when macro replacement has not been 
suppressed for those calls).  However, implementation of that pragma for 
such architectures would be rather different from implementations for 
architectures where it's necessary to insert dynamic rounding mode changes 
(inlined, to avoid introducing libm dependencies for fesetround).  (A 
third case is where there are multiple dynamic rounding modes that can be 
set independently and an instruction can choose which one to use, but I 
don't know if any architectures more modern than ia64 do that.)

[Bug target/96371] [nvptx] frounding-math support

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
The target hook float_exceptions_rounding_supported_p can be used to 
determine whether support for exceptions and rounding modes is available.  
For any architectures with hardware floating point that doesn't support 
exceptions and rounding modes it may give the wrong result (i.e. not have 
been added for those architectures), however.  It's not currently used for 
optimization purposes.

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Gah.  Thanks for the report and analysis.  Like you say,
I was hoping that adding the attributes in 10.2 but not
making them matter for type compatibility would have
been pretty conservative, but obviously it wasn't
conservative enough.

I'll take a look tomorrow.

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl  ---
Hi Paul,

Not sure how the UK is handling the pandemic.  Here, in
Washington we have 4 phases.  Phase 1 has the most
restrictions and phase 4 is the pandemic is over.  Most
of Washington made it into phase 2 (ie., small gathering,
restaurants, and stores opened with socialing distancing, etc).
Then the 4th of July holiday weekend happened, and now, many
places are back to phase 1 (ie., mandatory mask (which people
seem to ignore), gatherings of 5 (or 10) people, etc).  It
is interesting how people mistake common sense for infringement
of their civil liberties.  Of course, the political leadership
in the USA seems to be leading the pack with a lack common sense.

Transitioning to working from home has been interesting.
No small children to worry about.  But, my son was taking
graduate-level on-line courses on music composition for film
and multimedia, my wife was on-line, and I'm trying to
work.  Bandwidth was an issue.  Oh, I almost forgot.  I 
could often watch 2 EPL matches a day.

If you do look at one of my patches in a PR, feel free to 
ping me.  I had posted a list of PRs to comp.lang.fortran
trying to recruit new contributor.  Arjen has taken a 
baby step, but we could use more eyes.

[Bug target/96347] note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

  Attachment #48946|0   |1
is obsolete||

--- Comment #4 from Iain Buclaw  ---
Created attachment 48953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48953&action=edit
delegitimize mem(plus (unspec reg) tls)

Second patch, this time dealing with the following insn
---
(mem/f/c:DI (plus:DI (unspec:DI [
(const_int 0 [0])
] UNSPEC_TP)
(reg:DI 89)) [1 MEM  [(struct Darray *)&testYearsBC + 8B]+0 S8
A64])
---

After ix86_delegitimize_tls_address, it becomes
---
(mem/f/c:DI (reg/f:DI 6 bp [90]) [1 MEM  [(struct Darray *)&testYearsBC
+ 8B]+0 S8 A64])
---

Doesn't change assembly produced for given test, but alters debug output:
---
@@ -1105,12 +1105,9 @@ testYearsBC:
 .LLST4:
.quad   .LVL7
.quad   .LVL8-1
-   .value  0xd
-   .byte   0xe
-   .long   testYearsBC@dtpoff, 0
-   .byte   0xe0
-   .byte   0x23
-   .uleb128 0x8
+   .value  0x3
+   .byte   0x76
+   .sleb128 0
.byte   0x6
.quad   0
.quad   0
@@ -1148,15 +1145,12 @@ testYearsBC:
 .LLST6:
.quad   .LVL9
.quad   .LVL9
-   .value  0x11
+   .value  0x7
.byte   0x50
.byte   0x93
.uleb128 0x8
-   .byte   0xe
-   .long   testYearsBC@dtpoff, 0
-   .byte   0xe0
-   .byte   0x23
-   .uleb128 0x8
+   .byte   0x76
+   .sleb128 0
.byte   0x93
.uleb128 0x8
.quad   0
@@ -1167,15 +1161,12 @@ testYearsBC:
 .LLST7:
.quad   .LVL9
.quad   .LVL9
-   .value  0x11
+   .value  0x7
.byte   0x50
.byte   0x93
.uleb128 0x8
-   .byte   0xe
-   .long   testYearsBC@dtpoff, 0
-   .byte   0xe0
-   .byte   0x23
-   .uleb128 0x8
+   .byte   0x76
+   .sleb128 0
.byte   0x93
.uleb128 0x8
.quad   0
---

[Bug c++/91212] [8/9/10/11 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:81bc0ec3e926d7a2c90502847ddaacf3d56d5b75

commit r11-2411-g81bc0ec3e926d7a2c90502847ddaacf3d56d5b75
Author: Jason Merrill 
Date:   Wed Jul 29 00:57:40 2020 -0400

c++: Avoid calling const copy ctor on implicit move. [PR91212]

Our implementation of C++11 implicit move was wrong for return; we didn't
actually hit the check for the type of the first parameter of the selected
constructor, because we didn't see LOOKUP_PREFER_RVALUE set properly.

Fixing that to look at the right flags fixed the issue for this testcase,
but broke implicit move for a by-value converting constructor (PR58051).  I
think this was not allowed in C++17, but it is allowed under the implicit
move changes from C++20, and those changes were voted to apply as a DR to
earlier standards as well, so I don't want to break it now.

So after fixing the flags check I changed the test to allow value
parameters.

gcc/cp/ChangeLog:

PR c++/91212
* call.c (build_over_call): Don't call a const ref
overload for implicit move.

gcc/testsuite/ChangeLog:

PR c++/91212
* g++.dg/cpp0x/move-return3.C: New test.