[Bug c++/96743] ICE on flexible array in initializer list using lambdas

[kevin at arilabs dot net]

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

--- Comment #1 from Kevin Stallard  ---
A more complete output of the error:

/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:
In constructor 'BraceTest::BraceTest()':
/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:23:102:
internal compiler error: in build_vec_init_elt, at cp/tree.c:665
 BraceTest::BraceTest() : _entries { {"FirstAction", [this]( const char *data)
{this->Foo( data );} } }
   
  ^

[Bug c++/96743] New: ICE on flexible array in initializer list using lambdas

[kevin at arilabs dot net]

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

Bug ID: 96743
   Summary: ICE on flexible array in initializer list using
lambdas
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin at arilabs dot net
  Target Milestone: ---

I'm seeing:
/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:
In constructor 'BraceTest::BraceTest()':
/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:23:102:
internal compiler error: in build_vec_init_elt, at cp/tree.c:665

In the following code:
#include 
#include 
#include 

class BraceTest
{
public:
BraceTest();

struct BraceTestArrayEntries
{
const char *name;
std::function action;
};

void RunAction( const char *actionName );
void Foo( const char *data );

int _some_data=0;
BraceTestArrayEntries   _entries[];
};

BraceTest::BraceTest() : _entries { {"FirstAction", [this]( const char *data)
{this->Foo( data );} } }
{

}

void BraceTest::RunAction( const char *actionName )
{

}

void BraceTest::Foo( const char *data )
{

}


int main(int argc, char *argv[]) {
std::cout << "Welcome to the Momentics IDE" << std::endl;

BraceTest   bt;
bt.RunAction("FirstAction");

return EXIT_SUCCESS;
}

[Bug c++/96742] New: "warning: comparison of unsigned expression in ‘< 0’ is always false" with dependent values

[wtt6 at cornell dot edu]

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

Bug ID: 96742
   Summary: "warning: comparison of unsigned expression in ‘< 0’
is always false" with dependent values
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wtt6 at cornell dot edu
  Target Milestone: ---

The following code warns "comparison of unsigned expression in ‘< 0’ is always
false" when compiled with 10.2.0, but not with 10.1.

---
template 
bool f(unsigned x) {
return x < N;
}

int main() {
f<0>(1);
}
---

This appears to be similar to bug 11856 and, in particular, its duplicate bug
45553.

[Bug c++/96741] New: ICE in value_dependent_expression_p when compiling Boost.Xpressive in C++03 mode

[andysem at mail dot ru]

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

Bug ID: 96741
   Summary: ICE in value_dependent_expression_p when compiling
Boost.Xpressive in C++03 mode
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andysem at mail dot ru
  Target Milestone: ---

Created attachment 49097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49097=edit
Preprocessed source of the test that fails to compile with ICE

Attached is the preprocessed source of a Boost.Log test that uses
Boost.Xpressive, which fails to compile with ICE in C++03 mode. The same code
compiles in C++11 mode. Also compiles with gcc 9.3, both in C++03 and C++11.

$ "g++-10"   -std=c++03 -fPIC -m64 -pthread -O0 -fno-inline -Wall -g
-fno-strict-aliasing -ftemplate-depth-1024 -DBOOST_ALL_NO_LIB=1
-DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1
-DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LOG_DYN_LINK=1
-DBOOST_LOG_SETUP_DYN_LINK=1 -DBOOST_LOG_USE_AVX2 -DBOOST_LOG_USE_SSSE3
-DBOOST_TEST_DYN_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_THREAD_BUILD_DLL=1
-DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -D_XOPEN_SOURCE=600  -I"."
-I"libs/log/test/common"  -c -o "filt_matches_xpressive.o"
"libs/log/test/run/filt_matches_xpressive.cpp"

In file included from ./boost/assert.hpp:58,
 from
./boost/xpressive/detail/core/matcher/simple_repeat_matcher.hpp:16,
 from ./boost/xpressive/detail/core/matchers.hpp:46,
 from ./boost/xpressive/detail/core/linker.hpp:35,
 from ./boost/xpressive/detail/static/static.hpp:19,
 from
./boost/xpressive/detail/static/transforms/as_matcher.hpp:18,
 from ./boost/xpressive/detail/static/grammar.hpp:21,
 from ./boost/xpressive/basic_regex.hpp:28,
 from ./boost/xpressive/regex_compiler.hpp:30,
 from ./boost/xpressive/xpressive_dynamic.hpp:17,
 from libs/log/test/run/filt_matches_xpressive.cpp:18:
./boost/xpressive/detail/core/matcher/simple_repeat_matcher.hpp: In
instantiation of ‘boost::xpressive::detail::simple_repeat_matcher::simple_repeat_matcher(const Xpr&, unsigned int, unsigned int,
std::size_t) [with Xpr =
boost::xpressive::detail::matcher_wrapper >, mpl_::bool_,
boost::xpressive::detail::compound_charset > > > >; Greedy = mpl_::bool_;
std::size_t = long unsigned int]’:
./boost/xpressive/detail/dynamic/dynamic.hpp:216:48:   required from ‘void
boost::xpressive::detail::make_simple_repeat(const
boost::xpressive::detail::quant_spec&,
boost::xpressive::detail::sequence&, const Xpr&) [with BidiIter =
const char*; Xpr =
boost::xpressive::detail::matcher_wrapper >, mpl_::bool_,
boost::xpressive::detail::compound_charset > > > >]’
./boost/xpressive/detail/dynamic/dynamic.hpp:130:31:   required from ‘void
boost::xpressive::detail::dynamic_xpression::repeat_(const
boost::xpressive::detail::quant_spec&,
boost::xpressive::detail::sequence&, mpl_::int_<1>, mpl_::false_)
const [with Matcher =
boost::xpressive::detail::charset_matcher >, mpl_::bool_,
boost::xpressive::detail::compound_charset > > >; BidiIter = const char*;
mpl_::false_ = mpl_::bool_]’
./boost/xpressive/detail/dynamic/dynamic.hpp:96:22:   required from ‘void
boost::xpressive::detail::dynamic_xpression::repeat(const
boost::xpressive::detail::quant_spec&,
boost::xpressive::detail::sequence&) const [with Matcher =
boost::xpressive::detail::charset_matcher >, mpl_::bool_,
boost::xpressive::detail::compound_charset > > >; BidiIter = const char*]’
./boost/xpressive/detail/dynamic/dynamic.hpp:94:18:   required from here
./boost/xpressive/detail/core/matcher/simple_repeat_matcher.hpp:81:37: internal
compiler error: in value_dependent_expression_p, at cp/pt.c:26439
   81 | BOOST_ASSERT(0 != width && unknown_width() != width);
  |  ~~~^~~
