[Bug c++/96720] New: ICE with* after include

[cgnitash at gmail dot com]

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

Bug ID: 96720
   Summary: ICE with* after include
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cgnitash at gmail dot com
  Target Milestone: ---

The following code gives an ice on gcc trunk.

https://godbolt.org/z/5EaEGP


#include  *

[Bug analyzer/96713] [11 Regression] ICE: in fold_relational_const, at fold-const.c:14921 with -fanalyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/96713] [11 Regression] ICE: in fold_relational_const, at fold-const.c:14921 with -fanalyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-2776-g2f5951bd95e334d611f4be7bbe1a136c580f9c20
Author: David Malcolm 
Date:   Wed Aug 19 17:36:53 2020 -0400

analyzer: fix ICE on vector comparisons [PR96713]

gcc/analyzer/ChangeLog:
PR analyzer/96713
* region-model.cc (region_model::get_gassign_result): For
comparisons, only use eval_condition when the lhs has boolean
type, and use get_or_create_constant_svalue on the boolean
constants directly rather than via get_rvalue.

gcc/testsuite/ChangeLog:
PR analyzer/96713
* gcc.dg/analyzer/pr96713.c: New test.

[Bug c++/96719] New: non-standard handling of alias templates used as template template arguments

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 96719
   Summary: non-standard handling of alias templates used as
template template arguments
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

template struct A { using type = U; };
template using B = A;
template class Z> struct Q {
  using type = typename Z::type;
};

Here, Q::type should be float, but GCC believes it's int.

I think this is due to GCC implementing the (non-standard at this time) rule in
CWG1286. This is also reflected in incorrect manglings:

void f(Q) {}

... is mangled as if it were written as `f(Q)`, and other rejects-valids,
such as for:

void f(Q) {}
void f(Q) {}

[Bug testsuite/96718] [11 regression] 25_algorithms/pstl/feature_test-3.cc has excess error after r11-2743

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Sorry, git bisect lead me astray.  I will reopen once I narrow it down to the
actual failing revision.

[Bug testsuite/96718] New: [11 regression] 25_algorithms/pstl/feature_test-3.cc has excess error after r11-2743

[seurer at gcc dot gnu.org]

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

Bug ID: 96718
   Summary: [11 regression] 25_algorithms/pstl/feature_test-3.cc
has excess error after r11-2743
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:d367f5fcb579d21c3093cf5c464f5787fe584a1d, r11-2743

Executing on host: /home/seurer/gcc/git/build/gcc-test/./gcc/xg++
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-3.cc
   -std=gnu++17 -fdiagnostics-plain-output -E -o feature_test-3.i(timeout =
600)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xg++
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64le-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-3.cc
-std=gnu++17 -fdiagnostics-plain-output -E -o feature_test-3.i
In file included from
/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/pstl/parallel_backend.h:16,
 from
/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/pstl/algorithm_impl.h:22,
 from
/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/pstl/glue_execution_defs.h:50,
 from
/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/execution:32,
 from
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/25_algorithms/pstl/feature_test-3.cc:21:
/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/pstl/parallel_backend_tbb.h:28:
error: #error Intel(R) Threading Building Blocks 2018 is required; older
versions are not supported.
compiler exited with status 1
FAIL: 25_algorithms/pstl/feature_test-3.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/pstl/parallel_backend_tbb.h:28:
error: #error Intel(R) Threading Building Blocks 2018 is required; older
versions are not supported.

testcase
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
completed in 14 seconds

=== libstdc++ Summary ===

# of unexpected failures1

[Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4

[slyfox at gcc dot gnu.org]

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

Bug ID: 96717
   Summary: -flifetime-dse=2 breaks webkit-gtk-2.28.4
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49084=edit
part-of-webkit-gtk-2.28.4.tar.gz

Initially I noticed the bug on liferea which uses webkit-gtk-2.28.4 as a
rendering engine.

I was not able to extract minimal example because I got lost in SFINATE
instance selections. I am not sure if it's a webkit bug or gcc bug.

I'm leaning to gcc bug. gcc-10 used to work. gcc-11 generates code that hits
'ud2'.

The webkit client code looks simple: we create a hash set of raw pointers and
add pointers there to see how hashset resizes:

"""
#define USE_SYSTEM_MALLOC 1 /* avoid bmalloc */

#include "wtf/HashSet.h"
#include "wtf/Threading.h"

using namespace WTF;

int main() {
HashSet hst;
for (int i = 1; i < 1000; ++i) {
Thread * v = (Thread*)(long)(i * 128);
hst.add(v);
}
}
"""

But headers take almost 2 megabytes.

Building the example with -fno-lifetime-dse produces working code. Building
without breaks on first hash table resize:

$ ./mk.bash

./a
./mk.bash: line 50: 1054935 Illegal instruction (core dumped) ./a
132

./a-nodse
0

The 'ud2' is encountered in HashTable::rehash() method:
https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/HashTable.h#L1304

Attaching self-contained directory with sources and headers.

Can you help me rule out gcc's misbehaviour?

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Wed, Aug 19, 2020 at 09:36:32PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
> 
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> A very quick hack seems to solve the issue for me.  For some reason the
> final fold_convert seems to create a problem.  Does anybody know why?
> It there a shorter solution?
> 
> diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
> index 2483f016d8e..deb3030b75d 100644
> --- a/gcc/fortran/trans-intrinsic.c
> +++ b/gcc/fortran/trans-intrinsic.c
> @@ -395,11 +395,26 @@ build_round_expr (tree arg, tree restype)
>  fn = builtin_decl_for_precision (BUILT_IN_LROUND, argprec);
>else if (resprec <= LONG_LONG_TYPE_SIZE)
>  fn = builtin_decl_for_precision (BUILT_IN_LLROUND, argprec);
> +  else if (resprec >= argprec && resprec == 128)
> +{
> +  /* Search for a real kind suitable as temporary for conversion.  */
> +  int kind = -1;
> +  for (int i = 0; kind < 0 && gfc_real_kinds[i].kind != 0; i++)
> +   if (gfc_real_kinds[i].mode_precision >= resprec)
> + kind = gfc_real_kinds[i].kind;
> +  if (kind < 0)
> +   gfc_internal_error ("Could not find real kind with at least %d bits",
> +   resprec);
> +  arg = fold_convert (gfc_float128_type_node, arg);
> +  fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind);
> +}
>else
>  gcc_unreachable ();
> 
> -  return fold_convert (restype, build_call_expr_loc (input_location,
> -fn, 1, arg));
> +  return convert (restype, build_call_expr_loc (input_location,
> +   fn, 1, arg));
> +  /* return fold_convert (restype, build_call_expr_loc (input_location, */
> +  /*fn, 1, arg)); */
>  }

I tried an even uglier hack, and also got stumped by GIMPLE.
Jakub can probably shed some light on how to handle 
quad precision and GIMPLE.

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
A very quick hack seems to solve the issue for me.  For some reason the
final fold_convert seems to create a problem.  Does anybody know why?
It there a shorter solution?

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 2483f016d8e..deb3030b75d 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -395,11 +395,26 @@ build_round_expr (tree arg, tree restype)
 fn = builtin_decl_for_precision (BUILT_IN_LROUND, argprec);
   else if (resprec <= LONG_LONG_TYPE_SIZE)
 fn = builtin_decl_for_precision (BUILT_IN_LLROUND, argprec);
