[Bug target/71321] [6 Regression] x86: worse code for uint8_t % 10 and / 10

2020-08-09 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71321

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:71197a5d13d0b540a9b5efe7ae2512d76386e9d1

commit r11-2621-g71197a5d13d0b540a9b5efe7ae2512d76386e9d1
Author: Roger Sayle 
Date:   Sun Aug 9 23:14:58 2020 +0100

middle-end: Correct calculation of mul_widen_cost and mul_highpart_cost.

This patch fixes a subtle bug in the depths of GCC's synth_mult,
where the middle-end queries whether (how well) the target supports
widening and highpart multiplications by calling targetm.rtx_costs.
The code in init_expmed and init_expmed_one_mode iterates over various
RTL patterns querying the cost of each.  To avoid generating & garbage
collecting too much junk, it reuses the same RTL over and over, but
adjusting the modes between each call.

Alas this reuse of state is a little fragile, and at some point a
change to init_expmed_one_conv has resulted in the state (mode of
a register) being changed, but not reset before being used again.

Using the old software engineering/defensive programming maxim of
"why fix a bug just once, if it can be fixed in multiple places",
this patch both restores the original value in init_expmed_one_conv,
and also sets it to the expected value in init_expmed_one_mode.
This should hopefully signal the need to be careful of invariants for
anyone modifying this code in future.

2020-08-09  Roger Sayle  

gcc/ChangeLog
* expmed.c (init_expmed_one_conv): Restore all->reg's mode.
(init_expmed_one_mode): Set all->reg to desired mode.

gcc/testsuite/ChangeLog
PR target/71321
* gcc.target/i386/pr71321.c: Check that the code doesn't use
the 4B zero displacement lea, not that it uses lea.

[Bug target/96446] ICE when spilling an MMA accumulator

2020-08-08 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:38b240a9dc7186a51e577dd3ff73c31af3cfb0ab

commit r10-8594-g38b240a9dc7186a51e577dd3ff73c31af3cfb0ab
Author: Peter Bergner 
Date:   Thu Aug 6 10:03:03 2020 -0500

rs6000: Don't ICE when spilling an MMA accumulator

When we spill an accumulator that has a known zero value, LRA will emit
a new (set (reg:PXI ...) 0) insn, but it does not use the mma_xxsetaccz
pattern to do it, leading to an unrecognized insn ICE.  The solution here
is to move the xxsetaccz instruction into the movpxi pattern and have the
xxsetaccz pattern call the move pattern.

2020-08-06  Peter Bergner  

gcc/
PR target/96446
* config/rs6000/mma.md (*movpxi): Add xxsetaccz generation.
Disable split for zero constant source operand.
(mma_xxsetaccz): Change to define_expand.  Call gen_movpxi.

gcc/testsuite/
PR target/96446
* gcc.target/powerpc/pr96446.c: New test.

(cherry picked from commit 9c376d1c166e7c8b10bba6f1675d2471ffe8447f)

[Bug target/96530] MMA built-ins reject typedefs of MMA types

2020-08-08 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96530

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r11-2616-ge2882e76089cecdc268d0835c54cabfa80b5b0be
Author: Peter Bergner 
Date:   Sat Aug 8 11:54:48 2020 -0500

rs6000: MMA built-ins reject typedefs of MMA types

We do not allow conversions between the MMA types and other types.
However, we are being too strict in not matching MMA types with
typdefs of those types.  Use TYPE_CANONICAL to see through the
types to their canonical types before comparing them.

2020-08-08  Peter Bergner  

gcc/
PR target/96530
* config/rs6000/rs6000.c (rs6000_invalid_conversion): Use canonical
types for type comparisons.  Refactor code to simplify it.

gcc/testsuite/
PR target/96530
* gcc.target/powerpc/pr96530.c: New test.

[Bug fortran/93553] ICE in scan_omp_1_op, at omp-low.c:3485

2020-08-08 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:676b5525e8333005bdc1c596ed086f1da27a450f

commit r11-2615-g676b5525e8333005bdc1c596ed086f1da27a450f
Author: Jakub Jelinek 
Date:   Sat Aug 8 11:10:30 2020 +0200

openmp: Handle clauses with gimple sequences in
convert_nonlocal_omp_clauses properly

If the walk_body on the various sequences of reduction, lastprivate and/or
linear
clauses needs to create a temporary variable, we should declare that
variable
in that sequence rather than outside, where it would need to be privatized
inside of
the construct.

2020-08-08  Jakub Jelinek  

PR fortran/93553
* tree-nested.c (convert_nonlocal_omp_clauses): For
OMP_CLAUSE_REDUCTION, OMP_CLAUSE_LASTPRIVATE and OMP_CLAUSE_LINEAR
save info->new_local_var_chain around walks of the clause gimple
sequences and declare_vars if needed into the sequence.

2020-08-08  Tobias Burnus  

PR fortran/93553
* testsuite/libgomp.fortran/pr93553.f90: New test.

[Bug tree-optimization/96424] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 23); or ICE: Segmentation fault (in expand_omp_for_init_vars/contains_struct_check)

2020-08-08 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96424

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:87d6dae308d604bad111b1c0bfea7835888eed8d

commit r11-2614-g87d6dae308d604bad111b1c0bfea7835888eed8d
Author: Jakub Jelinek 
Date:   Sat Aug 8 11:07:09 2020 +0200

openmp: Avoid floating point comparison at the end of bb with
-fnon-call-exceptions

The following testcase ICEs with -fexceptions -fnon-call-exceptions because
in that mode floating point comparisons should not be done at the end of bb
in GIMPLE_COND.  Fixed by forcing it into a bool SSA_NAME and comparing
that against
false.

2020-08-08  Jakub Jelinek  

PR tree-optimization/96424
* omp-expand.c: Include tree-eh.h.
(expand_omp_for_init_vars): Handle -fexceptions
-fnon-call-exceptions
by forcing floating point comparison into a bool temporary.

* c-c++-common/gomp/pr96424.c: New test.

[Bug libstdc++/96303] [10/11 Regression] Ambiguous overload for operator!= for std::__debug::bitset compiled with -std=c++20 and -pedantic.

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96303

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

https://gcc.gnu.org/g:7e26e4fbd4ee618dd991c6bbf3c5403aa90d2192

commit r10-8592-g7e26e4fbd4ee618dd991c6bbf3c5403aa90d2192
Author: Jonathan Wakely 
Date:   Fri Aug 7 20:29:11 2020 +0100

libstdc++: Fix ambiguous comparisons in __gnu_debug::bitset [PR 96303]

With -pedantic the debug mode bitset has an ambiguous equality
comparison operator, because it tries to compare the non-debug base to
the debug object. The base object can be converted to another debug
bitset, making the same operator== a candidate again.

The fix is to do the comparison on both base objects, so the operator
for the derived type isn't a candidate.

For the inequality operator the same change should be done, but that
operator can be removed entirely for C++20 because it can be synthesized
by the compiler.

I don't think either equality or inequality operators are really needed,
because the public _GLIBCXX_STD_C::bitset base class cam always be
compared using its own comparison operators. I'm not changing that here
though.

libstdc++-v3/ChangeLog:

PR libstdc++/96303
* include/debug/bitset (bitset::operator==): Call _M_base() on
right operand.
(bitset::operator!=): Likewise, but don't define it at all when
default comparisons are supported by the compiler.
* testsuite/23_containers/bitset/operations/96303.cc: New test.

(cherry picked from commit de1e3b8795e507c3cfa5b62984272628ca62a9bd)

[Bug libstdc++/96303] [10/11 Regression] Ambiguous overload for operator!= for std::__debug::bitset compiled with -std=c++20 and -pedantic.

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96303

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-2611-gde1e3b8795e507c3cfa5b62984272628ca62a9bd
Author: Jonathan Wakely 
Date:   Fri Aug 7 20:29:11 2020 +0100

libstdc++: Fix ambiguous comparisons in __gnu_debug::bitset [PR 96303]

With -pedantic the debug mode bitset has an ambiguous equality
comparison operator, because it tries to compare the non-debug base to
the debug object. The base object can be converted to another debug
bitset, making the same operator== a candidate again.

The fix is to do the comparison on both base objects, so the operator
for the derived type isn't a candidate.

For the inequality operator the same change should be done, but that
operator can be removed entirely for C++20 because it can be synthesized
by the compiler.

I don't think either equality or inequality operators are really needed,
because the public _GLIBCXX_STD_C::bitset base class cam always be
compared using its own comparison operators. I'm not changing that here
though.

libstdc++-v3/ChangeLog:

PR libstdc++/96303
* include/debug/bitset (bitset::operator==): Call _M_base() on
right operand.
(bitset::operator!=): Likewise, but don't define it at all when
default comparisons are supported by the compiler.
* testsuite/23_containers/bitset/operations/96303.cc: New test.

[Bug target/96402] [8/9/10/11 Regression] Wrong code with -moutline-atomics

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402

--- Comment #12 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Tamar Christina
:

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

commit r8-10396-g3e2d69ee245e5a44c53cae27a797b97ba529eb72
Author: Jakub Jelinek 
Date:   Mon Aug 3 22:55:28 2020 +0200

aarch64: Fix up __aarch64_cas16_acq_rel fallback

As mentioned in the PR, the fallback path when LSE is unavailable writes
incorrect registers to the memory if the previous content compares equal
to x0, x1 - it writes copy of x0, x1 from the start of function, but it
should write x2, x3.

2020-08-03  Jakub Jelinek  

PR target/96402
* config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3
instead
of x(tmp0), x(tmp1) in STXP arguments.

* gcc.target/aarch64/pr96402.c: New test.

(cherry picked from commit 90b43856fdff7d96d93d22970eca8a86c56e0ddc)

[Bug target/96402] [8/9/10/11 Regression] Wrong code with -moutline-atomics

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Tamar Christina
:

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

commit r9-8796-g4e91af9877df9e6b28ea8e50ae9445590363d5b0
Author: Jakub Jelinek 
Date:   Mon Aug 3 22:55:28 2020 +0200

aarch64: Fix up __aarch64_cas16_acq_rel fallback

As mentioned in the PR, the fallback path when LSE is unavailable writes
incorrect registers to the memory if the previous content compares equal
to x0, x1 - it writes copy of x0, x1 from the start of function, but it
should write x2, x3.

2020-08-03  Jakub Jelinek  

PR target/96402
* config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3
instead
of x(tmp0), x(tmp1) in STXP arguments.

* gcc.target/aarch64/pr96402.c: New test.

(cherry picked from commit 90b43856fdff7d96d93d22970eca8a86c56e0ddc)

[Bug libstdc++/94242] filesystem::path::generic_string() only works with std::allocator

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94242

--- Comment #3 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:39a5a04daa09c711caeb6aaff12f1d03406fe29f

commit r8-10392-g39a5a04daa09c711caeb6aaff12f1d03406fe29f
Author: Jonathan Wakely 
Date:   Sat Mar 21 21:51:07 2020 +

libstdc++: Fix path::generic_string allocator handling (PR 94242)

It's not possible to construct a path::string_type from an allocator of
a different type. Create the correct specialization of basic_string, and
adjust path::_S_str_convert to use a basic_string_view so that it is
independent of the allocator type.

PR libstdc++/94242
* include/bits/fs_path.h (path::_S_str_convert): Replace first
parameter with basic_string_view so that strings with different
allocators can be accepted.
(path::generic_string()): Use basic_string object that uses
the
right allocator type.
* testsuite/27_io/filesystem/path/generic/94242.cc: New test.
* testsuite/27_io/filesystem/path/generic/generic_string.cc:
Improve
test coverage.

(cherry picked from commit 9fc985118d9f5014afc1caf32a411ee5803fba61)

[Bug libstdc++/93245] std::experimental::filesystem::path::generic_string() doesn't normalize

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93245

--- Comment #3 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:01cbd26b022cc9d4eaf26287b48299acfce80348

commit r8-10393-g01cbd26b022cc9d4eaf26287b48299acfce80348
Author: Jonathan Wakely 
Date:   Sat Mar 21 22:11:44 2020 +

libstdc++: Fix experimental::path::generic_string (PR 93245)

This function was unimplemented, simply returning the native format
string instead.

PR libstdc++/93245
* include/experimental/bits/fs_path.h
(path::generic_string()):
Return the generic format not the native format.
* testsuite/experimental/filesystem/path/generic/generic_string.cc:
Improve test coverage.