./boost/xpressive/detail/core/matcher/simple_repeat_matcher.hpp:81:13: note: in
expansion of macro ‘BOOST_ASSERT’
   81 | BOOST_ASSERT(0 != width && unknown_width() != width);
  | ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ g++-10 -v
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10-20200411-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib 

[Bug c/96740] frexp, modf, and remquo missing attribute nonnull

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization

--- Comment #1 from Martin Sebor  ---
Besides the missing warnings the absence of the attribute also means that
subsequent tests in the callers of the functions for the pointers being null
are not optimized away as they could be if the functions made use of attribute
nonnull:

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
double f0 (double x, int *p)
{
  double y = __builtin_frexp (x, p);
  if (!p) __builtin_abort ();  // not eliminated
  return y;

}
double f2 (const char *s)
{ 
  double x = __builtin_nan (s);
  if (!s) __builtin_abort ();  // eliminated
  return x;
}

;; Function f0 (f0, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

f0 (double x, int * p)
{
  double y;

   [local count: 1073741824]:
  y_5 = __builtin_frexp (x_2(D), p_3(D));
  if (p_3(D) == 0B)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return y_5;

}



;; Function f2 (f2, funcdef_no=1, decl_uid=1936, cgraph_uid=2, symbol_order=1)

f2 (const char * s)
{
  double x;

   [local count: 1073741824]:
  x_2 = __builtin_nan (s_1(D)); [tail call]
  return x_2;

}

[Bug c/96740] New: frexp, modf, and remquo missing attribute nonnull

[msebor at gcc dot gnu.org]

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

Bug ID: 96740
   Summary: frexp, modf, and remquo missing attribute nonnull
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The math built-in functions frexp, modf, and remquo take pointers to objects
that they are specified to unconditionally store a component of the result in. 
Their internal declarations should make use of attribute nonnull to trigger
-Wnonnull warnings when they're passed a null pointer.

$ cat z.c && gcc -O2 -S -Wall z.c
double f0 (double x)
{
  return __builtin_frexp (x, (int*)0);   // missing warning
}

double f1 (double x)
{ 
  return __builtin_modf (x, (double*)0); // missing warning
}

double f2 (void)
{ 
  return __builtin_nan ((char*)0);   // -Wnonnull (good)
}

double f3 (double x, double y)
{ 
  return __builtin_remquo (x, y, (int*)0);   // missing warning
}

z.c: In function ‘f2’:
z.c:13:10: warning: argument 1 null where non-null expected [-Wnonnull]
   13 |   return __builtin_nan ((char*)0);   // -Wnonnull (good)
  |  ^
: note: in a call to function ‘__builtin_nan’ declared ‘nonnull’

[Bug c/96739] attribute(constructor) vs format NULL check

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The warning is issued as a result of the if statement in help_oneline.  Since
cmd is passed ct->name, if cmd is null then so is ct->name (see below). 
Perhaps you went too far in reducing the test case?

$ cat pr96739.c && gcc -O2 -S -Wall pr96739.c
typedef struct cmdinfo {
  const char *name;
} cmdinfo_t;
;
cmdinfo_t *cmdtab;
int ncmds;

static void help_oneline(const char *cmd, const cmdinfo_t *ct) {
  if (cmd) {
  } else {
__builtin_printf("%s ", ct->name);
  }
}
void help_all(void) {
  const cmdinfo_t *ct;
  for (ct = cmdtab; ct < [ncmds]; ct++)
help_oneline (ct->name, ct);
}
In function ‘help_oneline’,
inlined from ‘help_all’ at pr96739.c:17:5:
pr96739.c:11:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
   11 | __builtin_printf("%s ", ct->name);
  | ^

[Bug c++/95428] ABI breakage for "base object constructor" for final classes

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/96739] New: attribute(constructor) vs format NULL check

[dgilbert at redhat dot com]

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

Bug ID: 96739
   Summary: attribute(constructor) vs format NULL check
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dgilbert at redhat dot com
  Target Milestone: ---

Created attachment 49096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49096=edit
boiled down test file

The following is boiled down (too far?) from current
(d6f83a72a7db94a3ede9f5cc4fb39f9c8e89f954) qemu-io-cmds.c

and generates the warning:
ioprob.c:28:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
   28 | printf("%s ", ct->name);
  | ^~~

unless the __attribute((constructor)) is removed from init_qemuio_commands

I think the problem here is that ct comes from cmdtab which is a static and it
doesn't notice that it's initialised, and therefore decides it's NULL?


cc -O1  -Wformat -Wformat-security  -c ioprob.c -Wunused 
In function ‘help_oneline’,
inlined from ‘help_all’ at ioprob.c:34:5,
inlined from ‘help_f’ at ioprob.c:39:5:
ioprob.c:28:5: warning: ‘%s’ directive argument is null [-Wformat-overflow=]
   28 | printf("%s ", ct->name);
  | ^~~

[dgilbert@dgilbert-t580 try]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20200723 (Red Hat 10.2.1-1) (GCC)