+  else if (resprec >= argprec && resprec == 128)
+{
+  /* Search for a real kind suitable as temporary for conversion.  */
+  int kind = -1;
+  for (int i = 0; kind < 0 && gfc_real_kinds[i].kind != 0; i++)
+   if (gfc_real_kinds[i].mode_precision >= resprec)
+ kind = gfc_real_kinds[i].kind;
+  if (kind < 0)
+   gfc_internal_error ("Could not find real kind with at least %d bits",
+   resprec);
+  arg = fold_convert (gfc_float128_type_node, arg);
+  fn = gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind);
+}
   else
 gcc_unreachable ();

-  return fold_convert (restype, build_call_expr_loc (input_location,
-fn, 1, arg));
+  return convert (restype, build_call_expr_loc (input_location,
+   fn, 1, arg));
+  /* return fold_convert (restype, build_call_expr_loc (input_location, */
+  /*fn, 1, arg)); */
 }

[Bug analyzer/96713] [11 Regression] ICE: in fold_relational_const, at fold-const.c:14921 with -fanalyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-19

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug; confirmed.

[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #7 from Jason Merrill  ---
Fixed for 10.3/11.

[Bug c++/96716] New: GCC reports "object is private" when it's accessed through proper accessor

[vorfeed.canal at gmail dot com]

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

Bug ID: 96716
   Summary: GCC reports "object is private" when it's accessed
through proper accessor
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vorfeed.canal at gmail dot com
  Target Milestone: ---

The following program doesn't work ( https://godbolt.org/z/87cr44 ):

#include 
#include 

class Foo {
 public:
  auto constexpr  getfoo() const -> std::string_view {
return {foo.data(), 2};
  }
 private:
  const std::array foo = {'a', 'b', '\0'};
};

inline constexpr Foo foo;

template 
class Bar {
 public:
  static constexpr auto bar = foo.getfoo();
};

auto& baz = Bar::bar;

Error message:
: In instantiation of 'constexpr const std::basic_string_view
Bar::bar':

:21:23:   required from here

:18:25: error: 'const std::array Foo::foo' is private within
this context

   18 |   static constexpr auto bar = foo.getfoo();

  | ^~~

:10:29: note: declared private here

   10 |   const std::array foo = {'a', 'b', '\0'};

  | ^~~

Compiler returned: 1

All other compilers work fine ( https://godbolt.org/z/WvfrPf )

[Bug tree-optimization/96715] New: Failure to optimize copysign of variable by negated variable

[gabravier at gmail dot com]

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

Bug ID: 96715
   Summary: Failure to optimize copysign of variable by negated
variable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

float f(float x, float y)
{
return __builtin_copysignf(x, -x);
}

This can be optimized to `return -x;`. This transformation is done by LLVM, but
not by GCC.

[Bug tree-optimization/96714] New: Failure to optimize sqrt*sqrt of same variable with ffast-math

[gabravier at gmail dot com]

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

Bug ID: 96714
   Summary: Failure to optimize sqrt*sqrt of same variable with
ffast-math
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

float f(float x)
{
return __builtin_sqrtf(x) * __builtin_sqrtf(x);
}

This can be optimized to `return x;` (with fast math enabled). This
transformation is done by LLVM, but not by GCC.

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[toon at moene dot org]

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

Toon Moene  changed:

   What|Removed |Added

 CC||toon at moene dot org

--- Comment #7 from Toon Moene  ---
*** Bug 96712 has been marked as a duplicate of this bug. ***

[Bug fortran/96712] internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:399

[toon at moene dot org]

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

Toon Moene  changed:

   What|Removed |Added

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

--- Comment #1 from Toon Moene  ---
I wasn't quick enough. Reported as PR 96711.

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

[Bug analyzer/96713] New: [11 Regression] ICE: in fold_relational_const, at fold-const.c:14921 with -fanalyzer

[zsojka at seznam dot cz]

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

Bug ID: 96713
   Summary: [11 Regression] ICE: in fold_relational_const, at
fold-const.c:14921 with -fanalyzer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 49083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49083=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c 
during IPA pass: analyzer
testcase.c: In function 'foo':
testcase.c:6:5: internal compiler error: in fold_relational_const, at
fold-const.c:14921
6 |   d <= e;
  |   ~~^~~~
0x66d990 fold_relational_const
/repo/gcc-trunk/gcc/fold-const.c:14921
0xd51bfe const_binop(tree_code, tree_node*, tree_node*, tree_node*)
/repo/gcc-trunk/gcc/fold-const.c:1599
0xd44841 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/repo/gcc-trunk/gcc/fold-const.c:10274
0x1478486 ana::constant_svalue::eval_condition(ana::constant_svalue const*,
tree_code, ana::constant_svalue const*)
/repo/gcc-trunk/gcc/analyzer/svalue.cc:403
0x143d597 ana::region_model::eval_condition(ana::svalue const*, tree_code,
ana::svalue const*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:1500
0x143f5ee ana::region_model::get_gassign_result(gassign const*,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:469
0x143f747 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:563
0x1423070 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
/repo/gcc-trunk/gcc/analyzer/engine.cc:1029
0x14241af ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:2526
0x1424aa2 ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:2341
0x1426b19 ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:4107
0x14284ac ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:4175
0x141c5e8 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:84
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2773-20200819203610-ge6e01618e83-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2773-20200819203610-ge6e01618e83-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200819 (experimental) (GCC)

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #5)
>  m = anint(y)
> 
> This will use libquadmath to round y to a quad precision
> floating point integral number, and then the rounded value
> will assigned to m where type conversion occurs.

gfc_conv_intrinsic_aint has the following comment:

/* Round a real value using the specified rounding mode.
   We use a temporary integer of that same kind size as the result.
...

This seems not to be done in gfc_conv_intrinsic_int, which is invoked
for nint.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2773-ge6e01618e83bcd9eb3a2b27df30ed87106a748b4
Author: Jonathan Wakely 
Date:   Wed Aug 19 20:36:10 2020 +0100

libstdc++: Make make-unsigned-like-t<__int128> work [PR 96042]

As well as ensuring that numeric_limits<__int128> is defined, we need to
ensure that make-unsigned-like-t and to-unsigned-like work correctly for
128-bit integers in strict mode. This ensures that a subrange created
from an iota_view's iterator and sentinel can represent its size.

Co-authored-by: Patrick Palka  

libstdc++-v3/ChangeLog:

2020-08-19  Jonathan Wakely  
Patrick Palka  

PR libstdc++/96042
* include/bits/range_access.h (__detail::__to_unsigned_like):
Do not use make_unsigned_t in the return type, as it can
result in an error before the integral constraint is checked.
[__STRICT_ANSI__]: Add overloads for 128-bit integer types.
(__detail::__make_unsigned_like_t): Define as the return type
of __to_unsigned_like.
* testsuite/std/ranges/subrange/96042.cc: New test.

[Bug fortran/96712] New: internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:399

[toon at moene dot org]

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

Bug ID: 96712
   Summary: internal compiler error: in build_round_expr, at
fortran/trans-intrinsic.c:399
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toon at moene dot org
  Target Milestone: ---

The following source:

integer i
real(kind=8) r
i = nint(r, 16)
end

generates an ICE when compiled with 10.2 as follows

gfortran -S nint_pr.f90 
nint_pr.f90:3:0:

3 | i = nint(r, 16)
  | 
internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:399
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug analyzer/96643] [11 Regression] ICE in deref_rvalue, at analyzer/region-model.cc:1288

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/96705] [11 Regression] ICE: in wide_int_to_tree_1, at tree.c:1612 with -fanalyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/96699] [11 Regression] ICE in fold_convert_const_int_from_real, at fold-const.c:2038

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #2 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/96643] [11 Regression] ICE in deref_rvalue, at analyzer/region-model.cc:1288

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:23ebfda0e352fa0a92c6b012458ecb65505a135f

commit r11-2772-g23ebfda0e352fa0a92c6b012458ecb65505a135f
Author: David Malcolm 
Date:   Wed Aug 19 13:21:47 2020 -0400

analyzer: fix ICE on deref_rvalue on SK_COMPOUND [PR96643]

gcc/analyzer/ChangeLog:
PR analyzer/96643
* region-model.cc (region_model::deref_rvalue): Rather than
attempting to handle all svalue kinds in the switch, only cover
the special cases, and move symbolic-region handling to after
the switch, thus implicitly handling the missing case SK_COMPOUND.

gcc/testsuite/ChangeLog:
PR analyzer/96643
* g++.dg/analyzer/pr96643.C: New test.

[Bug analyzer/96705] [11 Regression] ICE: in wide_int_to_tree_1, at tree.c:1612 with -fanalyzer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-2771-gfc02b568e2cd3f6a28d4b7c1063bbf8842c89aad
Author: David Malcolm 
Date:   Wed Aug 19 09:27:16 2020 -0400

analyzer: fix ICE on folding vector 0 [PR96705]

gcc/analyzer/ChangeLog:
* region-model-manager.cc
PR analyzer/96705
(region_model_manager::maybe_fold_binop): Check that we have an
integral type before calling build_int_cst.

gcc/testsuite/ChangeLog:
PR analyzer/96705
* gcc.dg/analyzer/pr96705.c: New test.

[Bug analyzer/96699] [11 Regression] ICE in fold_convert_const_int_from_real, at fold-const.c:2038

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:366bd1ac01a5249a463e64234674ad2d174faa9a

commit r11-2770-g366bd1ac01a5249a463e64234674ad2d174faa9a
Author: David Malcolm 
Date:   Wed Aug 19 05:00:52 2020 -0400

analyzer: fix ICE converting float to int [PR96699]

gcc/analyzer/ChangeLog:
PR analyzer/96699
* region-model-manager.cc
(region_model_manager::get_or_create_cast): Use FIX_TRUNC_EXPR for
casting from REAL_TYPE to INTEGER_TYPE.

gcc/testsuite/ChangeLog:
PR analyzer/96699
* gcc.dg/analyzer/pr96699.c: New test.

[Bug analyzer/94858] False report of memory leak

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
It looks like we lose the:
cluster for: (*INIT_VAL(td_14(D)))
  ESCAPED
  key:   {kind: direct, start: 0, size: 64, next: 64}
  value: ‘hashNx *’ {_ALLOCATED_REGION(0)}
at the "*index.0_1 = -1;", where the whole cluster for *INIT_VAL(td_14(D))
becomes unknown.

I think the aliasing code conservatively assumes that this write could affect
the *INIT_VAL(td_14(D)).

But that was the initial value of a pointer param, whereas
HEAP_ALLOCATED_REGION is a freshly allocated heap region, so they can't alias.

Looks like I need to teach that to the pointer-aliasing logic.

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Trivial workaround.

   program nint_error
 implicit none
 integer(kind=16) ::  m
 real(8) :: x, y
 x = 1
 y = x - 1
 m = anint(y)
 print *, m
   end

This will use libquadmath to round y to a quad precision
floating point integral number, and then the rounded value
will assigned to m where type conversion occurs.

[Bug analyzer/94858] False report of memory leak

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-19
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Thanks for filing this.  Still affects trunk (my rewrite of
r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d didn't fix it).

Seems to be an issue with state-merging; passing -fno-analyzer-state-merge
eliminates the false positive.

Immediately before the call to hashEmpty we have:

  cluster for: (*INIT_VAL(td_14(D)))
ESCAPED
key:   {kind: direct, start: 0, size: 64, next: 64}
value: ‘hashNx *’ {_ALLOCATED_REGION(0)}
key:   {kind: direct, start: 96, size: 32, next: 128}
value: ‘int’ {INIT_VAL(slots_15(D))}
  malloc: _ALLOCATED_REGION(0): nonnull (‘index_17’)

but afterwards (with state merging) we have:

  cluster for: (*INIT_VAL(td_14(D)))
ESCAPED
key:   {kind: direct, start: 0, size: 64, next: 64}
value: ‘hashNx *’ {UNKNOWN(hashNx *)}
key:   {kind: direct, start: 64, size: 32, next: 96}
value: ‘int’ {(int)0}
key:   {kind: direct, start: 96, size: 32, next: 128}
value: ‘int’ {UNKNOWN(int)}
key:   {kind: default, start: 0, size: 128, next: 128}
value: ‘struct hashSt’ {UNKNOWN(struct hashSt)}

so the pointer (first 64 bits) has somehow become UNKNOWN.

[Bug other/91085] fixincludes breaks

[martingalvan at sourceware dot org]

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

Tendel10 at protonmail dot com changed:

   What|Removed |Added

 CC||Tendel10 at protonmail dot com

martingalvan at sourceware dot org changed:

   What|Removed |Added

 CC||martingalvan at sourceware dot 
org

--- Comment #9 from Tendel10 at protonmail dot com ---
I am having this issue as well, any updates on this bug?

--- Comment #10 from Tendel10 at protonmail dot com ---
I am having this issue as well, any updates on this bug?

--- Comment #11 from martingalvan at sourceware dot org ---
This bug is still happening on gcc 9.2.1.

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-19
 Status|UNCONFIRMED |NEW

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to B Eggen from comment #3)
> Here is the latest f90 file:
> 
> program nint_error
> 
>   integer :: n, m
>   integer(kind=16) :: i, j, nint
> 
>   integer, parameter :: idp=selected_real_kind(9,99)
>   integer, parameter :: i16=selected_int_kind(38)
> 
>   real(kind=idp) :: x, y
> 
>   write(*,'(*(g0:" "))') 'i16=', i16, huge(i)
>   i=1_16
>   x=1.0d0
>   do n=1, 128, 1
>  j=i-1_16
>  y=x-1.0d0
>  m=nint(y) ! this compiles, but gives wrong results
> ! m=nint(y,i16) ! this will generate an internal compiler error
>  write(*,'(*(g0:" "))') n, i, x, m
>  i=i+i
>  x=x+x
>  if ( (m<1) .and. (n>3)) exit
>   end do
> 
>   do i=2147483647_16-10_16, 2147483648_16+10_16, 1_16
>  x=dble(i)
>  m=nint(x)
>  write(*,'(*(g0:" "))') i, x, m
>   end do
> 
> 
>   stop
> end program nint_error

It is somewhat hard to decipher what the problem.  You have conflated
correct behavior with that of an apparent.  First, 

m = nint(y) 

will return a default integer.  From 16.9.141

   Result Characteristics. Integer. If KIND is present, the kind type
   parameter is that specified by the value of KIND; otherwise, the
   kind type parameter is that of default integer type.

on your target the default integer kind is 4 (i.e., a 32-bit signed
integer).  This means that

32 2147483648 2147483648.000 2147483647
33 4294967296 4294967296.000 -1

your program becomes nonconforming for n = 33.  The Fortran standard
contains

  A program shall not invoke an intrinsic procedure under circumstances
  where a value to be assigned to a subroutine argument or returned as
  a function result is not representable by objects of the specified
  type and type parameters.

The function result of 4294967296 is technically not representable
(except that you're getting twos-complement wrap around).

As to your observation about IDNINT.  It is a specific name for
the generic intrinsic NINT.  It has one double precision argument.
It does not have a kind argument.

Now, onto the bug.  It can be distilled down to 

   program nint_error
 implicit none
 integer(kind=16) ::  m
 real(8) :: x, y
 x = 1
 y = x - 1
 m = nint(y,16)

end program nint_error

% gfcx -o z a.f90 && ./z
a.f90:9:0:

9 |   m = nint(y,16)
  | 
internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:396
0x5bd9fa build_round_expr
../../gccx/gcc/fortran/trans-intrinsic.c:396
0x5bd9fa build_fix_expr
../../gccx/gcc/fortran/trans-intrinsic.c:420
0x8c7bf2 gfc_conv_intrinsic_int
../../gccx/gcc/fortran/trans-intrinsic.c:550

It would seem that a fold_convert to an appropriate kind is missing.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:386fd16c551188e20d5b1684b7139e4269f9a739

commit r11-2766-g386fd16c551188e20d5b1684b7139e4269f9a739
Author: Jonathan Wakely 
Date:   Wed Aug 19 16:27:25 2020 +0100

libstdc++: Make __int128 meet integer-class requirements [PR 96042]

Because __int128 can be used as the difference type for iota_view, we
need to ensure that it meets the requirements of an integer-class type.
The requirements in [iterator.concept.winc] p10 include numeric_limits
being specialized and giving meaningful answers. Currently we only
specialize numeric_limits for non-standard integer types in non-strict
modes.  However, nothing prevents us from defining an explicit
specialization for any implementation-defined type, so it doesn't matter
whether std::is_integral<__int128> is true or not.

This patch ensures that the numeric_limits specializations for signed
and unsigned __int128 are defined whenever __int128 is available. It
also makes the __numeric_traits and __int_limits helpers work for
__int128, via a new __gnu_cxx::__is_integer_nonstrict trait.

libstdc++-v3/ChangeLog:

PR libstdc++/96042
* include/ext/numeric_traits.h (__is_integer_nonstrict): New
trait which is true for 128-bit integers even in strict modes.
(__numeric_traits_integer, __numeric_traits): Use
__is_integer_nonstrict instead of __is_integer.
* include/std/limits [__STRICT_ANSI__ && __SIZEOF_INT128__]
(numeric_limits<__int128>, (numeric_limits):
Define.
* testsuite/std/ranges/iota/96042.cc: New test.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|REOPENED|ASSIGNED
   Target Milestone|--- |10.3

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[bre08 at eggen dot co.uk]

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

--- Comment #3 from B Eggen  ---
Here is the latest f90 file:

program nint_error

  integer :: n, m
  integer(kind=16) :: i, j, nint

  integer, parameter :: idp=selected_real_kind(9,99)
  integer, parameter :: i16=selected_int_kind(38)

  real(kind=idp) :: x, y

  write(*,'(*(g0:" "))') 'i16=', i16, huge(i)
  i=1_16
  x=1.0d0
  do n=1, 128, 1
 j=i-1_16
 y=x-1.0d0
 m=nint(y) ! this compiles, but gives wrong results
! m=nint(y,i16) ! this will generate an internal compiler error
 write(*,'(*(g0:" "))') n, i, x, m
 i=i+i
 x=x+x
 if ( (m<1) .and. (n>3)) exit
  end do

  do i=2147483647_16-10_16, 2147483648_16+10_16, 1_16
 x=dble(i)
 m=nint(x)
 write(*,'(*(g0:" "))') i, x, m
  end do


  stop
end program nint_error

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[bre08 at eggen dot co.uk]

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

--- Comment #2 from B Eggen  ---
adding the compiler flag -fdefault-integer-8 extends the range somewhat, but I
really require NINT() to work for whole range (up to 2^127-1):

-> ./nint_error.e
i16= 16 170141183460469231731687303715884105727
1 1 1. 0
2 2 2. 1
3 4 4. 3
4 8 8. 7
5 16 16.000 15
6 32 32.000 31
[...]
61 1152921504606846976 0.11529215046068470E+019 1152921504606846976
62 2305843009213693952 0.23058430092136940E+019 2305843009213693952
63 4611686018427387904 0.46116860184273879E+019 4611686018427387904
64 9223372036854775808 0.92233720368547758E+019 -9223372036854775808

[Bug fortran/96711] Internal Compiler Error on NINT() Function

[bre08 at eggen dot co.uk]

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

B Eggen  changed:

   What|Removed |Added

 CC||bre08 at eggen dot co.uk

--- Comment #1 from B Eggen  ---
Comment on attachment 49082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49082
This recreates the error, either the internal compiler error (line 18), or, if
the previous line is activated instead, the incorrect behaviour

For some reason an older f90 file was attached, even with m moved to the line
below, the error continues to exist.

[Bug fortran/96711] New: Internal Compiler Error on NINT() Function

[bre08 at eggen dot co.uk]

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

Bug ID: 96711
   Summary: Internal Compiler Error on NINT() Function
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bre08 at eggen dot co.uk
  Target Milestone: ---

Created attachment 49082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49082=edit
This recreates the error, either the internal compiler error (line 18), or, if
the previous line is activated instead, the incorrect behaviour

Hello,

I've come across an internal compiler error (in GFortran), concerning the
function NINT(), I attach a very simple source code that illustrates the error.
 Essentially I am working with 16-byte integers (ie 128-bit width), and there
seems no way to ensure that NINT() returns the correct precision integer. I
also checked on Ubuntu-64, same GCC & GFortran version (9.3.0) and I get the
same error message / behaviour.

I tried a number of things, to no avail:

1)  m=nint(y) ! this gives at best an 8 byte integer return and or larger
numbers is negative,  
2)  m=nint(y,i16) ! this is the attached version, which generates compiler
error
3)  m=nint(y,kind=i16) ! also generates error
4)  integer(kind=16) :: nint; ... m=nint(y) ! does not change return type
5)  trying to compile with "-fdefault-integer-16" # option does not exist 

Compiling with "-fdefault-integer-8" gets me a bit further, but I really
require the nint function to work for 16-byte integers.

Interestingly, in the related function, IDNINT() the "KIND" optional argument
does not even seem to be implemented.  I would probably need a working version
from real(kind=16) to integer(kind=16).

The GCC bug site stipulates:

Please include all of the following items, the first three of which can be
obtained from the output of gcc -v:

the exact version of GCC;
the system type; (Cygwin 64 on top of Windows 10)
the options given when GCC was configured/built;

-> cygcheck -c cygwin
Cygwin Package Information
Package  VersionStatus
cygwin   3.1.6-1OK

-> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-9.3.0-2.x86_64/src/gcc-9.3.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-9.3.0-2.x86_64/src/gcc-9.3.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath
--enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers
--with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
--enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 9.3.0 (GCC)

and for Gfortran:

-> gfortran --version
GNU Fortran (GCC) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/9.3.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-9.3.0-2.x86_64/src/gcc-9.3.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-9.3.0-2.x86_64/src/gcc-9.3.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --enable-libquadmath
--enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers
--with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
--enable-libstdcxx-filesystem-ts

[Bug libstdc++/96710] New: __int128 vs

[redi at gcc dot gnu.org]

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

Bug ID: 96710
   Summary: __int128 vs 
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

In strict modes (e.g. -std=c++17) the __int128 type does not belong to any of
the standard type categories, because is_integer<__int128> is false, which
means is_arithmetic<__int128> is false.

Our definitions of is_scalar depends on is_arithmetic, so is_scalar<__int128>
is false, and therefore is_object<__int128> is false. This is clearly nonsense.

We should fix this, so that even when is_integer<__int128> is false, we can
still give sensible answers for __int128 that do not (unsucessfully) try to
deny its existence.

Of course the ideal would be for WG14 to accept
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2425.pdf and then we can just
say is_integer<__int128> is true even in strict modes and everybody rejoices.

[Bug c++/96709] New: cmov and vectorization

[g.peterh...@t-online.de]

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

Bug ID: 96709
   Summary: cmov and vectorization
   Product: gcc
   Version: unknown
   URL: https://godbolt.org/z/GKnj17
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.peterh...@t-online.de
  Target Milestone: ---

Hello gcc team,
I noticed 2 problems:
1) the compiler does not generate cmov commands
2) the auto-vectorization is very unreliable

I would like to clarify this using the example of a stable shift-left, see
https://godbolt.org/z/GKnj17
I have implemented several variants for this.

to 1)
Only silent::conditional_move generates a cmov, all other cases do not.

to 2)
- The auto-vectorization only works if the smaller of the two arrays (val and
bit) is at least as large as an sse register, although the values ​​could be
adjusted.
- If vectorization is used at all, often only 128-bit code is generated
(_mm_XXX) instead of 256-bit (avx _mm256_XXX) or larger.
- The 16-bit shift commands from AVX512 (_mmXXX_sllv_epi16) are not used if a
suitable architecture is selected.

The complex shl_attempt_vectorize function works a little better, but not 100%
either. Play around with the array size, the value/shift-types and the
functions!

Best regards
Gero

[Bug tree-optimization/94234] missed ccp folding for (addr + 8 * n) - (addr + 8 * (n - 1))

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Feng Xue :

https://gcc.gnu.org/g:459f6f68a75fe88e7c8309ca8ad3244a532b0d8e

commit r11-2764-g459f6f68a75fe88e7c8309ca8ad3244a532b0d8e
Author: Feng Xue 
Date:   Mon Jun 1 11:57:35 2020 +0800

tree-optimization/94234 - add pattern for ptr-diff on addresses with same
offset

2020-08-19  Feng Xue  

gcc/
PR tree-optimization/94234
* match.pd ((PTR_A + OFF) - (PTR_B + OFF)) -> (PTR_A - PTR_B): New
simplification.

gcc/testsuite/
PR tree-optimization/94234
* gcc.dg/pr94234-1.c: New test.

[Bug c++/61372] Add warning to detect noexcept functions that might throw

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to David Crocker from comment #5)
> You seem to be assuming that C++ exceptions can propagate through functions
> compiled with a C compiler.

I'm not assuming anything. I know for a fact that they can do so on some
platforms.

It is provably incorrect to say that extern "C" functions can't exit via an
exception. So it would be wrong to add a new warning which unconditionally
assumes extern "C" functions never throw.

> On most platforms, they normally cannot, because

Define most.

GCC supports it by default on many platforms.

> a C compiler does not produce the information needed for the C++ unwind
> mechanism to unwind the call stack. If you want bsearch and qsort to
> propagate C++ exceptions, on most platforms the implementations of those
> functions would have to be compiled either using a C++ compiler, or with a C
> compiler using a special option that tells the compiler to include the
> tables and/or code needed to propagate C++ exceptions. Otherwise the
> exception will end up at std::unexpected. Maybe bsearch and qsort in newlib
> are compiled this way, I haven't checked.

What has newlib got to do with anything? Are you asking for a new option that
only works when using newlib? Don't assume your use case is universal. New GCC
options need to consider a broad range of uses.

> I don't care whether extern "C" functions are to be assumed noexcept by
> default or another compiler option is needed to specify that. But without
> this facility, the proposed warning will be useless in practice, at least
> for people like me writing embedded software.

OK, so why do you keep arguing about it? What I said is it that treating extern
"C" functions as non-throwing needs to be optional. You've repeatedly argued
that my reasoning for that is bogus, based on "does it ever make sense to?" and
the answer is yes, sometimes it does.

[Bug c++/61372] Add warning to detect noexcept functions that might throw

[dcrocker at eschertech dot com]

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

--- Comment #5 from David Crocker  ---
You seem to be assuming that C++ exceptions can propagate through functions
compiled with a C compiler. On most platforms, they normally cannot, because a
C compiler does not produce the information needed for the C++ unwind mechanism
to unwind the call stack. If you want bsearch and qsort to propagate C++
exceptions, on most platforms the implementations of those functions would have
to be compiled either using a C++ compiler, or with a C compiler using a
special option that tells the compiler to include the tables and/or code needed
to propagate C++ exceptions. Otherwise the exception will end up at
std::unexpected. Maybe bsearch and qsort in newlib are compiled this way, I
haven't checked.

I don't care whether extern "C" functions are to be assumed noexcept by default
or another compiler option is needed to specify that. But without this
facility, the proposed warning will be useless in practice, at least for people
like me writing embedded software.

[Bug target/96706] [nvptx] compilation failure of pr89663-1.c

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Target||nvptx

--- Comment #1 from Tom de Vries  ---
Tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 39d0275493a..7ad9ab326d0 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -895,12 +895,12 @@ write_fn_proto (std::stringstream , bool is_defn,
  NULL in DECL_ARGUMENTS, for builtin functions without another
declaration.
  So we have to pick the best one we have.  */
-  tree args = TYPE_ARG_TYPES (fntype);
-  bool prototyped = true;
+  tree args = DECL_ARGUMENTS (decl);
+  bool prototyped = false;
   if (!args)
 {
-  args = DECL_ARGUMENTS (decl);
-  prototyped = false;
+  args = TYPE_ARG_TYPES (fntype);
+  prototyped = true;
 }

   for (; args; args = TREE_CHAIN (args), not_atomic_weak_arg--)
@@ -1304,12 +1304,12 @@ nvptx_declare_function_name (FILE *file, const char
*name, const_tree decl)
 argno = write_arg_type (s, 0, argno, ptr_type_node, true);

   /* Declare and initialize incoming arguments.  */
-  tree args = TYPE_ARG_TYPES (fntype);
-  bool prototyped = true;
+  tree args = DECL_ARGUMENTS (decl);
+  bool prototyped = false;
   if (!args)
 {
-  args = DECL_ARGUMENTS (decl);
-  prototyped = false;
+  args = TYPE_ARG_TYPES (fntype);
+  prototyped = true;
 }

   for (; args != NULL_TREE; args = TREE_CHAIN (args))
...

[Bug analyzer/96705] [11 Regression] ICE: in wide_int_to_tree_1, at tree.c:1612 with -fanalyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-08-19
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from David Malcolm  ---
Thanks for filing this; confirmed.

[Bug tree-optimization/96708] Failure to optimize max pattern with comparison when using a temporary variable

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
PS: This especially affects, for example, C++ code that uses std::max, which
fails to optimize properly compared to, for example, a `max` macro.

[Bug tree-optimization/96708] New: Failure to optimize max pattern with comparison when using a temporary variable

[gabravier at gmail dot com]

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

Bug ID: 96708
   Summary: Failure to optimize max pattern with comparison when
using a temporary variable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(int a, int b)
{
int tmp = (a < b) ? b : a;
return tmp >= a;
}

This can be optimized to `return true;`. This transformation is done by LLVM,
but not by GCC.

PS: This is probably related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95926.

[Bug target/95458] Inline strncmp is *much* slower than glibc

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-19

--- Comment #2 from H.J. Lu  ---
(In reply to Alexandre Oliva from comment #1)
> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00701.html seems
> relevant

We can improve inlined strncmp.  But the library version still is much
faster.

[Bug tree-optimization/96707] Failure to optimize right shift+unsigned compare of two variables optimally

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
PS: This transformation can also be done with a very similar pattern where the
return statement is replaced with this : `return (x / y) <= x;`

[Bug tree-optimization/96707] New: Failure to optimize right shift+unsigned compare of two variables optimally

[gabravier at gmail dot com]

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

Bug ID: 96707
   Summary: Failure to optimize right shift+unsigned compare of
two variables optimally
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(unsigned x, unsigned y)
{
return (x >> y) <= x;
}

This can be optimized to `return true;`. This transformation is done by LLVM,
but not by GCC.

[Bug target/96706] New: [nvptx] compilation failure of pr89663-1.c

[vries at gcc dot gnu.org]

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

Bug ID: 96706
   Summary: [nvptx] compilation failure of pr89663-1.c
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case pr89663-1.c, minimized from
gcc/testsuite/gcc.c-torture/compile/pr89663-1.c, and with added main:
...
long lrint ();

void
foo (long long *p)
{
  int n = 0;
  p[n++] = lrint (1);
}

long
lrint (a)
  int a;  
{
  return a + 1;
}

int
main (void)
{
  long long l;
  foo ();
  return l == 2;
}
...

With gcc on x86_64, we have:
...
$ gcc pr89663-1.c -fno-builtin
$ ./a.out; echo $?
1
...
and:
...
$ gcc pr89663-1.c
pr89663-1.c: In function ‘lrint’:
pr89663-1.c:12:7: warning: argument ‘a’ doesn’t match built-in prototype
   int a;
   ^
$ ./a.out; echo $?
1
...

With nvptx, we have:
...
$ /home/vries/nvptx/mainkernel-2/build-gcc/gcc/xgcc
-B/home/vries/nvptx/mainkernel-2/build-gcc/gcc/ -fdiagnostics-plain-output
--sysroot=/home/vries/nvptx/mainkernel-2/install/nvptx-none -w -O0 -isystem
/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib/targ-include
-isystem /home/vries/nvptx/mainkernel-2/source-gcc/newlib/libc/include
-B/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib/
-L/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib -mmainkernel -lm
pr89663-1.c -fno-builtin
$ ~/nvptx/mainkernel-2/install/bin/nvptx-none-run a.out; echo $?
1
...
and:
...
$ /home/vries/nvptx/mainkernel-2/build-gcc/gcc/xgcc
-B/home/vries/nvptx/mainkernel-2/build-gcc/gcc/ -fdiagnostics-plain-output
--sysroot=/home/vries/nvptx/mainkernel-2/install/nvptx-none -w -O0 -isystem
/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib/targ-include
-isystem /home/vries/nvptx/mainkernel-2/source-gcc/newlib/libc/include
-B/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib/
-L/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib -mmainkernel -lm
pr89663-1.c 
ptxas /tmp/ccbuZdU3.o, line 26; error   : Arguments mismatch for instruction
'mov'
ptxas /tmp/ccbuZdU3.o, line 71; error   : Type of argument does not match
formal parameter '%in_ar0'
ptxas /tmp/ccbuZdU3.o, line 71; error   : Alignment of argument does not match
formal parameter '%in_ar0'
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
...
because:
...
// BEGIN GLOBAL FUNCTION DECL: lrint
.visible .func (.param.u64 %value_out) lrint (.param.f64 %in_ar0);  

// BEGIN GLOBAL FUNCTION DEF: lrint 
.visible .func (.param.u64 %value_out) lrint (.param.f64 %in_ar0)
{
.reg.f64 %ar0;  
ld.param.f64 %ar0, [%in_ar0];   
.reg.u32 %r25;  
mov.u32 %r25, %ar0;
  ...

The problem is that we end up in nvptx_declare_function_name with a decl that
has as decl args:
...
arguments  unit-size 
...
but we to emit the declaration, we use the fntype, which has arg:
...
(gdb) call debug_tree (args)
 
...

[Bug c/96682] Arm: Wrong code generated for MVE with -O1 and above optimization options.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Joe Ramsay
:

https://gcc.gnu.org/g:10e0d2010f0597e6ae7efb88142b8820608c585e

commit r10-8643-g10e0d2010f0597e6ae7efb88142b8820608c585e
Author: Joe Ramsay 
Date:   Wed Jul 29 14:04:28 2020 +0100

arm: Enable no-writeback vldr.16/vstr.16.

There was previously no way to specify that a register operand cannot
have any writeback modifiers, and as a result the argument to vldr.16
and vstr.16 could be erroneously output with post-increment. This
change adds a constraint which forbids all writeback, and
selects it in the relevant case for vldr.16 and vstr.16

gcc/ChangeLog:

PR target/96682
* config/arm/arm-protos.h (arm_coproc_mem_operand_no_writeback):
Declare prototype.
(arm_mve_mode_and_operands_type_check): Declare prototype.
* config/arm/arm.c (arm_coproc_mem_operand): Refactor to use
_arm_coproc_mem_operand.
(arm_coproc_mem_operand_wb): New function to cover full, limited
and no writeback.
(arm_coproc_mem_operand_no_writeback): New constraint for memory
operand with no writeback.
(arm_print_operand): Extend 'E' specifier for memory operand
that does not support writeback.
(arm_mve_mode_and_operands_type_check): New constraint check for
MVE memory operands.
* config/arm/constraints.md: Add Uj constraint for VFP vldr.16
and vstr.16.
* config/arm/vfp.md (*mov_load_vfp_hf16): New pattern for
vldr.16.
(*mov_store_vfp_hf16): New pattern for vstr.16.
(*mov_vfp_16): Remove MVE moves.

gcc/testsuite/ChangeLog:

PR target/96682
* gcc.target/arm/mve/intrinsics/mve-vldstr16-no-writeback.c: New
test.

(cherry picked from commit 9f6abd2db90151c8966d2d2718ab8c299abf1105)

[Bug analyzer/96705] New: [11 Regression] ICE: in wide_int_to_tree_1, at tree.c:1612 with -fanalyzer

[zsojka at seznam dot cz]

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

Bug ID: 96705
   Summary: [11 Regression] ICE: in wide_int_to_tree_1, at
tree.c:1612 with -fanalyzer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 49081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49081=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c 
during IPA pass: analyzer
testcase.c: In function 'foo':
testcase.c:8:5: internal compiler error: in wide_int_to_tree_1, at tree.c:1612
8 |   v *= i;
  | ^~
0x7b2ac7 wide_int_to_tree_1
/repo/gcc-trunk/gcc/tree.c:1612
0x136d38c wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
/repo/gcc-trunk/gcc/tree.c:1724
0x136d38c build_int_cst(tree_node*, poly_int<1u, long>)
/repo/gcc-trunk/gcc/tree.c:1364
0x1451ff1 ana::region_model_manager::maybe_fold_binop(tree_node*, tree_code,
ana::svalue const*, ana::svalue const*)
/repo/gcc-trunk/gcc/analyzer/region-model-manager.cc:444
0x1450cd6 ana::region_model_manager::get_or_create_binop(tree_node*, tree_code,
ana::svalue const*, ana::svalue const*)
/repo/gcc-trunk/gcc/analyzer/region-model-manager.cc:525
0x143f637 ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:563
0x1422f70 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
/repo/gcc-trunk/gcc/analyzer/engine.cc:1029
0x14240af ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:2526
0x14249a2 ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:2341
0x1426a19 ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:4107
0x14283ac ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:4175
0x141c4e8 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:84
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:69f571ffc513b689fa26e4c9fceba17c2c989ab3

commit r11-2759-g69f571ffc513b689fa26e4c9fceba17c2c989ab3
Author: Antony Polukhin 
Date:   Wed Aug 19 12:10:57 2020 +0100

libstdc++: assert that type traits are not misused with incomplete types
[PR 71579]

libstdc++-v3/ChangeLog:

2020-08-19  Antony Polukhin  

PR libstdc++/71579
* include/std/type_traits (invoke_result, is_nothrow_invocable_r)
Add static_asserts to make sure that the argument of the type
trait is not misused with incomplete types.
(is_swappable_with, is_nothrow_swappable_with): Add static_asserts
to make sure that the first and second arguments of the type trait
are not misused with incomplete types.
* testsuite/20_util/invoke_result/incomplete_neg.cc: New test.
* testsuite/20_util/is_nothrow_invocable/incomplete_neg.cc: New
test.
* testsuite/20_util/is_nothrow_swappable/incomplete_neg.cc: New
test.
* testsuite/20_util/is_nothrow_swappable_with/incomplete_neg.cc:
New
test.
* testsuite/20_util/is_swappable_with/incomplete_neg.cc: New test.

[Bug c++/96704] begin() and end() iterators of views::values_view have different type

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Right, it's incorrect to assume begin and end return the same type for a range.

Use std::common_iterator if you need to turn an iterator and its sentinel into
a single type:

  using CI = std::common_iterator;
  foo(CI(r.begin()), CI(r.end()));

[Bug target/96262] [11 Regression] ICE: in decompose, at rtl.h:2280 with -O -mavx512bw since r11-1411-gc7199fb6e694d1a0

[zsojka at seznam dot cz]

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

--- Comment #4 from Zdenek Sojka  ---
Created attachment 49080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49080=edit
another testcase

[Bug c++/96704] begin() and end() iterators of views::values_view have different type

[gleb at scylladb dot com]

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

Gleb Natapov  changed:

   What|Removed |Added

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

--- Comment #2 from Gleb Natapov  ---
Closing.

[Bug c++/96704] begin() and end() iterators of views::values_view have different type

[gleb at scylladb dot com]

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

--- Comment #1 from Gleb Natapov  ---
Ah, those appears to be sentinel iterators.

[Bug gcov-profile/96622] gcov misses to count break statement

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Roland Illig from comment #3)
> Ah, thanks for the pointer.
> 
> I thought I had used -O0 in the larger project as well, but I hadn't.
> 
> Just as a suggestion, would it make sense to apply the coverage at the
> source code level (before any optimizations) instead of optimizing first and
> then adding the counters?  It would feel more predictable to me.

Note that it's not possible as some optimizations happen in folding even in
front-end. Intrumentation happens as soon as possible in optimization pipeline.

[Bug c++/96704] New: begin() and end() iterators of views::values_view have different type

[gleb at scylladb dot com]

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

Bug ID: 96704
   Summary: begin() and end() iterators of views::values_view have
different type
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gleb at scylladb dot com
  Target Milestone: ---

The following program fail on the second assert.

#include 
#include 

int main() {
  std::unordered_map x;
  auto r = std::views::values(x);
  static_assert(std::is_same_v);
  static_assert(std::is_same_v);
}

It means functions like:

template foo(I it1, I it2);

cannot be called with:

foo(r.begin(), r.end());

[Bug tree-optimization/96698] aarch64: ICE during GIMPLE pass:vect

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-08-19

[Bug tree-optimization/96703] New: Failure to optimize combined comparison of variables and of variable with 0 to two comparisons with 0

[gabravier at gmail dot com]

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

Bug ID: 96703
   Summary: Failure to optimize combined comparison of variables
and of variable with 0 to two comparisons with 0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(int x, int y)
{
return x > y && y == 0;
}

This can be optimized to `return (y == 0) && (x > 0);` (This transformation
doesn't by itself make the code faster, but it probably helps with pipelined
CPUs (avoids dependency on both variables for the first comparison) and looks
like it would most likely make other optimizations easier). This transformation
is done by LLVM, but not by GCC.

[Bug tree-optimization/96702] New: Failure to optimize comparisons involving result of subtraction

[gabravier at gmail dot com]

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

Bug ID: 96702
   Summary: Failure to optimize comparisons involving result of
subtraction
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(int a, int b)
{
int c = (a - b);
return c >= a && c != 0;
}

This can be optimized to `return (b <= 0) && (a != b);`. This transformation is
done by LLVM, but not by GCC.

[Bug tree-optimization/96701] New: Failure to optimize self right-shift to 0

[gabravier at gmail dot com]

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

Bug ID: 96701
   Summary: Failure to optimize self right-shift to 0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x)
{
return x >> x;
}

This can be optimized to `return 0;`. This transformation is done by LLVM, but
not by GCC.

[Bug c++/70462] Unnecessary "base object constructor" for final classes

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Let's keep that discussion in PR 95428 rather than in a resolved bug.

[Bug tree-optimization/96548] [11 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:247 since r11-2574-g6aec53ee4f75a64c

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Richi is on vacation. I'm pretty sure he'll quick it as soon as he gets back.

[Bug tree-optimization/96548] [11 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:247 since r11-2574-g6aec53ee4f75a64c

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
This bug has been hanging about for over a week now without resolution.

Is the best way to get this into Richard's intray to assign it to him ?

[Bug tree-optimization/96548] [11 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:247 since r11-2574-g6aec53ee4f75a64c

[cnsun at uwaterloo dot ca]

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

cnsun at uwaterloo dot ca  changed:

   What|Removed |Added

 CC||cnsun at uwaterloo dot ca

--- Comment #3 from cnsun at uwaterloo dot ca  ---
Another one.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --prefix=/scratch/software/gcc-trunk
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200818 (experimental) [master revision
:65bdb4763:bb1b7f087bdd028000fd8f84e74b20adccc9d5bb] (GCC) 
$ gcc-trunk -O2 small.c
during GIMPLE pass: lim
small.c: In function ‘main’:
small.c:4:5: internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
4 | int main() {
  | ^~~~
0x74a390 compute_live_loop_exits
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:247
0x74a390 add_exit_phis_var
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:334
0x74a390 add_exit_phis
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:356
0x74a390 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:678
0x74a390 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:631
0xfa022b tree_ssa_lim
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-im.c:3126
0xfa022b execute
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-im.c:3173
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ gcc-trunk -O3 small.c
during GIMPLE pass: lim
small.c: In function ‘main’:
small.c:4:5: internal compiler error: in compute_live_loop_exits, at
tree-ssa-loop-manip.c:247
4 | int main() {
  | ^~~~
0x74a390 compute_live_loop_exits
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:247
0x74a390 add_exit_phis_var
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:334
0x74a390 add_exit_phis
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:356
0x74a390 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:678
0x74a390 rewrite_into_loop_closed_ssa_1(bitmap_head*, unsigned int, int, loop*)
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-manip.c:631
0xfa022b tree_ssa_lim
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-im.c:3126
0xfa022b execute
/tmp/tmp.iVAQqIzIa4-gcc-builder/gcc/gcc/tree-ssa-loop-im.c:3173
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ cat small.c
short a, b, d, f, g, j;
int c, e;
int *h;
int main() {
  int i = 0;
  for (; i < 3; i++)
  l:
b = j;
  while (d)
e++;
  g = f ? a : f;
  *h = g;
  if (c)
goto l;
}

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #5 from Tom de Vries  ---
Testsuite patch committed, marking resolved-fixed.

[Bug target/96494] [nvptx] Enable effective target sync_int_long

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2756-g9eaf11417b6a017b21a5052a74be3d2a251cfb78
Author: Tom de Vries 
Date:   Mon Aug 10 15:42:38 2020 +0200

[testsuite, nvptx] Add effective target sync_int_long_stack

The nvptx target currently doesn't support effective target sync_int_long,
although it has support for 32-bit and 64-bit atomic.

When enabling sync_int_long for nvptx, we run into a failure in
gcc.dg/pr86314.c:
...
 nvptx-run: error getting kernel result: operation not supported on \
   global/shared address space
...
due to a ptx restriction:  accesses to local memory are illegal, and the
test-case does an atomic operation on a stack address, which is mapped to
local memory.

Fix this by adding a target sync_int_long_stack, wich returns false for
nvptx,
which can be used to mark test-cases that require sync_int_long support for
stack addresses.

Build on nvptx and tested with make check-gcc.

gcc/testsuite/ChangeLog:

PR target/96494
* lib/target-supports.exp (check_effective_target_sync_int_long):
Return 1 for nvptx.
(check_effective_target_sync_int_long_stack): New proc.
* gcc.dg/pr86314.c: Require effective target sync_int_long_stack.

[Bug target/96072] ICE: Segmentation fault (in add_reg_note)

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
Finally, yet another testcase which also plays games w/ SP but, unlike the
previous two, does not involve its "manual" manipulation.

void
he (int jn)
{
  {
int bh[jn];

if (jn != 0)
  goto wa;
  }

 wa:
  ;
}

[Bug c++/83445] conversion function has too high priority in overload resolution

[karzh at mail dot ru]

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

--- Comment #5 from Alexander Karzhenkov  ---
Also note that const-qualifier on `Source::operator Target()` affects the
conversion sequence (see https://godbolt.org/z/MexGW9). This seems inconsistent
here.

[Bug lto/96700] New: undefined reference to `failure_on_line_796'

[sujian.liu at huawei dot com]

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

Bug ID: 96700
   Summary: undefined reference to `failure_on_line_796'
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sujian.liu at huawei dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

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

When I compile without -flto, it has no errors.

riscv32-unknown-elf-gcc gcc.dg/tree-ssa/builtin-sprintf.c
-fno-optimize-sibling-calls -fstack-protector -fno-diagnostics-show-caret
-fdiagnostics-color=never -ansi -pedantic-errors -O2 -Wall -Wno-pedantic
-fprintf-return-value -lm -o ./builtin-sprintf.exe
gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_d_i':
gcc.dg/tree-ssa/builtin-sprintf.c:307:20: warning: '0' flag ignored with
precision and '%i' gnu_printf format [-Wformat=]
gcc.dg/tree-ssa/builtin-sprintf.c:128:44: note: in definition of macro 'RNG'
gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_percent':
gcc.dg/tree-ssa/builtin-sprintf.c:796:18: warning: too many arguments for
format [-Wformat-extra-args]
gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL'
gcc.dg/tree-ssa/builtin-sprintf.c:797:18: warning: too many arguments for
format [-Wformat-extra-args]
gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL'
gcc.dg/tree-ssa/builtin-sprintf.c:798:18: warning: too many arguments for
format [-Wformat-extra-args]
gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL'

When I compile with -flto, I will get the error as follow:

riscv32-unknown-elf-gcc gcc.dg/tree-ssa/builtin-sprintf.c
-fno-optimize-sibling-calls -fstack-protector -fno-diagnostics-show-caret
-fdiagnostics-color=never -ansi -pedantic-errors -O2 -Wall -Wno-pedantic
-fprintf-return-value -lm -o ./builtin-sprintf.exe -flto
gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_d_i':
gcc.dg/tree-ssa/builtin-sprintf.c:307:20: warning: '0' flag ignored with
precision and '%i' gnu_printf format [-Wformat=]
gcc.dg/tree-ssa/builtin-sprintf.c:128:44: note: in definition of macro 'RNG'
gcc.dg/tree-ssa/builtin-sprintf.c: In function 'test_percent':
gcc.dg/tree-ssa/builtin-sprintf.c:796:18: warning: too many arguments for
format [-Wformat-extra-args]
gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL'
gcc.dg/tree-ssa/builtin-sprintf.c:797:18: warning: too many arguments for
format [-Wformat-extra-args]
gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL'
gcc.dg/tree-ssa/builtin-sprintf.c:798:18: warning: too many arguments for
format [-Wformat-extra-args]
gcc.dg/tree-ssa/builtin-sprintf.c:114:44: note: in definition of macro 'EQL'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/ccvVHTzC.ltrans0.ltrans.o: in function `check':
:(.text+0x182): undefined reference to `failure_on_line_796'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/ccvVHTzC.ltrans0.ltrans.o: in function `test_percent':
:(.text+0x1c6): undefined reference to `failure_on_line_797'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
:(.text+0x206): undefined reference to `failure_on_line_798'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
:(.text+0x248): undefined reference to `failure_on_line_799'
..
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/ccvVHTzC.ltrans0.ltrans.o: in function `.L576':
:(.text+0x7744): undefined reference to `failure_on_line_164'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/ccvVHTzC.ltrans0.ltrans.o: in function `.L577':
:(.text+0x77a4): undefined reference to `failure_on_line_165'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/ccvVHTzC.ltrans0.ltrans.o: in function `.L579':
:(.text+0x7808): undefined reference to `failure_on_line_167'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/ccvVHTzC.ltrans0.ltrans.o: in function `.L580':
:(.text+0x7862): undefined reference to `failure_on_line_168'
/home/lsj/b014/hcc_riscv32/bin/../lib/gcc/riscv32-unknown-elf/7.3.0/../../../../riscv32-unknown-elf/bin/ld:
/tmp/ccvVHTzC.ltrans0.ltrans.o: in function `.L581':
:(.text+0x78b4): undefined reference to `failure_on_line_169'
collect2: error: ld returned 1 exit status

I trited with the lastest gcc version (10.1.0),it show the same error without
the option -flto:

[Bug gcov-profile/96622] gcov misses to count break statement

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
Ah, thanks for the pointer.

I thought I had used -O0 in the larger project as well, but I hadn't.

Just as a suggestion, would it make sense to apply the coverage at the source
code level (before any optimizations) instead of optimizing first and then
adding the counters?  It would feel more predictable to me.

https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html#Gcov-Intro

At least for the "discover untested parts of your program", that would make
sense to me since in my code, the "break" statement has an effect, independent
of any optimization level.

https://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html#Invoking-Gcov

In this section, the string "tim" occurs often, but only in "number of times",
"each time", but not in "measured wall time".  Therefore I think gcov is more
about counting that about measuring time.