(cherry picked from commit a577c0c26931090e7c25e56ef5ffc807627961ec)

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

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

commit r9-8795-g3e40be9cc92d3fa117be7f4fab07cedeed8361a2
Author: Richard Sandiford 
Date:   Fri Aug 7 12:17:37 2020 +0100

arm: Clear canary value after stack_protect_test [PR96191]

The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function.  An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.

gcc/
PR target/96191
* config/arm/arm.md (arm_stack_protect_test_insn): Zero out
operand 2 after use.
* config/arm/thumb1.md (thumb1_stack_protect_test_insn): Likewise.

gcc/testsuite/
* gcc.target/arm/stack-protector-1.c: New test.
* gcc.target/arm/stack-protector-2.c: Likewise.

(cherry picked from commit 6a3f3e08723063ea2dadb7ddf503f02972a724e2)

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:5380912a17ea09a8996720fb62b1a70c16c8f9f2

commit r9-8794-g5380912a17ea09a8996720fb62b1a70c16c8f9f2
Author: Richard Sandiford 
Date:   Fri Aug 7 12:17:37 2020 +0100

aarch64: Clear canary value after stack_protect_test [PR96191]

The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function.  An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.

gcc/
PR target/96191
* config/aarch64/aarch64.md (stack_protect_test_): Set the
CC register directly, instead of a GPR.  Replace the original GPR
destination with an extra scratch register.  Zero out operand 3
after use.
(stack_protect_test): Update accordingly.

gcc/testsuite/
PR target/96191
* gcc.target/aarch64/stack-protector-1.c: New test.
* gcc.target/aarch64/stack-protector-2.c: Likewise.

(cherry picked from commit fe1a26429038d7cd17abc53f96a6f3e2639b605f)

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:

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

commit r10-8584-g8f6b7c9796035ad8b2cdfbce5d3d11dd4b81fad7
Author: Richard Sandiford 
Date:   Fri Aug 7 12:15:02 2020 +0100

arm: Clear canary value after stack_protect_test [PR96191]

The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function.  An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.

gcc/
PR target/96191
* config/arm/arm.md (arm_stack_protect_test_insn): Zero out
operand 2 after use.
* config/arm/thumb1.md (thumb1_stack_protect_test_insn): Likewise.

gcc/testsuite/
* gcc.target/arm/stack-protector-1.c: New test.
* gcc.target/arm/stack-protector-2.c: Likewise.

(cherry picked from commit 6a3f3e08723063ea2dadb7ddf503f02972a724e2)

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:

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

commit r10-8583-gbab5fdaf9abb1236a7a56258d1d36265068b4827
Author: Richard Sandiford 
Date:   Fri Aug 7 12:15:01 2020 +0100

aarch64: Clear canary value after stack_protect_test [PR96191]

The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function.  An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.

gcc/
PR target/96191
* config/aarch64/aarch64.md (stack_protect_test_): Set the
CC register directly, instead of a GPR.  Replace the original GPR
destination with an extra scratch register.  Zero out operand 3
after use.
(stack_protect_test): Update accordingly.

gcc/testsuite/
PR target/96191
* gcc.target/aarch64/stack-protector-1.c: New test.
* gcc.target/aarch64/stack-protector-2.c: Likewise.

(cherry picked from commit fe1a26429038d7cd17abc53f96a6f3e2639b605f)

[Bug libstdc++/93245] std::experimental::filesystem::path::generic_string() doesn't normalize

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93245

--- Comment #2 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:88f2b72e77fea11803b761f4fb569d83266e1d9e

commit r9-8793-g88f2b72e77fea11803b761f4fb569d83266e1d9e
Author: Jonathan Wakely 
Date:   Sat Mar 21 22:11:44 2020 +

libstdc++: Fix experimental::path::generic_string (PR 93245)

This function was unimplemented, simply returning the native format
string instead.

PR libstdc++/93245
* include/experimental/bits/fs_path.h
(path::generic_string()):
Return the generic format path, not the native one.
* testsuite/experimental/filesystem/path/generic/generic_string.cc:
Improve test coverage.

(cherry picked from commit a577c0c26931090e7c25e56ef5ffc807627961ec)

[Bug libstdc++/94242] filesystem::path::generic_string() only works with std::allocator

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94242

--- Comment #2 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-8792-ge7406c364496dae51ef294b5720923fe4a1dfccb
Author: Jonathan Wakely 
Date:   Sat Mar 21 21:51:07 2020 +

libstdc++: Fix path::generic_string allocator handling (PR 94242)

It's not possible to construct a path::string_type from an allocator of
a different type. Create the correct specialization of basic_string, and
adjust path::_S_str_convert to use a basic_string_view so that it is
independent of the allocator type.

PR libstdc++/94242
* include/bits/fs_path.h (path::_S_str_convert): Replace first
parameter with basic_string_view so that strings with different
allocators can be accepted.
(path::generic_string()): Use basic_string object that uses
the
right allocator type.
* testsuite/27_io/filesystem/path/generic/94242.cc: New test.
* testsuite/27_io/filesystem/path/generic/generic_string.cc:
Improve
test coverage.

(cherry picked from commit 9fc985118d9f5014afc1caf32a411ee5803fba61)

[Bug tree-optimization/96514] [9/10/11 Regression] ICE: verify_flow_info failed (error: control flow in the middle of basic block 3)

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96514

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

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

commit r11-2607-gc3f94f5786a014515c09c7852db228c74adf51e5
Author: Richard Biener 
Date:   Fri Aug 7 10:16:05 2020 +0200

tree-optimization/96514 - avoid if-converting control-altering calls

This avoids if-converting when encountering control-altering calls.

2020-08-07  Richard Biener  

PR tree-optimization/96514
* tree-if-conv.c (if_convertible_bb_p): If the last stmt
is a call that is control-altering, fail.

* gcc.dg/pr96514.c: New testcase.

[Bug rtl-optimization/94605] [8/9 Regression] ICE in early-remat.c:process_block with multi-output asms

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94605

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

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

commit r9-8790-gcdb0af30f73923ec4355ecd5c294b7a026bb4aa4
Author: Richard Sandiford 
Date:   Fri Aug 7 10:39:39 2020 +0100

early-remat: Handle sets of multiple candidate regs [PR94605]

early-remat.c:process_block wasn't handling insns that set multiple
candidate registers, which led to an assertion failure at the end
of the main loop.

Instructions that set two pseudos aren't rematerialisation candidates in
themselves, but we still need to track them if another instruction that
sets the same register is a rematerialisation candidate.

gcc/
PR rtl-optimization/94605
* early-remat.c (early_remat::process_block): Handle insns that
set multiple candidate registers.

gcc/testsuite/
PR rtl-optimization/94605
* gcc.target/aarch64/sve/pr94605.c: New test.

(cherry picked from commit 3c3f12e2a7625c9a2f5d74a47dbacb2fd1ae5643)

[Bug middle-end/95114] [9 Regression] ICE in obj_type_ref_class for structural-equality types

2020-08-07 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Sandiford
:

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

commit r9-8789-ge4c68cc7dcb6617740ee26f359a34c37c6981685
Author: Richard Sandiford 
Date:   Fri Aug 7 10:39:38 2020 +0100

ipa-devirt: Fix crash in obj_type_ref_class [PR95114]

The testcase has failed since r9-5035, because obj_type_ref_class
tries to look up an ODR type when no ODR type information is
available.  (The information was available earlier in the
compilation, but was freed during pass_ipa_free_lang_data.)
We then crash dereferencing the null get_odr_type result.

The test passes with -O2.  However, it fails again if -fdump-tree-all
is used, since obj_type_ref_class is called indirectly from the
dump routines.

Other code creates ODR type entries on the fly by passing âtrueâ
as the insert parameter.  But obj_type_ref_class can't do that
unconditionally, since it should have no side-effects when used
from the dumping code.

Following a suggestion from Honza, this patch adds parameters
to say whether the routines are being called from dump routines
and uses those to derive the insert parameter.

gcc/
PR middle-end/95114
* tree.h (virtual_method_call_p): Add a default-false parameter
that indicates whether the function is being called from dump
routines.
(obj_type_ref_class): Likewise.
* tree.c (virtual_method_call_p): Likewise.
* ipa-devirt.c (obj_type_ref_class): Likewise.  Lazily add ODR
type information for the type when the parameter is false.
* tree-pretty-print.c (dump_generic_node): Update calls to
virtual_method_call_p and obj_type_ref_class accordingly.

gcc/testsuite/
PR middle-end/95114
* g++.target/aarch64/pr95114.C: New test.

(cherry picked from commit 5834e96a08fd8b86a42428f38a95903d2f1de202)

[Bug target/96493] powerpc local call linkage failure

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Alan Modra :

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

commit r11-2603-gf8ac30f1653ff69706c35af6d725f1d330600f11
Author: Alan Modra 
Date:   Thu Aug 6 14:12:21 2020 +0930

PR96493, powerpc local call linkage failure

This corrects current_file_function_operand, an operand predicate used
to determine whether a symbol_ref is safe to use with the local_call
patterns.  Calls between pcrel and non-pcrel code need to go via
linker stubs.  In the case of non-pcrel code to pcrel the stub saves
r2 but there needs to be a nop after the branch for the r2 restore.
So the local_call patterns can't be used there.  For pcrel code to
non-pcrel the local_call patterns could still be used, but I thought
it better to not use them since the call isn't direct.  Code generated
by the corresponding call_nonlocal_aix for pcrel is identical anyway.

Incidentally, without the TREE_CODE () == FUNCTION_DECL test,
gcc.c-torture/compile/pr37433.c and pr37433-1.c ICE.  Also, if you
make the test more strict by disallowing an op without a
SYMBOL_REF_DECL then a bunch of go and split-stack tests fail.  That's
because a prologue call to __morestack can't have a following nop.
(__morestack calls its caller at a fixed offset from the __morestack
call!)

gcc/
PR target/96493
* config/rs6000/predicates.md (current_file_function_operand):
Don't
accept functions that differ in r2 usage.

gcc/testsuite/
* gcc.target/powerpc/pr96493.c: New file.

[Bug libstdc++/96484] Horrible performance of std::read_symlink

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484

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

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

commit r8-10390-g8b692f8b4c0e47bc8e11d9c3ab83049f68b2edbc
Author: Jonathan Wakely 
Date:   Thu Aug 6 18:44:50 2020 +0100

libstdc++: Fix unnecessary allocations in read_symlink [PR 96484]

libstdc++-v3/ChangeLog:

PR libstdc++/96484
* src/filesystem/ops.cc (fs::read_symlink): Return an error
immediately for non-symlinks.
* src/filesystem/std-ops.cc (fs::read_symlink): Likewise.

(cherry picked from commit 6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184)

[Bug libstdc++/96484] Horrible performance of std::read_symlink

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

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

commit r9-8787-gf86f80dbccece356fa5ca7e1fd4dc581cc6a1cc4
Author: Jonathan Wakely 
Date:   Thu Aug 6 18:44:50 2020 +0100

libstdc++: Fix unnecessary allocations in read_symlink [PR 96484]

libstdc++-v3/ChangeLog:

PR libstdc++/96484
* src/c++17/fs_ops.cc (fs::read_symlink): Return an error
immediately for non-symlinks.
* src/filesystem/ops.cc (fs::read_symlink): Likewise.

(cherry picked from commit 6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184)

[Bug libstdc++/96484] Horrible performance of std::read_symlink

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484

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

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

commit r10-8581-g8b7e7fcb5fff8255122a8fa94109f7ae05aeaa81
Author: Jonathan Wakely 
Date:   Thu Aug 6 18:44:50 2020 +0100

libstdc++: Fix unnecessary allocations in read_symlink [PR 96484]

libstdc++-v3/ChangeLog:

PR libstdc++/96484
* src/c++17/fs_ops.cc (fs::read_symlink): Return an error
immediately for non-symlinks.
* src/filesystem/ops.cc (fs::read_symlink): Likewise.

(cherry picked from commit 6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184)

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191

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

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

commit r11-2598-g6a3f3e08723063ea2dadb7ddf503f02972a724e2
Author: Richard Sandiford 
Date:   Thu Aug 6 19:19:41 2020 +0100

arm: Clear canary value after stack_protect_test [PR96191]

The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function.  An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.

gcc/
PR target/96191
* config/arm/arm.md (arm_stack_protect_test_insn): Zero out
operand 2 after use.
* config/arm/thumb1.md (thumb1_stack_protect_test_insn): Likewise.