[Bug rtl-optimization/96738] New: GCC generates worse assembly than clang and It fails to vectorized code compared to clang

[euloanty at live dot com]

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

Bug ID: 96738
   Summary: GCC generates worse assembly than clang and It fails
to vectorized code compared to clang
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

https://godbolt.org/z/9K3369

#include
#include

struct number
{
std::array num;


inline constexpr std::uint64_t& operator[](std::size_t position)
noexcept
{
return num[position];
}
inline constexpr std::uint64_t const& operator[](std::size_t position)
const noexcept
{
return num[position];
}
};


number add_reduce(number const& a,number const& b) noexcept
{
constexpr auto reduce_mask_51{(static_cast(1) << 51) - 1};
number out;
std::uint64_t c{(a[0] + b[0])>>51};
out[1] = a[1] + b[1] + c; c = (out[1] >> 51); out[1] &= reduce_mask_51;
out[2] = a[2] + b[2] + c; c = (out[2] >> 51); out[2] &= reduce_mask_51;
out[3] = a[3] + b[3] + c; c = (out[3] >> 51); out[3] &= reduce_mask_51;
out[4] = a[4] + b[4] + c; c = (out[4] >> 51); out[4] &= reduce_mask_51;
out[0] = c * 19;
return out;
}


gcc:

add_reduce(number const&, number const&):
movq(%rdx), %rax
addq(%rsi), %rax
movq%rdi, %r8
movq%rdx, %rdi
shrq$51, %rax
movq8(%rdx), %rdx
addq8(%rsi), %rdx
movq%rsi, %rcx
movabsq $2251799813685247, %rsi
addq%rdx, %rax
movq%rax, %rdx
shrq$51, %rax
andq%rsi, %rdx
movq%rdx, 8(%r8)
movq16(%rdi), %rdx
addq16(%rcx), %rdx
addq%rdx, %rax
movq%rax, %rdx
shrq$51, %rax
andq%rsi, %rdx
movq%rdx, 16(%r8)
movq24(%rdi), %rdx
addq24(%rcx), %rdx
addq%rax, %rdx
movq%rdx, %rax
shrq$51, %rdx
andq%rsi, %rax
movq%rax, 24(%r8)
movq32(%rdi), %rax
addq32(%rcx), %rax
addq%rdx, %rax
andq%rax, %rsi
shrq$51, %rax
leaq(%rax,%rax,8), %rdx
movq%rsi, 32(%r8)
leaq(%rax,%rdx,2), %rax
movq%rax, (%r8)
movq%r8, %rax
ret

clang:
add_reduce(number const&, number const&): # @add_reduce(number
const&, number const&)
movq%rdi, %rax
movq(%rdx), %rcx
movq8(%rdx), %rdi
addq(%rsi), %rcx
shrq$51, %rcx
addq8(%rsi), %rdi
addq%rcx, %rdi
movq%rdi, %rcx
shrq$51, %rcx
movabsq $2251799813685247, %r8  # imm = 0x7
andq%r8, %rdi
movq%rdi, 8(%rax)
movq16(%rdx), %rdi
addq16(%rsi), %rdi
addq%rcx, %rdi
movq%rdi, %rcx
shrq$51, %rcx
andq%r8, %rdi
movq%rdi, 16(%rax)
movq24(%rdx), %rdi
addq24(%rsi), %rdi
addq%rcx, %rdi
movq%rdi, %rcx
andq%r8, %rdi
movq%rdi, 24(%rax)
movq32(%rdx), %rdx
addq32(%rsi), %rdx
shrq$51, %rcx
addq%rcx, %rdx
movq%rdx, %rcx
shrq$51, %rcx
andq%r8, %rdx
movq%rdx, 32(%rax)
leaq(%rcx,%rcx,8), %rdx
leaq(%rcx,%rdx,2), %rcx
movq%rcx, (%rax)
retq

clang with -march=native

.LCPI0_0:
.quad   2251799813685247
add_reduce(number const&, number const&): # @add_reduce(number
const&, number const&)
movq%rdi, %rax
movq(%rdx), %rcx
movq8(%rdx), %rdi
addq(%rsi), %rcx
shrq$51, %rcx
addq8(%rsi), %rdi
addq%rcx, %rdi
vmovq   %rdi, %xmm0
shrq$51, %rdi
movq16(%rdx), %rcx
addq16(%rsi), %rcx
addq%rdi, %rcx
vmovq   %rcx, %xmm1
shrq$51, %rcx
movq24(%rdx), %rdi
addq24(%rsi), %rdi
addq%rcx, %rdi
vmovq   %rdi, %xmm2
shrq$51, %rdi
movq32(%rdx), %rcx
addq32(%rsi), %rcx
addq%rdi, %rcx
vpunpcklqdq %xmm1, %xmm0, %xmm0 # xmm0 = xmm0[0],xmm1[0]
vmovq   %rcx, %xmm1
vpunpcklqdq %xmm1, %xmm2, %xmm1 # xmm1 = xmm2[0],xmm1[0]
vinserti128 $1, %xmm1, %ymm0, %ymm0
vpandq  .LCPI0_0(%rip){1to4}, %ymm0, %ymm0
shrq$51, %rcx
vmovdqu %ymm0, 8(%rax)
leaq(%rcx,%rcx,8), %rdx
leaq(%rcx,%rdx,2), %rcx

[Bug libstdc++/96736] FAIL: 17_intro/headers/c++1998/all_attributes.cc on Darwin

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2801-g9b5d4f6e6689cb80933aa5ac22684c83c7604a11
Author: Jonathan Wakely 
Date:   Fri Aug 21 18:23:22 2020 +0100

libstdc++: Do not check "cold" name on darwin [PR 96736]

libstdc++-v3/ChangeLog:

