[Bug middle-end/95442] LRA inserts a reload insn for REG_DEAD register

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
That seems right to be, last commit to touch it was 55a2c3226a3e. After looking
at it the reload insn and the related commit we should not be adding the reload
insn here.

[Bug target/68837] PowerPC switch statement performance

[guihaoc at gcc dot gnu.org]

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

--- Comment #5 from HaoChen Gui  ---
I think there are two ways avoiding sign extension for offset loading.

a. Make sure all offsets be positive.  There exists backward jumps as well as
STC will reorder the basic block. So the offset might be negative. We can check
the offsets after bb-reorder pass and remove sign extension if all offsets are
positive. It may need a new pass.

b. Use absolute addresses instead of offsets. It's controlled by macro
CASE_VECTOR_PC_RELATIVE and flag_pic. x86 uses absolute address(labels) in
their jump table, though the size of jump is bigger. Power haven't supported
absolute address yet.

[Bug fortran/95631] Unable to redefine a literal with `-std=legacy'

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from kargl at gcc dot gnu.org ---
I think Eric Korpela may not know the Fortran standards.  Yes,
old compiler did dumb things, because it was/is difficult to
detect this violation of the Fortran standards.  Note, these
prohibitions are on the programmer.

F66 8.4.2

If an actual argument corresponds to a dummy argument that is
defined or redefined in the referenced subprogram, the actual
argument must be a variable name, an array element name, or an
array name.

F77 15.9.2

Actual arguments may be constants, symbolic names of constants,
function references, expressions involving operators, and
expressions enclosed in parentheses if and only if the associated
dummy argument is a variable that is not defined during execution
of the referenced external procedure.

[Bug target/95632] New: Redundant zero extension

[bina2374 at gmail dot com]

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

Bug ID: 95632
   Summary: Redundant zero extension
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bina2374 at gmail dot com
CC: kito at gcc dot gnu.org, wilson at gcc dot gnu.org
  Target Milestone: ---
Target: riscv32-unknown-elf

Command line: bin/riscv64-unknown-elf-gcc -march=rv32imafc -mabi=ilp32f -O2
foo.c -S

==
 C Source
==
unsigned short foo(unsigned short crc) {
  crc ^= 0x4002;
  crc >>= 1;
  crc |= 0x8000;

  return crc;
}

=
 GCC asm
=
foo:
li  a5,-24576  #
addia5,a5,1# a5 = 0xa001
srlia0,a0,1
xor a0,a0,a5
sllia0,a0,16   # 
srlia0,a0,16   # redundant zero-extension
ret

===
 Ideal Code Generation 
===
foo:
li  a5,40960   #
addia5,a5,1# a5 = 0xa001
srlia0,a0,1
xor a0,a0,a5
ret

[Bug fortran/95631] Unable to redefine a literal with `-std=legacy'

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Note I think this is a bug in the RISCV backend that selects the small data
section for read only constants.  Rather than we want to support this
extension.

[Bug fortran/95631] Unable to redefine a literal with `-std=legacy'

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
PR 17887 was the same issue against g77.

[Bug fortran/95631] Unable to redefine a literal with `-std=legacy'

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Well we decided long time ago not to support that extension.
See PR 37974 and maybe even some g77 bug reports.

[Bug fortran/95631] New: Unable to redefine a literal with `-std=legacy'

[ma...@linux-mips.org]

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

Bug ID: 95631
   Summary: Unable to redefine a literal with `-std=legacy'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma...@linux-mips.org
  Target Milestone: ---

This is an interesting one.  This was mentioned by Eric Korpela here:
 as a
language peculiarity of up to at least FORTRAN 77.  Which is given the
following program:

C
C CHANGE THE VALUE OF 4
C

  CALL INC(4)
  WRITE (*, 30) 4
30FORMAT ('2+2=',I4)
  END

  SUBROUTINE INC(I)
  I = I + 1
  END

the supposed output is:

2+2=   5

Eric says:

'Most languages will give you some way to shoot yourself in the foot.  The
question is how much work do you need to do?  In FORTRAN the easiest method
was changing the value of a literal in a subroutine call.  It is standard
compliant behavior that goes back to at least FORTRAN IV.   Current
compliers and converters go to pains to make sure it still happens.  Not
sure if it is still present in f90 and beyond.  At least modern compilers
for other languages will give you a "potential foot shooting warning",
although in C++ that warning statement could take 200 kB.'

However when this program is built with GCC like this and run on an
`x86_64-linux-gnu' system, it causes SIGSEGV at the incrementation:

$ gfortran -Wall -W -Wextra -pedantic -std=legacy -O2 -g -o four four.f
$ ./four

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f0e8c9f5b90 in ???
#1  0x7f0e8c9f4dc5 in ???
#2  0x7f0e8c66683f in ???
#3  0x4011b1 in inc_
at /home/macro/src/four.f:11
#4  0x4011b1 in MAIN__
at /home/macro/src/four.f:5
#5  0x40109c in main
at /home/macro/src/four.f:8
$ 

The reason is the literal to be incremented (4) has been assigned to
`.rodata'.  There is no warning issued with the compilation either.
Conversely with the `riscv64-linux-gnu' target the literal gets assigned
to `.sdata' and the program executes as expected:

$ ./four
2+2=   5
$ 