gcc/testsuite/
* gcc.target/arm/stack-protector-1.c: New test.
* gcc.target/arm/stack-protector-2.c: Likewise.

[Bug libstdc++/96484] Horrible performance of std::read_symlink

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-2597-g6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184
Author: Jonathan Wakely 
Date:   Thu Aug 6 18:44:50 2020 +0100

libstdc++: Fix unnecessary allocations in read_symlink [PR 96484]

libstdc++-v3/ChangeLog:

PR libstdc++/96484
* src/c++17/fs_ops.cc (fs::read_symlink): Return an error
immediately for non-symlinks.
* src/filesystem/ops.cc (fs::read_symlink): Likewise.

[Bug target/96446] ICE when spilling an MMA accumulator

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:9c376d1c166e7c8b10bba6f1675d2471ffe8447f

commit r11-2595-g9c376d1c166e7c8b10bba6f1675d2471ffe8447f
Author: Peter Bergner 
Date:   Thu Aug 6 10:03:03 2020 -0500

rs6000: Don't ICE when spilling an MMA accumulator

When we spill an accumulator that has a known zero value, LRA will emit
a new (set (reg:PXI ...) 0) insn, but it does not use the mma_xxsetaccz
pattern to do it, leading to an unrecognized insn ICE.  The solution here
is to move the xxsetaccz instruction into the movpxi pattern and have the
xxsetaccz pattern call the move pattern.

2020-08-06  Peter Bergner  

gcc/
PR target/96446
* config/rs6000/mma.md (*movpxi): Add xxsetaccz generation.
Disable split for zero constant source operand.
(mma_xxsetaccz): Change to define_expand.  Call gen_movpxi.

gcc/testsuite/
PR target/96446
* gcc.target/powerpc/pr96446.c: New test.

[Bug tree-optimization/96480] [8/9/10/11 Regression] missed optimisation: unnecessary compare in standard algorithms

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96480

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r11-2593-gb3aa137212b1af0c824a9890eba2ca27a7271d56
Author: Jakub Jelinek 
Date:   Thu Aug 6 15:47:25 2020 +0200

reassoc: Improve maybe_optimize_range_tests [PR96480]

On the following testcase, if the IL before reassoc would be:
...
   [local count: 354334800]:
  if (x_3(D) == 2)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 233860967]:
  if (x_3(D) == 3)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 79512730]:

   [local count: 1073741824]:
  # prephitmp_7 = PHI <1(3), 1(4), 1(5), 1(2), 0(6)>
then we'd optimize it properly, but as bb 5-7 is instead:
   [local count: 233860967]:
  if (x_3(D) == 3)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 79512730]:

   [local count: 1073741824]:
  # prephitmp_7 = PHI <1(3), 1(4), 0(5), 1(2), 1(6)>
(i.e. the true/false edges on the last bb with condition swapped
and ditto for the phi args), we don't recognize it.  If bb 6
is empty, there should be no functional difference between the two IL
representations.

This patch handles those special cases.

2020-08-06  Jakub Jelinek  

PR tree-optimization/96480
* tree-ssa-reassoc.c (suitable_cond_bb): Add TEST_SWAPPED_P
argument.
If TEST_BB ends in cond and has one edge to *OTHER_BB and another
through an empty bb to that block too, if PHI args don't match,
retry
them through the other path from TEST_BB.
(maybe_optimize_range_tests): Adjust callers.  Handle such LAST_BB
through inversion of the condition.

* gcc.dg/tree-ssa/pr96480.c: New test.

[Bug tree-optimization/96483] ICE in code hoisting with AArch64 SVE2 intrinsics

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96483

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-8580-gca6c1bda8023d17577f1fca0b406402fbaaba63f
Author: Richard Biener 
Date:   Thu Aug 6 12:16:05 2020 +0200

tree-optimization/96483 - fix ICE in PRE with POLY_INT_CST

This adds a missing case for PRE expression re-materialization.

2020-08-06  Richard Biener  

PR tree-optimization/96483
* tree-ssa-pre.c (create_component_ref_by_pieces_1): Handle
POLY_INT_CST.

(cherry picked from commit 1f4c8afa1b2dac97f2ee78eacafe6eee246a4dae)

[Bug tree-optimization/96491] [11 Regression] ICE: tree check: expected ssa_name, have integer_cst in add_phi_arg, at tree-phinodes.c:373

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96491

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

https://gcc.gnu.org/g:89b84cd794f984038984c10b03c3b0ab582f49cc

commit r11-2591-g89b84cd794f984038984c10b03c3b0ab582f49cc
Author: Richard Biener 
Date:   Thu Aug 6 12:18:24 2020 +0200

tree-optimization/96491 - avoid store commoning across abnormal edges

This avoids store commoning across abnormal edges since that easily
can disrupt abnormal coalescing because it might create overlapping
lifetime of variables.

2020-08-06  Richard Biener  

PR tree-optimization/96491
* tree-ssa-sink.c (sink_common_stores_to_bb): Avoid
sinking across abnormal edges.

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

[Bug tree-optimization/96483] ICE in code hoisting with AArch64 SVE2 intrinsics

2020-08-06 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96483

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

https://gcc.gnu.org/g:1f4c8afa1b2dac97f2ee78eacafe6eee246a4dae

commit r11-2590-g1f4c8afa1b2dac97f2ee78eacafe6eee246a4dae
Author: Richard Biener 
Date:   Thu Aug 6 12:16:05 2020 +0200

tree-optimization/96483 - fix ICE in PRE with POLY_INT_CST

This adds a missing case for PRE expression re-materialization.

2020-08-06  Richard Biener  

PR tree-optimization/96483
* tree-ssa-pre.c (create_component_ref_by_pieces_1): Handle
POLY_INT_CST.

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

2020-08-05 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96282

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

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

commit r11-2580-gd21252de6c81ed236d8981d47b9a57dc4f1c6d57
Author: Patrick Palka 
Date:   Wed Aug 5 15:05:30 2020 -0400

c++: cxx_eval_vec_init after zero-initialization [PR96282]

In the first testcase below, expand_aggr_init_1 sets up t's default
constructor such that the ctor first zero-initializes the entire base b,
followed by calling b's default constructor, the latter of which just
default-initializes the array member b::m via a VEC_INIT_EXPR.

So upon constexpr evaluation of this latter VEC_INIT_EXPR, ctx->ctor is
nonempty due to the prior zero-initialization, and we proceed in
cxx_eval_vec_init to append new constructor_elts to the end of ctx->ctor
without first checking if a matching constructor_elt already exists.
This leads to ctx->ctor having two matching constructor_elts for each
index.

This patch fixes this issue by truncating a zero-initialized array
CONSTRUCTOR in cxx_eval_vec_init_1 before we begin appending array
elements to it.  We propagate its zeroed out state during evaluation by
clearing CONSTRUCTOR_NO_CLEARING on each new appended aggregate element.

gcc/cp/ChangeLog:

PR c++/96282
* constexpr.c (cxx_eval_vec_init_1): Truncate ctx->ctor and
then clear CONSTRUCTOR_NO_CLEARING on each appended element
initializer if we're initializing a previously zero-initialized
array object.

gcc/testsuite/ChangeLog:

PR c++/96282
* g++.dg/cpp0x/constexpr-array26.C: New test.
* g++.dg/cpp0x/constexpr-array27.C: New test.
* g++.dg/cpp2a/constexpr-init18.C: New test.

Co-authored-by: Jason Merrill 

[Bug fortran/96469] Compile-time check for change in DO variable in contained procedures

2020-08-05 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96469

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

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

commit r11-2579-gdd30d93f1a3ead7b814c1b179cf7197e4bf1e183
Author: Thomas Koenig 
Date:   Wed Aug 5 20:53:44 2020 +0200

Added test case to make sure that legal cases still pass.

gcc/testsuite/ChangeLog:

PR fortran/96469
* gfortran.dg/do_check_14.f90: New test.

[Bug fortran/96469] Compile-time check for change in DO variable in contained procedures

2020-08-05 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96469

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:27eac9ee6137a6b5ae693b54cafa22bdc0cbcd5a

commit r11-2578-g27eac9ee6137a6b5ae693b54cafa22bdc0cbcd5a
Author: Thomas Koenig 
Date:   Wed Aug 5 18:37:32 2020 +0200

Static analysis for definition of DO index variables in contained
procedures.

When encountering a procedure call in a DO loop, this patch checks if
the call is to a contained procedure, and if it is, check for
changes in the index variable.

gcc/fortran/ChangeLog:

PR fortran/96469
* frontend-passes.c (doloop_contained_function_call): New
function.
(doloop_contained_procedure_code): New function.
(CHECK_INQ): Macro for inquire checks.
(doloop_code): Invoke doloop_contained_procedure_code and
doloop_contained_function_call if appropriate.
(do_intent): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/96469
* gfortran.dg/do_check_4.f90: Hide change in index variable
from compile-time analysis.
* gfortran.dg/do_check_13.f90: New test.

[Bug tree-optimization/95906] Failure to recognize max pattern with mask

2020-08-05 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marc Glisse :

https://gcc.gnu.org/g:229752afe3156a3990dacaedb94c76846cebf132

commit r11-2577-g229752afe3156a3990dacaedb94c76846cebf132
Author: Marc Glisse 
Date:   Wed Aug 5 16:45:33 2020 +0200

VEC_COND_EXPR optimizations

When vector comparisons were forced to use vec_cond_expr, we lost a number
of optimizations (my fault for not adding enough testcases to
prevent that). This patch tries to unwrap vec_cond_expr a bit so some
optimizations can still happen.

I wasn't planning to add all those transformations together, but adding one
caused a regression, whose fix introduced a second regression,
etc.

Restricting to constant folding would not be sufficient, we also need at
least things like X|0 or X The transformations are quite
conservative with :s and folding only if everything simplifies, we may want
to relax this later. And of course we are going to miss things
like a?b:c + a?c:b -> b+c.

In terms of number of operations, some transformations turning 2
VEC_COND_EXPR into VEC_COND_EXPR + BIT_IOR_EXPR + BIT_NOT_EXPR might not look
like a gain... I expect the bit_not disappears in most cases, and
VEC_COND_EXPR looks more costly than a simpler BIT_IOR_EXPR.

2020-08-05  Marc Glisse  

PR tree-optimization/95906
PR target/70314
* match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
(v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations.
(op (c ? a : b)): Update to match the new transformations.

* gcc.dg/tree-ssa/andnot-2.c: New file.
* gcc.dg/tree-ssa/pr95906.c: Likewise.
* gcc.target/i386/pr70314.c: Likewise.

[Bug target/70314] AVX512 not using kandw to combine comparison results

2020-08-05 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70314

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marc Glisse :

https://gcc.gnu.org/g:229752afe3156a3990dacaedb94c76846cebf132

commit r11-2577-g229752afe3156a3990dacaedb94c76846cebf132
Author: Marc Glisse 
Date:   Wed Aug 5 16:45:33 2020 +0200

VEC_COND_EXPR optimizations

When vector comparisons were forced to use vec_cond_expr, we lost a number
of optimizations (my fault for not adding enough testcases to
prevent that). This patch tries to unwrap vec_cond_expr a bit so some
optimizations can still happen.

I wasn't planning to add all those transformations together, but adding one
caused a regression, whose fix introduced a second regression,
etc.

Restricting to constant folding would not be sufficient, we also need at
least things like X|0 or X The transformations are quite
conservative with :s and folding only if everything simplifies, we may want
to relax this later. And of course we are going to miss things
like a?b:c + a?c:b -> b+c.

In terms of number of operations, some transformations turning 2
VEC_COND_EXPR into VEC_COND_EXPR + BIT_IOR_EXPR + BIT_NOT_EXPR might not look
like a gain... I expect the bit_not disappears in most cases, and
VEC_COND_EXPR looks more costly than a simpler BIT_IOR_EXPR.

2020-08-05  Marc Glisse  

PR tree-optimization/95906
PR target/70314
* match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e),
(v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): New transformations.
(op (c ? a : b)): Update to match the new transformations.

* gcc.dg/tree-ssa/andnot-2.c: New file.
* gcc.dg/tree-ssa/pr95906.c: Likewise.
* gcc.target/i386/pr70314.c: Likewise.

[Bug target/96191] aarch64 stack_protect_test canary leak

2020-08-05 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191

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

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