PR libstdc++/96736
* testsuite/17_intro/headers/c++1998/all_attributes.cc: Do not
test "cold" on darwin.
* testsuite/17_intro/headers/c++2011/all_attributes.cc:
Likewise.
* testsuite/17_intro/headers/c++2014/all_attributes.cc:
Likewise.
* testsuite/17_intro/headers/c++2017/all_attributes.cc:
Likewise.
* testsuite/17_intro/headers/c++2020/all_attributes.cc:
Likewise.

[Bug libstdc++/96736] FAIL: 17_intro/headers/c++1998/all_attributes.cc on Darwin

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Should be fixed now.

[Bug bootstrap/96735] --enable-maintainer-mode broken

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Checking out master instead of the branch I was on "fixed" things.

So, I guess may just be random timestamps in git, which do not
get updated correctly with contrib/gcc_update.

[Bug fortran/96737] ICE when compiling module and submodule in same file

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Dominique d'Humieres  ---
This seems fixed on GCC11.

[Bug libstdc++/96736] FAIL: 17_intro/headers/c++1998/all_attributes.cc on Darwin

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Looks like "cold" is defined in Darwin headers.

It needs to be moved after the #if check for Darwin.

[Bug fortran/96737] New: ICE when compiling module and submodule in same file

[vehre at gcc dot gnu.org]

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

Bug ID: 96737
   Summary: ICE when compiling module and submodule in same file
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vehre at gcc dot gnu.org
  Target Milestone: ---

Latest gfortran ICE with:
   35 | end module
  | 
Error: 'TYPE_CANONICAL' is not compatible
  constant 960>
unit-size  constant 120>
align:64 warn_if_not_align:0 symtab:620683744 alias-set -1 canonical-type
0x7f1324fef000
fields  unit-size 
align:64 warn_if_not_align:0 symtab:620683824 alias-set -1
canonical-type 0x7f1324fef348 fields 
pointer_to_this  chain >
BLK ../build-gcc/opencoarrays/intel-18-works-onefile.f90:35:10 size
 unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context 
pointer_to_this  reference_to_this
 chain >
  constant 1152>
unit-size  constant 144>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f1324fef000
fields  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f1324c2c498 fields 
pointer_to_this  chain >
BLK ../build-gcc/opencoarrays/intel-18-works-onefile.f90:64:13 size
 unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context >
chain >
../build-gcc/opencoarrays/intel-18-works-onefile.f90:35:0: internal compiler
error: 'verify_type' failed
0x17b70de verify_type(tree_node const*)
/home/vehre/Projekte/gcc/gcc.orig/gcc/tree.c:14744
0xd38de7 gen_type_die_with_usage
/home/vehre/Projekte/gcc/gcc.orig/gcc/dwarf2out.c:25500
0xd39a1a gen_type_die
/home/vehre/Projekte/gcc/gcc.orig/gcc/dwarf2out.c:25730
0xd3b95b gen_decl_die
/home/vehre/Projekte/gcc/gcc.orig/gcc/dwarf2out.c:26362
0xd3ce96 dwarf2out_decl
/home/vehre/Projekte/gcc/gcc.orig/gcc/dwarf2out.c:26910
0xd3c2f9 dwarf2out_type_decl
/home/vehre/Projekte/gcc/gcc.orig/gcc/dwarf2out.c:26635
0x11b6fa3 rest_of_type_compilation(tree_node*, int)
/home/vehre/Projekte/gcc/gcc.orig/gcc/passes.c:339
0xb70435 gfc_finish_type(tree_node*)
/home/vehre/Projekte/gcc/gcc.orig/gcc/fortran/trans-types.c:2327
0xb71ce0 gfc_get_derived_type(gfc_symbol*, int)
/home/vehre/Projekte/gcc/gcc.orig/gcc/fortran/trans-types.c:2812
0xb6c943 gfc_typenode_for_spec(gfc_typespec*, int)
/home/vehre/Projekte/gcc/gcc.orig/gcc/fortran/trans-types.c:1166
0xb700ce gfc_sym_type(gfc_symbol*)
/home/vehre/Projekte/gcc/gcc.orig/gcc/fortran/trans-types.c:2247
0xac977d gfc_get_symbol_decl(gfc_symbol*)
/home/vehre/Projekte/gcc/gcc.orig/gcc/fortran/trans-decl.c:1769
0xad70b2 gfc_create_module_variable
/home/vehre/Projekte/gcc/gcc.orig/gcc/fortran/trans-decl.c:5307

when compiling the example from:

https://github.com/sourceryinstitute/AdHoc/blob/master/src/gnu/nrc/coarray-with-nested-allocatable-components/intel-18-works.f90

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

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #6 from Hongtao.liu  ---
Fixed in GCC11.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r11-2800-gc44c2a3b0559979e3694ee2ab6860ec95fa3068a
Author: liuhongt 
Date:   Wed Jul 22 14:37:24 2020 +0800

Using gen_int_mode instead of GEN_INT to avoid ICE caused by type
promotion.

2020-07-22  Hongtao Liu  

gcc/
PR target/96262
* config/i386/i386-expand.c
(ix86_expand_vec_shift_qihi_constant): Refine.

gcc/testsuite/
* gcc.target/i386/pr96262-1.c: New test.

[Bug fortran/96724] Bogus warnings with the repeat intrinsic and the flag -Wconversion-extra

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Dominique d'Humieres  ---
Patch at https://gcc.gnu.org/pipermail/fortran/2020-August/054902.html.

[Bug fortran/96726] ICE with user defined specification function on assumed-rank array

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Patches have been submitted at

https://gcc.gnu.org/pipermail/fortran/2020-August/054903.html
and https://gcc.gnu.org/pipermail/fortran/2020-August/054904.html

[Bug fortran/96727] ICE with character length specified using specification function on assumed-rank array

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Patches have been submitted at

https://gcc.gnu.org/pipermail/fortran/2020-August/054903.html
and https://gcc.gnu.org/pipermail/fortran/2020-August/054904.html