but I take it it is by chance rather than design (no `.srodata' has been
defined, for obvious reasons).

My Fortran experience is so-so, but I did some language standard
examination and indeed it says something like:

"INTENT (INOUT) is not equivalent to omitting the INTENT attribute.  The
argument corresponding to an INTENT (INOUT) dummy argument always shall
be definable, while an argument corresponding to a dummy argument without
an INTENT attribute need be definable only if the dummy argument is
actually redefined."

which essentially means that the actual argument associated with I in the
call to INC here has to be a variable rather than a literal.

My understanding however is we still intend to support peculiar old
programs if built with the `-std=legacy' level.  If not, then perhaps we
ought to at least give that "potential foot shooting warning" Eric talks
about?

[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
to summarise.

This doesn't appear to be a bug in GCC (or clang) but something perhaps that
could benefit from a clarifying note in the std?

[Bug c++/95629] consteval operator== crashes compiler

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
preliminary analysis on pr95510 (which might be a dup) has the assert failing
because the first operand of the target expression is a CTOR not a call. 
However, accepting a CTOR there just leads to a fail later (that's as far as I
got).

[Bug c++/95629] consteval operator== crashes compiler

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-10

--- Comment #1 from Marek Polacek  ---
Thanks for the report.

95629.C: In function ‘int main()’:
95629.C:13:42: internal compiler error: in extract_call_expr, at cp/call.c:6634
   13 |   static_assert(hana{} == hana{});
  |  ^
0x93ae4c extract_call_expr(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/call.c:6634
0x939f5a build_new_op_1
/home/mpolacek/src/gcc/gcc/cp/call.c:6335
0x93abb8 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:6592
0xcb24b5 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/typeck.c:4280
0xb42759 cp_parser_binary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9777
0xb42c12 cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9914
0xb43462 cp_parser_constant_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:10208
0xb4d16e cp_parser_static_assert
/home/mpolacek/src/gcc/gcc/cp/parser.c:14741
0xb4b0ff cp_parser_block_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:13608
0xb4a594 cp_parser_declaration_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:13217
0xb4651c cp_parser_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11523
0xb47230 cp_parser_statement_seq_opt
/home/mpolacek/src/gcc/gcc/cp/parser.c:11889
0xb47114 cp_parser_compound_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11839
0xb5d175 cp_parser_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.c:23115
0xb5d499 cp_parser_ctor_initializer_opt_and_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.c:23166
0xb69008 cp_parser_function_definition_after_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:29062
0xb68e2f cp_parser_function_definition_from_specifiers_and_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:28978
0xb58384 cp_parser_init_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:20721
0xb4b57c cp_parser_simple_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:13785
0xb4b11e cp_parser_block_declaration
/home/mpolacek/src/gcc/gcc/cp/parser.c:13611

[Bug c++/10037] String literal has type `char*' when passed as parameter to function template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c/95630] New: rejects-valid on comparison of pointers to complete vs incomplete types in C11 mode

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 95630
   Summary: rejects-valid on comparison of pointers to complete vs
incomplete types in C11 mode
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase:

int f(int (*p)[], int (*q)[3]) { return p < q; }

This is a constraint violation in C99, but the relevant rule was removed in
C11. GCC still rejects in -std=c11 mode under -pedantic-errors.

[Bug bootstrap/95628] [11 regression] ICE in gcc build after r11-1181

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc*-*-*
 Ever confirmed|0   |1
  Build|powerpc64*-linux-gnu|powerpc*-*-*
   Host|powerpc64*-linux-gnu|powerpc*-*-*
 CC||dje at gcc dot gnu.org
   Last reconfirmed||2020-06-10
 Status|UNCONFIRMED |NEW

--- Comment #2 from David Edelsohn  ---
Confirmed.

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-1186-ga73051a0ea9ce8281e748a74dd924a6eb8fb3723
Author: Patrick Palka 
Date:   Wed Jun 10 17:37:53 2020 -0400

libstdc++: Fix some ranges algos optimizations [PR95578]

ranges::copy and a number of other ranges algorithms have unwrapping
optimizations for iterators of type __normal_iterator, move_iterator and
reverse_iterator.  But in the checks that guard these optimizations we
currently only test that the iterator of the iterator/sentinel pair has
the appropriate type before proceeding with the corresponding
optimization, and do not also test the sentinel type.

This breaks the testcase in this PR because this testcase constructs via
range adaptors a range whose begin() is a __normal_iterator and whose
end() is a custom sentinel type, and then performs ranges::copy on it.
From there we bogusly perform the __normal_iterator unwrapping
optimization on this iterator/sentinel pair, which immediately leads to
a constraint failure since the custom sentinel type does not model
sentinel_for.

This patch fixes this issue by refining each of the problematic checks
to also test that the iterator and sentinel types are the same before
applying the corresponding unwrapping optimization.  Along the way, some
code simplifications are made.

libstdc++-v3/ChangeLog:

PR libstdc++/95578
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Also check that the iterator and sentinel have the same type before
applying the unwrapping optimization for __normal_iterator.
Split the check into two, one for the first iterator/sentinel
pair and another for second iterator/sentinel pair.  Remove uses
of __niter_base, and remove uses of std::move on a
__normal_iterator.
* include/bits/ranges_algobase.h (__equal_fn): Likewise.
(__copy_or_move): Likewise.  Perform similar adjustments for
the reverse_iterator and move_iterator optimizations.  Inline
the checks into the if-constexprs, and use using-declarations to
make them less visually noisy.  Remove uses of __niter_wrap.
(__copy_or_move_backward): Likewise.
* testsuite/25_algorithms/copy/95578.cc: New test.
* testsuite/25_algorithms/copy_backward/95578.cc: New test.
* testsuite/25_algorithms/equal/95578.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/95578.cc: New
test.
* testsuite/25_algorithms/move/95578.cc: New test.
* testsuite/25_algorithms/move_backward/95578.cc: New test.

[Bug target/93571] PPC: fmr gets used instead of faster xxlor

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-10
 Target|powerpc-*-*-*   |powerpc*-*-*
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Interesting!  I tried it out, and indeed xxlor is 2 cycles while fmr is 6,
on p8 and p7, it's not just a documentation artefact.  Apparently fmr goes
through the FP pipeline (while it doesn't have to, of course -- well it
may be easier to implement "fmr." this way, even that isn't needed).

It does not normally matter very much, but still.  Confirmed.

[Bug c++/95629] New: consteval operator== crashes compiler

[tobias.bruell at gmail dot com]

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

Bug ID: 95629
   Summary: consteval operator== crashes compiler
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tobias.bruell at gmail dot com
  Target Milestone: ---

This also crashed in g++10 v10.1.0 for me.



#include 

template
struct hana {
  template
  consteval bool operator==(hana) {
return std::is_same_v;
  }
};

int main ()
{
  static_assert(hana{} == hana{});
}

[Bug bootstrap/95628] [11 regression] ICE in gcc build after r11-1181

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Build||powerpc64*-linux-gnu
   Host||powerpc64*-linux-gnu
 Target||powerpc64*-linux-gnu

--- Comment #1 from Bill Seurer  ---
commit 371cc683371bedb0e53ebcee0c0e89604a1e74b1
Author: Richard Biener 
Date:   Wed Jun 10 18:07:37 2020 +0200

avoid stmt-info allocation for debug stmts

The following avoids allocating stmt info structs for debug stmts.

2020-06-10  Richard Biener  

* tree-vect-loop.c (vect_determine_vectorization_factor):
Skip debug stmts.
(_loop_vec_info::_loop_vec_info): Likewise.
(vect_update_vf_for_slp): Likewise.
(vect_analyze_loop_operations): Likewise.
(update_epilogue_loop_vinfo): Likewise.
* tree-vect-patterns.c (vect_determine_precisions): Likewise.
(vect_pattern_recog): Likewise.
* tree-vect-slp.c (vect_detect_hybrid_slp): Likewise.
(_bb_vec_info::_bb_vec_info): Likewise.
* tree-vect-stmts.c (vect_mark_stmts_to_be_vectorized):
Likewise.

[Bug bootstrap/95628] New: [11 regression] ICE in gcc build after r11-1181

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95628
   Summary: [11 regression] ICE in gcc build after r11-1181
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:371cc683371bedb0e53ebcee0c0e89604a1e74b1, r11-1181

This appears to affect at the least all powerpc64 and AIX builds.  Even basic
non-bootstrap ones.

libtool: compile:  /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I/home/seurer/gcc/git/gcc-test/libgfortran
-iquote/home/seurer/gcc/git/gcc-test/libgfortran/io
-I/home/seurer/gcc/git/gcc-test/libgfortran/../gcc
-I/home/seurer/gcc/git/gcc-test/libgfortran/../gcc/config
-I/home/seurer/gcc/git/gcc-test/libgfortran/../libquadmath -I../.././gcc
-I/home/seurer/gcc/git/gcc-test/libgfortran/../libgcc -I../libgcc
-I/home/seurer/gcc/git/gcc-test/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -ffast-math -ftree-vectorize -funroll-loops
--param max-unroll-times=4 -g -O2 -MT matmul_i1.lo -MD -MP -MF
.deps/matmul_i1.Tpo -c
/home/seurer/gcc/git/gcc-test/libgfortran/generated/matmul_i1.c  -fPIC -DPIC -o
.libs/matmul_i1.o
during GIMPLE pass: vect
/home/seurer/gcc/git/gcc-test/libgfortran/generated/matmul_i1.c: In function
'matmul_i1':
/home/seurer/gcc/git/gcc-test/libgfortran/generated/matmul_i1.c:2446:1:
internal compiler error: Segmentation fault
 2446 | matmul_i1 (gfc_array_i1 * const restrict retarray,
  | ^
0x10b4cd3b crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:328
0x10ffa2e0 rs6000_density_test
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.c:4992
0x10ffa2e0 rs6000_finish_cost
/home/seurer/gcc/git/gcc-test/gcc/config/rs6000/rs6000.c:5102
0x10edce43 finish_cost
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.h:1400
0x10edce43 vect_compute_single_scalar_iteration_cost
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:1134
0x10edce43 vect_analyze_loop_2
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2041
0x10edce43 vect_analyze_loop(loop*, vec_info_shared*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:2583
0x10f0511f try_vectorize_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:894
0x10f05eaf vectorize_loops()
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1128
0x10d7b6c7 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [matmul_i1.lo] Error 1
make[3]: Leaving directory
`/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libgfortran'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libgfortran'
make[1]: *** [all-target-libgfortran] Error 2
make[1]: Leaving directory `/home/seurer/gcc/git/build/gcc-test'
make: *** [all] Error 2

[Bug target/94833] vec_first_match_index does not function as described in its description

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Carl Love :

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

commit r8-10304-gc6dce1d8083a2fdc94be167a2465db7fd837ccae
Author: Carl Love 
Date:   Wed Jun 10 16:12:08 2020 -0500

pr94833, fix vec_first_match_index for nulls

Backported patch from mainline.  Updated ChangeLog format
commit 24f68831d25bad739a6fe167a58b5b4c0c3cbf9a
Author: Carl Love 
Date:   Wed Apr 29 10:23:11 2020 -0500

Note the mainlin patch adds tests to the test case in mainline. 
The test
case does not exist in GCC 8.  Only the functional change in
gcc/config/rs6000/vsx.md was backported.

2020-06-10  Carl Love  

gcc/
PR target/94833
* config/rs6000/vsx.md (define_expand): Fix instruction generation
for
first_match_index_.

[Bug c++/95346] [coroutines] coroutine return-type should be initialised with rvalue if different from get_return_object() return-type

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5bb75908cbcc0d2ddfbadedfcd716b33694fd9c4

commit r10-8269-g5bb75908cbcc0d2ddfbadedfcd716b33694fd9c4
Author: Iain Sandoe 
Date:   Wed Jun 10 08:12:32 2020 +0100

coroutines: Fix missed ramp function return copy elision [PR95346].

Confusingly, "get_return_object ()" can do two things:
- Firstly it can provide the return object for the ramp function (as
  the name suggests).
- Secondly if the type of the ramp function is different from that
  of the get_return_object call, this is used as a single parameter
  to a CTOR for the ramp's return type.

In the first case we can rely on finish_return_stmt () to do the
necessary processing for copy elision.
In the second case, we should have passed a prvalue to the CTOR as
per the standard comment, but I had omitted the rvalue () call.  Fixed
thus.

gcc/cp/ChangeLog:

PR c++/95346
* coroutines.cc (morph_fn_to_coro): Ensure that the get-
return-object is constructed correctly; When it is not the
final return value, pass it to the CTOR of the return type
as an rvalue, per the standard comment.

gcc/testsuite/ChangeLog:

PR c++/95346
* g++.dg/coroutines/pr95346.C: New test.

(cherry picked from commit 4f2d05ef0142d269964e165c14c6f7fe4bdfd5a3)

[Bug rtl-optimization/51447] [4.7 Regression] global register variable definition incorrectly removed as dead code

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:06ef9c119c56568e5f77a5189aa382cb97c95a9e

commit r11-1185-g06ef9c119c56568e5f77a5189aa382cb97c95a9e
Author: Alexandre Oliva 
Date:   Wed Jun 10 17:56:36 2020 -0300

[PR51447] restore the global reg var before returning from main

A runtime system might legitimately hold in rbx a value expected to be
preserved across the call to main, but its use as a global register
variable stops main from preserving it.


for  gcc/testsuite/ChangeLog

PR rtl-optimization/51447
* gcc.c-torture/execute/pr51447.c (main): Preserve call-saved
register.

[Bug c++/95440] [coroutines] ICE with static members in promise_type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r11-1184-ga9eec9625ea7165292958be04899b057804192fb
Author: Iain Sandoe 
Date:   Wed Jun 10 00:15:28 2020 +0100

coroutines: Make call argument handling more robust [PR95440]

build_new_method_call is supposed to be able to handle a null
arguments list pointer (when the method has no parms).  There
were a couple of places where uses of the argument list pointer
were not defended against NULL.

gcc/cp/ChangeLog:

PR c++/95440
* call.c (add_candidates): Use vec_safe_length() for
testing the arguments list.
(build_new_method_call_1): Use vec_safe_is_empty() when
checking for an empty args list.

gcc/testsuite/ChangeLog:

PR c++/95440
* g++.dg/coroutines/pr95440.C: New test.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #32 from Qing Zhao  ---
> I would be more interested in overall statistics for your training scenario.
> How much can you get from ~1TB of data?

The profile directory generated by the new executable compiled with this patch
was 112G  in size, a lot smaller than previous 1TB. 
Though still bigger than what ICC generated.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #31 from Qing Zhao  ---
> The explanation is not sufficient.
You mean the following explanation: (in comment 18)

we tried the scheme that all the processes generate profiling feedback data to
the single directory, 
but looks like a lot of profiling info got lost, resulting bad performance
effect. 
We thought this might relate to the parallel running environment of our
application, 
then we switched to this current approach. 

Per the documentation of -fprofile-dir=path at:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html


"When an executable is run in a massive parallel environment, it is recommended
to save profile to different folders.
 That can be done with variables in path that are exported during run-time:
%p
process ID.

%q{VAR}
value of environment variable VAR"


> You mentioned that merging takes 24 hours, so I would expect that directing
> merging will same you quite some time.
Yes, that will help.
But at the same time, if the profiling feedback size can be reduced, then the
time for merging will be reduced too. 

> I'm still missing information like:
> - how long does it take the training run?
I have asked the question too (I don’t have permission to run that real app, so
I need to collect such info from other engineer), but no answer so far.
> - how many parallel runs do you have?
Over 1 processes are running at the same time. 
> - what's the average duration of a process?
I have asked the question too, no answer so far.

[Bug tree-optimization/95627] [11 Regression] ICE in rs6000_density_test at rs6000.c:4992 since r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||11.0
   Last reconfirmed||2020-06-10

[Bug tree-optimization/95627] New: [11 Regression] ICE in rs6000_density_test at rs6000.c:4992 since r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1

[marxin at gcc dot gnu.org]

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

Bug ID: 95627
   Summary: [11 Regression] ICE in rs6000_density_test at
rs6000.c:4992 since
r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Since the revision I see:

$ ./xgcc -B.
/home/mliska/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20070520-1.c
-fvar-tracking-assignments-toggle -ftree-loop-vectorize -O2
during GIMPLE pass: vect
/home/mliska/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20070520-1.c:
In function ‘ff_pred8x8_plane_c’:
/home/mliska/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20070520-1.c:4:6:
internal compiler error: Segmentation fault
4 | void ff_pred8x8_plane_c(uint8_t *src, int stride){
  |  ^~
0xe7e38f crash_signal
../../gcc/toplev.c:328
0x1259ce4 rs6000_density_test
../../gcc/config/rs6000/rs6000.c:4992
0x125a00c rs6000_finish_cost
../../gcc/config/rs6000/rs6000.c:5102
0x1150170 finish_cost
../../gcc/tree-vectorizer.h:1400
0x1153821 vect_compute_single_scalar_iteration_cost
../../gcc/tree-vect-loop.c:1134
0x11568fb vect_analyze_loop_2
../../gcc/tree-vect-loop.c:2041
0x11586ef vect_analyze_loop(loop*, vec_info_shared*)
../../gcc/tree-vect-loop.c:2583
0x119131c try_vectorize_loop_1
../../gcc/tree-vectorizer.c:894
0x1191d69 vectorize_loops()
../../gcc/tree-vectorizer.c:1128
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #30 from Martin Liška  ---
(In reply to Qing Zhao from comment #29)
> > 
> > And you still haven't replied to my essential question: Why can't you merge
> > profiles into one directory during run? Or at least merge to a reasonable
> > number of folders that you'll merge later?
> Comment #18 has my answer to the above question.

The explanation is not sufficient.
You mentioned that merging takes 24 hours, so I would expect that directing
merging will same you quite some time.
Feel free to provide some 'perf report' and I can make some suggestions based
on that.

I'm still missing information like:
- how long does it take the training run?
- how many parallel runs do you have?
- what's the average duration of a process?

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
So this is essentially:

struct S {
  S(const char *);
};

void foo(char *) = delete;
void foo(S);

void
g ()
{
  foo ("");
}

which compiles with clang++ but not with gcc.

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug c++/92102] identical requires-expression not subsumed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||godeffroy.valet at m4x dot org

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

[Bug c++/95626] [concepts] incorrect ambiguous overload with constraints "A && !B" vs "!B"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not a bug, subsumption doesn't work for !B

To make it work you need to define a concept, as in your second example.

This is explained in the C++20 draft by the note in [temp.constr.op] p5, which
was added by https://wg21.link/p1971r0#US111

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

[Bug c++/95560] [8/9/10/11 Regression] ICE in comptypes, at cp/typeck.c:1498 since r7-4206-g84ff4775d41b716c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
We have a CONST_DECL with null type -- it's the case when the underlying type
is not fixed, and finish_enum_value_list hasn't yet run.  A stopgap fix would
be

--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2762,7 +2762,9 @@ check_local_shadow (tree decl)
   enum opt_code warning_code;
   if (warn_shadow)
warning_code = OPT_Wshadow;
-  else if (same_type_p (TREE_TYPE (old), TREE_TYPE (decl))
+  else if ((TREE_TYPE (old)
+   && TREE_TYPE (decl)
+   && same_type_p (TREE_TYPE (old), TREE_TYPE (decl)))
   || TREE_CODE (decl) == TYPE_DECL
   || TREE_CODE (old) == TYPE_DECL
   || (!dependent_type_p (TREE_TYPE (decl))

[Bug c++/95626] New: [concepts] incorrect ambiguous overload with constraints "A && !B" vs "!B"

[godeffroy.valet at m4x dot org]

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

Bug ID: 95626
   Summary: [concepts] incorrect ambiguous overload with
constraints "A && !B" vs "!B"
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: godeffroy.valet at m4x dot org
  Target Milestone: ---

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

The following code fails to compile, giving an "ambiguous overload" error while
one function is clrearly more constrined than the other.


#include
template concept ConceptA=std::is_same::value;
template concept ConceptB=std::is_same::value;

template
requires (!ConceptB && ConceptA)
auto constexpr test__(A const& ){
}

template
requires (!ConceptB)
auto constexpr test__(A const& ){
}

int main(){
test__(2); // error
}


Note that the negation in "!ConceptB" is required to reproduced the issue.
In particular, the following code compiles.


#include
template concept ConceptA=std::is_same::value;
template concept ConceptB=!std::is_same::value;

template
requires (ConceptB && ConceptA)
auto constexpr test__(A const& ){
}

template
requires (ConceptB)
auto constexpr test__(A const& ){
}

int main(){
test__(2); // OK
}


Command used : g++ -std=c++2a -Wall -Wextra test.cpp
Output :
geometry/algebra/definition.test.cpp: In function 'int main()':
geometry/algebra/definition.test.cpp:23:10: error: call of overloaded
'test__(int)' is ambiguous
   23 |  test__(2);
  |  ^
geometry/algebra/definition.test.cpp:10:17: note: candidate: 'constexpr auto
test__(const A&) [with A = int]'
   10 |  auto constexpr test__(A const& ){
  | ^~
geometry/algebra/definition.test.cpp:14:17: note: candidate: 'constexpr auto
test__(const A&) [with A = int]'
   14 |  auto constexpr test__(A const& ){
  | ^~

Output of gcc -v :
Utilisation des specs internes.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Cible : x86_64-pc-linux-gnu
Configuré avec: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Modèle de thread: posix
Algorithmes de compression LTO supportés: zlib zstd
gcc version 10.1.0 (GCC)

[Bug middle-end/92939] missing -Wstringop-overflow on negative index from the end of array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.1.0
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |11.0
  Known to work||11.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
After r11-1183 GCC detects the overflow as expected:

$ gcc -O2 -S -Wall -Wextra -Wno-array-bounds pr92939.c

pr92939.c: In function ‘f’:
pr92939.c:12:8: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   12 |   p[1] = 0;// a[3]a[3] a[4]a[4]<< warns
  |   ~^~~
pr92939.c:8:8: note: at offset 3 to object ‘a’ with size 3 declared here
8 |   char a[3], *p = a + n;
  |^
pr92939.c:22:9: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   22 |   p[-2] = 0;   // a[-2]   a[-3]a[-1]   a[-2]   << should warn
  |   ~~^~~
pr92939.c:8:8: note: at offset -1 to object ‘a’ with size 3 declared here
8 |   char a[3], *p = a + n;
  |^

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[msebor at gcc dot gnu.org]

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

Bug 92939 Summary: missing -Wstringop-overflow on negative index from the end 
of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92939

   What|Removed |Added

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

[Bug tree-optimization/95353] [10 Regression] spurious -Wstringop-overflow writing to a trailing array plus offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|11.0|
  Known to work||11.0
Summary|[10/11 Regression] spurious |[10 Regression] spurious
   |-Wstringop-overflow writing |-Wstringop-overflow writing
   |to a trailing array plus|to a trailing array plus
   |offset  |offset

--- Comment #13 from Martin Sebor  ---
Fixed on trunk.

[Bug tree-optimization/95353] [10/11 Regression] spurious -Wstringop-overflow writing to a trailing array plus offset

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-1183-ga2c2cee92e5defff9bf23d3b1184ee96e57e5fdd
Author: Martin Sebor 
Date:   Wed Jun 10 12:00:08 2020 -0600

PR middle-end/95353 - spurious -Wstringop-overflow writing to a trailing
array plus offset

Also resolves:
PR middle-end/92939 - missing -Wstringop-overflow on negative index from
the end of array

gcc/ChangeLog:

PR middle-end/95353
PR middle-end/92939
* builtins.c (inform_access): New function.
(check_access): Call it.  Add argument.
(addr_decl_size): Remove.
(get_range): New function.
(compute_objsize): New overload.  Only use
compute_builtin_object_size
with raw memory function.
(check_memop_access): Pass new argument to compute_objsize and
check_access.
(expand_builtin_memchr, expand_builtin_strcat): Same.
(expand_builtin_strcpy, expand_builtin_stpcpy_1): Same.
(expand_builtin_stpncpy, check_strncat_sizes): Same.
(expand_builtin_strncat, expand_builtin_strncpy): Same.
(expand_builtin_memcmp): Same.
* builtins.h (check_nul_terminated_array): Declare extern.
(check_access): Add argument.
(struct access_ref, struct access_data): New structs.
* gimple-ssa-warn-restrict.c (clamp_offset): New helper.
(builtin_access::overlap): Call it.
* tree-object-size.c (decl_init_size): Declare extern.
(addr_object_size): Correct offset computation.
* tree-object-size.h (decl_init_size): Declare.
* tree-ssa-strlen.c (handle_integral_assign): Remove a call
to maybe_warn_overflow when assigning to an SSA_NAME.

gcc/testsuite/ChangeLog:

PR middle-end/95353
PR middle-end/92939
* c-c++-common/Wstringop-truncation.c: Remove an xfail.
* gcc.dg/Warray-bounds-46.c: Remove a bogus warning.
* gcc.dg/Wrestrict-9.c: Disable -Wstringop-overflow.
* gcc.dg/Wstringop-overflow-12.c: Remove xfails.
* gcc.dg/Wstringop-overflow-28.c: Same.
* gcc.dg/builtin-stringop-chk-4.c: Same.
* gcc.dg/builtin-stringop-chk-5.c: Same.
* gcc.dg/builtin-stringop-chk-8.c: Same.
* gcc.dg/strlenopt-74.c: Avoid buffer overflow.
* gcc.dg/Wstringop-overflow-34.c: New test.
* gcc.dg/Wstringop-overflow-35.c: New test.
* gcc.dg/Wstringop-overflow-36.c: New test.
* gcc.dg/Wstringop-overflow-37.c: New test.
* gcc.dg/Wstringop-overflow-38.c: New test.

[Bug middle-end/92939] missing -Wstringop-overflow on negative index from the end of array

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-1183-ga2c2cee92e5defff9bf23d3b1184ee96e57e5fdd
Author: Martin Sebor 
Date:   Wed Jun 10 12:00:08 2020 -0600

PR middle-end/95353 - spurious -Wstringop-overflow writing to a trailing
array plus offset

Also resolves:
PR middle-end/92939 - missing -Wstringop-overflow on negative index from
the end of array

gcc/ChangeLog:

PR middle-end/95353
PR middle-end/92939
* builtins.c (inform_access): New function.
(check_access): Call it.  Add argument.
(addr_decl_size): Remove.
(get_range): New function.
(compute_objsize): New overload.  Only use
compute_builtin_object_size
with raw memory function.
(check_memop_access): Pass new argument to compute_objsize and
check_access.
(expand_builtin_memchr, expand_builtin_strcat): Same.
(expand_builtin_strcpy, expand_builtin_stpcpy_1): Same.
(expand_builtin_stpncpy, check_strncat_sizes): Same.
(expand_builtin_strncat, expand_builtin_strncpy): Same.
(expand_builtin_memcmp): Same.
* builtins.h (check_nul_terminated_array): Declare extern.
(check_access): Add argument.
(struct access_ref, struct access_data): New structs.
* gimple-ssa-warn-restrict.c (clamp_offset): New helper.
(builtin_access::overlap): Call it.
* tree-object-size.c (decl_init_size): Declare extern.
(addr_object_size): Correct offset computation.
* tree-object-size.h (decl_init_size): Declare.
* tree-ssa-strlen.c (handle_integral_assign): Remove a call
to maybe_warn_overflow when assigning to an SSA_NAME.

gcc/testsuite/ChangeLog:

PR middle-end/95353
PR middle-end/92939
* c-c++-common/Wstringop-truncation.c: Remove an xfail.
* gcc.dg/Warray-bounds-46.c: Remove a bogus warning.
* gcc.dg/Wrestrict-9.c: Disable -Wstringop-overflow.
* gcc.dg/Wstringop-overflow-12.c: Remove xfails.
* gcc.dg/Wstringop-overflow-28.c: Same.
* gcc.dg/builtin-stringop-chk-4.c: Same.
* gcc.dg/builtin-stringop-chk-5.c: Same.
* gcc.dg/builtin-stringop-chk-8.c: Same.
* gcc.dg/strlenopt-74.c: Avoid buffer overflow.
* gcc.dg/Wstringop-overflow-34.c: New test.
* gcc.dg/Wstringop-overflow-35.c: New test.
* gcc.dg/Wstringop-overflow-36.c: New test.
* gcc.dg/Wstringop-overflow-37.c: New test.
* gcc.dg/Wstringop-overflow-38.c: New test.

[Bug tree-optimization/82608] missing -Warray-bounds on an out-of-bounds VLA index

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=50584
 Status|NEW |ASSIGNED

--- Comment #5 from Martin Sebor  ---
I'm working a fix for GCC 11 (it handles pr50584 as well).

[Bug tree-optimization/82608] missing -Warray-bounds on an out-of-bounds VLA index

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.0, 8.4.0, 9.3.0
   Last reconfirmed|2019-11-05 00:00:00 |2020-6-10

--- Comment #4 from Martin Sebor  ---
GCC 11 issues -Wuninitialized for all accesses but only because the test case
isn't careful enough to initialize the arrays before using them:

$ gcc -O2 -S -Wall -Wextra pr82608.c
pr82608.c: In function ‘idx_negative’:
pr82608.c:18:11: warning: ‘*()[-99]’ is used uninitialized
[-Wuninitialized]
   18 |   return a[-99]; // -Warray-bounds (since GCC 8)
  |  ~^
pr82608.c: In function ‘idx_cst_too_big’:
pr82608.c:25:11: warning: ‘*()[]’ is used uninitialized
[-Wuninitialized]
   25 |   return a[n + 1];   // missing _Warray-bounds
  |  ~^~~
pr82608.c: In function ‘idx_out_of_type_bounds’:
pr82608.c:31:11: warning: ‘*()[2147483647]’ is used uninitialized
[-Wuninitialized]
   31 |   return a[__INT_MAX__]; // missing -Warray-bounds
  |  ~^
pr82608.c: In function ‘idx_var_too_big’:
pr82608.c:37:11: warning: ‘*()[]’ is used uninitialized
[-Wuninitialized]
   37 |   return a[n + 1];   // missing -Warray-bounds
  |  ~^~~


With -Wno-uninitialized or with the arrays initialized GCC still doesn't detect
all the out-of-bounds accesses:

$ cat pr82608.c && gcc -O2 -S -Wall -Wextra pr82608.c
void sink (void*);

int f (unsigned n)
{
  if (n < 1 || n > 32)
n = 32;

  char vla[n];
  sink (vla);
  return vla[97];// missing -Warray-bounds
}
int idx_negative (void)
{ 
  int n = 4;
  char a[n];
  sink (a);
  return a[-99]; // -Warray-bounds (since GCC 8)
}

int idx_cst_too_big (void)
{
  int n = 4;
  char a[n];
  sink (a);
  return a[n + 1];   // missing _Warray-bounds
}

int idx_out_of_type_bounds (unsigned char n)
{
  char a[n];
  sink (a);
  return a[__INT_MAX__]; // missing -Warray-bounds
}

int idx_var_too_big (int n)
{ 
  char a[n];
  sink (a);
  return a[n + 1];   // missing -Warray-bounds
}
pr82608.c: In function ‘idx_negative’:
pr82608.c:17:11: warning: array subscript -99 is below array bounds of
‘char[ + 1]’ [-Warray-bounds]
   17 |   return a[-99]; // -Warray-bounds (since GCC 8)
  |  ~^
pr82608.c:15:8: note: while referencing ‘a.16’
   15 |   char a[n];
  |^
pr82608.c: In function ‘idx_cst_too_big’:
pr82608.c:25:11: warning: array subscript 5 is above array bounds of
‘char[ + 1]’ [-Warray-bounds]
   25 |   return a[n + 1];   // missing _Warray-bounds
  |  ~^~~
pr82608.c:23:8: note: while referencing ‘a.18’
   23 |   char a[n];
  |^

[Bug tree-optimization/82581] missing -Warray-bounds on writing past the end of a member array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||10.1.0, 11.0, 8.4.0, 9.3.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-10

--- Comment #1 from Martin Sebor  ---
Confirming with GCC 10 and 11.

[Bug tree-optimization/86889] s390x gcc build fails when configured with --disable-checking

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2018-08-09 00:00:00 |2020-6-10
  Known to fail||10.1.0, 11.0, 9.2.0

--- Comment #6 from Martin Sebor  ---
Reconfirming with GCC 10 and 11.  The output for the test case in comment #2
is:

pr86889.c: In function ‘d’:
pr86889.c:8:13: warning: array subscript -1 is below array bounds of ‘long
int[2]’ [-Warray-bounds]
8 | if (p->b[g])
  | ^~~
pr86889.c:1:17: note: while referencing ‘b’
1 | struct a { long b[2]; };
  | ^

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 88992 Summary: missing -Warray-bounds indexing into a zero-length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88992

   What|Removed |Added

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

[Bug middle-end/88992] missing -Warray-bounds indexing into a zero-length array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to work||10.1.0
   Target Milestone|--- |10.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Sebor  ---
Fixed in GCC 10.

[Bug c/95625] New: missing detail in -Waddress initializing a function argument

[msebor at gcc dot gnu.org]

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

Bug ID: 95625
   Summary: missing detail in -Waddress initializing a function
argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In a real-world scenario where the declaration of the called function was
removed from the call it took me a few minutes to understand what the warning
below was trying to tell me (I passed the address to the wrong argument):

$ cat t.C && gcc -O2 -S -Wall -Wextra t.C
void f (int, int, int, bool = false, int * = 0);

void g (int i)
{
  f (1, 2, 3, );
}
t.C: In function ‘void g(int)’:
t.C:5:15: warning: the address of ‘i’ will never be NULL [-Waddress]
5 |   f (1, 2, 3, );
  |   ^~

Clang issues an almost identical message (so not much better) but the name of
the warning option it prints makes the problem much clearer:

t.C:5:16: warning: address of 'i' will always evaluate to 'true'
[-Wpointer-bool-conversion]
  f (1, 2, 3, );
  ~^
1 warning generated.


Printing a note pointing to the called function and referencing the argument to
which the address is passed would be even better.

The test case is C++ but a similar improvement applies to the C front end.

[Bug debug/95576] [11 Regression] -fcompare-debug failure with -O3 -fno-tree-forwprop -fvect-cost-model=unlimited

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug debug/95576] [11 Regression] -fcompare-debug failure with -O3 -fno-tree-forwprop -fvect-cost-model=unlimited

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:36e95a9e539a08275a0a6ef542a7fae5baa5710f

commit r11-1180-g36e95a9e539a08275a0a6ef542a7fae5baa5710f
Author: Richard Biener 
Date:   Wed Jun 10 15:16:23 2020 +0200

tree-optimization/95576 - fix compare-debug issue with SLP vectorization

The following avoids leading debug stmts in BB vectorizer regions.

2020-06-10  Richard Biener  

PR tree-optimization/95576
* tree-vect-slp.c (vect_slp_bb): Skip leading debug stmts.

* g++.dg/vect/pr95576.cc: New testcase.

[Bug target/95523] aarch64:ICE in register_tuple_type，at config/aarch64/aarch64-sve-builtins.cc:3434

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug target/95523] aarch64:ICE in register_tuple_type，at config/aarch64/aarch64-sve-builtins.cc:3434

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-1179-gb5cebc9ab7f6ab47067dc04cae17bf9921a62a18
Author: z00219097 
Date:   Wed Jun 10 16:58:51 2020 +0100

aarch64: Fix an ICE in register_tuple_type [PR95523]

When registering the tuple type in register_tuple_type, the
TYPE_ALIGN (tuple_type) will be changed by -fpack-struct=n. We need to
maintain natural alignment in handle_arm_sve_h.

2020-06-10  Haijian Zhang  

gcc/
PR target/95523
* config/aarch64/aarch64-sve-builtins.h
(sve_switcher::m_old_maximum_field_alignment): New member.
* config/aarch64/aarch64-sve-builtins.cc
(sve_switcher::sve_switcher): Save maximum_field_alignment in
m_old_maximum_field_alignment and clear maximum_field_alignment.
(sve_switcher::~sve_switcher): Restore maximum_field_alignment.

gcc/testsuite/
PR target/95523
* gcc.target/aarch64/sve/pr95523.c: New test.

[Bug c++/95562] [10/11 Regression] ICE when using noexcept depending on boolean template parameter since r10-1280-g78f7607db4c53f8c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/95562] [10/11 Regression] ICE when using noexcept depending on boolean template parameter since r10-1280-g78f7607db4c53f8c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:977a173c196dc5ba5ac2e1b890083beb0451cf60

commit r10-8268-g977a173c196dc5ba5ac2e1b890083beb0451cf60
Author: Marek Polacek 
Date:   Wed Jun 10 10:49:08 2020 -0400

c++: Fix ICE with delayed parsing of noexcept-specifier [PR95562]

Here we ICE because a DEFERRED_PARSE expression leaked to tsubst_copy.
We create these expressions for deferred noexcept-specifiers in
cp_parser_save_noexcept; they are supposed to be re-parsed in
cp_parser_late_noexcept_specifier.  In this case we never got around
to re-parsing it because the noexcept-specifier was attached to a
pointer to a function, not to a function declaration.  But we should
not have delayed the parsing here in the first place; we already
avoid delaying the parsing for alias-decls, typedefs, and friend
function declarations.  (Clang++ also doesn't delay the parsing
for pointers to function.)

gcc/cp/ChangeLog:

PR c++/95562
* parser.c (cp_parser_direct_declarator): Clear
CP_PARSER_FLAGS_DELAY_NOEXCEPT if the declarator kind is not
cdk_id.

gcc/testsuite/ChangeLog:

PR c++/95562
* g++.dg/cpp0x/noexcept60.C: New test.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[iains at gcc dot gnu.org]

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

--- Comment #26 from Iain Sandoe  ---
(In reply to Rafael Avila de Espindola from comment #25)
> (In reply to CVS Commits from comment #24)
> > The master branch has been updated by Iain D Sandoe :

> I can confirm that the reduced testcase is now fixed. 

the patch was intended to address the UBSAN failure identified - fixing the
asan ones was incidental.

>On the original test I still get  runtime error: member call on misaligned 
>address 0x0003 for type
> 'struct future', which requires 8 byte alignment
> 
> I will try reducing the testcase again and upload the results.

thanks, that's very helpful.

On the test cases in the testsuite, I saw three fails that looked like false
positives (because the asan logic doesn't know about things being moved into
the coroutine frame).  However, the error you report above seems more likely
related to some incorrect dtor (there are some known issues there too...)

In general, debug-related support is pretty much non-existent in coroutines
impls (other than in MSVC).  I have some ideas about how to make this better on
GCC - and I suspect that will help deal with support for the sanitisers.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[rafael at espindo dot la]

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

--- Comment #25 from Rafael Avila de Espindola  ---
(In reply to CVS Commits from comment #24)
> The master branch has been updated by Iain D Sandoe :

Thanks!

I can confirm that the reduced testcase is now fixed. On the original test I
still get

 runtime error: member call on misaligned address 0x0003 for type
'struct future', which requires 8 byte alignment

I will try reducing the testcase again and upload the results.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #29 from Qing Zhao  ---
> 
> And you still haven't replied to my essential question: Why can't you merge
> profiles into one directory during run? Or at least merge to a reasonable
> number of folders that you'll merge later?
Comment #18 has my answer to the above question.

[Bug c++/95562] [10/11 Regression] ICE when using noexcept depending on boolean template parameter since r10-1280-g78f7607db4c53f8c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:4fed5d5dd85e3f5d812d125f692351646a0417cb

commit r11-1176-g4fed5d5dd85e3f5d812d125f692351646a0417cb
Author: Marek Polacek 
Date:   Tue Jun 9 18:08:45 2020 -0400

c++: Fix ICE with delayed parsing of noexcept-specifier [PR95562]

Here we ICE because a DEFERRED_PARSE expression leaked to tsubst_copy.
We create these expressions for deferred noexcept-specifiers in
cp_parser_save_noexcept; they are supposed to be re-parsed in
cp_parser_late_noexcept_specifier.  In this case we never got around
to re-parsing it because the noexcept-specifier was attached to a
pointer to a function, not to a function declaration.  But we should
not have delayed the parsing here in the first place; we already
avoid delaying the parsing for alias-decls, typedefs, and friend
function declarations.  (Clang++ also doesn't delay the parsing
for pointers to function.)

gcc/cp/ChangeLog:

PR c++/95562
* parser.c (cp_parser_direct_declarator): Clear
CP_PARSER_FLAGS_DELAY_NOEXCEPT if the declarator kind is not
cdk_id.

gcc/testsuite/ChangeLog:

PR c++/95562
* g++.dg/cpp0x/noexcept60.C: New test.

[Bug c++/95559] GCC accepts "too many braces around scalar initializer " in the version of 6.1 - 8.4

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #6 from Marek Polacek  ---


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

[Bug c++/88572] error: braces around scalar initializer - should be a warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||haoxintu at gmail dot com

--- Comment #19 from Marek Polacek  ---
*** Bug 95559 has been marked as a duplicate of this bug. ***

[Bug c++/95559] GCC accepts "too many braces around scalar initializer " in the version of 6.1 - 8.4

[haoxintu at gmail dot com]

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

--- Comment #5 from Haoxin Tu  ---
(In reply to Marek Polacek from comment #4)
> That's the same case, initializing an int with {{}}.  GCC 8 compiled the
> second testcase, but that was fixed in r269045.

Ok, got it. At least this was a bug, can you change the status to DUPLICATE if
you are convenience? Thank you so much~

[Bug c++/95559] GCC accepts "too many braces around scalar initializer " in the version of 6.1 - 8.4

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
That's the same case, initializing an int with {{}}.  GCC 8 compiled the second
testcase, but that was fixed in r269045.

[Bug libstdc++/95624] std::put_time() and std::strftime() don't recognize %e

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||86976
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-10
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
strftime is nothing to do with GCC, that comes from MinGW and/or the Windows
CRT.

The std::put_time function uses std::time_put which doesn't implement any of
the new conversion specifiers added in C99, including %e.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976
[Bug 86976] [meta-bug] Issues with std::time_get, std::time_put etc.

[Bug target/95621] Add CET(PTA_SHSTK) to march=tigerlake

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot 
com

--- Comment #1 from H.J. Lu  ---
I don't think PTA_SHSTK is needed since -mshstk is only used to enable CET
in run-time library which is backward compatible.  GCC run-time libraries
are compiled with -mshstk when CET is enabled.  As for IBT, ENDBR is
generated with -fcf-protection for all processors.

The whole CET thing is backward compatible.  We don't need to add PTA_SHSTK
to Tiger Lake.

[Bug debug/95576] [11 Regression] -fcompare-debug failure with -O3 -fno-tree-forwprop -fvect-cost-model=unlimited

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
It's also odd vectorization.

t.c:14:3: note:   Detected interleaving store this_3(D)->D.2378._vptr.S and
_1->_vptr.S
t.c:14:3: note:   Queuing group with duplicate access for fixup
t.c:14:3: missed:   not consecutive access _6 = _1->s;
t.c:14:3: note:   Detected interleaving store of size 1
t.c:14:3: note: this_3(D)->D.2378._vptr.S =   [(void
*)&_ZTV1T + 16B];
t.c:14:3: note:   Detected interleaving store of size 1
t.c:14:3: note: _1->_vptr.S =   [(void *)&_ZTV1S +
16B];

so we split the group into two of size one and vectorizing with V1DImode.  But
that's something else to fix I guess.

[Bug libstdc++/95624] New: std::put_time() and std::strftime() don't recognize %e

[karen.arutyunov at gmail dot com]

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

Bug ID: 95624
   Summary: std::put_time() and std::strftime() don't recognize %e
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: karen.arutyunov at gmail dot com
  Target Milestone: ---

Created attachment 48714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48714=edit
Test program

For MinGW build of GCC std::put_time() and std::strftime() don't recognize the
%e specifier, converting it into the empty string.

The attached program demonstrates the issue:

$ g++ -std=c++2a test.cxx
$ ./a.exe
0 ''
'CD'

While the expected output for June 10 should be:

4 'A10B'
'C10D'

In case this information helps, the same program produces the correct output on
the same host if built with MSVC.

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||11.0
  Known to fail||10.1.0, 8.4.0, 9.3.0

--- Comment #12 from Martin Liška  ---
Fixed on master so far.

[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-1145-g8b6731e674c76cb48a417f2eef74ced92a17f469
Author: Martin Liska 
Date:   Tue May 19 16:57:56 2020 +0200

Add missing store in emission of asan_stack_free.

gcc/ChangeLog:

2020-05-19  Martin Liska  

PR sanitizer/94910
* asan.c (asan_emit_stack_protection): Emit
also **SavedFlagPtr(FakeStack, class_id) = 0 in order to release
a stack frame.

[Bug c++/95623] #include fails to define this_thread

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Your compiler is configured with "Thread model: win32" and that doesn't support
std::thread, so the  header doesn't define anything.

[Bug c++/95623] New: #include fails to define this_thread

[jesus at refusetoown dot com]

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

Bug ID: 95623
   Summary: #include  fails to define this_thread
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jesus at refusetoown dot com
  Target Milestone: ---

seeker2 "The bug in gcc is that #include  fails fails fails fails if
evil if evil if evil if good if good if good, if so, if so, if so"
the bug in gcc is that #include  fails fails fails fails if evil if
evil if evil if good if good if good, if so, if so, if so
Consistent with 46 fidelities.

The compiler is on windows 10, with MinGW-W64 used with -std=c++11 or c++17
they both fail.

C:\Users\Larry\Documents\safe>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Program\
Files/mingw-w64/x86_64-8.1.0-win32-seh-rt_v6-rev0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/8.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-8.1.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-bootstrap --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2
--with-libiconv --with-system-zlib
--with-gmp=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw810/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-win32-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/include
-I/c/mingw810/prerequisites/x86_64-zlib-static/include
-I/c/mingw810/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident -L/c/mingw810/x86_64-810-win32-seh-rt_v6-rev0/mingw64/opt/lib
-L/c/mingw810/prerequisites/x86_64-zlib-static/lib
-L/c/mingw810/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: win32
gcc version 8.1.0 (x86_64-win32-seh-rev0, Built by MinGW-W64 project)

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[wilco at gcc dot gnu.org]

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

--- Comment #44 from Wilco  ---
(In reply to Jiu Fu Guo from comment #43)
> To handle vectorization for this kind of code, it needs to overcome the hard
> issue mentioned in comment #5: the loop has 2 exits.

Yes and that also implies vector loads are unsafe unless they are non-faulting.
Few ISAs have such support.

[Bug libstdc++/95606] [10/11 regression] conflicts with std::is_constructible

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
And probably one or both of the basic_json and json_ref constructors should be
explicit, so that you can't implicitly convert them both to each other.

[Bug libstdc++/95606] [10/11 regression] conflicts with std::is_constructible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
I think this is not a bug in GCC. A specialization of std::swap still depends
on the signature of the primary template, and that primary template requires
the argument types to be swappable. The is_swappable trait requires
move_constructible, and that requires complete types. Checking
is_move_constructible will perform overload resolution which considers
the basic_json(json_ref) constructor, which tries to see if json_ref can be
constructed from a basic_json rvalue, which checks the constraint on the
json_ref constructor, which depends on basic_json, which is incomplete at this
point.

The json code is incorrect and should be fixed.

The std::swap specialization is wrong and should be replaced by a normal
(non-template) overload in the same namespace as the json type:

void swap(json&, json&) noexcept;

The json_ref constructor should be constrained to avoid recursive
instantiations with incomplete types, e.g.

template
  using is_not = std::is_same>, U>;

class json_ref
{
  public:
template ::value>,
  typename = std::enable_if_t::value>,
  bool = std::is_constructible::value>
json_ref(T &&){}
};

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[guojiufu at gcc dot gnu.org]

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

--- Comment #43 from Jiu Fu Guo  ---
To handle vectorization for this kind of code, it needs to overcome the hard
issue mentioned in comment #5: the loop has 2 exits.

[Bug libstdc++/95606] [10/11 regression] conflicts with std::is_constructible

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The testcase is:

#include 
#include 

template
class basic_json;

using json = basic_json;

class json_ref
{
  public:
template ::value>
json_ref(T &&){}
};

template
class basic_json
{
  public:
basic_json(json_ref) {}
};

namespace std {

template<>
void swap(json&, json&) noexcept {}

}

int main() {}


This fails when compiled with -std=gnu++17 or later.

Specializing std::swap like this is wrong (and in C++20 explicitly results in
undefined behaviour). Replacing it with a normal overload in the same namespace
as the type avoids the error.

Do you have an example that doesn't involve a bogus specialization in namespace
std?

[Bug middle-end/95622] force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta-2.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Dunno, perhaps there is a better way than force_output, how exactly we
represent
void *refs[] __attribute__((used)) = { , ,  };
where we say the array can't be optimized away and thus the referenced vars
can't be optimized away?  Does that also prevent such an optimization?
For these vars, all we want to ensure is that the vars aren't optimized away,
but don't need to derive from that that some other code could be accessing
those vars indirectly.
Or, shall we support putting NULL (or some other magic value) into the tables
on the host or offload side if those vars have been optimized away completely
on the host (or offload) sides?  At least when not doing the not yet supported
offloading from offload device back to host, perhaps a variable optimized away
completely on the host will mean we can't every lookup such variable's address
and so nothing needs to be recorded in the splay trees.  But, if something is
completely unused on the offload side but used on the host side, one can still
try to e.g. map those variables and should get the address of the device var
even if it is otherwise unused.

[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Any update on the failing target1.f90 test-case?

[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #6 from Martin Liška  ---
(In reply to Paul Thomas from comment #5)
> (In reply to CVS Commits from comment #4)
> > The master branch has been updated by David Malcolm :
> > 
> > https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25
> > 
> > commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25
> > Author: David Malcolm 
> > Date:   Wed Mar 4 12:10:34 2020 -0500
> > 
> > analyzer: add regression test for fixed ICE [PR94028]
> > 
> > The C++ reproducer for PR analyzer/94028 generates a similar ICE
> > to that of the Fortran reproducer for PR analyzer/93993 and, like
> > it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa.
> > 
> > This patch adds the C++ reproducer as a regression test.
> > 
> > gcc/testsuite/ChangeLog:
> > PR analyzer/94028
> > * g++.dg/analyzer/pr94028.C: New test.
> 
> FAIL: gfortran.dg/analyzer/pr93993.f90   -O  (test for excess errors)
> Excess errors:
> /home/pault/gitsources/gcc/gcc/testsuite/gfortran.dg/analyzer/pr93993.f90:21:
> 0: Warning: leak of 'tm' [CWE-401] [-Wanalyzer-malloc-leak]
> 
> On current 10-branch. FC31/x86_64
> 
> Paul

@David: The test-case is still failing. Are you planning to fix it or may I
mark it as xfail?

[Bug middle-end/95622] New: force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta-2.c

[burnus at gcc dot gnu.org]

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

Bug ID: 95622
   Summary: force_output flag on a variable prevents optimization
/ regresses
c-c++-common/goacc/kernels-alias-ipa-pta-2.c
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization, openacc, openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

The following only shows up as FAIL in the testsuite if  ENABLE_OFFLOAD  is
true, even though it is only a compile-time test.   [Hence, it can make sense
to not only "make check-target-libgomp" with an offloading compiler but also
gcc/.]

Somewhat similar to PR 68773.

The testcase: c-c++-common/goacc/kernels-alias-ipa-pta-2.c
…
  {
a[0] = 0;
b[0] = 1;
c[0] = a[0];
  }
…

Without ENABLE_OFFLOAD or before
r11-1075-g1c0fdaf79e3618fd7512608a2e5c62b6b306e9e8 (for PR94848 + PR95551):

  MEM[(unsigned int *)_5] = 0;  // a[0] = 0
  MEM[(unsigned int *)_4] = 1;  // b[0] = 1
  MEM[(unsigned int *)_3] = 0;  // c[0] = a[0]

With r11-1075 + offloading compiler, force_output is on offloading variables
(to ensure they are not optimized away), the last line becomes

  _8 = MEM[(unsigned int *)_5];  // _8 = a[0]
  MEM[(unsigned int *)_3] = _8;  // c[0] = _8

Expected: force_output does not affect the optimization. (Especially as "a"
cannot be optimized away as it is also used for "copyout".)

[A very well optimizing compiler could see that nothing uses a/b/c after the
target section and could replace the whole function body by "{ }"…]

[Bug tree-optimization/95569] ICE in tmmark：verify_ssa failed

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-1142-g6d9ef0621f8e1aaafd458dba1a8b5476e655b479
Author: Qian Chao 
Date:   Wed Jun 10 04:46:56 2020 -0400

tmmark: verify_ssa failed [PR95569]

This patch fixes a latent bug exposed by
eb72dc663e9070b281be83a80f6f838a3a878822.
See the discussion on the bug for details.

Bootstrapped and regtested on aarch64-linux-gnu. No new fails introduced.

2020-06-10  Qian Chao  

gcc/ChangeLog:

PR tree-optimization/95569
* trans-mem.c (expand_assign_tm): Ensure that rtmp is marked
TREE_ADDRESSABLE.

gcc/testsuite/ChangeLog:

PR tree-optimization/95569
* gcc.dg/tm/pr95569.c: New test.

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #23 from Martin Liška  ---
We've mitigated the majority of the collisions and I've added a sanitization
checking. I'll keep the issue opened and I'm unassigning.

[Bug sanitizer/95617] [11 regression] many excess errors starting with r11-1117

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
And also gcc110.fsffrance.org is happy. Please reopen if the issue still
exists.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #28 from Martin Liška  ---
(In reply to Qing Zhao from comment #26)
> > --- Comment #25 from Martin Liška  ---
> >> I will try to get more data on our real application. 
> >> 
> >> one question: why not just delete the entire records whose counter is zero
> >> and delete the entire file whose counter is zero?
> > 
> > Because we need to distinguish in between situations where a function was
> > really not executed (counter == 0) and the situation where we miss profile 
> > for
> > a function.
> Understood.  However, is it possible to just provide an option for the user
> to choose
> to just delete all the zero records and files in order to save more space?

It can be possible to add option for that, yes. To be honest, I don't have much
time to work on that right now.

And you still haven't replied to my essential question: Why can't you merge
profiles into one directory during run? Or at least merge to a reasonable
number of folders that you'll merge later?

Note that you can use -fprofile-dir=path with:
%q{VAR}
value of environment variable VAR

which can be used to multiplex into multiple folders for concurrent processes.


> > 
> > How exactly do you merge profiles? Do you run parallel invocation which can
> > take log2(N)?
> We run serial merge adding one at a time right now. 
> Is it possible for gcov-merge to add a new functionality to automatically
> merge complete
> Set of subdirectories?

One would need to run it in multiple threads and I've made a Python script
prototype:
https://github.com/marxin/script-misc/blob/master/gcov-merge-parallel.py

So yes, current GCOV streaming is far from being optimal, but with a small
tweaks we can make it working for your scenario..

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #27 from Martin Liška  ---
(In reply to qinzhao from comment #24)
> with the patch added to gcc11, I tested it with the small testing case, and
> got the following data:
> 

I would be more interested in overall statistics for your training scenario.
How much can you get from ~1TB of data?

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-1141-gdc6d15eaa23cbae1468a6ef92371b1c856c14819
Author: Martin Liska 
Date:   Tue Dec 10 19:41:08 2019 +0100

Add gcc_assert that _options are not dirty modified.

gcc/ChangeLog:

2020-03-20  Martin Liska  

PR tree-optimization/92860
* optc-save-gen.awk: Generate new function cl_optimization_compare.
* opth-gen.awk: Generate declaration of the function.

gcc/c-family/ChangeLog:

2020-03-20  Martin Liska  

PR tree-optimization/92860
* c-attribs.c (handle_optimize_attribute):
Save global options and compare it after parsing of function
attribute.
* c-pragma.c (opt_stack::saved_global_options): New field.
(handle_pragma_push_options): Save global_options.
(handle_pragma_pop_options): Compare them after pop.

[Bug c++/95607] Inconsistent treating of default argument instantiation as immediate context

[akrzemi1 at gmail dot com]

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

--- Comment #1 from Andrzej Krzemienski  ---
Note that the behavior of GCC cannot be called non conformant with the C++
Standard, as the Standard is very unclear: it does not define the term
"immediate context", but later refers to it.

The problem reported here is that GCC appears not to have a self-consistent
behavior. If this is considered "working as designed", I would appreciate a
description of the mechanism and the logic behind it, so that the users can
predict what will happen in different situations/contexts.

[Bug lto/95620] [10/11 Regression] relocation truncated to fit: R_X86_64_PC32 against `.bss'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2020-06-10
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
So it's really problem as with LTO we don't put the large array into .lbss
section:

LTO:
.file   ""
.text
.local  a
.comm   a,2830270464,32
.local  b
.comm   b,4,4

non-LTO mode:

.globl  a
.section.lbss,"aw"
.align 32
.type   a, @object
.size   a, 2830270464
a:
.zero   2830270464

So the symbol goes from .lbss section to .data section as LTO makes the symbol
local.

[Bug sanitizer/95617] [11 regression] many excess errors starting with r11-1117

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

[Bug libstdc++/95606] [10/11 regression] conflicts with std::is_constructible

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
   Keywords||rejects-valid

[Bug c++/95618] [11 Regression] ICE in remap_type_1, at tree-inline.c:607

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Fixed on master with r11-1122-gef41587df9839d1d.

[Bug target/95621] Add CET(PTA_SHSTK) to march=tigerlake

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-10
 Status|UNCONFIRMED |NEW
 CC||hjl at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug lto/95620] [10/11 Regression] relocation truncated to fit: R_X86_64_PC32 against `.bss'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
So we basically change assembly in the following way:

$ diff -u good.s bad.s -U999
--- good.s  2020-06-09 23:37:35.755366723 +0200
+++ bad.s   2020-06-09 23:37:36.771361476 +0200
@@ -1,13 +1,13 @@
.file   ""
.text
.globl  main
.type   main, @function
 main:
 .LFB1:
movlb(%rip), %edx
 .LFE1:
.size   main, .-main
-   .local  b
-   .comm   b,4,4
.local  a
.comm   a,2430270464
+   .local  b
+   .comm   b,4,4

and logically the relocation for 'b(%rip)' now has to go over the huge 'a'
array.
It's invalid to me, I would recommend using -mcmodel=large.

[Bug target/95621] New: Add CET(PTA_SHSTK) to march=tigerlake

[lili.cui at intel dot com]

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

Bug ID: 95621
   Summary: Add CET(PTA_SHSTK) to march=tigerlake
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lili.cui at intel dot com
  Target Milestone: ---

For intel TigerLake need support CET, add PTA_SHSTK to march=tigerlake.