commit r11-2576-gfe1a26429038d7cd17abc53f96a6f3e2639b605f
Author: Richard Sandiford 
Date:   Wed Aug 5 15:18:36 2020 +0100

aarch64: Clear canary value after stack_protect_test [PR96191]

The stack_protect_test patterns were leaving the canary value in the
temporary register, meaning that it was often still in registers on
return from the function.  An attacker might therefore have been
able to use it to defeat stack-smash protection for a later function.

gcc/
PR target/96191
* config/aarch64/aarch64.md (stack_protect_test_): Set the
CC register directly, instead of a GPR.  Replace the original GPR
destination with an extra scratch register.  Zero out operand 3
after use.
(stack_protect_test): Update accordingly.

gcc/testsuite/
PR target/96191
* gcc.target/aarch64/stack-protector-1.c: New test.
* gcc.target/aarch64/stack-protector-2.c: Likewise.

[Bug middle-end/96459] OpenMP host teams reductions ignored

2020-08-05 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96459

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:916c7a201a9a1dc94f2c056a773826a26d1daca9

commit r11-2571-g916c7a201a9a1dc94f2c056a773826a26d1daca9
Author: Jakub Jelinek 
Date:   Wed Aug 5 10:40:10 2020 +0200

openmp: Handle reduction clauses on host teams construct [PR96459]

As the new testcase shows, we weren't actually performing reductions on
host teams construct.  And fixing that revealed a flaw in the for-14.c
testcase.
The problem is that the tests perform also initialization and checking
around the
calls to the functions with the OpenMP constructs.  In that testcase, all
the
tests have been spawned from a teams construct but only the tested loops
were
distribute, which means the initialization and checking has been performed
redundantly and racily in each team.  Fixed by performing the
initialization
and checking outside of host teams and only do the calls to functions with
the tested constructs inside of host teams.

2020-08-05  Jakub Jelinek  

PR middle-end/96459
* omp-low.c (lower_omp_taskreg): Call lower_reduction_clauses even
in
for host teams.

* testsuite/libgomp.c/teams-3.c: New test.
* testsuite/libgomp.c-c++-common/for-2.h (OMPTEAMS): Define to
nothing
if not defined yet.
(N(test)): Use it before all N(f*) calls.
* testsuite/libgomp.c-c++-common/for-14.c (DO_PRAGMA, OMPTEAMS):
Define.
(main): Don't call all test_* functions from within
#pragma omp teams reduction(|:err), call them directly.

[Bug c++/96082] [9/10 Regression] GCC rejects the template disambiguator with "typename"

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96082

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

https://gcc.gnu.org/g:1c4d223d37d067f5d372688c0c0cc5a05d977df7

commit r10-8576-g1c4d223d37d067f5d372688c0c0cc5a05d977df7
Author: Marek Polacek 
Date:   Tue Aug 4 09:35:25 2020 -0400

c++: Template keyword following :: [PR96082]

In r9-4235 I tried to make sure that the template keyword follows
a nested-name-specifier.  :: is a valid nested-name-specifier, so
I also have to check 'globalscope' before giving the error.

gcc/cp/ChangeLog:

PR c++/96082
* parser.c (cp_parser_elaborated_type_specifier): Allow
'template' following ::.

gcc/testsuite/ChangeLog:

PR c++/96082
* g++.dg/template/template-keyword3.C: New test.

(cherry picked from commit 97def1f34c134d78d4423e9ac3e9b262417ea390)

[Bug c++/96082] [9/10/11 Regression] GCC rejects the template disambiguator with "typename"

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96082

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

https://gcc.gnu.org/g:97def1f34c134d78d4423e9ac3e9b262417ea390

commit r11-2560-g97def1f34c134d78d4423e9ac3e9b262417ea390
Author: Marek Polacek 
Date:   Tue Aug 4 09:35:25 2020 -0400

c++: Template keyword following :: [PR96082]

In r9-4235 I tried to make sure that the template keyword follows
a nested-name-specifier.  :: is a valid nested-name-specifier, so
I also have to check 'globalscope' before giving the error.

gcc/cp/ChangeLog:

PR c++/96082
* parser.c (cp_parser_elaborated_type_specifier): Allow
'template' following ::.

gcc/testsuite/ChangeLog:

PR c++/96082
* g++.dg/template/template-keyword3.C: New test.

[Bug go/96450] [11 Regression] Go bootstrap failure on i686-linux

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96450

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

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

commit r11-2559-gacf83db025cfd4a67724838e9dbd19813f4f5960
Author: Ian Lance Taylor 
Date:   Mon Aug 3 18:23:39 2020 -0700

compiler: delete lowered constant strings

If we lower a constant string operation in a Binary_expression,
delete the strings.  This is safe because constant strings are always
newly allocated.

This is a hack to use much less memory when compiling the new
time/tzdata package, which has a file that contains the sum of over
13,000 constant strings.  We don't do this for numeric expressions
because that could cause us to delete an Iota_expression.

We should have a cleaner approach to memory usage some day.

Fixes PR go/96450

[Bug rtl-optimization/60473] optimization after shift sub-optimal

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60473

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:76eafcc395d2bcd4147cb1ba1a8aff321571402f

commit r11-2551-g76eafcc395d2bcd4147cb1ba1a8aff321571402f
Author: Roger Sayle 
Date:   Tue Aug 4 16:56:06 2020 +0100

Test case for PR rtl-optimization/60473

PR rtl-optimization/60473 is code quality regression that has
been cured by improvements to register allocation.  For the function
in the test case, GCC 4.4, 4.5 and 4.6 generated very poor code
requiring two mov instructions, and GCC 4.7 and 4.8 (when the PR was
filed) produced better but still poor code with one mov instruction.
Since GCC 4.9 (including current mainline), it generates optimal
code with no mov instructions, matching what used to be generated
in GCC 4.1.

2020-08-04  Roger Sayle  

gcc/testsuite/ChangeLog
PR rtl-optimization/60473
* gcc.target/i386/pr60473.c: New test.

[Bug tree-optimization/95433] Failure to completely optimize simple compare after operations

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Marc Glisse :

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

commit r11-2550-gca2b8c082c4f16919071c9f8de8db0b33b54c405
Author: Marc Glisse 
Date:   Tue Aug 4 17:30:16 2020 +0200

Simplify X * C1 == C2 with undefined overflow

this transformation is quite straightforward, without overflow, 3*X==15 is
the same as X==5 and 3*X==5 cannot happen. Adding a single_use restriction
for the first case didn't seem necessary, although of course it can
slightly increase register pressure in some cases.

2020-08-04  Marc Glisse  

PR tree-optimization/95433
* match.pd (X * C1 == C2): New transformation.

* gcc.c-torture/execute/pr23135.c: Add -fwrapv to avoid
undefined behavior.
* gcc.dg/tree-ssa/pr95433.c: New file.

[Bug d/96153] d: struct literals have non-deterministic hash values

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96153

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r11-2548-g2ac51bdf63b0e17d1b9974f30303fb24e3cbc83d
Author: Iain Buclaw 
Date:   Wed Jul 22 09:50:38 2020 +0200

d: Fix struct literals that have non-deterministic hash values (PR96153)

Adds code generation for generating a temporary for, and pre-filling
struct and array literals with zeroes before assigning, so that
alignment holes don't cause objects to produce a non-deterministic hash
value.  A new field has been added to the expression visitor to track
whether the result is being generated for another literal, so that
memset() is only called once on the top-level literal expression, and
not for nesting struct or arrays.

gcc/d/ChangeLog:

PR d/96153
* d-tree.h (build_expr): Add literalp argument.
* expr.cc (ExprVisitor): Add literalp_ field.
(ExprVisitor::ExprVisitor): Initialize literalp_.
(ExprVisitor::visit (AssignExp *)): Call memset() on blits where
RHS
is a struct literal.  Elide assignment if initializer is all
zeroes.
(ExprVisitor::visit (CastExp *)): Forward literalp_ to generation
of
subexpression.
(ExprVisitor::visit (AddrExp *)): Likewise.
(ExprVisitor::visit (ArrayLiteralExp *)): Use memset() to pre-fill
object with zeroes.  Set literalp in subexpressions.
(ExprVisitor::visit (StructLiteralExp *)): Likewise.
(ExprVisitor::visit (TupleExp *)): Set literalp in subexpressions.
(ExprVisitor::visit (VectorExp *)): Likewise.
(ExprVisitor::visit (VectorArrayExp *)): Likewise.
(build_expr): Forward literal_p to ExprVisitor.

gcc/testsuite/ChangeLog:

PR d/96153
* gdc.dg/pr96153.d: New test.

[Bug c++/94024] Error message has misleading source location for constructor member initialisation.

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94024

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

https://gcc.gnu.org/g:843710c037c1396dcdbc23e5b6b456b8ae6e2b8b

commit r11-2546-g843710c037c1396dcdbc23e5b6b456b8ae6e2b8b
Author: Patrick Palka 
Date:   Tue Aug 4 10:11:35 2020 -0400

c++: Member initializer list diagnostic locations [PR94024]

This patch preserves the source locations of each node in a member
initializer list so that during processing of the list we can set
input_location appropriately for generally more accurate diagnostic
locations.  Since TREE_LIST nodes are tcc_exceptional, they can't have
source locations, so we instead store the location in a dummy
tcc_expression node within the TREE_TYPE of the list node.

gcc/cp/ChangeLog:

PR c++/94024
* init.c (sort_mem_initializers): Preserve TREE_TYPE of the
member initializer list node.
(emit_mem_initializers): Set input_location when performing each
member initialization.
* parser.c (cp_parser_mem_initializer): Attach the source
location of this initializer to a dummy EMPTY_CLASS_EXPR
within the TREE_TYPE of the list node.
* pt.c (tsubst_initializer_list): Preserve TREE_TYPE of the
member initializer list node.

gcc/testsuite/ChangeLog:

PR c++/94024
* g++.dg/diagnostic/mem-init1.C: New test.

[Bug tree-optimization/88240] [8/9/10/11 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240

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

https://gcc.gnu.org/g:1af5cdd77985daf76130f527deac425c43df9f49

commit r11-2545-g1af5cdd77985daf76130f527deac425c43df9f49
Author: Richard Biener 
Date:   Tue Aug 4 14:10:45 2020 +0200

tree-optimization/88240 - stopgap for floating point code-hoisting issues

This adds a stopgap measure to avoid performing code-hoisting
on mixed type loads when the load we'd insert in the hoisting
position would be a floating point one.  This is because certain
targets (hello x87) cannot perform floating point loads without
possibly altering the bit representation and thus cannot be used
in place of integral loads.

2020-08-04  Richard Biener  

PR tree-optimization/88240
* tree-ssa-sccvn.h (vn_reference_s::punned): New flag.
* tree-ssa-sccvn.c (vn_reference_insert): Initialize punned.
(vn_reference_insert_pieces): Likewise.
(visit_reference_op_call): Likewise.
(visit_reference_op_load): Track whether a ref was punned.
* tree-ssa-pre.c (do_hoist_insertion): Refuse to perform hoist
insertion on punned floating point loads.

* gcc.target/i386/pr88240.c: New testcase.

[Bug target/96428] [nvptx] nvptx_gen_shuffle does not handle V2DI mode – Fails with an ICE

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

https://gcc.gnu.org/g:344f09a756ebd50510cc1eb3db111fd61c527702

commit r11-2541-g344f09a756ebd50510cc1eb3db111fd61c527702
Author: Tom de Vries 
Date:   Tue Aug 4 09:53:08 2020 +0200

[nvptx] Handle V2DI/V2SI mode in nvptx_gen_shuffle

With the pr96628-part1.f90 source and -ftree-slp-vectorize, we run into an
ICE due to the fact that V2DI mode is not handled in nvptx_gen_shuffle.

Fix this by adding handling of V2DI as well as V2SI mode in
nvptx_gen_shuffle.

Build and reg-tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

PR target/96428
* config/nvptx/nvptx.c (nvptx_gen_shuffle): Handle V2SI/V2DI.

libgomp/ChangeLog:

PR target/96428
* testsuite/libgomp.oacc-fortran/pr96628-part1.f90: New test.
* testsuite/libgomp.oacc-fortran/pr96628-part2.f90: New test.

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

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354

--- Comment #24 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:49643954ffa71ddeec8e979e05f145ea688027f9

commit r10-8569-g49643954ffa71ddeec8e979e05f145ea688027f9
Author: Jakub Jelinek 
Date:   Tue Aug 4 11:31:44 2020 +0200

gimple-fold: Fix ICE in maybe_canonicalize_mem_ref_addr on debug stmt
[PR96354]

In debug stmts, we are less strict about what is and what is not accepted
there, so this patch just punts on optimization of a debug stmt rather than
ICEing.

2020-08-04  Jakub Jelinek  

PR debug/96354
* gimple-fold.c (maybe_canonicalize_mem_ref_addr): Add IS_DEBUG
argument.  Return false instead of gcc_unreachable if it is true
and
get_addr_base_and_unit_offset returns NULL.
(fold_stmt_1) : Adjust caller.

* g++.dg/opt/pr96354.C: New test.

(cherry picked from commit fabe0ede9db9fa95832b2329d3d6156711905e20)

[Bug middle-end/96426] __builtin_convertvector ICE without lhs

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96426

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

https://gcc.gnu.org/g:046501dc30f9b0fe31385698af4fd27b464af6ba

commit r10-8570-g046501dc30f9b0fe31385698af4fd27b464af6ba
Author: Jakub Jelinek 
Date:   Tue Aug 4 11:33:18 2020 +0200

veclower: Don't ICE on .VEC_CONVERT calls with no lhs [PR96426]

.VEC_CONVERT is a const internal call, so normally if the lhs is not used,
we'd DCE it far before getting to veclower, but with -O0 (or perhaps
-fno-tree-dce and some other -fno-* options) it can happen.
But as the internal fn needs the lhs to know the type to which the
conversion is done (and I think that is a reasonable representation, having
some magic another argument and having to create constants with that type
looks overkill to me), we just should DCE those calls ourselves.
During veclower, we can't really remove insns, as the callers would be
upset, so this just replaces it with a GIMPLE_NOP.