[Bug fortran/96728] Fatal Error: Reading module inquiry functions on assumed-rank

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Another patch has been submitted at
https://gcc.gnu.org/pipermail/fortran/2020-August/054907.html

[Bug libstdc++/96736] New: FAIL: 17_intro/headers/c++1998/all_attributes.cc on Darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 96736
   Summary: FAIL: 17_intro/headers/c++1998/all_attributes.cc on
Darwin
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org, redi at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin19.6.0
Target: x86_64-apple-darwin19.6.0
 Build: x86_64-apple-darwin19.6.0

At r11-2757 (but not at r11-2711) I see

FAIL: 17_intro/headers/c++1998/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2011/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2017/all_attributes.cc (test for excess errors)
FAIL: 17_intro/headers/c++2020/all_attributes.cc (test for excess errors)

The failure is

In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/assert.h:42,^M
 from
/opt/gcc/build_w/x86_64-apple-darwin19.6.0/libstdc++-v3/include/cassert:44,^M
 from
/opt/gcc/build_w/x86_64-apple-darwin19.6.0/libstdc++-v3/include/x86_64-apple-darwin19.6.0/bits/stdc++.h:33,^M
 from
/opt/gcc/build_w/x86_64-apple-darwin19.6.0/libstdc++-v3/include/x86_64-apple-darwin19.6.0/bits/stdtr1c++.h:29,^M
 from
/opt/gcc/build_w/x86_64-apple-darwin19.6.0/libstdc++-v3/include/x86_64-apple-darwin19.6.0/bits/extc++.h:30,^M
 from
/opt/gcc/work/libstdc++-v3/testsuite/17_intro/headers/c++1998/all_attributes.cc:39:^M
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:171:
error: macro "__has_attribute" requires an identifier^M
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:171:
error: missing '(' in expression^M
compiler exited with status 1

[Bug bootstrap/96735] --enable-maintainer-mode broken

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
(And yes, I did run contrib/gcc_update)

