[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig  ---
See also https://xkcd.com/221/

[Bug target/91441] ICE in asan_shadow_offset at asan.c:342 on riscv64 target

[kito at gcc dot gnu.org]

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

kito at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kito at gcc dot gnu.org ---
Fixed

[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Really close.

[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |9.3

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed.

Re: [PATCH] PR target/91441 - Turn off -fsanitize=kernel-address if TARGET_ASAN_SHADOW_OFFSET is not implemented.

[Kito Cheng]

Hi Jeff:

Thanks, committed as r274631.

On Fri, Aug 16, 2019 at 11:51 PM Jeff Law  wrote:
>
> On 8/15/19 8:45 PM, Kito Cheng wrote:
> >  - -fsanitize=kernel-address will call targetm.asan_shadow_offset ()
> >at asan_shadow_offset, so it will crash if TARGET_ASAN_SHADOW_OFFSET
> >is not implemented, that's mean -fsanitize=kernel-address is not
> >supported for target without TARGET_ASAN_SHADOW_OFFSET implementation.
> >
> > gcc/ChangeLog:
> >
> >   PR target/91441
> >   * toplev.c (process_options): Check TARGET_ASAN_SHADOW_OFFSET is
> >   implemented for -fsanitize=kernel-address, and merge check logic
> >   with -fsanitize=address.
> >
> > testsuite/ChangeLog:
> >
> >   PR target/91441
> >   * gcc.target/riscv/pr91441.c: New.
> OK
> jeff

[Bug target/91441] ICE in asan_shadow_offset at asan.c:342 on riscv64 target

[kito at gcc dot gnu.org]

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

--- Comment #2 from kito at gcc dot gnu.org ---
Author: kito
Date: Mon Aug 19 03:21:44 2019
New Revision: 274631

URL: https://gcc.gnu.org/viewcvs?rev=274631=gcc=rev
Log:
PR target/91441 - Turn off -fsanitize=kernel-address if
TARGET_ASAN_SHADOW_OFFSET is not implemented.

 - -fsanitize=kernel-address will call targetm.asan_shadow_offset ()
   at asan_shadow_offset, so it will crash if TARGET_ASAN_SHADOW_OFFSET
   is not implemented, that's mean -fsanitize=kernel-address is not
   supported for target without TARGET_ASAN_SHADOW_OFFSET implementation.

gcc/ChangeLog:

PR target/91441
* toplev.c (process_options): Check TARGET_ASAN_SHADOW_OFFSET is
implemented for -fsanitize=kernel-address, and merge check logic
with -fsanitize=address.

testsuite/ChangeLog:

PR target/91441
* gcc.target/riscv/pr91441.c: New.

Added:
trunk/gcc/testsuite/gcc.target/riscv/pr91441.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/toplev.c

[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug 19 03:21:46 2019
New Revision: 274632

URL: https://gcc.gnu.org/viewcvs?rev=274632=gcc=rev
Log:
2019-08-18  Steven G. Kargl  

PR fortran/91485
module.c (gfc_match_use): User defined operator cannot conflict with
a rename symbol.

2019-08-18  Steven G. Kargl  

PR fortran/91485
* gfortran.dg/pr91485.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91485.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/module.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug 19 03:00:54 2019
New Revision: 274630

URL: https://gcc.gnu.org/viewcvs?rev=274630=gcc=rev
Log:
2019-08-18  Steven G. Kargl  

PR fortran/91485
module.c (gfc_match_use): User defined operator cannot conflict with
a rename symbol.

2019-08-18  Steven G. Kargl  

PR fortran/91485
* gfortran.dg/pr91485.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91485.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/91488] New: [9/10 Regression] char_traits::length causes "inlining failed in call to always_inline" error with -fgnu-tm -O2 -std=c++17

[rs2740 at gmail dot com]

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

Bug ID: 91488
   Summary: [9/10 Regression] char_traits::length causes "inlining
failed in call to always_inline" error with -fgnu-tm
-O2 -std=c++17
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

Repro (https://gcc.godbolt.org/z/RO-2Ec):

#include 

int main() {
auto z = std::char_traits::length("");
}

$ g++ -fgnu-tm -O2 -std=c++17

In file included from
/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/string:40,

 from :1:

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:
In static member function 'static constexpr std::size_t
std::char_traits::length(const char_type*)':

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:231:5:
error: inlining failed in call to 'always_inline' 'constexpr bool
std::__constant_string_p(const _CharT*) [with _CharT = char]': 

  231 | __constant_string_p(const _CharT* __s)

  | ^~~

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:332:25:
note: called from here

  332 |  if (__constant_string_p(__s))

  |  ~~~^

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:231:5:
error: inlining failed in call to 'always_inline' 'constexpr bool
std::__constant_string_p(const _CharT*) [with _CharT = char]': 

  231 | __constant_string_p(const _CharT* __s)

  | ^~~

/opt/compiler-explorer/gcc-trunk-20190818/include/c++/10.0.0/bits/char_traits.h:332:25:
note: called from here

  332 |  if (__constant_string_p(__s))

  |  ~~~^

[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

[helijia at gcc dot gnu.org]

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

Li Jia He  changed:

   What|Removed |Added

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

--- Comment #5 from Li Jia He  ---
This issue has been resolved on the trunk.

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Jason Merrill]

Ok, thanks.

On Sun, Aug 18, 2019, 6:26 PM Marek Polacek  wrote:

> On Sun, Aug 18, 2019 at 08:37:14PM -0400, Marek Polacek wrote:
> > Ok if that passes?
>
> Which it did.
>

[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

[helijia at gcc dot gnu.org]

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

Li Jia He  changed:

   What|Removed |Added

 CC||helijia at gcc dot gnu.org

--- Comment #4 from Li Jia He  ---
This question may not be as complicated as described.  May only have a more
important relationship with the setting of the vect-cost-model value
(rs6000_builtin_vectorization_cost).  And it has been vectorized on the current
trunk(subversion id 274560).

If we use the code that mike said(subversion id 248266), and compile option is 
```
-mcpu=power9 -O3 -ffast-math -fdump-tree-vect-details-all
-fdump-tree-slp-details-all
```
We can see the following analysis of vect-cost-model
```
m_amatvec.c:114:5: note: density 96%, cost 87 exceeds threshold, penalizing
loop body cost by 10%m_amatvec.c:114:5: note: Cost model analysis:
  Vector inside of loop cost: 92
  Vector prologue cost: 5
  Vector epilogue cost: 36
  Scalar iteration cost: 36
  Scalar outside cost: 1
  Vector outside cost: 41
  prologue iterations: 0
  epilogue iterations: 1
m_amatvec.c:114:5: note: cost model: the vector iteration cost = 92 divided by
the scalar iteration cost = 36 is greater or equal to the vectorization factor
= 2.
m_amatvec.c:114:5: note: not vectorized: vectorization not profitable.
m_amatvec.c:114:5: note: not vectorized: vector version will never be
profitable.
```
We can see that the value of ‘Vector inside of loop cost’ is 92, however (92 /
36 = 2) >= 2, which causes vect-cost-model to think that vector version will
never be profitable.

If we use the current trunk code(subversion id 274560), and compile option is 
```
-mcpu=power9 -O3 -ffast-math -fdump-tree-vect-details-all
-fdump-tree-slp-details-all
```
We can see the following analysis of vect-cost-model
```
m_amatvec.c:114:5: note:  Cost model analysis:
  Vector inside of loop cost: 60
  Vector prologue cost: 5
  Vector epilogue cost: 36
  Scalar iteration cost: 36
  Scalar outside cost: 1
  Vector outside cost: 41
  prologue iterations: 0
  epilogue iterations: 1
  Calculated minimum iters for profitability: 2
m_amatvec.c:114:5: note:Runtime profitability threshold = 2
m_amatvec.c:114:5: note:Static estimate profitability threshold = 2
```
At this point, we can see that the value of 'Vector inside of loop cost' is 60.
At this time (60 / 36 = 1) < 2, we think that vectorization can be profitable
at this time.

‘Vector inside of loop cost’ value change consists of 2 parts
  (1) The value of unaligned_store is reduced by ((3-1)*12)=24.
  (2) rs6000_density_test value is reduced by 8.

The change in the unaligned_store partial value fixed by the following patch.
```
commit 01cabe21e4ecae1e9c53fe12d7c0aa654143a3d2
Author: pthaugen 
Date:   Fri Oct 13 16:05:53 2017 +

* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost):
Remove
TARGET_P9_VECTOR code for unaligned_load case.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@253731
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fefac6e0c95..00be94fe349 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2017-10-13  Pat Haugen  
+
+   * config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Remove
+   TARGET_P9_VECTOR code for unaligned_load case.
+
 2017-10-13  Jan Hubicka  

* cfghooks.c (verify_flow_info): Check that edge probabilities are
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index e6e254ac041..b08cd316e68 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -5419,9 +5419,6 @@ rs6000_builtin_vectorization_cost (enum
vect_cost_for_stmt type_of_cost,
 return 3;

   case unaligned_load:
-   if (TARGET_P9_VECTOR)
- return 3;
-
if (TARGET_EFFICIENT_UNALIGNED_VSX)
  return 1;

```
The analysis of the changes in the rs6000_density_test part of the data is as
follows:
As the code below, the density penalty fixup **depends on** the vec_cost.
```
  if (density_pct > DENSITY_PCT_THRESHOLD
  && vec_cost + not_vec_cost > DENSITY_SIZE_THRESHOLD)
{
  data->cost[vect_body] = vec_cost * (100 + DENSITY_PENALTY) / 100;
  if (dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location,
 "density %d%%, cost %d exceeds threshold, penalizing "
 "loop body cost by %d%%", density_pct,
 vec_cost + not_vec_cost, DENSITY_PENALTY);
}
```
With the commit 253731, the vec_cost is reduced by 24 as you mentioned, the
`vec_cost + not_vec_cost` is less than DENSITY_SIZE_THRESHOLD, so it's fine.
(btw, not_vec_cost can be calculated as 3 from the previous dump.)

By the way, if we use this option -fvect-cost-model=unlimited, with the
‘unlimited’ model the vectorized code-path is assumed to be profitable while
with the ‘dynamic’ model a 

[Bug c++/91487] New: [concepts] alias constraint not respected

[frederik.engels24 at gmail dot com]

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

Bug ID: 91487
   Summary: [concepts] alias constraint not respected
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederik.engels24 at gmail dot com
  Target Milestone: ---

The following should fail to compile since it doesn't pass the only_int
constraint.

https://godbolt.org/z/HrB1wz (gcc version 10.0.0 20190817)

#include 

template
requires std::is_same_v
using only_int = T;

template
using forward = only_int;

int main()
{
forward f;
}

Re: [PATCH V2 8/8] bpf: add myself as the maintainer for the eBPF port

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> ChangeLog:
> 
>   * MAINTAINERS: Add myself as the maintainer for the eBPF port.
Will need steering committee approval, but I don't see that being
problematical.

jeff

Re: [PATCH V2 7/8] bpf: manual updates for eBPF

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> gcc/ChangeLog:
> 
>   * doc/invoke.texi (Option Summary): Cover eBPF.
>   (eBPF Options): New section.
>   * doc/extend.texi (BPF Built-in Functions): Likewise.
>   (BPF Kernel Helpers): Likewise.
This is likely fine once the port as a whole is accepted.

jeff

Re: [PATCH V2 6/8] bpf: adjust GCC testsuite to eBPF limitations

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch makes many tests in gcc.dg and gcc.c-torture to be skipped
> in bpf-*-* targets.  This is due to the many limitations imposed by
> eBPF to what would be perfectly valid C code: no support for indirect
> calls, no support for more than 5 arguments to function calls, no
> support for indirect jumps, a very limited range for direct jumps, the
> stack limit, lack of standard header files, etc.
> 
> Hopefully some of these restrictions will be relaxed in the future.
> In particular, I expect the stack limit will be significantly
> increased at some point.  Also, as semantics associated with object
> linking get developed in eBPF, it may be possible at some point to
> provide a set of standard run-time libraries for eBPF programs.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.dg/builtins-config.h: eBPF doesn't support C99 standard
>   functions.
>   * gcc.c-torture/compile/2211-1.c: Skip if target bpf-*-*.
>   * gcc.c-torture/compile/2403-1.c: Likewise.
>   * gcc.c-torture/compile/2609-1.c: Likewise.
>   * gcc.c-torture/compile/2804-1.c: Likewise.
>   * gcc.c-torture/compile/20001226-1.c: Likewise.
>   * gcc.c-torture/compile/20010102-1.c: Likewise.
>   * gcc.c-torture/compile/20010107-1.c: Likewise.
>   * gcc.c-torture/compile/20011109-1.c: Likewise.
>   * gcc.c-torture/compile/20011218-1.c: Likewise.
>   * gcc.c-torture/compile/20011229-1.c: Likewise.
>   * gcc.c-torture/compile/20020129-1.c: Likewise.
>   * gcc.c-torture/compile/20020304-1.c: Likewise.
>   * gcc.c-torture/compile/20020320-1.c: Likewise.
>   * gcc.c-torture/compile/20020604-1.c: Likewise.
>   * gcc.c-torture/compile/20020706-1.c: Likewise.
>   * gcc.c-torture/compile/20020706-2.c: Likewise.
>   * gcc.c-torture/compile/20021015-1.c: Likewise.
>   * gcc.c-torture/compile/20021205-1.c: Likewise.
>   * gcc.c-torture/compile/20030903-1.c: Likewise.
>   * gcc.c-torture/compile/20030921-1.c: Likewise.
>   * gcc.c-torture/compile/20031023-1.c: Likewise.
>   * gcc.c-torture/compile/20031023-2.c: Likewise.
>   * gcc.c-torture/compile/20031023-3.c: Likewise.
>   * gcc.c-torture/compile/20031023-4.c: Likewise.
>   * gcc.c-torture/compile/20031125-1.c: Likewise.
>   * gcc.c-torture/compile/20040101-1.c: Likewise.
>   * gcc.c-torture/compile/20040317-2.c: Likewise.
>   * gcc.c-torture/compile/20040614-1.c: Likewise.
>   * gcc.c-torture/compile/20040726-1.c: Likewise.
>   * gcc.c-torture/compile/20040909-1.c: Likewise.
>   * gcc.c-torture/compile/20050122-1.c: Likewise.
>   * gcc.c-torture/compile/20050202-1.c: Likewise.
>   * gcc.c-torture/compile/20050303-1.c: Likewise.
>   * gcc.c-torture/compile/20050622-1.c: Likewise.
>   * gcc.c-torture/compile/20051216-1.c: Likewise.
>   * gcc.c-torture/compile/20060208-1.c: Likewise.
>   * gcc.c-torture/compile/20060421-1.c: Likewise.
>   * gcc.c-torture/compile/20071207-1.c: Likewise.
>   * gcc.c-torture/compile/20080903-1.c: Likewise.
>   * gcc.c-torture/compile/20081108-1.c: Likewise.
>   * gcc.c-torture/compile/20101217-1.c: Likewise.
>   * gcc.c-torture/compile/20121027-1.c: Likewise.
>   * gcc.c-torture/compile/20150327.c: Likewise.
>   * gcc.c-torture/compile/20151204.c: Likewise.
>   * gcc.c-torture/compile/900313-1.c: Likewise.
>   * gcc.c-torture/compile/920428-2.c: Likewise.
>   * gcc.c-torture/compile/920501-12.c: Likewise.
>   * gcc.c-torture/compile/920501-4.c: Likewise.
>   * gcc.c-torture/compile/920501-7.c: Likewise.
>   * gcc.c-torture/compile/920625-1.c: Likewise.
>   * gcc.c-torture/compile/920723-1.c: Likewise.
>   * gcc.c-torture/compile/920928-5.c: Likewise.
>   * gcc.c-torture/compile/921202-1.c: Likewise.
>   * gcc.c-torture/compile/930117-1.c: Likewise.
>   * gcc.c-torture/compile/930421-1.c: Likewise.
>   * gcc.c-torture/compile/930607-1.c: Likewise.
>   * gcc.c-torture/compile/930623-1.c: Likewise.
>   * gcc.c-torture/compile/931003-1.c: Likewise.
>   * gcc.c-torture/compile/931004-1.c: Likewise.
>   * gcc.c-torture/compile/950719-1.c: Likewise.
>   * gcc.c-torture/compile/951222-1.c: Likewise.
>   * gcc.c-torture/compile/961004-1.c: Likewise.
>   * gcc.c-torture/compile/980504-1.c: Likewise.
>   * gcc.c-torture/compile/980816-1.c: Likewise.
>   * gcc.c-torture/compile/990517-1.c: Likewise.
>   * gcc.c-torture/compile/990625-1.c: Likewise.
>   * gcc.c-torture/compile/991213-2.c: Likewise.
>   * gcc.c-torture/compile/DFcmp.c: Likewise.
>   * gcc.c-torture/compile/HIcmp.c: Likewise.
>   * gcc.c-torture/compile/HIset.c: Likewise.
>   * gcc.c-torture/compile/QIcmp.c: Likewise.
>   * gcc.c-torture/compile/QIset.c: Likewise.
>   * gcc.c-torture/compile/SFset.c: Likewise.
>   * gcc.c-torture/compile/SIcmp.c: Likewise.
>   * 

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Marek Polacek]

On Sun, Aug 18, 2019 at 08:37:14PM -0400, Marek Polacek wrote:
> Ok if that passes?

Which it did.

Re: [PATCH V2 5/8] bpf: make target-supports.exp aware of eBPF

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch makes the several effective target checks in
> target-supports.exp to be aware of eBPF targets.
> 
> gcc/testsuite/ChangeLog:
> 
>   * lib/target-supports.exp (check_effective_target_malloc): New
>   function.
>   (check_effective_target_trampolines): Adapt to eBPF.
>   (check_effective_target_stack_size): Likewise.
>   (dg-effective-target-value): Likewise.
>   (check_effective_target_indirect_jumps): Likewise.
>   (check_effective_target_nonlocal_goto): Likewise.
>   (check_effective_target_global_constructor): Likewise.
>   (check_effective_target_return_address): Likewise.
> ---
>  gcc/testsuite/ChangeLog   | 11 +++
>  gcc/testsuite/lib/target-supports.exp | 27 +++
>  2 files changed, 30 insertions(+), 8 deletions(-)
> 
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 300d22a2d65..8b6168626d8 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
>  
> @@ -546,7 +550,11 @@ proc check_effective_target_stack_size { } {
>  proc dg-effective-target-value { effective_target } {
>  if { "$effective_target" == "stack_size" } {
>   if [check_effective_target_stack_size] {
> - return [target_info gcc,stack_size]
> + if [istarget bpf-*-*] {
> + return "512"
> + } else {
> + return [target_info gcc,stack_size]
> + }
>   }
>  }
Shouldn't the BPF stack size be defined be in your target files?


The ChangeLog mentions check_effective_target_malloc, but I don't see it
in the patch itself.  Note that it needs to be documented in
gcc/doc/sourcebuild.texi as well if you are adding a new
check_effective_target_

jeff

Re: [PATCH V2 4/8] bpf: gcc.target eBPF testsuite

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch adds a new testsuite to gcc.target, with eBPF specific
> tests.
> 
> Tests are included for:
> - Target specific diagnostics.
> - All built-in functions.
> 
> testsuite/ChangeLog:
> 
>   * gcc.target/bpf/bpf.exp: New file.
>   * gcc.target/bpf/builtin-load.c: Likewise.
>   * cc.target/bpf/constant-calls.c: Likewise.
>   * gcc.target/bpf/diag-funargs.c: Likewise.
>   * cc.target/bpf/diag-indcalls.c: Likewise.
>   * gcc.target/bpf/helper-bind.c: Likewise.
>   * cc.target/bpf/helper-bpf-redirect.c: Likewise.
>   * gcc.target/bpf/helper-clone-redirect.c: Likewise.
>   * gcc.target/bpf/helper-csum-diff.c: Likewise.
>   * gcc.target/bpf/helper-csum-update.c: Likewise.
>   * gcc.target/bpf/helper-current-task-under-cgroup.c: Likewise.
>   * gcc.target/bpf/helper-fib-lookup.c: Likewise.
>   * gcc.target/bpf/helper-get-cgroup-classid.c: Likewise.
>   * gcc.target/bpf/helper-get-current-cgroup-id.c: Likewise.
>   * gcc.target/bpf/helper-get-current-comm.c: Likewise.
>   * gcc.target/bpf/helper-get-current-pid-tgid.c: Likewise.
>   * gcc.target/bpf/helper-get-current-task.c: Likewise.
>   * gcc.target/bpf/helper-get-current-uid-gid.c: Likewise.
>   * gcc.target/bpf/helper-get-hash-recalc.c: Likewise.
>   * gcc.target/bpf/helper-get-listener-sock.c: Likewise.
>   * gcc.target/bpf/helper-get-local-storage.c: Likewise.
>   * gcc.target/bpf/helper-get-numa-node-id.c: Likewise.
>   * gcc.target/bpf/helper-get-prandom-u32.c: Likewise.
>   * gcc.target/bpf/helper-get-route-realm.c: Likewise.
>   * gcc.target/bpf/helper-get-smp-processor-id.c: Likewise.
>   * gcc.target/bpf/helper-get-socket-cookie.c: Likewise.
>   * gcc.target/bpf/helper-get-socket-uid.c: Likewise.
>   * gcc.target/bpf/helper-getsockopt.c: Likewise.
>   * gcc.target/bpf/helper-get-stack.c: Likewise.
>   * gcc.target/bpf/helper-get-stackid.c: Likewise.
>   * gcc.target/bpf/helper-ktime-get-ns.c: Likewise.
>   * gcc.target/bpf/helper-l3-csum-replace.c: Likewise.
>   * gcc.target/bpf/helper-l4-csum-replace.c: Likewise.
>   * gcc.target/bpf/helper-lwt-push-encap.c: Likewise.
>   * gcc.target/bpf/helper-lwt-seg6-action.c: Likewise.
>   * gcc.target/bpf/helper-lwt-seg6-adjust-srh.c: Likewise.
>   * gcc.target/bpf/helper-lwt-seg6-store-bytes.c: Likewise.
>   * gcc.target/bpf/helper-map-delete-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-lookup-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-peek-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-pop-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-push-elem.c: Likewise.
>   * gcc.target/bpf/helper-map-update-elem.c: Likewise.
>   * gcc.target/bpf/helper-msg-apply-bytes.c: Likewise.
>   * gcc.target/bpf/helper-msg-cork-bytes.c: Likewise.
>   * gcc.target/bpf/helper-msg-pop-data.c: Likewise.
>   * gcc.target/bpf/helper-msg-pull-data.c: Likewise.
>   * gcc.target/bpf/helper-msg-push-data.c: Likewise.
>   * gcc.target/bpf/helper-msg-redirect-hash.c: Likewise.
>   * gcc.target/bpf/helper-msg-redirect-map.c: Likewise.
>   * gcc.target/bpf/helper-override-return.c: Likewise.
>   * gcc.target/bpf/helper-perf-event-output.c: Likewise.
>   * gcc.target/bpf/helper-perf-event-read.c: Likewise.
>   * gcc.target/bpf/helper-perf-event-read-value.c: Likewise.
>   * gcc.target/bpf/helper-perf-prog-read-value.c: Likewise.
>   * gcc.target/bpf/helper-probe-read.c: Likewise.
>   * gcc.target/bpf/helper-probe-read-str.c: Likewise.
>   * gcc.target/bpf/helper-probe-write-user.c: Likewise.
>   * gcc.target/bpf/helper-rc-keydown.c: Likewise.
>   * gcc.target/bpf/helper-rc-pointer-rel.c: Likewise.
>   * gcc.target/bpf/helper-rc-repeat.c: Likewise.
>   * gcc.target/bpf/helper-redirect-map.c: Likewise.
>   * gcc.target/bpf/helper-set-hash.c: Likewise.
>   * gcc.target/bpf/helper-set-hash-invalid.c: Likewise.
>   * gcc.target/bpf/helper-setsockopt.c: Likewise.
>   * gcc.target/bpf/helper-skb-adjust-room.c: Likewise.
>   * gcc.target/bpf/helper-skb-cgroup-id.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-head.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-proto.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-tail.c: Likewise.
>   * gcc.target/bpf/helper-skb-change-type.c: Likewise.
>   * gcc.target/bpf/helper-skb-ecn-set-ce.c: Likewise.
>   * gcc.target/bpf/helper-skb-get-tunnel-key.c: Likewise.
>   * gcc.target/bpf/helper-skb-get-tunnel-opt.c: Likewise.
>   * gcc.target/bpf/helper-skb-get-xfrm-state.c: Likewise.
>   * gcc.target/bpf/helper-skb-load-bytes.c: Likewise.
>   * gcc.target/bpf/helper-skb-load-bytes-relative.c: Likewise.
>   * gcc.target/bpf/helper-skb-pull-data.c: Likewise.
>   * gcc.target/bpf/helper-skb-set-tunnel-key.c: Likewise.
>   * 

Re: [PATCH V2 3/8] bpf: new libgcc port

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
> This patch adds an eBPF port to libgcc.
> 
> As of today, compiled eBPF programs do not support a single-entry
> point schema.  Instead, a BPF "executable" is a relocatable ELF object
> file containing multiple entry points, in certain named sections.
> 
> Also, the BPF loaders in the kernel do not execute .ini/.fini
> constructors/destructors.  Therefore, this patch provides empty crtn.S
> and cri.S files.
> 
> libgcc/ChangeLog:
> 
>   * config.host: Set cpu_type for bpf-*-* targets.
>   * config/bpf/t-bpf: Likewise.
>   * config/bpf/crtn.S: Likewise.
>   * config/bpf/crti.S: New file.

> diff --git a/libgcc/config/bpf/crti.S b/libgcc/config/bpf/crti.S
> new file mode 100644
> index 000..e69de29bb2d
> diff --git a/libgcc/config/bpf/crtn.S b/libgcc/config/bpf/crtn.S
> new file mode 100644
> index 000..e69de29bb2d
> diff --git a/libgcc/config/bpf/t-bpf b/libgcc/config/bpf/t-bpf
> new file mode 100644
> index 000..c1bda7c98cb
> --- /dev/null
> +++ b/libgcc/config/bpf/t-bpf
> @@ -0,0 +1,24 @@
> +HOST_LIBGCC2_CFLAGS += -O0
> +LIB2ADDEH = 
I'd like to understand the motivation behind the -O0, but otherwise I
don't see anything particularly concerning here.

Jeff

Re: [PATCH V2 1/8] Update config.sub and config.guess.

[Jeff Law]

On 8/16/19 6:50 PM, Jose E. Marchesi wrote:
>   * config.sub: Import upstream version 2019-06-30.
>   * config.guess: Import upstream version 2019-07-24.
Similar to the runtimes and such where we're downstream resyncing to the
upstream sources is always OK in stage1.  Feel free to commit whenever
you want.

jeff

[RFA] [PR tree-optimization/80576] Handle strcpy and strcpy_chk in DSE

[Jeff Law]

So this builds on the previous DSE patch to add handling of strcpy and
resolves the remainder of 80576.

Recall there's two cases to consider.

If the strcpy is the first store (ie, potentially dead), then the
conservative choice when setting up the ao_ref is to take the smaller of
the destination object's size and the maximum length of the source string.

For the second store (ie, the killing store) we want the minimum of the
length of the source string when setting up the ao_ref.

We do not handle trimming in the case of a partially dead call to
strcpy.  We only handle cases where it's fully dead.


Bootstrapped and regression tested on x86_64, i686, aarch64, ppc64,
ppc64le, s390x & sparc64.

Also built and tested the various *-elf targets with no regressions.  I
also verified the new test passes on all those targets.

Several other targets have been bootstrapped (alpha, m68k, various arm*
things, mipsisa32r2, riscv64 and others).


OK for the trunk?

Jeff



PR tree-optimization/80576
* tree-ssa-dse.c (initialize_ao_ref_for_dse): Handle strcpy and
strcpy_chk.
(dse_dom_walker::dse_optimize_stmt): Similarly.
 
* gcc.dg/tree-ssa/ssa-dse-41.c: New test.

commit 24f60672cacb4da2ae898ec7e90bd55f52073954
Author: Jeff Law 
Date:   Fri Aug 9 18:13:50 2019 -0400

MOre DSE improvements

Add test

diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index ae03980f792..47907617aaf 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -181,6 +181,56 @@ initialize_ao_ref_for_dse (gimple *stmt, ao_ref *write, 
bool maxlen)
return true;
  }
 
+   case BUILT_IN_STRCPY:
+   case BUILT_IN_STRCPY_CHK:
+ {
+   tree dest = gimple_call_arg (stmt, 0);
+   tree src = gimple_call_arg (stmt, 1);
+   tree size = NULL_TREE;
+
+   /* Get the range of the length of the source string.  */
+   c_strlen_data src_data = { };
+   if (get_range_strlen (src, _data, 1))
+ {
+   size = maxlen ? src_data.maxlen : src_data.minlen;
+
+   /* Adjust the source length to account for NUL terminator.  */
+   size = fold_build2 (PLUS_EXPR, TREE_TYPE (size), size, 
integer_one_node);
+ }
+
+   /* If we are asking for the minimum size and did not get a usable
+  size from get_range_strlen, then the minimum size would be zero
+  and there's nothing we can do.   If we were asking for the
+  maximum size, then we can try and get a size from the destination
+  object.  */
+   if (!maxlen && !size)
+ return false;
+
+   /* If we did not get a size from the source operand, then try to
+  get it from the size of the destination object's type.
+
+  If we got a size from the source operand, then choose the
+  minimum of the size from the operand and the size we got
+  from the input operand.  In theory the latter would be
+  sufficient, but the size from the input operand is a range
+  and could, in theory, be larger than the output buffer
+  due to imprecision in the computation of the size.  */
+   tree dest_size = objsize_from_type (dest);
+   if (!size)
+ size = dest_size;
+   else if (dest_size)
+ size = fold_build2 (MIN_EXPR, TREE_TYPE (dest_size),
+ dest_size, size);
+
+   /* If we still don't have size information, then assume we can
+  not analyze this case.  */
+   if (!size)
+ return false;
+
+   ao_ref_init_from_ptr_and_size (write, dest, size);
+   return true;
+ }
+
/* A calloc call can never be dead, but it can make
   subsequent stores redundant if they store 0 into
   the same memory locations.  */
@@ -1078,6 +1128,26 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator 
*gsi)
return;
  }
 
+   case BUILT_IN_STRCPY:
+   case BUILT_IN_STRCPY_CHK:
+ {
+   enum dse_store_status store_status;
+   m_byte_tracking_enabled
+ = setup_live_bytes_from_ref (, m_live_bytes);
+   store_status = dse_classify_store (, stmt,
+  m_byte_tracking_enabled,
+  m_live_bytes);
+   if (store_status == DSE_STORE_LIVE)
+ return;
+
+   /* We don't handle trimming these calls, though we might
+  be able to trim a strcpy into a strncpy for example.  */
+
+   if (store_status == DSE_STORE_DEAD)
+ delete_dead_or_redundant_call (gsi, "dead");
+   break;
+ }
+
case BUILT_IN_CALLOC:
  /* We already know the arguments are integer constants.  */
  dse_optimize_redundant_stores (stmt);
diff 

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Marek Polacek]

On Sun, Aug 18, 2019 at 05:08:07PM -0700, Jason Merrill wrote:
> On 8/18/19 6:52 AM, Marek Polacek wrote:
> > On Fri, Aug 16, 2019 at 05:40:39PM -0700, Jason Merrill wrote:
> > > On 8/16/19 5:11 AM, Marek Polacek wrote:
> > > > On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:
> > > > > On 8/15/19 5:34 PM, Marek Polacek wrote:
> > > > > > On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:
> > > > > > > On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> > > > > > > > > On 8/6/19 3:20 PM, Marek Polacek wrote:
> > > > > > > > > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill 
> > > > > > > > > > wrote:
> > > > > > > > > > > On 7/31/19 3:26 PM, Marek Polacek wrote:
> > > > > > > > > > > > One of the features of constexpr is that it doesn't 
> > > > > > > > > > > > allow UB; and such UB must
> > > > > > > > > > > > be detected at compile-time.  So running your code in a 
> > > > > > > > > > > > context that requires
> > > > > > > > > > > > a constant expression should ensure that the code in 
> > > > > > > > > > > > question is free of UB.
> > > > > > > > > > > > In effect, constexpr can serve as a sanitizer.  E.g. 
> > > > > > > > > > > > this article describes in
> > > > > > > > > > > > in more detail:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > [dcl.type.cv]p4 says "Any attempt to modify a const 
> > > > > > > > > > > > object during its lifetime
> > > > > > > > > > > > results in undefined behavior." However, as the article 
> > > > > > > > > > > > above points out, we
> > > > > > > > > > > > aren't detecting that case in constexpr evaluation.
> > > > > > > > > > > > 
> > > > > > > > > > > > This patch fixes that.  It's not that easy, though, 
> > > > > > > > > > > > because we have to keep in
> > > > > > > > > > > > mind [class.ctor]p5:
> > > > > > > > > > > > "A constructor can be invoked for a const, volatile or 
> > > > > > > > > > > > const volatile object.
> > > > > > > > > > > > const and volatile semantics are not applied on an 
> > > > > > > > > > > > object under construction.
> > > > > > > > > > > > They come into effect when the constructor for the most 
> > > > > > > > > > > > derived object ends."
> > > > > > > > > > > > 
> > > > > > > > > > > > I handled this by keeping a hash set which tracks 
> > > > > > > > > > > > objects under construction.
> > > > > > > > > > > > I considered other options, such as going up 
> > > > > > > > > > > > call_stack, but that wouldn't
> > > > > > > > > > > > work with trivial constructor/op=.  It was also 
> > > > > > > > > > > > interesting to find out that
> > > > > > > > > > > > the definition of TREE_HAS_CONSTRUCTOR says "When 
> > > > > > > > > > > > appearing in a FIELD_DECL,
> > > > > > > > > > > > it means that this field has been duly initialized in 
> > > > > > > > > > > > its constructor" though
> > > > > > > > > > > > nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR 
> > > > > > > > > > > > on a FIELD_DECL as far
> > > > > > > > > > > > as I can see.  Unfortunately, using this bit proved 
> > > > > > > > > > > > useless for my needs here.
> > > > > > > > > > > 
> > > > > > > > > > > > Also, be mindful of mutable subobjects.
> > > > > > > > > > > > 
> > > > > > > > > > > > Does this approach look like an appropriate strategy 
> > > > > > > > > > > > for tracking objects'
> > > > > > > > > > > > construction?
> > > > > > > > > > > 
> > > > > > > > > > > For scalar objects, we should be able to rely on 
> > > > > > > > > > > INIT_EXPR vs. MODIFY_EXPR
> > > > > > > > > > > to distinguish between initialization and modification; 
> > > > > > > > > > > for class objects, I
> > > > > > > > > > 
> > > > > > > > > > This is already true: only class object go into the hash 
> > > > > > > > > > set.
> > > > > > > > > > 
> > > > > > > > > > > wonder about setting a flag on the CONSTRUCTOR after 
> > > > > > > > > > > initialization is
> > > > > > > > > > > complete to indicate that the value is now constant.
> > > > > > > > > > 
> > > > > > > > > > But here we're not dealing with CONSTRUCTORs in the gcc 
> > > > > > > > > > sense (i.e. exprs with
> > > > > > > > > > TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y 
> > > > > > > > > > ((struct Y *) ),
> > > > > > > > > > which initializes the object "y".  Setting a flag on the 
> > > > > > > > > > CALL_EXPR or its underlying
> > > > > > > > > > function decl wouldn't help.
> > > > > > > > > > 
> > > > > > > > > > Am I missing something?
> > > > > > > > > 
> > > > > > > > > I was thinking that where in your current patch you call
> > > > > > > > > remove_object_under_construction, we could instead mark the 
> > > > > > > > > object's value
> > > > > > > > > CONSTRUCTOR as immutable.
> > > > > > > > 
> > > > 

[Bug fortran/91485] [10 Regression] Erroneous conflict between variable x and operator(.x.)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org
   Severity|normal  |enhancement

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Jason Merrill]

On 8/18/19 6:52 AM, Marek Polacek wrote:

On Fri, Aug 16, 2019 at 05:40:39PM -0700, Jason Merrill wrote:

On 8/16/19 5:11 AM, Marek Polacek wrote:

On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:

On 8/15/19 5:34 PM, Marek Polacek wrote:

On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:

On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  wrote:


On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:

On 8/6/19 3:20 PM, Marek Polacek wrote:

On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:

On 7/31/19 3:26 PM, Marek Polacek wrote:

One of the features of constexpr is that it doesn't allow UB; and such UB must
be detected at compile-time.  So running your code in a context that requires
a constant expression should ensure that the code in question is free of UB.
In effect, constexpr can serve as a sanitizer.  E.g. this article describes in
in more detail:


[dcl.type.cv]p4 says "Any attempt to modify a const object during its lifetime
results in undefined behavior." However, as the article above points out, we
aren't detecting that case in constexpr evaluation.

This patch fixes that.  It's not that easy, though, because we have to keep in
mind [class.ctor]p5:
"A constructor can be invoked for a const, volatile or const volatile object.
const and volatile semantics are not applied on an object under construction.
They come into effect when the constructor for the most derived object ends."

I handled this by keeping a hash set which tracks objects under construction.
I considered other options, such as going up call_stack, but that wouldn't
work with trivial constructor/op=.  It was also interesting to find out that
the definition of TREE_HAS_CONSTRUCTOR says "When appearing in a FIELD_DECL,
it means that this field has been duly initialized in its constructor" though
nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a FIELD_DECL as far
as I can see.  Unfortunately, using this bit proved useless for my needs here.



Also, be mindful of mutable subobjects.

Does this approach look like an appropriate strategy for tracking objects'
construction?


For scalar objects, we should be able to rely on INIT_EXPR vs. MODIFY_EXPR
to distinguish between initialization and modification; for class objects, I


This is already true: only class object go into the hash set.


wonder about setting a flag on the CONSTRUCTOR after initialization is
complete to indicate that the value is now constant.


But here we're not dealing with CONSTRUCTORs in the gcc sense (i.e. exprs with
TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y ((struct Y *) ),
which initializes the object "y".  Setting a flag on the CALL_EXPR or its 
underlying
function decl wouldn't help.

Am I missing something?


I was thinking that where in your current patch you call
remove_object_under_construction, we could instead mark the object's value
CONSTRUCTOR as immutable.


Ah, what you meant was to look at DECL_INITIAL of the object we're
constructing, which could be a CONSTRUCTOR.  Unfortunately, this
DECL_INITIAL is null (in all the new tests when doing
remove_object_under_construction), so there's nothing to mark as TREE_READONLY 
:/.


There's a value in ctx->values, isn't there?


Doesn't seem to be the case for e.g.

struct A {
 int n;
 constexpr A() : n(1) { n = 2; }
};

struct B {
 const A a;
 constexpr B(bool b) {
   if (b)
 const_cast(a).n = 3; // { dg-error "modifying a const object" }
   }
};

constexpr B b(false);
static_assert(b.a.n == 2, "");

Here we're constructing "b", its ctx->values->get(new_obj) is initially
"{}".  In the middle of constructing "b", we construct "b.a", but that
has nothing in ctx->values.


Right, subobjects aren't in ctx->values.  In cxx_eval_call_expression we
have

if (DECL_CONSTRUCTOR_P (fun))
  /* This can be null for a subobject constructor call, in

 which case what we care about is the initialization

 side-effects rather than the value.  We could get at the

 value by evaluating *this, but we don't bother; there's

 no need to put such a call in the hash table.  */
  result = lval ? ctx->object : ctx->ctor;

Your patch already finds *this (b.a) and puts it in new_obj; if it's const
we can evaluate it to get the CONSTRUCTOR to set TREE_READONLY on.


Ah, got it!  This patch uses setting TREE_READONLY to achieve what I was after.
I also needed to set TREE_READONLY in cxx_eval_constant_expression/DECL_EXPR.
The additional evaluating will only happen for const-qual objects so I hope not
very often.

Any further comments?  Thanks,

@@ -1910,6 +1958,29 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree 
t,

+ /* At this point, the object's constructor will have run, so
+the object is 

[Bug libstdc++/91486] future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration

[john.salmon at deshaw dot com]

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

--- Comment #2 from John Salmon  ---
The same incorrect logic that was fixed in bug 68519 is present in the
implementations of future::wait_for and shared_timed_mutex::wait_for.  The fix
should be the same:  explicitly duration_cast the __rtime argument to
__clock::duration before adding to __clock::now().  Fixes are required in
shared_mutex and bits/atomic_futex.h.

The attached code demonstrates the problem.  wait_for either waits too long or
too short.  Output is:

drdws0134$ garden with -m gcc/8.1.0-01c7/bin g++ -std=c++14 futurewait.cpp
-pthread && ./a.out
ERROR - future::wait_for took too short: t1 looping: 0 milliseconds
0 second
t2 looping: 0 second
ERROR - shared_timed_mutex::try_lock_shared took too short: 0 milliseconds
t2 looping: 1 second
t1 looping: 1 second
t2 looping: 2 second
t1 looping: 2 second
t2 looping: 3 second
t1 looping: 3 second
t2 looping: 4 second
t1 looping: 4 second

[Bug libstdc++/91486] future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration

[john.salmon at deshaw dot com]

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

--- Comment #1 from John Salmon  ---
Created attachment 46727
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46727=edit
demonstration code

[Bug libstdc++/91486] New: future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration

[john.salmon at deshaw dot com]

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

Bug ID: 91486
   Summary: future::wait_for and shared_timed_mutex::wait_for do
not work properly with float duration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.salmon at deshaw dot com
  Target Milestone: ---

gcc-10-20190818 is now available

[gccadmin]

Snapshot gcc-10-20190818 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/10-20190818/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 274625

You'll find:

 gcc-10-20190818.tar.xz   Complete GCC

  SHA256=bf95c2937c54e7de24504fb16fceecb8dce962270b558d3b4869d4169e57aeb6
  SHA1=2b10fb55b097baf3638e39c51d0974deb4080f26

Diffs from 10-20190811 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Created attachment 46726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46726=edit
Much better patch

It a) does not try to do two things at once, and b) has passed
regression-testing at least once.

[Bug fortran/91485] New: [10 Regression] Erroneous conflict between variable x and operator(.x.)

[anlauf at gcc dot gnu.org]

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

Bug ID: 91485
   Summary: [10 Regression] Erroneous conflict between variable x
and operator(.x.)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46725
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46725=edit
Minimal reproducer

The attached valid code suddenly fails with current 10-trunk:

gfcbug155.f90:23:26:

   23 |   subroutine print_prod (x, y)
  |  1
   24 | use foo, only: cartesian, operator(.x.)
  |   2
Error: Symbol 'x' at (1) conflicts with the symbol at (2)
gfcbug155.f90:26:19:

   26 | type(cartesian), intent(in)  :: x, y
  |   1
Error: Derived type 'cartesian' at (1) is being used before it is defined
gfcbug155.f90:23:26:

   23 |   subroutine print_prod (x, y)
  |  1
Error: Symbol 'x' at (1) has no IMPLICIT type
gfcbug155.f90:23:29:

   23 |   subroutine print_prod (x, y)
  | 1
Error: Symbol 'y' at (1) has no IMPLICIT type

The regression is most likely introduced in the last 2 days.

Note that it is important that the USE statement is placed in the contained
subroutine, not at module level.

[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #16 from Iain Sandoe  ---
fixed for 9.3

Re: [PATCH, sanitizer] Wrap rethrow_primary_exception (PR 87880).

[Iain Sandoe]

> On 16 Jun 2019, at 19:58, Jakub Jelinek  wrote:
> 
> On Sun, Jun 16, 2019 at 07:54:42PM +0100, Iain Sandoe wrote:

>> Actually, because the way in which interposing works for Darwin is 
>> different, the only
>> symbol change in the library on Darwin is removing an "undefined dynamic 
>> lookup".
>> So, for back-ports, I can could up with some Darwin-specific Makefike change 
>> that
>> only adds the ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0 for Darwin.
>> 
>> So - OK for trunk with a bumped soname?
> 
> Yes.
> 
>> (and a TODO to figure a Darwin-only backport)
> 
> Yeah.

This turned out to be easier than I’d expected, since there was already a 
Darwin-specific
guard in the Makefile.

Tested on x86_64-darwin{11,13,14,16,17,18}, x86_64,powerpc64-linux-gnu
(that the symbol is not removed for the Linux cases).

Applied to the 9 branch for 9.3
Iain

libsanitizer/

2019-08-18  Iain Sandoe  

Backport from mainline
2019-06-18  Iain Sandoe  

PR libsanitizer/87880
* asan/asan_interceptors.h:
(ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION): New.
* asan/Makefile.am (DEFS): Add (for Darwin only)
ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION, defined to 0.
* asan/Makefile.in: Regenerated.


diff --git a/libsanitizer/asan/Makefile.am b/libsanitizer/asan/Makefile.am
index 867240d244..6efbc1df7f 100644
--- a/libsanitizer/asan/Makefile.am
+++ b/libsanitizer/asan/Makefile.am
@@ -5,7 +5,7 @@ gcc_version := $(shell @get_gcc_base_ver@ 
$(top_srcdir)/../gcc/BASE-VER)
 
 DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 
-DCAN_SANITIZE_UB=0
 if USING_MAC_INTERPOSE
-DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT
+DEFS += -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT 
-DASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION=0
 endif
 AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic 
-Wno-long-long  -fPIC -fno-builtin -fno-exceptions -fno-rtti 
-fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros 
-fno-ipa-icf
 AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)

diff --git a/libsanitizer/asan/asan_interceptors.h 
b/libsanitizer/asan/asan_interceptors.h
index b599ebb0ba..beb1dc9532 100644
--- a/libsanitizer/asan/asan_interceptors.h
+++ b/libsanitizer/asan/asan_interceptors.h
@@ -79,7 +79,12 @@ void InitializePlatformInterceptors();
 #if ASAN_HAS_EXCEPTIONS && !SANITIZER_WINDOWS && !SANITIZER_SOLARIS && \
 !SANITIZER_NETBSD
 # define ASAN_INTERCEPT___CXA_THROW 1
-# define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# if ! defined(ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION) \
+ || ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 1
+# else
+#   define ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION 0
+# endif
 # if defined(_GLIBCXX_SJLJ_EXCEPTIONS) || (SANITIZER_IOS && defined(__arm__))
 #  define ASAN_INTERCEPT__UNWIND_SJLJ_RAISEEXCEPTION 1
 # else

[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe  ---
Author: iains
Date: Sun Aug 18 19:11:29 2019
New Revision: 274625

URL: https://gcc.gnu.org/viewcvs?rev=274625=gcc=rev
Log:
Darwin, libsanitizer - remove reference to __cxa_rethrow_primary_exception.

For some Darwin versions the absence of the rethrow_primary_exception
symbol causes almost all sanitizer tests to fail.
The symbol is not present in libstdc++ and, therefore is is correct to
remove the reference to it for all platforms.  We do this by adding a
new guard "ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION".

For the backported version, to avoid bumping the library version, this
is only applied for Darwin (because of the way that symbol interposing
works on Darwin, this does not alter the exported symbols list).

libsanitizer/

2019-08-18  Iain Sandoe  


Backport from mainline
2019-06-18  Iain Sandoe  

PR libsanitizer/87880
* asan/asan_interceptors.h:
(ASAN_INTERCEPT___CXA_RETHROW_PRIMARY_EXCEPTION): New.
* asan/Makefile.am (DEFS): Add (for Darwin only)
ASAN_HAS_CXA_RETHROW_PRIMARY_EXCEPTION, defined to 0.
* asan/Makefile.in: Regenerated.


Modified:
branches/gcc-9-branch/libsanitizer/ChangeLog
branches/gcc-9-branch/libsanitizer/asan/Makefile.am
branches/gcc-9-branch/libsanitizer/asan/Makefile.in
branches/gcc-9-branch/libsanitizer/asan/asan_interceptors.h

[Darwin, fixincludes, committed] Fix PR83531

[Iain Sandoe]

There is no reasonable chance that the SDKs in question will be re-
issued, so the only viable solution is a fixincludes.

tested on x86_64-darwin, x86_64-linux-gnu, powerpc64-linux-gnu
(fixincludes tests pass on linux)
applied to mainline,
Iain

2019-08-18  C.G. Dogan 
Iain Sandoe  

PR target/83531
* inclhack.def (darwin_api_availability): New, strip leading
underscores from API_ defines.
* fixincl.x: Regenerate.
* tests/base/os/availability.h: New file.

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 861532c2a1..3c6b48d26e 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -194,6 +194,33 @@ fix = {
_EndOfHeader_;
 };
 
+/*
+ *  SDKs for 10.13 and 10.14 omit the definitions for API_AVAILABLE where
+ *  __attribute__((availability)) is not supported.
+ */
+fix = {
+hackname  = darwin_api_availability;
+mach  = "*-*-darwin*";
+files = os/availability.h;
+bypass= "__IPHONE_OS_VERSION_MIN_REQUIRED";
+select=
+" *#define __API_AVAILABLE.*\n"
+" *#define __API_DEPRECATED.*\n"
+" *#define __API_DEPRECATED_WITH_REPLACEMENT.*\n"
+" *#define __API_UNAVAILABLE.*\n";
+c_fix = format;
+c_fix_arg =
+"#define API_AVAILABLE(...)\n"
+"#define API_DEPRECATED(...)\n"
+"#define API_DEPRECATED_WITH_REPLACEMENT(...)\n"
+"#define API_UNAVAILABLE(...)\n";
+test_text =
+"#define __API_AVAILABLE(...)\n"
+"#define __API_DEPRECATED(...)\n"
+"#define __API_DEPRECATED_WITH_REPLACEMENT(...)\n"
+"#define __API_UNAVAILABLE(...)\n";
+};
+
 /*
  *  This fixes __FD_ZERO bug for linux 2.x.y (x <= 2 && y <= some n)
  */
diff --git a/fixincludes/tests/base/os/availability.h 
b/fixincludes/tests/base/os/availability.h
new file mode 100644
index 00..e8696b14ac
--- /dev/null
+++ b/fixincludes/tests/base/os/availability.h
@@ -0,0 +1,18 @@
+/*  DO NOT EDIT THIS FILE.
+
+It has been auto-edited by fixincludes from:
+
+   "fixinc/tests/inc/os/availability.h"
+
+This had to be done to correct non-standard usages in the
+original, manufacturer supplied header file.  */
+
+
+
+#if defined( DARWIN_API_AVAILABILITY_CHECK )
+#define API_AVAILABLE(...)
+#define API_DEPRECATED(...)
+#define API_DEPRECATED_WITH_REPLACEMENT(...)
+#define API_UNAVAILABLE(...)
+
+#endif  /* DARWIN_API_AVAILABILITY_CHECK */

[Bug target/83531] Build broken on macOS 10.13.2

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

--- Comment #12 from Iain Sandoe  ---
so fixed for trunk so far.

[Bug target/83531] Build broken on macOS 10.13.2

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
Author: iains
Date: Sun Aug 18 18:54:13 2019
New Revision: 274624

URL: https://gcc.gnu.org/viewcvs?rev=274624=gcc=rev
Log:
[Darwin, fixincludes] Fix PR83531

There is no reasonable chance that the SDKs in question will be re-
issued, so the only viable solution is a fixincludes.

2019-08-18  C.G. Dogan 
Iain Sandoe  

PR target/83531
* inclhack.def (darwin_api_availability): New, strip leading
underscores from API_ defines.
* fixincl.x: Regenerate.
* tests/base/os/availability.h: New file.


Added:
trunk/fixincludes/tests/base/os/availability.h
Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def

[Darwin, PPC, committed] Fix fail of cpp/assert4.c

[Iain Sandoe]

Despite that the cpp assert facility is deprecated, we do have a test
for it.

This test needs the cpu and machine asserts to be implemented
which hadn't been done for PPC Darwin.  Fixed thus.

tested on powerpc-darwin9,
applied to mainline,
Iain

gcc/

2019-08-18  Iain Sandoe  

* config/rs6000/darwin.h (TARGET_OS_CPP_BUILTINS): Add asserts
for cpu and machine.  Factor 64/32b builtins.

diff --git a/gcc/config/rs6000/darwin.h b/gcc/config/rs6000/darwin.h
index 150dc4f4cd..a626325c2d 100644
--- a/gcc/config/rs6000/darwin.h
+++ b/gcc/config/rs6000/darwin.h
@@ -52,11 +52,23 @@
 #define TARGET_OS_CPP_BUILTINS()   \
   do   \
 {  \
-  if (!TARGET_64BIT) builtin_define ("__ppc__");   \
-  if (!TARGET_64BIT) builtin_define ("__PPC__");   \
-  if (TARGET_64BIT) builtin_define ("__ppc64__");  \
-  if (TARGET_64BIT) builtin_define ("__PPC64__");  \
   builtin_define ("__POWERPC__");  \
+  builtin_define ("__PPC__");  \
+  if (TARGET_64BIT)\
+   {   \
+ builtin_define ("__ppc64__"); \
+ builtin_define ("__PPC64__"); \
+ builtin_define ("__powerpc64__"); \
+ builtin_assert ("cpu=powerpc64"); \
+ builtin_assert ("machine=powerpc64"); \
+   }   \
+  else \
+   {   \
+ builtin_define ("__ppc__");   \
+ builtin_define_std ("PPC");   \
+ builtin_assert ("cpu=powerpc");   \
+ builtin_assert ("machine=powerpc");   \
+   }   \
   builtin_define ("__NATURAL_ALIGNMENT__");\
   darwin_cpp_builtins (pfile); \
 }  \

[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Eric Botcazou  ---
OK, I can reproduce, thanks.

[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
I can reproduce the SEGV with the gmp-6.1.2 release tarball and gcc-8.3 on
sparc64-linux, making either a 32-bit or a 64-bit build of gmp, using gmp's
defaults (not overriding CC or CFLAGS).

[Bug lto/64636] Bootstrapping gcc-4.9.2 fails if lto is enabled

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
I can confirm that disabling LTO on sparc64 makes gcc build fine.

[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #3 from John Paul Adrian Glaubitz  ---
It can reproduced by simply cloning the gmp repo, building it and running the
testsuite:

$ hg clone https://gmplib.org/repo/gmp
$ cd gmp
$ ./.bootstrap && ./configure --enable-cxx --enable-fat --build
sparc64-linux-gnu && make -j32 && make check

Switching gcc versions can be achieved by just setting the CC variable, e.g.:

$ export CC=gcc-8

[Bug target/91472] gmp testsuite segfaults with gcc-8 and gcc-9, works fine with gcc-7

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-08-18
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
We need a reproducer (or at least instructions to reproduce).

Re: [PATCH][DOC] Define email limit for gcc-patches mailing list.

[Gerald Pfeifer]

On Tue, 30 Apr 2019, Martin Liška wrote:
>>> This would fix bug 89770 if/when you commit it, btw:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89770
> Thanks for useful comments, I've included all of them (except kB change).
> Feel free to see current version at https://gcc.gnu.org/lists.html

Thank you!  This whole thing caused a bit of a deja vu for me since
I already had fixed PR89770 earlier on.  Turns out it got stuck in a 
local tree, so you had to replicate that work. :-o

Gerald

[PATCH,i386] Don't use errno when freestanding (was: config/i386/xmmintrin.h: Only #include if __STDC_HOSTED__)

[Gerald Pfeifer]

On Sat, 9 Dec 2017, Jakub Jelinek wrote:
>> Some users on FreeBSD noticed a problem when trying to use GCC to
>> build things in a standalone environment that manifests itself as
>> 
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/xmmintrin.h:34 
>> from
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/immintrin.h:29 
>> from
>> /workspace/src/sys/crypto/aesni/intel_sha256.c:62 
>> In function '_mm_malloc':
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.0/6.3.0/include/mm_malloc.h:39: 
>> error: 'errno' undeclared (first use in this function)
>> 
>> It turns out the clang version of xmmintrin.h does not include mm_malloc.h 
>> if !__STDC_HOSTED__ whereas ours unconditionally does so.
> 
> Wouldn't it be better to just ifdef out parts of gmm_malloc.h (pmm_malloc.h
> should be ok)?

Very good point, Jakub.  Thank you!  

Somehow I thought I had submitted this updated patch, but apparently 
not so. :-(  (This has been on my autotester for ages.)

Okay?  And if so, okay for GCC 9 after a while?

Gerald


2019-08-18  Gerald Pfeifer  
 
* config/i386/gmm_malloc.h: Only include errno.h and use errno
if __STDC_HOSTED__.
 
Index: config/i386/gmm_malloc.h
===
--- config/i386/gmm_malloc.h(revision 274618)
+++ config/i386/gmm_malloc.h(working copy)
@@ -25,7 +25,9 @@
 #define _MM_MALLOC_H_INCLUDED
 
 #include 
+#if __STDC_HOSTED__
 #include 
+#endif
 
 static __inline__ void * 
 _mm_malloc (size_t __size, size_t __align)
@@ -36,7 +38,9 @@ _mm_malloc (size_t __size, size_t __align)
   /* Error if align is not a power of two.  */
   if (__align & (__align - 1))
 {
+#if __STDC_HOSTED__
   errno = EINVAL;
+#endif
   return ((void *) 0);
 }
 

[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros

[frankhb1989 at gmail dot com]

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

--- Comment #2 from frankhb1989 at gmail dot com ---
I agree the problem of 'L' is not likely found as a real issue in practice.

Perhaps this could be forwarded as an issue of the standard which requires
overspecified definitions. I don't find any intentional use cases about relying
on the exactly specified type. (Despite the range limitation of int, the macro
expansion results can be specified as "integer literal equal to the
corresponding numerical values specified in the table" and a note about
intentionally unspecified types.)

[Bug c++/91484] New: Error message: std::is_constructible with incomplete types.

[asschool at yandex dot ru]

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

Bug ID: 91484
   Summary: Error message: std::is_constructible with incomplete
types.
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asschool at yandex dot ru
  Target Milestone: ---

https://godbolt.org/z/BGkt7T
https://godbolt.org/z/EyDV9s
GCC correctly(i suppose) reports UB in the first example, but not in the second
one.

Real-life example:
https://godbolt.org/z/gSkmMW

[Bug c++/91483] Poor diagnostic on trying to take constexpr reference to non-static object

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-18
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Yup, that's true.  I'll add it onto my list.

[Bug c++/91483] New: Poor diagnostic on trying to take constexpr reference to non-static object

[barry.revzin at gmail dot com]

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

Bug ID: 91483
   Summary: Poor diagnostic on trying to take constexpr reference
to non-static object
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider:

struct X {
int const& var;
};

void foo() {
constexpr int i = 42;
constexpr X x{i};
}

This is ill-formed because i doesn't have static storage duration. But the
error gcc provides is:

: In function 'void foo()':
:7:20: error: 'const X{i}' is not a constant expression
7 | constexpr X x{i};
  |^

It would be a lot nicer if the diagnostic here explained the reason that this
isn't a constant expression.

[Bug rtl-optimization/91482] New: __builtin_assume_aligned should not break write combining

[msharov at users dot sourceforge.net]

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

Bug ID: 91482
   Summary: __builtin_assume_aligned should not break write
combining
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

void write64 (void* p)
{
unsigned* p1 = (unsigned*) __builtin_assume_aligned (p, 8);
*p1++ = 0;
unsigned* p2 = (unsigned*) __builtin_assume_aligned (p1, 4);
*p2++ = 1;
}

When the two stores are written without __builtin_assume_aligned, they are
coalesced into a single movq store. The code above, however, results in two
movl stores, even though the new information provided by
__builtin_assume_aligned does not prevent combination.

[Bug target/91481] New: POWER9 "DARN" RNG intrinsic produces repeated output

[lloyd at randombit dot net]

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

Bug ID: 91481
   Summary: POWER9 "DARN" RNG intrinsic produces repeated output
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lloyd at randombit dot net
  Target Milestone: ---

The POWER9 ISA includes a hardware random number generator "DARN" which is
similar to x86 RDRAND/RDSEED. Using the GCC intrinsics and *any optimization
level* then `__builtin_darn()` and `__builtin_darn_raw()` produce repeated
output:

$ cat darn.c
#include 
#include 

int main()
{
  uint64_t darn[32];
  for(size_t i = 0; i != 32; ++i)
darn[i] = __builtin_darn(); // or __builtin_darn_raw()

  for(size_t i = 0; i != 32; ++i)
printf("%016lX\n", darn[i]);

}
$ $HOME/opt/bin/powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/home/lloyd/opt/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/lloyd/opt/libexec/gcc/powerpc64le-unknown-linux-gnu/9.2.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc-9.2.0/configure --prefix=/home/lloyd/opt
--enable-languages=c,c++
Thread model: posix
gcc version 9.2.0 (GCC)
$ $HOME/opt/bin/powerpc64le-unknown-linux-gnu-gcc -mcpu=power9 -O -m64 darn.c
-o darn
$ ./darn
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
32A7727F89101CF3
...


The binary produces a unique value each time it is executed, but the same value
repeats. If no optimization is used, then different values are produced. Since
these instructions are supposed to be used to seed cryptographic random number
generators, this is quite bad. I don't know PPC asm but my read of the
generated code when optimizations are enabled is that `darn` is invoked just
once and then the value is placed repeatedly into the array - maybe GCC has not
been taught that this instruction is volatile and produces a different output
each time it is used?

Originally observed with "gcc version 8.3.1 20190304 (Advance-Toolchain-at12.0)
[revision 269374] (GCC)" on gcc135, same behavior with stock GCC 9.2.0.

I don't think there is an issue with the hardware; if using inline asm instead
of the intrinsics, everything seems to work as expected.

Re: C++ PATCH for c++/91264 - detect modifying const objects in constexpr

[Marek Polacek]

On Fri, Aug 16, 2019 at 05:40:39PM -0700, Jason Merrill wrote:
> On 8/16/19 5:11 AM, Marek Polacek wrote:
> > On Thu, Aug 15, 2019 at 08:21:25PM -0400, Jason Merrill wrote:
> > > On 8/15/19 5:34 PM, Marek Polacek wrote:
> > > > On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:
> > > > > On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek  
> > > > > wrote:
> > > > > > 
> > > > > > On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> > > > > > > On 8/6/19 3:20 PM, Marek Polacek wrote:
> > > > > > > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill wrote:
> > > > > > > > > On 7/31/19 3:26 PM, Marek Polacek wrote:
> > > > > > > > > > One of the features of constexpr is that it doesn't allow 
> > > > > > > > > > UB; and such UB must
> > > > > > > > > > be detected at compile-time.  So running your code in a 
> > > > > > > > > > context that requires
> > > > > > > > > > a constant expression should ensure that the code in 
> > > > > > > > > > question is free of UB.
> > > > > > > > > > In effect, constexpr can serve as a sanitizer.  E.g. this 
> > > > > > > > > > article describes in
> > > > > > > > > > in more detail:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > [dcl.type.cv]p4 says "Any attempt to modify a const object 
> > > > > > > > > > during its lifetime
> > > > > > > > > > results in undefined behavior." However, as the article 
> > > > > > > > > > above points out, we
> > > > > > > > > > aren't detecting that case in constexpr evaluation.
> > > > > > > > > > 
> > > > > > > > > > This patch fixes that.  It's not that easy, though, because 
> > > > > > > > > > we have to keep in
> > > > > > > > > > mind [class.ctor]p5:
> > > > > > > > > > "A constructor can be invoked for a const, volatile or 
> > > > > > > > > > const volatile object.
> > > > > > > > > > const and volatile semantics are not applied on an object 
> > > > > > > > > > under construction.
> > > > > > > > > > They come into effect when the constructor for the most 
> > > > > > > > > > derived object ends."
> > > > > > > > > > 
> > > > > > > > > > I handled this by keeping a hash set which tracks objects 
> > > > > > > > > > under construction.
> > > > > > > > > > I considered other options, such as going up call_stack, 
> > > > > > > > > > but that wouldn't
> > > > > > > > > > work with trivial constructor/op=.  It was also interesting 
> > > > > > > > > > to find out that
> > > > > > > > > > the definition of TREE_HAS_CONSTRUCTOR says "When appearing 
> > > > > > > > > > in a FIELD_DECL,
> > > > > > > > > > it means that this field has been duly initialized in its 
> > > > > > > > > > constructor" though
> > > > > > > > > > nowhere in the codebase do we set TREE_HAS_CONSTRUCTOR on a 
> > > > > > > > > > FIELD_DECL as far
> > > > > > > > > > as I can see.  Unfortunately, using this bit proved useless 
> > > > > > > > > > for my needs here.
> > > > > > > > > 
> > > > > > > > > > Also, be mindful of mutable subobjects.
> > > > > > > > > > 
> > > > > > > > > > Does this approach look like an appropriate strategy for 
> > > > > > > > > > tracking objects'
> > > > > > > > > > construction?
> > > > > > > > > 
> > > > > > > > > For scalar objects, we should be able to rely on INIT_EXPR 
> > > > > > > > > vs. MODIFY_EXPR
> > > > > > > > > to distinguish between initialization and modification; for 
> > > > > > > > > class objects, I
> > > > > > > > 
> > > > > > > > This is already true: only class object go into the hash set.
> > > > > > > > 
> > > > > > > > > wonder about setting a flag on the CONSTRUCTOR after 
> > > > > > > > > initialization is
> > > > > > > > > complete to indicate that the value is now constant.
> > > > > > > > 
> > > > > > > > But here we're not dealing with CONSTRUCTORs in the gcc sense 
> > > > > > > > (i.e. exprs with
> > > > > > > > TREE_CODE == CONSTRUCTOR).  We have a CALL_EXPR like Y::Y 
> > > > > > > > ((struct Y *) ),
> > > > > > > > which initializes the object "y".  Setting a flag on the 
> > > > > > > > CALL_EXPR or its underlying
> > > > > > > > function decl wouldn't help.
> > > > > > > > 
> > > > > > > > Am I missing something?
> > > > > > > 
> > > > > > > I was thinking that where in your current patch you call
> > > > > > > remove_object_under_construction, we could instead mark the 
> > > > > > > object's value
> > > > > > > CONSTRUCTOR as immutable.
> > > > > > 
> > > > > > Ah, what you meant was to look at DECL_INITIAL of the object we're
> > > > > > constructing, which could be a CONSTRUCTOR.  Unfortunately, this
> > > > > > DECL_INITIAL is null (in all the new tests when doing
> > > > > > remove_object_under_construction), so there's nothing to mark as 
> > > > > > TREE_READONLY :/.
> > > > > 
> > > > > There's a value in ctx->values, isn't there?
> > > > 
> > > > Doesn't seem to be the case for e.g.
> > > > 
> > > > struct A {
> > > > int n;
> > 

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Created attachment 46724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46724=edit
Something that sort of works...

and also extends the error message with a reference to where the
mismatching procedure is defined.

[doc] install.texi and bfin "end of life"

[Gerald Pfeifer]

https://blackfin.uclinux.org redirects to a page on ez.analog.com
that states "End of Life for Blackfin Linux" and has a link to
sourceforge.net that at least offers some remaining bits.

Jie, can you please have a look? 

This, or something similar, probably should be backported to all
active release branches.

Committed for now.

Gerald
 
2019-08-18  Gerald Pfeifer  

* doc/install.texi (Specific, bfin): blackfin.uclinux.org is
gone, point to sourceforge.net.

Index: doc/install.texi
===
--- doc/install.texi(revision 274618)
+++ doc/install.texi(working copy)
@@ -3584,7 +3584,7 @@ See ``Blackfin Options'' in the main manual
 @end ifhtml
 
 More information, and a version of binutils with support for this processor,
-is available at @uref{https://blackfin.uclinux.org}
+are available at @uref{https://sourceforge.net/projects/adi-toolchain/}.
 
 @html
 

[wwwdocs PATCH] for Re: autovectorization in gcc

[Gerald Pfeifer]

On Thu, 10 Jan 2019, Jonathan Wakely wrote:
>> [ https://gcc.gnu.org/projects/tree-ssa/vectorization.html ]
> I'm not disputing that there could be better documentation, but that
> page is not the place to find it. That page should probably get a
> notice added saying that the project is complete and that the page is
> now only of historical interest.

Like this? ;-)

Committed.

Gerald

Index: projects/tree-ssa/vectorization.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/vectorization.html,v
retrieving revision 1.42
diff -u -r1.42 vectorization.html
--- projects/tree-ssa/vectorization.html30 Sep 2018 14:38:57 -  
1.42
+++ projects/tree-ssa/vectorization.html18 Aug 2019 10:55:46 -
@@ -2,15 +2,17 @@
 
 
 
-Auto-vectorization in GCC
+Auto-vectorization in GCC
 https://gcc.gnu.org/gcc.css; />
 
 
 
 Auto-vectorization in GCC
 
-The goal of this project is to develop a loop and basic block 
vectorizer in
-GCC, based on the tree-ssa framework.
+The goal of this project was to develop a loop and basic block
+vectorizer in GCC, based on the tree-ssa framework.
+It has been completed and the functionality has been part of GCC
+for years.
 
 Table of Contents

[wwwdocs PATCH] for Re: autovectorization in gcc

[Gerald Pfeifer]

On Thu, 10 Jan 2019, Jonathan Wakely wrote:
>> [ https://gcc.gnu.org/projects/tree-ssa/vectorization.html ]
> I'm not disputing that there could be better documentation, but that
> page is not the place to find it. That page should probably get a
> notice added saying that the project is complete and that the page is
> now only of historical interest.

Like this? ;-)

Committed.

Gerald

Index: projects/tree-ssa/vectorization.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/tree-ssa/vectorization.html,v
retrieving revision 1.42
diff -u -r1.42 vectorization.html
--- projects/tree-ssa/vectorization.html30 Sep 2018 14:38:57 -  
1.42
+++ projects/tree-ssa/vectorization.html18 Aug 2019 10:55:46 -
@@ -2,15 +2,17 @@
 
 
 
-Auto-vectorization in GCC
+Auto-vectorization in GCC
 https://gcc.gnu.org/gcc.css; />
 
 
 
 Auto-vectorization in GCC
 
-The goal of this project is to develop a loop and basic block 
vectorizer in
-GCC, based on the tree-ssa framework.
+The goal of this project was to develop a loop and basic block
+vectorizer in GCC, based on the tree-ssa framework.
+It has been completed and the functionality has been part of GCC
+for years.
 
 Table of Contents

[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-18
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The original macros in the Library Fundamentals TS were ints not longs, which
is why some started that way. I've been gradually fixing them, but it's very,
very low priority. Your example doesn't seem very realistic.

The allocator traits one is a bug though.

[wwwdocs] Reverting your own patches (was: [PATCH] Revert 2 ::get to ::get_create for IPA summaries (PR ipa/86279))

[Gerald Pfeifer]

On Fri, 29 Jun 2018, Jeff Law wrote:
> ISTM that if you're reverting something recent of your own that's
> causing failures you ought to be able to revert without waiting.

Indeed.  And https://gcc.gnu.org/svnwrite.html#all documents this
in the third items.

(Well, that direct link only works after the patch below that I
just committed; the text has been there since October 2005. ;-)

Gerald


Add an id of "all" to the "Free for all" subsection.

Index: svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.44
diff -u -r1.44 svnwrite.html
--- svnwrite.html   5 Jul 2019 12:42:51 -   1.44
+++ svnwrite.html   18 Aug 2019 10:33:04 -
@@ -140,7 +140,7 @@
 SVN or the https://gcc.gnu.org/ml/gcc-cvs/;>gcc-cvs
 list.
 
-Free for all
+Free for all
 
 The following changes can be made by everyone with write access:
 

[wwwdocs] bugs/index.html - remove a last reference to Java/libgcj

[Gerald Pfeifer]

Committed.

Gerald

Index: bugs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v
retrieving revision 1.130
diff -u -r1.130 index.html
--- bugs/index.html 16 Aug 2019 20:59:00 -  1.130
+++ bugs/index.html 18 Aug 2019 10:06:52 -
@@ -667,9 +667,8 @@
 modify it with each major release.  If you change your compiler to a
 different major release you must recompile all libraries that
 contain C++ code.  If you fail to do so you risk getting linker
-errors or malfunctioning programs.  Some of our Java support libraries
-also contain C++ code, so you might want to recompile all libraries to
-be safe.  It should not be necessary to recompile if you have changed
+errors or malfunctioning programs.
+It should not be necessary to recompile if you have changed
 to a bug-fix release of the same version of the compiler; bug-fix
 releases are careful to avoid ABI changes. See also the
 https://gcc.gnu.org/onlinedocs/gcc/Compatibility.html;>compatibility

[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition

[dimhen at gmail dot com]

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

--- Comment #24 from Dmitry G. Dyachenko  ---
r257061 optimize too

gcc version 8.0.1 20180125 (experimental) [trunk revision 257061] (GCC)

[Bug fortran/91390] treatment of extra parameter in a subroutine call

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
I'm currently working on this... finding a lot of interesting
cases in the test suite, in particular one where I am not sure
what to do.

The test case is gfortran.dg/goacc/acc_on_device-1.f95 , and the code is

! Have to enable optimizations, as otherwise builtins won't be expanded.
! { dg-additional-options "-O -fdump-rtl-expand" }

logical function f ()
  implicit none

  external acc_on_device
  logical (4) acc_on_device

  f = .false.
  f = f .or. acc_on_device ()
  f = f .or. acc_on_device (1, 2)
  f = f .or. acc_on_device (3.14)
  f = f .or. acc_on_device ("hello")

  return
end function f

! Unsuitable to be handled as a builtin, so we're expecting four calls.
! { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 4
"expand" } }

With my current patch, this would result in

/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:12:12:

   11 |   f = f .or. acc_on_device ()
  |2
   12 |   f = f .or. acc_on_device (1, 2)
  |1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:13:12:

   11 |   f = f .or. acc_on_device ()
  |2
   12 |   f = f .or. acc_on_device (1, 2)
   13 |   f = f .or. acc_on_device (3.14)
  |1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/goacc/acc_on_device-1.f95:14:12:

   11 |   f = f .or. acc_on_device ()
  |2
..
   14 |   f = f .or. acc_on_device ("hello")
  |1
Error: More actual than formal arguments in procedure call at (1) for procedure
defined at (2)

where the warnings could be mitigated to a warning using -std=legacy.

Now, needless to say, this is illegal Fortran. Is the test case actually
a valid use case?  Wouldn't it be better to make this into an intrinsic
with -fopenacc? Would it be acceptable to have to set -std=legacy on that
particular use case?

[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition

[dimhen at gmail dot com]

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

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 CC||dimhen at gmail dot com

--- Comment #23 from Dmitry G. Dyachenko  ---
sounds like gcc10 r274581 optimize c#3 and c#4

c#3 gcc -O -S x.c
f:
.LFB0:
.cfi_startproc
leal2(%rdi,%rdi), %eax
ret
.cfi_endproc

c#4 gcc -O -S y.c
m:
.LFB0:
.cfi_startproc
movl$0, %eax
ret
.cfi_endproc

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

Re: Update x86-tune-costs.h for znver2

[Gerald Pfeifer]

On Tue, 30 Jul 2019, Jan Hubicka wrote:
>> Thanks - can you please update changes.html for it in the 9.2 section?
> There seems to be no GCC 9.2 section yet.

I see one now. 

On Tue, 30 Jul 2019, Richard Biener wrote:
> Yes.  Looks good to me btw.

Same here.  (I would have taken Richard's note as approval, though
as maintainer over that area you don't even need any.)

For the benefit of the doubt, though: okay, thanks. :-)

Gerald