2020-08-04  Jakub Jelinek  

PR middle-end/96426
* tree-vect-generic.c (expand_vector_conversion): Replace
.VEC_CONVERT
call with GIMPLE_NOP if there is no lhs.

* gcc.c-torture/compile/pr96426.c: New test.

(cherry picked from commit 95f5a3258dd8a9584f2b10304f79441ef2d4c64c)

[Bug middle-end/96426] __builtin_convertvector ICE without lhs

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96426

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:95f5a3258dd8a9584f2b10304f79441ef2d4c64c

commit r11-2540-g95f5a3258dd8a9584f2b10304f79441ef2d4c64c
Author: Jakub Jelinek 
Date:   Tue Aug 4 11:33:18 2020 +0200

veclower: Don't ICE on .VEC_CONVERT calls with no lhs [PR96426]

.VEC_CONVERT is a const internal call, so normally if the lhs is not used,
we'd DCE it far before getting to veclower, but with -O0 (or perhaps
-fno-tree-dce and some other -fno-* options) it can happen.
But as the internal fn needs the lhs to know the type to which the
conversion is done (and I think that is a reasonable representation, having
some magic another argument and having to create constants with that type
looks overkill to me), we just should DCE those calls ourselves.
During veclower, we can't really remove insns, as the callers would be
upset, so this just replaces it with a GIMPLE_NOP.

2020-08-04  Jakub Jelinek  

PR middle-end/96426
* tree-vect-generic.c (expand_vector_conversion): Replace
.VEC_CONVERT
call with GIMPLE_NOP if there is no lhs.

* gcc.c-torture/compile/pr96426.c: New test.

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

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r11-2539-gfabe0ede9db9fa95832b2329d3d6156711905e20
Author: Jakub Jelinek 
Date:   Tue Aug 4 11:31:44 2020 +0200

gimple-fold: Fix ICE in maybe_canonicalize_mem_ref_addr on debug stmt
[PR96354]

In debug stmts, we are less strict about what is and what is not accepted
there, so this patch just punts on optimization of a debug stmt rather than
ICEing.

2020-08-04  Jakub Jelinek  

PR debug/96354
* gimple-fold.c (maybe_canonicalize_mem_ref_addr): Add IS_DEBUG
argument.  Return false instead of gcc_unreachable if it is true
and
get_addr_base_and_unit_offset returns NULL.
(fold_stmt_1) : Adjust caller.

* g++.dg/opt/pr96354.C: New test.

[Bug d/96429] d: Pointer subtraction uses TRUNC_DIV_EXPR

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96429

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

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

commit r11-2536-g3a3fda119036f46bfa70e06e7c69e04e78040079
Author: Iain Buclaw 
Date:   Mon Aug 3 22:35:38 2020 +0200

d: Fix PR96429: Pointer subtraction uses TRUNC_DIV_EXPR

gcc/d/ChangeLog:

PR d/96429
* expr.cc (ExprVisitor::visit (BinExp*)): Use EXACT_DIV_EXPR for
pointer diff expressions.

gcc/testsuite/ChangeLog:

PR d/96429
* gdc.dg/pr96429.d: New test.

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

2020-08-04 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:863de9321813f947018cc60b06ba163ddcfbb5f2

commit r11-2535-g863de9321813f947018cc60b06ba163ddcfbb5f2
Author: Paul Thomas 
Date:   Tue Aug 4 07:53:50 2020 +0100

Change testcase for pr96325 from run to compile.

2020-08-04  Paul Thomas  

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: Change from run to compile.

[Bug rtl-optimization/71309] Copying fields within a struct followed by use results in load hit store

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71309

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

https://gcc.gnu.org/g:265d817b1eb4644c7a9613ad6920315d98e2e0a4

commit r11-2526-g265d817b1eb4644c7a9613ad6920315d98e2e0a4
Author: Xionghu Luo 
Date:   Mon Aug 3 22:09:15 2020 -0500

dse: Remove partial load after full store for high part access[PR71309]

v5 update as comments:
1. Move const_rhs out of loop;
2. Iterate from int size for read_mode.

This patch could optimize(works for char/short/int/void*):

6: r119:TI=[r118:DI+0x10]
7: [r118:DI]=r119:TI
8: r121:DI=[r118:DI+0x8]

=>

6: r119:TI=[r118:DI+0x10]
16: r122:DI=r119:TI#8

Final ASM will be as below without partial load after full store(stxv+ld):
  ld 10,16(3)
  mr 9,3
  ld 3,24(3)
  std 10,0(9)
  std 3,8(9)
  blr

It could achieve ~25% performance improvement for typical cases on
Power9.  Bootstrap and regression tested on Power9-LE.

For AArch64, one ldr is replaced by mov with this patch:

ldp x2, x3, [x0, 16]
stp x2, x3, [x0]
ldr x0, [x0, 8]

=>

mov x1, x0
ldp x2, x0, [x0, 16]
stp x2, x0, [x1]

gcc/ChangeLog:

2020-08-04  Xionghu Luo  

PR rtl-optimization/71309
* dse.c (find_shift_sequence): Use subreg of shifted from high part
register to avoid loading from address.

gcc/testsuite/ChangeLog:

2020-08-04  Xionghu Luo  

PR rtl-optimization/71309
* gcc.target/powerpc/pr71309.c: New test.

[Bug c++/96218] DR 2032: Default template-arguments of variable templates

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96218

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

https://gcc.gnu.org/g:50bee766bc9f4020cf1f814178155d16e80dccaa

commit r11-2521-g50bee766bc9f4020cf1f814178155d16e80dccaa
Author: Marek Polacek 
Date:   Thu Jul 16 09:15:37 2020 -0400

c++: Variable template and template parameter pack [PR96218]

This is DR 2032 which says that the restrictions regarding template
parameter packs and default arguments apply to variable templates as
well, but we weren't detecting that.

gcc/cp/ChangeLog:

DR 2032
PR c++/96218
* pt.c (check_default_tmpl_args): Also consider variable
templates.

gcc/testsuite/ChangeLog:

DR 2032
PR c++/96218
* g++.dg/cpp1y/var-templ67.C: New test.