[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Fri, Aug 21, 2020 at 10:35:27AM +, jrfsousa at gmail dot com wrote:
> Done!
> 
> https://gcc.gnu.org/pipermail/fortran/2020-August/054908.html
> 
> Thank you very much.
> 

Thanks for submitting.  If no one reviews the patch in the
next day or so, I think you can commit it.

BTW, for the git log and ChangeLog, I use ka...@gcc.gnu.org
not my sgk@troutmask address.

[Bug bootstrap/96735] New: --enable-maintainer-mode broken

[tkoenig at gcc dot gnu.org]

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

Bug ID: 96735
   Summary: --enable-maintainer-mode broken
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49095=edit
config.log from failed attempt

Current master is

commit b46584d7836bee011facdf946fd7241c748d66f0 (HEAD -> zfkts_branch,
origin/master, origin/HEAD)
Author: Alex Coplan 
Date:   2020-08-21 15:26:11 +0200

configure command is

../trunk/gcc/configure --prefix=$HOME --enable-languages=c,c++,fortran
--enable-maintainer-mode

Output is

$ make
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/sh ../trunk/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="" \
HEADERS="options.h insn-constants.h config/vxworks-dummy.h
config/i386/biarch64.h config/i386/i386.h config/i386/unix.h config/i386/att.h
config/dbxelf.h config/elfos.h config/gnu-user.h config/glibc-stdint.h
config/i386/x86-64.h config/i386/gnu-user-common.h config/i386/gnu-user64.h
config/linux.h config/linux-android.h config/i386/linux-common.h
config/i386/linux64.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1
LIBC_UCLIBC=2 LIBC_BIONIC=3 LIBC_MUSL=4 DEFAULT_LIBC=LIBC_GLIBC
ANDROID_DEFAULT=0" \
/bin/sh ../trunk/gcc/mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/i386/i386-protos.h config/linux-protos.h tm-preds.h" DEFINES=""
\
/bin/sh ../trunk/gcc/mkconfig.sh tm_p.h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/sh ../trunk/gcc/mkconfig.sh bconfig.h
g++ -c   -g   -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE
-I. -Ibuild -I../trunk/gcc -I../trunk/gcc/build -I../trunk/gcc/../include 
-I../trunk/gcc/../libcpp/include  \
-o build/genmodes.o ../trunk/gcc/genmodes.c
make: *** No rule to make target
'../build-x86_64-pc-linux-gnu/libiberty/libiberty.a', needed by
'build/genmodes'.  Stop.

[Bug fortran/96727] ICE with character length specified using specification function on assumed-rank array

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
   Last reconfirmed||2020-08-21
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  ---
Created attachment 49094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49094=edit
Patch for the PR

The first chunk fixes this PR and the second PR96726.

Regtests OK.

Paul

[Bug fortran/96726] ICE with user defined specification function on assumed-rank array

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-08-21
 CC||pault at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  ---
Created attachment 49093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49093=edit
Patch for the PR

The second chunk fixes this PR. The first fixes PR96727.

Regtests fine.

Oh, the benefits of long, boring meetings.

Paul

[Bug ipa/95320] [11 Regression] ICE in odr_type_p, at ipa-utils.h:246, during IPA pass: pure-const

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2974c828615b240f66b208301b5a73c6a07fcb22

commit r10-8653-g2974c828615b240f66b208301b5a73c6a07fcb22
Author: Tobias Burnus 
Date:   Tue May 26 18:24:28 2020 +0200

[LTO/offloading] Fix offloading-compilation ICE without -flto (PR84320)

gcc/ChangeLog:
PR ipa/95320
* ipa-utils.h (odr_type_p): Also permit calls with
only flag_generate_offload set.

(cherry picked from commit c5ab336ba106a407a67e84d8faac5b0ea6f18310)

[Bug c++/96732] [11 Regression] ice in pop_nested_class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|ice in pop_nested_class |[11 Regression] ice in
   ||pop_nested_class
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-21
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r11-2748

[Bug fortran/96728] Fatal Error: Reading module inquiry functions on assumed-rank

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-21
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Created attachment 49092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49092=edit
Patch for the PR

This fixes the bug and regtests. It will be some days before I submit - I have
a bit of a backlog on my hands :-(

Paul

[Bug jit/63854] Fix memory leaks seen in JIT

[cvs-commit at gcc dot gnu.org]

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

--- Comment #33 from CVS Commits  ---
The master branch has been updated by Alex Coplan :

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

commit r11-2799-gb46584d7836bee011facdf946fd7241c748d66f0
Author: Alex Coplan 
Date:   Fri Aug 21 14:26:11 2020 +0100

driver: Fix several memory leaks [PR63854]

This patch fixes several memory leaks in the driver, all of which relate
to the handling of static specs. We introduce functions
set_static_spec_{shared,owned}() which are used to enforce proper memory
management when updating the strings in the static_specs table.

This is achieved by making use of the alloc_p field in the table
entries. Similarly to set_spec(), each time we update an entry, we check
whether alloc_p is set, and free the old value if so. We then set
alloc_p correctly based on whether we "own" this memory or whether we're
just taking a pointer to a shared string which we shouldn't free.

The following table shows the number of leaks found by AddressSanitizer
when running a minimal libgccjit program on AArch64. The test program
does the whole libgccjit compilation cycle in a loop (including acquiring
and releasing the context), and the table below shows the number of leaks
for different iterations of that loop.

+--+-+-+--+---+
| # of runs >  | 1   | 2   | 3| Leaks per run |
+--+-+-+--+---+
| Before patch | 463 | 940 | 1417 | 477   |
+--+-+-+--+---+
| After patch  | 416 | 846 | 1276 | 430   |
+--+-+-+--+---+

gcc/ChangeLog:

PR jit/63854
* gcc.c (set_static_spec): New.
(set_static_spec_owned): New.
(set_static_spec_shared): New.
(driver::maybe_putenv_COLLECT_LTO_WRAPPER): Use
set_static_spec_owned() to take ownership of lto_wrapper_file
such that it gets freed in driver::finalize.
(driver::maybe_run_linker): Use set_static_spec_shared() to
ensure that we don't try and free() the static string "ld",
also ensuring that any previously-allocated string in
linker_name_spec is freed. Likewise with argv0.
(driver::finalize): Use set_static_spec_shared() when resetting
specs that previously had allocated strings; remove if(0)
around call to free().

[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass

[ariadne at dereferenced dot org]

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

--- Comment #1 from Ariadne Conill  ---
Manually compiling cp/method.o using:

g++ -c -o cp/method.o -O2 method.ii

works fine.

I wonder if this is somehow related to pre-compiled headers, actually.

[Bug ipa/96734] New: gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass

[ariadne at dereferenced dot org]

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

Bug ID: 96734
   Summary: gcc 10.2.0 fails to compile on mips64 due to crash in
IPA SRA pass
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ariadne at dereferenced dot org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When building gcc 10.2.0 using previous gcc 9.3.0 on a mips64 host, gcc 10.2.0
crashes while building stage3:

during IPA pass: sra
In file included from
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/cp/method.c:3199:
./gt-cp-method.h:36:2: internal compiler error: Segmentation fault
   36 | };
  |  ^
0x1208017a3 crash_signal
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/toplev.c:328
0x12041ef55 cgraph_edge::redirect_callee(cgraph_node*)
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/cgraph.c:1374
0x120431cd3 cgraph_edge::redirect_callee_duplicating_thunks(cgraph_node*)
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/cgraphclones.c:262
0x120432167 cgraph_node::create_clone(tree_node*, profile_count, bool,
vec, bool, cgraph_node*, ipa_param_adjustments*,
char const*)
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/cgraphclones.c:427
0x12043258b cgraph_node::create_virtual_clone(vec, vec*, ipa_param_adjustments*, char
const*, unsigned int)
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/cgraphclones.c:613
0x1205eba27 process_isra_node_results
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/ipa-sra.c:3811
0x1205eba27 ipa_sra_analysis
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/ipa-sra.c:4047
0x1205eba27 execute
/home/buildozer/aports/main/gcc/src/gcc-10.2.0/gcc/ipa-sra.c:4099
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Full log of building cp/method.o:
https://distfiles.dereferenced.org/method.log

method.ii:
https://distfiles.dereferenced.org/method.ii

Unfortunately I wouldn't know where to begin creating a reduced test case for
this.  Sorry.

I suspect the issue is because `caller` is null, which means
to->check_calls_comdat_local_p() does a null dereference when trying to fetch
the vtable.  But I could be wrong entirely.  :)

[Bug libstdc++/96718] 25_algorithms/pstl/feature_test-3.cc has excess error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
This should be fixed on master and gcc-10 now, please reopen if you still see
it (I didn't change one of the related tests, but I think that one shouldn't be
failing).

[Bug libstdc++/96718] 25_algorithms/pstl/feature_test-3.cc has excess error

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:098a67ff74cca5f17ed630d870adf364c47031f6

commit r10-8652-g098a67ff74cca5f17ed630d870adf364c47031f6
Author: Jonathan Wakely 
Date:   Fri Aug 21 12:01:05 2020 +0100

libstdc++: Skip PSTL tests when installed TBB is too old [PR 96718]

These tests do not actually require TBB, because they only inspect the
feature test macros present in the headers. However, if TBB is installed
then its headers will be included, and the version will be checked. If
the version is too old, compilation fails due to a #error directive.

This change disables the tests if TBB is not present, so that we skip
them instead of failing.

libstdc++-v3/ChangeLog:

PR libstdc++/96718
* testsuite/25_algorithms/pstl/feature_test-2.cc: Require
tbb-backend effective target.
* testsuite/25_algorithms/pstl/feature_test-3.cc: Likewise.
* testsuite/25_algorithms/pstl/feature_test-5.cc: Likewise.
* testsuite/25_algorithms/pstl/feature_test.cc: Likewise.

(cherry picked from commit 988fb2f597d67cdf3603654372c020c28448441f)

[Bug libstdc++/96718] 25_algorithms/pstl/feature_test-3.cc has excess error

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:988fb2f597d67cdf3603654372c020c28448441f

commit r11-2797-g988fb2f597d67cdf3603654372c020c28448441f
Author: Jonathan Wakely 
Date:   Fri Aug 21 12:01:05 2020 +0100

libstdc++: Skip PSTL tests when installed TBB is too old [PR 96718]

These tests do not actually require TBB, because they only inspect the
feature test macros present in the headers. However, if TBB is installed
then its headers will be included, and the version will be checked. If
the version is too old, compilation fails due to a #error directive.

This change disables the tests if TBB is not present, so that we skip
them instead of failing.

libstdc++-v3/ChangeLog:

PR libstdc++/96718
* testsuite/25_algorithms/pstl/feature_test-2.cc: Require
tbb-backend effective target.
* testsuite/25_algorithms/pstl/feature_test-3.cc: Likewise.
* testsuite/25_algorithms/pstl/feature_test-5.cc: Likewise.
* testsuite/25_algorithms/pstl/feature_test.cc: Likewise.

[Bug libstdc++/96718] 25_algorithms/pstl/feature_test-3.cc has excess error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug middle-end/96733] std::clamp for floats and doubles produces worse code than a combo of std::min / std::max

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Last reconfirmed||2020-08-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Without the library dependency:

namespace std
{
  template
constexpr const _Tp&
min(const _Tp& __a, const _Tp& __b)
{
  //return __b < __a ? __b : __a;
  if (__b < __a)
return __b;
  return __a;
}

  template
constexpr const _Tp&
max(const _Tp& __a, const _Tp& __b)
{
  //return  __a < __b ? __b : __a;
  if (__a < __b)
return __b;
  return __a;
}

  template
constexpr const _Tp&
clamp(const _Tp& __val, const _Tp& __lo, const _Tp& __hi)
{
  return (__val < __lo) ? __lo : (__hi < __val) ? __hi : __val;
}
}

// This version is good in gcc, not so on vc++
double clamp_minmax( double x, double i, double ax )
{
return std::min( std::max( x, i ), ax );
}

// This version should be identical but is not.
// gcc compiles to scalar comparisons
// vc++ code is outright horrible, compiles into RAM access.
double clamp_builtin( double x, double i, double ax )
{
return std::clamp( x, i, ax );
}

[Bug fortran/95352] ICE on select rank with assumed-size selector and lbound intrinsic

[jrfsousa at gmail dot com]

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

José Rui Faustino de Sousa  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from José Rui Faustino de Sousa  ---
Done!

https://gcc.gnu.org/pipermail/fortran/2020-August/054908.html

Thank you very much.

Best regards,
José Rui

[Bug c++/96733] New: std::clamp for floats and doubles produces worse code than a combo of std::min / std::max

[soonts at gmail dot com]

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

Bug ID: 96733
   Summary: std::clamp for floats and doubles produces worse code
than a combo of std::min / std::max
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: soonts at gmail dot com
  Target Milestone: ---

C++/17 introduced std::clamp in the standard library.

Very useful, but the code gcc generates for it is not optimal for doubles and
floats. Source code:

// This version is good in gcc, not so on vc++
double clamp_minmax( double x, double i, double ax )
{
return std::min( std::max( x, i ), ax );
}

// This version should be identical but is not.
// gcc compiles to scalar comparisons
// vc++ code is outright horrible, compiles into RAM access.
double clamp_builtin( double x, double i, double ax )
{
return std::clamp( x, i, ax );
} 

Demo there: https://godbolt.org/z/Gnvc1s

[Bug c++/95428] ABI breakage for "base object constructor" for final classes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #8 from Jonathan Wakely  ---
Let's reopen this then, as GCC needs to keep providing the alias for the base
object constructor.

[Bug testsuite/96718] 25_algorithms/pstl/feature_test-3.cc has excess error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|REOPENED|ASSIGNED

--- Comment #3 from Jonathan Wakely  ---
I forgot to add this to that test:

// { dg-require-effective-target tbb-backend }

[Bug libstdc++/96731] uniform_int_distribution requirement that its type is_integral is too strict

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Last reconfirmed||2020-08-21

--- Comment #2 from Jonathan Wakely  ---
Since it's undefined, we can do whatever we want, including causing compilation
to fail with a static_assert, or ignoring it (as libc++ seems to do), or using
another condition to check for sufficiently integer-like types (possibly only
in non-strict modes).

Confirming as an enhancement request.

[Bug libstdc++/96731] uniform_int_distribution requirement that its type is_integral is too strict

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Tony E Lewis from comment #0)
> I can't see any obvious mention of constraints on
> uniform_­int_­distribution's IntType in
> http://eel.is/c++draft/rand.dist.uni.int

See http://eel.is/c++draft/rand#req.genl-1.5

[Bug libgcc/67792] GCC 5.2 - make clean fails in libgcc

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Alex Kruppa from comment #4)
> Problem still exists in 10.2.0:

And everybody still just removes the build dir instead of using 'make clean'.

[Bug c++/96732] New: ice in pop_nested_class

[dcb314 at hotmail dot com]

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

Bug ID: 96732
   Summary: ice in pop_nested_class
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ source code:

template  struct a;
template  struct b;
template  class d {
  struct {
template  using f = typename e ::g;
template  f::i>::j, e> k();
  };
};

sometime between 20200818 and 20200819, it fails to compile:

/home/dcb/gcc/results.20200818/bin/gcc
/home/dcb/gcc/results.20200819/bin/gcc
bug637.cc: In substitution of ‘template template,
clas
s e> using f = typename e::g [with bool  = b::i>::j; e = e; c = c]’:
bug637.cc:6:66:   required from here
bug637.cc:6:66: internal compiler error: Segmentation fault
6 | template  f::i>::j, e> k();
  |  ^