[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:

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

commit r10-8567-gfd2ec4542fd2975e6d3f2f1c1a2639945a84f9e1
Author: Jakub Jelinek 
Date:   Mon Aug 3 22:55:28 2020 +0200

aarch64: Fix up __aarch64_cas16_acq_rel fallback

As mentioned in the PR, the fallback path when LSE is unavailable writes
incorrect registers to the memory if the previous content compares equal
to x0, x1 - it writes copy of x0, x1 from the start of function, but it
should write x2, x3.

2020-08-03  Jakub Jelinek  

PR target/96402
* config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3
instead
of x(tmp0), x(tmp1) in STXP arguments.

* gcc.target/aarch64/pr96402.c: New test.

(cherry picked from commit 90b43856fdff7d96d93d22970eca8a86c56e0ddc)

[Bug target/96402] [10/11 Regression] Wrong code with -moutline-atomics

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:90b43856fdff7d96d93d22970eca8a86c56e0ddc

commit r11-2520-g90b43856fdff7d96d93d22970eca8a86c56e0ddc
Author: Jakub Jelinek 
Date:   Mon Aug 3 22:55:28 2020 +0200

aarch64: Fix up __aarch64_cas16_acq_rel fallback

As mentioned in the PR, the fallback path when LSE is unavailable writes
incorrect registers to the memory if the previous content compares equal
to x0, x1 - it writes copy of x0, x1 from the start of function, but it
should write x2, x3.

2020-08-03  Jakub Jelinek  

PR target/96402
* config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3
instead
of x(tmp0), x(tmp1) in STXP arguments.

* gcc.target/aarch64/pr96402.c: New test.

[Bug tree-optimization/96430] internal compiler error: in verify_range, at value-range.cc:354

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96430

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

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

commit r11-2512-g6c4763fa5b55f6e883ed7077b67c6175c2da63d1
Author: Aldy Hernandez 
Date:   Mon Aug 3 18:30:30 2020 +0200

Avoid shifting by amounts larger than target int in irange self-tests.

gcc/ChangeLog:

PR tree-optimization/96430
* range-op.cc (operator_tests): Do not shift by 31 on targets with
integer's smaller than 32 bits.

[Bug rtl-optimization/95696] regrename creates overlapping register allocations for vliw

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95696

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

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

commit r11-2507-gd1773f58f3a03e6c764373635fa079fa7526cfcf
Author: Yunde Zhong 
Date:   Mon Aug 3 15:05:02 2020 +0100

regrename: Avoid disrupting SMS schedule [PR95696]

SMS is performed before reload, and each insn in SMS schedule uses
pseudo-register.  After reload, regrename pass try to adjust the hard
registers with def/use chain created by build_def_use.  For now, regrename
pass isn't aware of VLIW bundles created by SMS, it may updated a register
which may not be really unused, which will causes invalid VLIW bundles.
Before the final schedule, we recheck the validation of VLIW bundles and
reschedule the conflicted insns to avoid the above issue.  Rescheduling
the conflicted insns will destroy SMS schedule of the kernel loop, which
would be harmful to performance.

2020-08-03  Yunde Zhong  

gcc/
PR rtl-optimization/95696
* regrename.c (regrename_analyze): New param include_all_block_p
with default value TRUE.  If set to false, avoid disrupting SMS
schedule.
* regrename.h (regrename_analyze): Adjust prototype.

[Bug lto/96385] [8/9/10/11 Regression] GCC generates separate debug info with undefined symbols without relocations

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385

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

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

commit r11-2506-gb32c5d0b72fda2588b4e170e75a9c64e4bf266c7
Author: Richard Biener 
Date:   Mon Aug 3 15:05:37 2020 +0200

lto/96385 - avoid unused global UNDEFs in debug objects

Unused global UNDEFs can have side-effects in some circumstances so
the following patch avoids them by treating them the same as other
to be discarded DEFs - make them local.

2020-08-03  Richard Biener  

PR lto/96385
libiberty/
* simple-object-elf.c
(simple_object_elf_copy_lto_debug_sections): Localize global
UNDEFs and reuse the prevailing name.

[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61494

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:919c9d4bd3db7da09061af3b6f2a9193bf7bae45

commit r11-2502-g919c9d4bd3db7da09061af3b6f2a9193bf7bae45
Author: Roger Sayle 
Date:   Mon Aug 3 13:15:58 2020 +0100

PR rtl-optimization 61494: Preserve x-0.0 with HONOR_SNANS.

The following patch avoids simplifying x-0.0 to x when -fsignaling-nans
is specified, which resolves PR rtl-optimization 61494.  Indeed, running
the test program attached to that PR now reports no failures.

2020-08-02  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/61494
* simplify-rtx.c (simplify_binary_operation_1) [MINUS]: Don't
simplify x - 0.0 with -fsignaling-nans.

[Bug d/96254] d: ICE using non-local variable: internal compiler error: Segmentation fault

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96254

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r11-2497-g2b1c2a4bd9fb555dccde5d67d6da64547064e0e6
Author: Iain Buclaw 
Date:   Tue Jul 21 19:59:00 2020 +0200

d: Fix ICE using non-local variable: internal compiler error: Segmentation
fault

Moves no frame access error to own function, adding use of it for both
when get_framedecl() cannot find a path to the outer function frame, and
guarding get_decl_tree() from recursively calling itself.

gcc/d/ChangeLog:

PR d/96254
* d-codegen.cc (error_no_frame_access): New.
(get_frame_for_symbol): Use fdparent name in error message.
(get_framedecl): Replace call to assert with error.
* d-tree.h (error_no_frame_access): Declare.
* decl.cc (get_decl_tree): Detect recursion and error.

gcc/testsuite/ChangeLog:

PR d/96254
* gdc.dg/pr96254a.d: New test.
* gdc.dg/pr96254b.d: New test.

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

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:

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

commit r10-8562-ga216daaa30bc8949086a16e7656f2025b692d03c
Author: Richard Sandiford 
Date:   Mon Aug 3 09:48:36 2020 +0100

c: Fix bogus vector initialisation error [PR96377]

One of the problems in this PR was that if we had:

  vector_type1 array[] = { vector_value1 };

process_init_element would only treat vector_value1 as initialising
a vector_type1 if they had the same TYPE_MAIN_VARIANT.  This has
several problems:

(1) It gives confusing error messages if the vector types are
incompatible.  (Tested by gcc.dg/pr96377-1.c.)

(2) It means that we reject code that should be valid with
-flax-vector-conversions.  (Tested by gcc.dg/pr96377-2.c.)

(3) On arm and aarch64 targets, it means that we reject some
initializers that mix Advanced SIMD and standard GNU vectors.
These vectors have traditionally had different TYPE_MAIN_VARIANTs
because they have different mangling schemes.  (Tested by
gcc.dg/pr96377-[3-6].c.)

(4) It means that we reject SVE initializers that should be valid.
(Tested by gcc.target/aarch64/sve/gnu_vectors_[34].c.)

(5) After r11-1741-g:31427b974ed7b7dd54e2 we reject:

  arm_neon_type1 array[] = { k ^ arm_neon_value1 };

because applying the binary operator to arm_neon_value1 strips
the "Advanced SIMD type" attributes that were added in that patch.
Stripping the attributes is problematic for other reasons though,
so that still needs to be fixed separately.

g++.target/aarch64/sve/gnu_vectors_[34].C already pass.

gcc/c/
PR c/96377
* c-typeck.c (process_init_element): Split test for whether to
recurse into a record, union or array into...
(initialize_elementwise_p): ...this new function.  Don't recurse
into a vector type if the initialization value is also a vector.

gcc/testsuite/
PR c/96377
* gcc.dg/pr96377-1.c: New test.
* gcc.dg/pr96377-2.c: Likewise.
* gcc.dg/pr96377-3.c: Likewise.
* gcc.dg/pr96377-4.c: Likewise.
* gcc.dg/pr96377-5.c: Likewise.
* gcc.dg/pr96377-6.c: Likewise.
* gcc.target/aarch64/pr96377-1.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_3.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_4.c: Likewise.
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_3.C:
Likewise.
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_4.C:
Likewise.

(cherry picked from commit 7d599ad27b9bcf5165f87710f1abc64bbabd06ae)

[Bug d/96250] d: Field access in parentheses causes error: need 'this' for 'field' of type 'type'

2020-08-03 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96250

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:442b5a661e312b27fc87f769834a2b58412a847a

commit r11-2493-g442b5a661e312b27fc87f769834a2b58412a847a
Author: Iain Buclaw 
Date:   Tue Jul 21 19:32:54 2020 +0200

d: Merge upstream dmd c2274e56a (PR96250).

1. Fixes an ICE in the front-end if a struct symbol were to appear twice
in the compilation unit.

2. Fixes a rejects-valid bug in the front-end where `(symbol)' was being
resolved as a `var' expression, instead of `this.var'.

Reviewed-on: https://github.com/dlang/dmd/pull/11436
 https://github.com/dlang/dmd/pull/11439

gcc/d/ChangeLog:

PR d/96250
* dmd/MERGE: Merge upstream dmd c2274e56a.

[Bug bootstrap/96404] [10 Regression] Bootstrap failure

2020-08-02 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96404

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

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

commit r11-2491-g6e46b3f3da5c03bc529b3690dd0995927feb9142
Author: Sergei Trofimovich 
Date:   Sun Aug 2 12:03:55 2020 +0100

var-tracking: fix uninitialised use of 'in_pending' [PR96404]

r11-2447-g:1212cfad093 ("Improve var-tracking dataflow
iteration order") changed 'in_pending' initialization
from:

in_pending = sbitmap_alloc (last_basic_block_for_fn (cfun));
bitmap_ones (in_pending);

to more complex partial bit population algorithm. Due to presence
of uninitialized bits gcc started injecting extra debug entries
in seemigly arbitrary locations and started failing stage2/stage3
bootstrap comparison.

valgrind detected unilitialized bits as:

  Conditional jump or move depends on uninitialised value(s)
 at 0xDBED3B: vt_find_locations() (var-tracking.c:7230)
 by 0xDBF2FB: variable_tracking_main_1() (var-tracking.c:10519)
 ...
   Uninitialised value was created by a heap allocation
 at 0x483779F: malloc (vg_replace_malloc.c:307)
 by 0x14EE80B: xmalloc (xmalloc.c:147)
 by 0x14911F9: sbitmap_alloc(unsigned int) (sbitmap.c:51)
 ...

The fix explicitly initializes 'in_pending' bitmap with zeros.

2020-08-02  Sergei Trofimovich  

gcc/

PR bootstrap/96404
* var-tracking.c (vt_find_locations): Fully initialize
all 'in_pending' bits.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-08-02 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

--- Comment #19 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-2489-ga5baf71b0a5bd79923c095cf81218b8194008f60
Author: Paul Thomas 
Date:   Sun Aug 2 10:57:59 2020 +0100

This patch fixes PR96320. See the explanatory comment in the testcase.

2020-08-01  Paul Thomas  

gcc/fortran
PR target/96320
* interface.c (gfc_check_dummy_characteristics): If a module
procedure arrives with assumed shape in the interface and
deferred shape in the procedure itself, update the latter and
copy the lower bounds.

gcc/testsuite/
PR target/96320
* gfortran.dg/module_procedure_4.f90 : New test.

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

2020-08-02 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-2487-ge41da82345fb01c4c2641c979a94a975d15312ab
Author: Paul Thomas 
Date:   Sun Aug 2 10:35:36 2020 +0100

This patch fixes PR96325. See the explanatory comment in the testcase.

2020-08-02  Paul Thomas  

gcc/fortran
PR fortran/96325
* primary.c (gfc_match_varspec): In the case that a component
reference is added to an intrinsic type component, emit the
error message in this function.

gcc/testsuite/
PR fortran/96325
* gfortran.dg/pr96325.f90: New test.
* gfortran.dg/pr91589.f90: Update error message.

[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg

2020-08-01 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96140

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Iain Buclaw
:

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

commit r9-8776-ga6e2dc45099d5d23dfeae245617f316e95ac646b
Author: Iain Buclaw 
Date:   Thu Jul 16 18:34:18 2020 +0200

d: Fix ICE in expand_intrinsic_vaarg

Both intrinsics did not handle the case where the va_list object comes
from a ref parameter.

gcc/d/ChangeLog:

PR d/96140
* intrinsics.cc (expand_intrinsic_vaarg): Handle ref parameters as
arguments to va_arg().
(expand_intrinsic_vastart): Handle ref parameters as arguments to
va_start().

gcc/testsuite/ChangeLog:

PR d/96140
* gdc.dg/pr96140.d: New test.

(cherry picked from commit dfc420f8d4492dbf5f45df4fecf93cb9645c0d7b)

[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg

2020-08-01 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96140

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

https://gcc.gnu.org/g:891bd1f15280def813bf6a363495d44951e13e04

commit r10-8558-g891bd1f15280def813bf6a363495d44951e13e04
Author: Iain Buclaw 
Date:   Thu Jul 16 18:34:18 2020 +0200

d: Fix ICE in expand_intrinsic_vaarg

Both intrinsics did not handle the case where the va_list object comes
from a ref parameter.

gcc/d/ChangeLog:

PR d/96140
* intrinsics.cc (expand_intrinsic_vaarg): Handle ref parameters as
arguments to va_arg().
(expand_intrinsic_vastart): Handle ref parameters as arguments to
va_start().

gcc/testsuite/ChangeLog:

PR d/96140
* gdc.dg/pr96140.d: New test.

(cherry picked from commit dfc420f8d4492dbf5f45df4fecf93cb9645c0d7b)

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

2020-08-01 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377

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

https://gcc.gnu.org/g:7d599ad27b9bcf5165f87710f1abc64bbabd06ae

commit r11-2481-g7d599ad27b9bcf5165f87710f1abc64bbabd06ae
Author: Richard Sandiford 
Date:   Sat Aug 1 12:41:28 2020 +0100

c: Fix bogus vector initialisation error [PR96377]

One of the problems in this PR was that if we had:

  vector_type1 array[] = { vector_value1 };

process_init_element would only treat vector_value1 as initialising
a vector_type1 if they had the same TYPE_MAIN_VARIANT.  This has
several problems:

(1) It gives confusing error messages if the vector types are
incompatible.  (Tested by gcc.dg/pr96377-1.c.)

(2) It means that we reject code that should be valid with
-flax-vector-conversions.  (Tested by gcc.dg/pr96377-2.c.)

(3) On arm and aarch64 targets, it means that we reject some
initializers that mix Advanced SIMD and standard GNU vectors.
These vectors have traditionally had different TYPE_MAIN_VARIANTs
because they have different mangling schemes.  (Tested by
gcc.dg/pr96377-[3-6].c.)

(4) It means that we reject SVE initializers that should be valid.
(Tested by gcc.target/aarch64/sve/gnu_vectors_[34].c.)

(5) After r11-1741-g:31427b974ed7b7dd54e2 we reject:

  arm_neon_type1 array[] = { k ^ arm_neon_value1 };

because applying the binary operator to arm_neon_value1 strips
the "Advanced SIMD type" attributes that were added in that patch.
Stripping the attributes is problematic for other reasons though,
so that still needs to be fixed separately.

g++.target/aarch64/sve/gnu_vectors_[34].C already pass.

gcc/c/
PR c/96377
* c-typeck.c (process_init_element): Split test for whether to
recurse into a record, union or array into...
(initialize_elementwise_p): ...this new function.  Don't recurse
into a vector type if the initialization value is also a vector.

gcc/testsuite/
PR c/96377
* gcc.dg/pr96377-1.c: New test.
* gcc.dg/pr96377-2.c: Likewise.
* gcc.dg/pr96377-3.c: Likewise.
* gcc.dg/pr96377-4.c: Likewise.
* gcc.dg/pr96377-5.c: Likewise.
* gcc.dg/pr96377-6.c: Likewise.
* gcc.target/aarch64/pr96377-1.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_3.c: Likewise.
* gcc.target/aarch64/sve/acle/general-c/gnu_vectors_4.c: Likewise.
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_3.C:
Likewise.
* g++.target/aarch64/sve/acle/general-c++/gnu_vectors_4.C:
Likewise.

[Bug c++/96182] GCC accepts constexpr function with no return-statement

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96182

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r11-2473-g5f9669d9e23a1116e040c80e0f3d4f43639bda52
Author: Jakub Jelinek 
Date:   Fri Jul 31 23:08:00 2020 +0200

c++: Use error_at rather than warning_at for missing return in constexpr
functions [PR96182]

For C++11 we already emit an error if a constexpr function doesn't contain
a return statement, because in C++11 that is the only thing it needs to
contain, but for C++14 we would normally issue a -Wreturn-type warning.

As mentioned by Jonathan, such constexpr functions are invalid, no
diagnostics required, because there doesn't exist any arguments for
which it would result in valid constant expression.

This raises it to an error in such cases.  The !LAMBDA_TYPE_P case
is to avoid error on g++.dg/pr81194.C where the user didn't write
constexpr anywhere and the operator() is compiler generated.

2020-07-31  Jakub Jelinek  

PR c++/96182
* decl.c (finish_function): In constexpr functions use for C++14
and
later error instead of warning if no return statement is present
and
diagnose it regardless of warn_return_type.  Move the
warn_return_type
diagnostics earlier in the function.

* g++.dg/cpp1y/constexpr-96182.C: New test.
* g++.dg/other/error35.C (S::g()): Add return statement.
* g++.dg/cpp1y/pr63996.C (foo): Likewise.
* g++.dg/cpp1y/constexpr-return2.C (f): Likewise.
* g++.dg/cpp1y/var-templ44.C (make_array): Add throw 1.

[Bug libstdc++/96382] [11 Regression] const_reverse_iterator() ctor is rejected in c++98

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96382

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-2465-g8abab28bb5c0cd80063518d47494cb6078767b89
Author: Jonathan Wakely 
Date:   Fri Jul 31 19:55:28 2020 +0100

libstdc++: Remove condition around friend declaration (PR 96382)

libstdc++-v3/ChangeLog:

PR libstdc++/96382
* include/bits/stl_iterator.h (reverse_iterator): Friend
declaration should not depend on __cplusplus.

[Bug target/90928] [9/10/11 Regression] [nvptx] internal compiler error: in instantiate_virtual_regs_in_insn, at function.c:1737

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90928

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

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

commit r11-2464-g3a4a92598014d33ef2c8b8ec38d8ad917812921a
Author: Roger Sayle 
Date:   Thu Jul 30 11:42:06 2020 +0200

nvptx: Define TARGET_TRULY_NOOP_TRUNCATION to false

Many thanks to Richard Biener for approving the midde-end
patch that cleared the way for this one.  This nvptx patch
defines the target hook TARGET_TRULY_NOOP_TRUNCATION to
false, indicating that integer truncations require explicit
instructions.  nvptx.c already defines TARGET_MODES_TIEABLE_P
and TARGET_CAN_CHANGE_MODE_CLASS to false, and as (previously)
documented that may require TARGET_TRULY_NOOP_TRUNCATION to
be defined likewise.

This patch decreases the number of unexpected failures in
the testsuite by 10, and increases the number of expected
passes by 4, including these previous FAILs/ICEs:
gcc.c-torture/compile/opout.c
gcc.dg/torture/pr79125.c
gcc.dg/tree-ssa/pr92085-1.c

Unfortunately there is one testsuite failure that used to
pass gcc.target/nvptx/v2si-cvt.c, but this isn't an ICE or
incorrect code.  This regression has been filed as PR96403,
and the failing scan-assembler directives have been replaced
by a reference to the PR.

This patch has been tested on nvptx-none hosted on
x86_64-pc-linux-gnu with "make" and "make check" with
fewer ICEs and no wrong code regressions.

2020-07-31  Roger Sayle  
Tom de Vries  

gcc/ChangeLog:

PR target/90928
* config/nvptx/nvptx.c (nvptx_truly_noop_truncation): Implement.
(TARGET_TRULY_NOOP_TRUNCATION): Define.

gcc/testsuite/ChangeLog:

* gcc.target/nvptx/v2si-cvt.c: Simplify source.  Remove
scan-assembler directives.  Mention PR96403.

[Bug d/96393] [11 regression] All 32-bit execution tests FAIL: internal error printing module cycle

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:239724956d4ef29dcaa7f1b378cc76f5f6a7ad5b

commit r11-2458-g239724956d4ef29dcaa7f1b378cc76f5f6a7ad5b
Author: Iain Buclaw 
Date:   Fri Jul 31 16:03:17 2020 +0200

d: Fix regression, all 32-bit execution tests FAIL: internal error printing
module cycle

For 32-bit btr(), BIT_NOT_EXPR was being generated twice, something that
was not seen with the 64-bit variant.  Removed the second call to fix
the generated code.

gcc/d/ChangeLog:

PR d/96393
* intrinsics.cc (expand_intrinsic_bt): Don't generate BIT_NOT_EXPR
for
btr32 intrinsic.

[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003

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

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

commit r11-2457-gdf5cf47a978aaeb53fc2b18ff0b22eb4531a27d8
Author: Martin Sebor 
Date:   Fri Jul 31 10:27:33 2020 -0600

Set and test no-warning bit to avoid -Wnonnull for synthesized expressions.

Resolves:
PR c++/96003 spurious -Wnonnull calling a member on the result of
static_cast

gcc/c-family/ChangeLog:

PR c++/96003
* c-common.c (check_function_arguments_recurse): Return early when
no-warning bit is set.

gcc/cp/ChangeLog:

PR c++/96003
* class.c (build_base_path): Set no-warning bit on the synthesized
conditional expression in static_cast.

gcc/testsuite/ChangeLog:

PR c++/96003
* g++.dg/warn/Wnonnull7.C: New test.

[Bug debug/96383] [8/9/10/11 Regression] Full ABI information missing from GCC compiled C

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383

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

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

commit r11-2455-gc6ef9d8d3f11221df1ea6358b8d4e79e42f074fb
Author: Richard Biener 
Date:   Thu Jul 30 11:46:43 2020 +0200

debug/96383 - emit debug info for used external functions

This makes sure to emit full declaration DIEs including
formal parameters for used external functions.  This helps
debugging when debug information of the external entity is
not available and also helps external tools cross-checking
ABI compatibility which was the bug reporters use case.

For cc1 this affects debug information size as follows:

 VM SIZE FILE SIZE
 ++ GROWING   ++
  [ = ]   0 .debug_info   +1.63Mi  +1.3%
  [ = ]   0 .debug_str +263Ki  +3.4%
  [ = ]   0 .debug_abbrev  +101Ki  +4.9%
  [ = ]   0 .debug_line   +5.71Ki  +0.0%
   +44% +16 [Unmapped]+48  +1.2%

 -- SHRINKING --
  [ = ]   0 .debug_loc   -213  -0.0%
  -0.0% -48 .text -48  -0.0%
  [ = ]   0 .debug_ranges -16  -0.0%

  -0.0% -32 TOTAL +1.99Mi  +0.6%

and DWARF compression via DWZ can only shave off minor bits
here.

Previously we emitted no DIEs for external functions at all
unless they were referenced via DW_TAG_GNU_call_site which
for some GCC revs caused a regular DIE to appear and since
GCC 4.9 only a stub without formal parameters.  This means
at -O0 we did not emit any DIE for external functions
but with optimization we emitted stubs.

2020-07-30  Richard Biener  

PR debug/96383
* langhooks-def.h (lhd_finalize_early_debug): Declare.
(LANG_HOOKS_FINALIZE_EARLY_DEBUG): Define.
(LANG_HOOKS_INITIALIZER): Amend.
* langhooks.c: Include cgraph.h and debug.h.
(lhd_finalize_early_debug): Default implementation from
former code in finalize_compilation_unit.
* langhooks.h (lang_hooks::finalize_early_debug): Add.
* cgraphunit.c (symbol_table::finalize_compilation_unit):
Call the finalize_early_debug langhook.

gcc/c-family/
* c-common.h (c_common_finalize_early_debug): Declare.
* c-common.c: Include debug.h.
(c_common_finalize_early_debug): finalize_early_debug langhook
implementation generating debug for extern declarations.

gcc/c/
* c-objc-common.h (LANG_HOOKS_FINALIZE_EARLY_DEBUG):
Define to c_common_finalize_early_debug.

gcc/cp/
* cp-objcp-common.h (LANG_HOOKS_FINALIZE_EARLY_DEBUG):
Define to c_common_finalize_early_debug.

gcc/testsuite/
* gcc.dg/debug/dwarf2/pr96383-1.c: New testcase.
* gcc.dg/debug/dwarf2/pr96383-2.c: Likewise.

libstdc++-v3/
* testsuite/20_util/assume_aligned/3.cc: Use -g0.

[Bug tree-optimization/96369] [8/9/10/11 Regression] Wrong evaluation order of || operator

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369

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

https://gcc.gnu.org/g:10231958fcfb13bc4847729eba21470c101b4a88

commit r11-2450-g10231958fcfb13bc4847729eba21470c101b4a88
Author: Richard Biener 
Date:   Fri Jul 31 08:41:56 2020 +0200

middle-end/96369 - fix missed short-circuiting during range folding

This makes the special case of constant evaluated LHS for a
short-circuiting or/and explicit rather than doing range
merging and eventually exposing a side-effect that shouldn't be
evaluated.

2020-07-31  Richard Biener  

PR middle-end/96369
* fold-const.c (fold_range_test): Special-case constant
LHS for short-circuiting operations.

* c-c++-common/pr96369.c: New testcase.

[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc

2020-07-31 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288

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

https://gcc.gnu.org/g:1212cfad09378bc85860a7de22dde0cf7a19fd01

commit r11-2447-g1212cfad09378bc85860a7de22dde0cf7a19fd01
Author: Richard Biener 
Date:   Fri Jul 24 13:44:09 2020 +0200

Improve var-tracking dataflow iteration order

This builds upon the rev_post_order_and_mark_dfs_back_seme improvements
and makes vt_find_locations iterate over the dataflow problems for
each toplevel SCC separately, improving memory locality and avoiding
to process nodes after the SCC before the SCC itself stabilized.

On the asan_interceptors.cc testcase this for example reduces the
number of visited blocks from 3751 to 2867.  For stage3-gcc
this reduces the number of visited blocks by ~4%.

2020-07-28  Richard Biener  

PR debug/78288
* var-tracking.c (vt_find_locations): Use
rev_post_order_and_mark_dfs_back_seme and separately iterate
over toplevel SCCs.

[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197

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

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

commit r11-2445-g8c00059ce058ea2aec2933319e270f5443b8b909
Author: Patrick Palka 
Date:   Thu Jul 30 22:21:41 2020 -0400

c++: decl_constant_value and unsharing [PR96197]

In the testcase from the PR we're seeing excessive memory use (> 5GB)
during constexpr evaluation, almost all of which is due to the call to
decl_constant_value in the VAR_DECL/CONST_DECL branch of
cxx_eval_constant_expression.  We reach here every time we evaluate an
ARRAY_REF of a constexpr VAR_DECL, and from there decl_constant_value
makes an unshared copy of the VAR_DECL's initializer.  But unsharing
here is unnecessary because callers of cxx_eval_constant_expression
already unshare its result when necessary.

To fix this excessive unsharing, this patch adds a new defaulted
parameter unshare_p to decl_really_constant_value and
decl_constant_value so that callers can control whether to unshare.

As a simplification, we can also move the call to unshare_expr in
constant_value_1 outside of the loop, since doing unshare_expr on a
DECL_P is a no-op.

Now that we no longer unshare the result of decl_constant_value and
decl_really_constant_value from cxx_eval_constant_expression, memory use
during constexpr evaluation for the testcase from the PR falls from ~5GB
to 15MB according to -ftime-report.

gcc/cp/ChangeLog:

PR c++/96197
* constexpr.c (cxx_eval_constant_expression) :
Pass false to decl_constant_value and decl_really_constant_value
so that they don't unshare their result.
* cp-tree.h (decl_constant_value): New declaration with an added
bool parameter.
(decl_really_constant_value): Add bool parameter defaulting to
true to existing declaration.
* init.c (constant_value_1): Add bool parameter which controls
whether to unshare the initializer before returning.  Call
unshare_expr at most once.
(scalar_constant_value): Pass true to constant_value_1's new
bool parameter.
(decl_really_constant_value): Add bool parameter and forward it
to constant_value_1.
(decl_constant_value): Likewise, but instead define a new
overload with an added bool parameter.

gcc/testsuite/ChangeLog:

PR c++/96197
* g++.dg/cpp1y/constexpr-array8.C: New test.

[Bug d/96152] d: associative array literals don't have alignment holes filled.

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96152

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:7508a7e958ea06eb311a4a106312634eaf6d40c3

commit r11-2443-g7508a7e958ea06eb311a4a106312634eaf6d40c3
Author: Iain Buclaw 
Date:   Sat Jul 18 17:14:54 2020 +0200

d: Fix associative array literals that don't have alignment holes filled

Associative array literal keys with alignment holes are now filled using
memset() prior to usage, with LTR evaluation of side-effects enforced.

gcc/d/ChangeLog:

PR d/96152
* d-codegen.cc (build_array_from_exprs): New function.
* d-tree.h (build_array_from_exprs): Declare.
* expr.cc (ExprVisitor::visit (AssocArrayLiteralExp *)): Use
build_array_from_exprs to generate key and value arrays.

gcc/testsuite/ChangeLog:

PR d/96152
* gdc.dg/pr96152.d: New test.

[Bug d/96154] d: Add -Wvarargs warning flag to compiler

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96154

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:873b45d39c14fee6b68032b83ea6bfbc023e3379

commit r11-2442-g873b45d39c14fee6b68032b83ea6bfbc023e3379
Author: Iain Buclaw 
Date:   Thu Jul 16 18:56:18 2020 +0200

d: Add -Wvarargs warning flag to the D front-end

The D front-end has C-style variadic functions and va_start/va_arg, so
it is right to also have warnings for inproper use.

gcc/d/ChangeLog:

PR d/96154
* gdc.texi (Warnings): Document -Wvarargs.
* lang.opt: Add -Wvarargs

gcc/testsuite/ChangeLog:

PR d/96154
* gdc.dg/pr96154a.d: New test.
* gdc.dg/pr96154b.d: New test.

[Bug d/96140] internal compiler error: in expand_intrinsic_vaarg

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96140

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

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

commit r11-2441-gdfc420f8d4492dbf5f45df4fecf93cb9645c0d7b
Author: Iain Buclaw 
Date:   Thu Jul 16 18:34:18 2020 +0200

d: Fix ICE in expand_intrinsic_vaarg

Both intrinsics did not handle the case where the va_list object comes
from a ref parameter.

gcc/d/ChangeLog:

PR d/96140
* intrinsics.cc (expand_intrinsic_vaarg): Handle ref parameters as
arguments to va_arg().
(expand_intrinsic_vastart): Handle ref parameters as arguments to
va_start().

gcc/testsuite/ChangeLog:

PR d/96140
* gdc.dg/pr96140.d: New test.

[Bug bootstrap/96202] --enable-cet complains about missing assembler support with GCC 7 host compiler

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202

--- Comment #3 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:4712bde3cabed644884a52386404765fca3b0ac2

commit r11-2430-g4712bde3cabed644884a52386404765fca3b0ac2
Author: H.J. Lu 
Date:   Wed Jul 15 06:16:01 2020 -0700

Require CET support only for the final GCC build

With --enable-cet, require CET support only for the final GCC build.
Don't enable CET without CET support for non-bootstrap build, in stage1
nor for build support.

config/

PR bootstrap/96202
* cet.m4 (GCC_CET_HOST_FLAGS): Don't enable CET without CET
support in stage1 nor for build support.

gcc/

PR bootstrap/96202
* configure: Regenerated.

libbacktrace/

PR bootstrap/96202
* configure: Regenerated.

libcc1/

PR bootstrap/96202
* configure: Regenerated.

libcpp/

PR bootstrap/96202
* configure: Regenerated.

libdecnumber/

PR bootstrap/96202
* configure: Regenerated.

libiberty/

PR bootstrap/96202
* configure: Regenerated.

lto-plugin/

PR bootstrap/96202
* configure: Regenerated.

[Bug tree-optimization/96370] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370

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

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

commit r11-2424-g2c558d2655cb22f472c83e8296b5cd2a92365cd3
Author: Richard Biener 
Date:   Thu Jul 30 10:24:42 2020 +0200

tree-optimization/96370 - make reassoc expr rewrite more robust

In the face of the more complex tricks in reassoc with respect
to negate processing it can happen that the expression rewrite
is fooled to recurse on a leaf and pick up a bogus expression
code.  The following patch makes the expression rewrite more
robust in providing the expression code to it directly since
it is the same for all operations in a chain.

2020-07-30  Richard Biener  

PR tree-optimization/96370
* tree-ssa-reassoc.c (rewrite_expr_tree): Add operation
code parameter and use it instead of picking it up from
the stmt that is being rewritten.
(reassociate_bb): Pass down the operation code.

* gcc.dg/pr96370.c: New testcase.

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435

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

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

commit r11-2422-gdc65aba7a4725d1b464c8c64a5f739ee910e8943
Author: Martin Liska 
Date:   Mon Jun 1 13:21:40 2020 +0200

Tune memcpy and memset for Zen cores.

Based on the collected numbers in PR95435, I suggest the following
tuning changes:

gcc/ChangeLog:

PR target/95435
* config/i386/x86-tune-costs.h: Use libcall for large sizes for
-m32. Start using libcall from 128+ bytes.

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

2020-07-30 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:809b4d226c7f5ded392a88ffafe8d652f911b473

commit r10-8554-g809b4d226c7f5ded392a88ffafe8d652f911b473
Author: Martin Liska 
Date:   Mon Jun 1 13:21:40 2020 +0200

Tune memcpy and memset for Zen cores.

Based on the collected numbers in PR95435, I suggest the following
tuning changes:

gcc/ChangeLog:

PR target/95435
* config/i386/x86-tune-costs.h: Use libcall for large sizes for
-m32. Start using libcall from 128+ bytes.

(cherry picked from commit dc65aba7a4725d1b464c8c64a5f739ee910e8943)

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

2020-07-29 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95486

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

https://gcc.gnu.org/g:71141b1bd537cc516e485c834c2d36abba3f4544

commit r11-2419-g71141b1bd537cc516e485c834c2d36abba3f4544
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:41 2020 -0400

c++: alias_ctad_tweaks and constrained dguide [PR95486]

In the below testcase, we're ICEing from alias_ctad_tweaks ultimately
because the implied deduction guide for X's user-defined constructor
already has constraints associated with it.  We then carry over these
constraints to 'fprime', the overlying deduction guide for the alias
template Y, via tsubst_decl from alias_ctad_tweaks.  Later in
alias_ctad_tweaks we call get_constraints followed by set_constraints
without doing remove_constraints in between, which triggers the !found
assert in set_constraints.

This patch fixes this issue by adding an intervening call to
remove_constraints.

gcc/cp/ChangeLog:

PR c++/95486
* pt.c (alias_ctad_tweaks): Call remove_constraints before
calling set_constraints.

gcc/testsuite/ChangeLog:

PR c++/95486
* g++.dg/cpp2a/class-deduction-alias3.C: New test.

[Bug c++/96106] [10/11 Regression] A friend abbreviated template function denies access to private members

2020-07-29 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96106

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

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

commit r11-2418-gf31dd9beb95f4beda1d2bd5c0526c42d0ce455c4
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:36 2020 -0400

c++: abbreviated function template friend matching [PR96106]

In the below testcase, duplicate_decls wasn't merging the tsubsted
friend declaration for 'void add(auto)' with its definition, because
reduce_template_parm_level (during tsubst_friend_function) lost the
DECL_VIRTUAL_P flag on the auto's invented template parameter, which
caused template_heads_equivalent_p to deem the two template heads as not
equivalent in C++20 mode.

This patch makes reduce_template_parm_level carry over the
DECL_VIRTUAL_P flag from the original TEMPLATE_PARM_DECL.

gcc/cp/ChangeLog:

PR c++/96106
* pt.c (reduce_template_parm_level): Propagate DECL_VIRTUAL_P
from the original TEMPLATE_PARM_DECL to the new lowered one.

gcc/testsuite/ChangeLog:

PR c++/96106
* g++.dg/concepts/abbrev7.C: New test.

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

2020-07-29 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194

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

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

commit r11-2420-g2c58f5cadfac338a67723fd6e41c9097760c4a33
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:44 2020 -0400

c++: overload sets and placeholder return type [PR64194]

In the testcase below, template argument deduction for the call
g(id) goes wrong because the functions in the overload set id
each have a yet-undeduced auto return type, and this undeduced return
type makes try_one_overload fail to match up any of the overloads with
g's parameter type, leading to g's template argument going undeduced and
to the overload set going unresolved.

This patch fixes this issue by performing return type deduction via
instantiation before doing try_one_overload, in a manner similar to what
resolve_address_of_overloaded_function does.

gcc/cp/ChangeLog:

PR c++/64194
* pt.c (resolve_overloaded_unification): If the function
template specialization has a placeholder return type,
then instantiate it before attempting unification.

gcc/testsuite/ChangeLog:

PR c++/64194
* g++.dg/cpp1y/auto-fn60.C: New test.

[Bug c++/96164] Constraints and explicit template instantiation

2020-07-29 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96164

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

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

commit r11-2417-gdc3d1e181445fafbbd146eb355a750c41c338794
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:33 2020 -0400

c++: constraints and explicit instantiation [PR96164]

When considering to instantiate a member of a class template as part of
an explicit instantiation of the class template, we need to first check
the member's constraints before proceeding with the instantiation of the
member.

gcc/cp/ChangeLog:

PR c++/96164
* constraint.cc (constraints_satisfied_p): Return true if
!flags_concepts.
* pt.c (do_type_instantiation): Update a paragraph taken from
[temp.explicit] to reflect the latest specification.  Don't
instantiate a member with unsatisfied constraints.

gcc/testsuite/ChangeLog:

PR c++/96164
* g++.dg/cpp2a/concepts-explicit-inst5.C: New test.

[Bug c++/91427] Implement P1825R0, Merged wording for P0527R1 and P1155R3

2020-07-29 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91427

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

https://gcc.gnu.org/g:1722e2013f05f1f1f99379dbaa0c0df356da731f

commit r11-2412-g1722e2013f05f1f1f99379dbaa0c0df356da731f
Author: Jason Merrill 
Date:   Tue Jul 21 00:19:49 2020 -0400

c++: Implement C++20 implicit move changes. [PR91427]

P1825R0 extends the C++11 implicit move on return by removing the
constraints on the called constructor: previously, it needed to take an
rvalue reference to the type of the returned variable.  The paper also
allows move on throw of parameters and implicit move of rvalue references.

Discussion on the CWG reflector about how to avoid breaking the PR91212
test
in the new model settled on the model of doing only a single overload
resolution, with the variable treated as an xvalue that can bind to
non-const lvalue references.  So this patch implements that approach.  The
implementation does not use the existing LOOKUP_PREFER_RVALUE flag, but
instead sets a flag on the representation of the static_cast turning the
variable into an xvalue.

For the time being I'm limiting the new semantics to C++20 mode; since it
was moved as a DR, we will probably want to apply the change to other
standard modes as well once we have a better sense of the impact on
existing
code, probably in GCC 12.

gcc/cp/ChangeLog:

PR c++/91427
* cp-tree.h (IMPLICIT_RVALUE_P): New.
(enum cp_lvalue_kind_flags): Add clk_implicit_rval.
(implicit_rvalue_p, set_implicit_rvalue_p): New.
* call.c (reference_binding): Check clk_implicit_rval.
(build_over_call): Adjust C++20 implicit move.
* coroutines.cc (finish_co_return_stmt): Simplify implicit move.
* except.c (build_throw): Adjust C++20 implicit move.
* pt.c (tsubst_copy_and_build) [STATIC_CAST_EXPR]: Propagate
IMPLICIT_RVALUE_P.
* tree.c (lvalue_kind): Set clk_implicit_rval.
* typeck.c (treat_lvalue_as_rvalue_p): Overhaul.
(maybe_warn_pessimizing_move): Adjust.
(check_return_expr): Adjust C++20 implicit move.

gcc/testsuite/ChangeLog:

PR c++/91427
* g++.dg/coroutines/co-return-syntax-10-movable.C: Extend.
* g++.dg/cpp0x/Wredundant-move1.C: Adjust for C++20.
* g++.dg/cpp0x/Wredundant-move7.C: Adjust for C++20.
* g++.dg/cpp0x/Wredundant-move9.C: Adjust for C++20.
* g++.dg/cpp0x/elision_neg.C: Adjust for C++20.
* g++.dg/cpp0x/move-return2.C: Adjust for C++20.
* g++.dg/cpp0x/ref-qual20.C: Adjust for C++20.
* g++.dg/cpp2a/implicit-move1.C: New test.
* g++.dg/cpp2a/implicit-move2.C: New test.
* g++.dg/cpp2a/implicit-move3.C: New test.

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

2020-07-29 Thread 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.

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

2020-07-29 Thread 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 debug/95096] Feature request: add -fsplit-dwarf

2020-07-29 Thread 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 fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

2020-07-29 Thread 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 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]

2020-07-29 Thread 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 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

2020-07-29 Thread 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 fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

2020-07-29 Thread 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 c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717

2020-07-29 Thread 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

2020-07-29 Thread 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)

  1   2   3   4   5   6   7   8   9   10   >