0xf14119 crash_signal(int)
../../trunk.git/gcc/toplev.c:327
0x66009b tree_class_check(tree_node*, tree_code_class, char const*, int, char
co
nst*)
../../trunk.git/gcc/tree.h:3417
0x66009b pop_nested_class()
../../trunk.git/gcc/cp/class.c:8138
0x8633b2 instantiate_template_1(tree_node*, tree_node*, int)
../../trunk.git/gcc/cp/pt.c:20826

[Bug libgcc/67792] GCC 5.2 - make clean fails in libgcc

[akruppa at gmail dot com]

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

Alex Kruppa  changed:

   What|Removed |Added

 CC||akruppa at gmail dot com

--- Comment #4 from Alex Kruppa  ---
Problem still exists in 10.2.0:

true "AR_FLAGS=" "CC_FOR_BUILD=" "CC_FOR_TARGET=" "CFLAGS=" "CXXFLAGS="
"CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=" "INSTALL=/usr/bin/install -c"
"INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c"
"INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS="
"LIBCFLAGS_FOR_TARGET=" "MAKE=make" "MAKEINFO=makeinfo --split-size=500
--split-size=500 " "SHELL=/bin/sh" "RUNTESTFLAGS="
"exec_prefix=/opt/gcc-10.2.0" "infodir=/opt/gcc-10.2.0/share/info"
"libdir=/opt/gcc-10.2.0/lib64" "includedir=/opt/gcc-10.2.0/include"
"prefix=/opt/gcc-10.2.0" "tooldir="
"gxx_include_dir=/opt/gcc-10.2.0/include/c++/10.2.0" "AR=" "AS=/./gcc/as"
"LD=/./gcc/collect-ld" "RANLIB=" "NM=/./gcc/nm" "NM_FOR_BUILD="
"NM_FOR_TARGET=" "DESTDIR=" "WERROR=" DO=mostlyclean multi-clean # make
make[5]: Leaving directory
'/home/alex/build/gcc-10.2.0/x86_64-pc-linux-gnu/32/libstdc++-v3'
make[4]: Leaving directory
'/home/alex/build/gcc-10.2.0/x86_64-pc-linux-gnu/32/libstdc++-v3'
make[3]: Leaving directory
'/home/alex/build/gcc-10.2.0/x86_64-pc-linux-gnu/libstdc++-v3'
make[2]: Leaving directory
'/home/alex/build/gcc-10.2.0/x86_64-pc-linux-gnu/libstdc++-v3'
make[1]: Leaving directory
'/home/alex/build/gcc-10.2.0/x86_64-pc-linux-gnu/libstdc++-v3'
make[1]: Entering directory
'/home/alex/build/gcc-10.2.0/x86_64-pc-linux-gnu/libgcc'
make[1]: -B/opt/gcc-10.2.0/x86_64-pc-linux-gnu/bin/: Command not found
make[1]: -B/opt/gcc-10.2.0/x86_64-pc-linux-gnu/bin/: Command not found
/bin/sh: line 0: test: !=: unary operator expected
rm -f libgcc_tm.h libgcc.map
Makefile:187: *** Recursive variable 'AR_FOR_TARGET' references itself
(eventually).  Stop.
make[1]: Leaving directory
'/home/alex/build/gcc-10.2.0/x86_64-pc-linux-gnu/libgcc'
make: *** [Makefile:19194: clean-stage1-target-libgcc] Error 2

[Bug libstdc++/96731] New: uniform_int_distribution requirement that its type is_integral is too strict

[TonyELewis at hotmail dot com]

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

Bug ID: 96731
   Summary: uniform_int_distribution requirement that its type
is_integral is too strict
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TonyELewis at hotmail dot com
  Target Milestone: ---

Following on from https://github.com/ericniebler/range-v3/issues/1532 ...

I think the static_assert requirement in libstdc++'s uniform_int_distribution
code that its template argument type is_integral may be too strict.

I can't see any obvious mention of constraints on uniform_­int_­distribution's
IntType in http://eel.is/c++draft/rand.dist.uni.int

The motivating case is attempting to sample from a range-v3 view::indices. The
range-v3 clever tricks lead to uniform_int_distribution being invoked with a
range-v3 type.

This all works OK under libc++ because it doesn't impose any requirements on
the type. But the aforementioned static_assert in libstdc++ won't allow it.

The problem can be seen with the first error under GCC or Clang with -std=c++17
on this code:


#include 
#include 
#include 
#include 

#include 

void fill_vec_with_random_sample_of_first_n_ints( const size_t 
_num_possible_vals,
  std::vector
_result,
  std::mt19937_rng
  ) {
auto some_indices = ranges::views::indices( prm_num_possible_vals );
std::sample(
std::begin( some_indices ),
std::end  ( some_indices ),
std::begin( prm_result ),
static_cast( prm_result.size() ),
prm_rng
);
}


Compiler Explorer : https://godbolt.org/z/MxrazP


One option is that libstdc++ could use std::numeric_limits::is_integer
instead of std::is_integral, so that range-v3 could then specialise accordingly
for its type.

[Bug target/71453] Spills to vector registers are sub-optimal.

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #7 from Hongtao.liu  ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by hongtao Liu :
> 
> https://gcc.gnu.org/g:00cb3494cab397b5655ab42fd69310883c12137c
> 
> commit r11-2793-g00cb3494cab397b5655ab42fd69310883c12137c
> Author: H.J. Lu 
> Date:   Tue Sep 3 14:41:02 2019 -0700
> 
> x86: Add cost model for operation of mask registers.
> 
> gcc/
> 

Just clarify that the whole patch set enable spilling to mask registers and has
nothing to do with spill to vector registers.