[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

2020-06-17 Thread egorenar at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712

--- Comment #10 from Alexander Egorenkov  ---
When i add the dependency in Makefile manually, then the parallel build works.

Regards

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

2020-06-17 Thread egorenar at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712

--- Comment #9 from Alexander Egorenkov  ---
Created attachment 48751
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48751&action=edit
top gcc Makefile

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

2020-06-17 Thread egorenar at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712

--- Comment #8 from Alexander Egorenkov  ---

$ make --version
GNU Make 4.1
Built for s390x-ibm-linux-gnu

In my top Makefile the dependecny on maybe-all-gcc is missing:

configure-target-libgcc:
...

I attached the top Makefile.

[Bug c++/95725] Confusing error diagnostic in an invalid template

2020-06-17 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

--- Comment #7 from Haoxin Tu  ---
By the way, can you take a look at bug 95597 and bug 95659? I think GCC should
accept the first case and shouldn't miss the error message in the second code. 
Those cases are different from this report.

[Bug c++/95735] New: ICE on invalid non-type template argument

2020-06-17 Thread johelegp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95735

Bug ID: 95735
   Summary: ICE on invalid non-type template argument
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/v7iLPn.
```C++
template 
requires requires { F(); }
bool v{};

void f() {
int x;
static_assert(v);
}
```
: In function 'void f()':
:7:19: error: parse error in template argument list
7 | static_assert(v);
  |   ^~~~
:7:19: error: template argument 1 is invalid
:7: confused by earlier errors, bailing out
Compiler returned: 1

Less silly example: https://godbolt.org/z/-bWfJ4.
```C++
template 
requires requires { F(); }
bool v{};

void f() {
int x;
static_assert(v<[&] { x++; }>);
}
```
: In function 'void f()':
:7:19: error: 'f()::{x}' is not a
constant expression
7 | static_assert(v<[&] { x++; }>);
  |   ^~~
:7: confused by earlier errors, bailing out
Compiler returned: 1

[Bug target/95732] Use CPU dispatching to support mixing -fcf-protection with -mindirect-branch and -mfunction-return

2020-06-17 Thread josephcsible at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95732

--- Comment #1 from Joseph C. Sible  ---
Thinking about this a bit more, it's a win for performance even if we ignore
CET completely. In particular, it would let a single binary use retpolines only
on CPUs that have the Spectre vulnerabilities that they mitigate.

[Bug c++/86441] instantiate_class_template() unable to re-execute constexpr function

2020-06-17 Thread boris at kolpackov dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441

Boris Kolpackov  changed:

   What|Removed |Added

Version|8.1.0   |10.1.0

--- Comment #2 from Boris Kolpackov  ---
I am running into what I believe is the same issue with GCC 10.1.0 and a
static_assert in shared_ptr's default ctor. Here is the code:

#include 
struct object1
{
};
struct object2
{
  std::shared_ptr o1;
};

If a plugin calls locate_ctor() for object2, it ends up with the following
error:

In file included from /usr/local/gcc10/include/c++/10.1.0/bits/move.h:57,
 from /usr/local/gcc10/include/c++/10.1.0/bits/stl_pair.h:59,
 from
/usr/local/gcc10/include/c++/10.1.0/bits/stl_algobase.h:64,
 from
/usr/local/gcc10/include/c++/10.1.0/bits/char_traits.h:39,
 from /usr/local/gcc10/include/c++/10.1.0/string:40,
 from :7:
/usr/local/gcc10/include/c++/10.1.0/type_traits: In instantiation of ‘struct
std::is_default_constructible’:
/usr/local/gcc10/include/c++/10.1.0/type_traits:143:12:   required from ‘struct
std::__and_,
std::is_default_constructible,
std::__not_,
std::__is_implicitly_default_constructible > > >’
/usr/local/gcc10/include/c++/10.1.0/bits/stl_pair.h:244:59:   required by
substitution of ‘template,
std::is_default_constructible<_Dp>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
 > constexpr std::pair::pair() [with _U1 = int; _U2 = int;
typename std::enable_if,
std::is_default_constructible<_Dp>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
 = ]’
test3.hxx:47:31:   required from here
/usr/local/gcc10/include/c++/10.1.0/type_traits:918:52: error: non-constant
condition for static assertion
  918 |  
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
  |
~~~^~~~
/usr/local/gcc10/include/c++/10.1.0/type_traits:918: confused by earlier
errors, bailing out

The stack trace for the same invocation (obtained with -dH) is as follows:

#0  0x7f8843fc4428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f8843fc602a in __GI_abort () at abort.c:89
#2  0x0229fc95 in real_abort () at
../../gcc-10.1.0/gcc/diagnostic.c:1911
#3  0x0229baf3 in diagnostic_action_after_output (context=0x332c5e0
, diag_kind=DK_ERROR) at
../../gcc-10.1.0/gcc/diagnostic.c:564
#4  0x0229d1fb in diagnostic_report_diagnostic (context=0x332c5e0
, diagnostic=0x7ffd503c5f20) at
../../gcc-10.1.0/gcc/diagnostic.c:1179
#5  0x0229d7bb in diagnostic_impl (richloc=0x7ffd503c5fb0,
metadata=0x0, opt=-1, gmsgid=0x2390648 "non-constant condition for static
assertion", ap=0x7ffd503c5f98,
kind=DK_ERROR) at ../../gcc-10.1.0/gcc/diagnostic.c:1316
#6  0x0229ed0d in error (gmsgid=0x2390648 "non-constant condition for
static assertion") at ../../gcc-10.1.0/gcc/diagnostic.c:1612
#7  0x00b2445a in finish_static_assert (condition=0x7f883e0178c0,
message=0x7f8841d1cbb0, location=2147484459, member_p=true) at
../../gcc-10.1.0/gcc/cp/semantics.c:9699
#8  0x00ac5f33 in instantiate_class_template_1 (type=0x7f883e030348) at
../../gcc-10.1.0/gcc/cp/pt.c:11823
#9  0x00ac66e2 in instantiate_class_template (type=0x7f883e030348) at
../../gcc-10.1.0/gcc/cp/pt.c:12101
#10 0x00b46487 in complete_type (type=0x7f883e030348) at
../../gcc-10.1.0/gcc/cp/typeck.c:137
#11 0x00b04bf7 in lookup_member (xbasetype=0x0, name=0x7f8843a89040,
protect=2, want_type=false, complain=3, afi=0x0) at
../../gcc-10.1.0/gcc/cp/search.c:1129
#12 0x00a39487 in lookup_qualified_name (scope=0x7f883e030348,
name=0x7f8843a89040, prefer_type=0, complain=false, find_hidden=false)
at ../../gcc-10.1.0/gcc/cp/name-lookup.c:6023
#13 0x00ad18bf in tsubst_qualified_id (qualified_id=0x7f8841db2af0,
args=0x7f883e0177e0, complain=1, in_decl=0x0, done=true, address_p=false)
at ../../gcc-10.1.0/gcc/cp/pt.c:16158
#14 0x00adc40c in tsubst_copy_and_build (t=0x7f8841db2af0,
args=0x7f883e0177e0, complain=1, in_decl=0x0, function_p=false,
integral_constant_expression_p=true)
at ../../gcc-10.1.0/gcc/cp/pt.c:19449
#15 0x00ada2d1 in tsubst_expr (t=0x7f8841db2af0, args=0x7f883e0177e0,
complain=1, in_decl=0x0, integral_constant_expression_p=true) at
../../gcc-10.1.0/gcc/cp/pt.c:18738
#16 0x00ac678e in tsubst_template_arg (t=0x7f8841db2af0,
args=0x7f883e0177e0, complain=1, in_decl=0x0) at
../../gcc-10.1.0/gcc/cp/pt.c:12119
#17 0x00ac8e09 in tsubst_template_args (t=0x7f8841da56c0,
args=0x7f883e0177e0, complain=1, in_decl=0x0) at
../../gcc-10.1.0/gcc/cp/pt.c:13168
#18 0x00ac9672 in tsubst_aggr_type (t=0x7f8841db3e70,
args=0x7f883e0177e0, complain=1, in_decl=0x0, entering_scope=1) at
../../gc

[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

2020-06-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
  Component|libgcc  |bootstrap

--- Comment #7 from Andrew Pinski  ---
@if gcc-no-bootstrap

configure-target-libgcc: maybe-all-gcc
...
@endif gcc-no-bootstrap

What version of GNU make are you using?
Can you attach the toplevel Makefile?  I checked the version that is generated
for aarch64-linux-gnu that I configured for and it has:

# Generic dependencies for target modules on host stuff, especially gcc

configure-target-libgcc: maybe-all-gcc
...

[Bug bootstrap/95734] New: [11 regression] lots of ICEs after r11-1445

2020-06-17 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95734

Bug ID: 95734
   Summary: [11 regression] lots of ICEs after r11-1445
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:502d63b6d6141597bb18fd23c87736a1b384cf8f, r11-1445

This also appears to break bootstrap for powerpc64

> FAIL: gcc.dg/vmx/5-11.c   -O0  (internal compiler error)
> FAIL: gcc.dg/vmx/5-11.c   -O0  (test for excess errors)
> FAIL: gcc.dg/vmx/5-11.c   -O1  (internal compiler error)
> FAIL: gcc.dg/vmx/5-11.c   -O1  (test for excess errors)
> FAIL: gcc.dg/vmx/5-11.c   -O2  (internal compiler error)
> FAIL: gcc.dg/vmx/5-11.c   -O2  (test for excess errors)
> FAIL: gcc.dg/vmx/5-11.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (internal compiler error)
> FAIL: gcc.dg/vmx/5-11.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: gcc.dg/vmx/5-11.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  
> (internal compiler error)
> FAIL: gcc.dg/vmx/5-11.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  
> (test for excess errors)
> FAIL: gcc.dg/vmx/5-11.c   -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/5-11.c   -O3 -g  (test for excess errors)
> FAIL: gcc.dg/vmx/5-11.c   -Os  (internal compiler error)
> FAIL: gcc.dg/vmx/5-11.c   -Os  (test for excess errors)
> FAIL: gcc.dg/vmx/debug-4.c   -O0  (internal compiler error)
> FAIL: gcc.dg/vmx/debug-4.c   -O0  (test for excess errors)
> FAIL: gcc.dg/vmx/debug-4.c   -O1  (internal compiler error)
> FAIL: gcc.dg/vmx/debug-4.c   -O1  (test for excess errors)
> FAIL: gcc.dg/vmx/debug-4.c   -O2  (internal compiler error)
> FAIL: gcc.dg/vmx/debug-4.c   -O2  (test for excess errors)
> FAIL: gcc.dg/vmx/debug-4.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (internal compiler error)
> FAIL: gcc.dg/vmx/debug-4.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: gcc.dg/vmx/debug-4.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (internal compiler error)
> FAIL: gcc.dg/vmx/debug-4.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.dg/vmx/debug-4.c   -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/debug-4.c   -O3 -g  (test for excess errors)
> FAIL: gcc.dg/vmx/debug-4.c   -Os  (internal compiler error)
> FAIL: gcc.dg/vmx/debug-4.c   -Os  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O0  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O0  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O1  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O1  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -O3 -g  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -Os  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-f.c   -Os  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O0  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O0  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O1  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O1  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O3 -g  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -O3 -g  (test for excess errors)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -Os  (internal compiler error)
> FAIL: gcc.dg/vmx/gcc-bug-g.c   -Os  (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c   -O0  (internal compiler error)
> FAIL: gcc.dg/vmx/ops.c   -O0  (test for excess errors)
> FAIL: gcc.dg/vmx/ops.c   -O1  (internal

[Bug c++/95725] Confusing error diagnostic in an invalid template

2020-06-17 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

--- Comment #6 from Haoxin Tu  ---
Hi, there.

I hold the view that the compiler should have good fault tolerance, which means
giving an input(even invalid), the compiler might emit appropriate error
message diagnostics so that we can fix them into valid code according to the
diagnostics. 

I have tested in both GCC and Clang, the results show that GCC has lots of
unrelated diagnostic messages than Clang. 

In this report, GCC-trunk seems ok, but GCC-9 emits too many duplicated error
messages. So I guess there might something not correct in FE.

Finally, I am wondering if those cases are useful for the GCC community? If
not, I will stop reporting similar test cases (invalid code but let GCC get
confused while parsing it).

Thank you all!

[Bug regression/95733] New: Building on PowerPC 64 Tests Fail With GCC 11

2020-06-17 Thread xerofoify at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95733

Bug ID: 95733
   Summary: Building on PowerPC 64 Tests Fail With GCC 11
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xerofoify at gmail dot com
  Target Milestone: ---

After building gcc as such:
../gcc/configure --enable-lanuages=c,c++ --enable-threads -disable-multilibs
--enable-checking=yes --prefix=/home/xerofoify/obdjir

it fails on running tests with make -k check with:
=== libgomp Summary ===

# of expected passes7764
# of expected failures  4
# of unsupported tests  573
make[4]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp/testsuite'
make[3]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp/testsuite'
make[3]: Entering directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
:
:
:
make  DO=all multi-do # make
make[4]: Entering directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
if [ -z "" ]; then \
  true; \
else \
  rootpre=`${PWDCMD-pwd}`/; export rootpre; \
  srcrootpre=`cd ../../../gcc/libgomp; ${PWDCMD-pwd}`/; export srcrootpre; \
  lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
  compiler="/home/xerofoify/obdjir/./gcc/xgcc -B/home/xerofoify/obdjir/./gcc/
-B/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/bin/
-B/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/include -isystem
/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/sys-include   "; \
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
  true; \
else \
  if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make  \
CFLAGS="-g -O2 ${flags}" \
CCASFLAGS=" ${flags}" \
FCFLAGS="-L. -Wall -L../libgfortran  ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/home/xerofoify/obdjir" \
exec_prefix="/home/xerofoify/obdjir" \
GOCFLAGS="-O2 -g ${flags}" \
GDCFLAGS="-O2 -g ${flags}" \
CXXFLAGS="-g -O2 -D_GNU_SOURCE ${flags}" \
LIBCFLAGS="-g -O2 ${flags}" \
LIBCXXFLAGS="-g -O2 -D_GNU_SOURCE
-fno-implicit-templates ${flags}" \
LDFLAGS=" ${flags}" \
MULTIFLAGS="${flags}" \
DESTDIR="" \
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" \
all); then \
  true; \
else \
  exit 1; \
fi; \
  else true; \
  fi; \
fi; \
  done; \
fi
make[4]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[3]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[2]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[1]: Leaving directory `/home/xerofoify/obdjir'
make: *** [do-check] Error 2
make: Target `check' not remade because of errors.
[xerofoify@gcc2-power8 obdjir]$ cd bin
[xerofoify@gcc2-power8 bin]$ ./g++ -v
Using built-in specs.
COLLECT_GCC=./g++
COLLECT_LTO_WRAPPER=/home/xerofoify/obdjir/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc/configure --enable-lanuages=c,c++ --enable-threads
-disable-multilibs --enable-checking=yes --prefix=/home/xerofoify/obdjir
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200613 (experimental) (GCC) 

OpenMP should be enabled by default with C++ and therefore this seems to be a
regression.

[Bug tree-optimization/94969] [8/10 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

2020-06-17 Thread amker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

--- Comment #16 from bin cheng  ---
(In reply to Richard Biener from comment #15)
> I don't see the commit on the GCC 10 branch nor the GCC 8 branch.  Master
> and GCC 9 are fixed though.

Will backport the 10 and 8, thanks for reminding.

[Bug target/95732] New: Use CPU dispatching to support mixing -fcf-protection with -mindirect-branch and -mfunction-return

2020-06-17 Thread josephcsible at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95732

Bug ID: 95732
   Summary: Use CPU dispatching to support mixing -fcf-protection
with -mindirect-branch and -mfunction-return
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josephcsible at gmail dot com
  Target Milestone: ---
Target: x86_64

The thunks generated by -mindirect-branch and -mfunction-return should do CPU
dispatching à la "ifunc". We should generate one path for CPUs with CET and one
without. The path without CET should stay like it is today. Intel claims that
their CPUs that support CET no longer need Spectre mitigations. For as long as
this remains true, the path with CET should just be "jmp *%rax" and "ret". If
this ends up turning out to be false, then we should instead use the "incsspq",
"rdsspq", and "wrssq" instructions to make the shadow stack match what we do in
the real stack. (We can't just do this unconditionally, since unlike "endbr64",
those instructions aren't all NOPs on older CPUs.) This change will allow the
same binary to run safely on Spectre-vulnerable CPUs and still get the benefits
of CET on new CPUs, without needing programs to all supply their own external
thunks.

[Bug c++/95725] Confusing error diagnostic in an invalid template

2020-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

--- Comment #5 from Jonathan Wakely  ---
Garbage in, garbage out.

[Bug c++/95725] Confusing error diagnostic in an invalid template

2020-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
(In reply to Martin Sebor from comment #3)
> The diagnostic is usually for false positive/negative warnings or wrong
> information in diagnostic messages.  It's not normally used for internal
> compiler errors.  But I don't see an ICE on trunk with this test case, just
> errors (so diagnostic would seem appropriate).  At the same time, the latest
> GCC output seems reasonable.  Clang prints something similar:
> 
> pr95725.C:1:20: error: expected expression
> template ^
> pr95725.C:1:22: error: expected expression
> template   ^
> pr95725.C:1:22: error: expected ',' or '>' in template-parameter-list
> pr95725.C:1:22: warning: declaration does not declare anything
>   [-Wmissing-declarations]
> 1 warning and 3 errors generated.
> 
> I'm not sure there's a lot to improve here.

Agreed.  As I said in bug 95723, I'm on the verge of closing these reports as
WONFIX or INVALID or something similar.

[Bug c++/95723] GCC get confused while parsing a code

2020-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
This code is so hopelessly broken that I'm not sure how we could generate
better diagnostics.  clang doesn't issue anything better.  I'm tempted to
WONTFIX this.

[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper

2020-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711

Marek Polacek  changed:

   What|Removed |Added

Summary|ICE: [[no_unique_address]   |[9/10/11 Regression] ICE:
   |when constructing via   |[[no_unique_address] when
   |template helper |constructing via template
   ||helper
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-06-17
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |9.4
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Same backtrace as bug 90254 but it didn't start with the same revision.  This
one started with r264813.

[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594

2020-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
...which also generates a better diagnostic than gcc 10 & older.

[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594

2020-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |11.0

--- Comment #1 from Marek Polacek  ---
Since the introduction of tsubst_tree_list we now return a naked
error_mark_node rather than an error_mark_node wrapped in a TREE_LIST.  So
tsubst_copy_and_build/NEW_EXPR ICEs:

19654 tree placement = RECUR (TREE_OPERAND (t, 0)); // now a naked
error_mark_node
...
19668 for (; placement != NULL_TREE; placement = TREE_CHAIN
(placement)) // crash

A simple

--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19633,6 +19660,8 @@ tsubst_copy_and_build (tree t,

if (placement == NULL_TREE)
  placement_vec = NULL;
+   else if (placement == error_mark_node)
+ RETURN (error_mark_node);
else
  {
placement_vec = make_tree_vector ();

should fix this.

[Bug lto/94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures

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

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

https://gcc.gnu.org/g:61c896d84bdefbfffa7573a8af89119d4db7b3de

commit r10-8319-g61c896d84bdefbfffa7573a8af89119d4db7b3de
Author: Thomas Schwinge 
Date:   Tue Jan 7 17:40:14 2020 +0100

Add 'dg-do run' to 'libgomp.fortran/use_device_ptr-optional-3.f90'
[PR94848]

Fix-up for r279858/commit f760c0c77fe350616da9dbeaea16442b0acfb09c
"Fortran]
OpenMP/OpenACC â fix more issues with OPTIONAL".

With offloading enabled, we then saw:

PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O0  (test for
excess errors)
PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O0  execution
test
PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O1  (test for
excess errors)
PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O1  execution
test
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -O2  (test for
excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -O2 
compilation failed to produce executable
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
compilation failed to produce executable
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -O3 -g  (test for
excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -O3 -g 
compilation failed to produce executable
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -Os  (test for
excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -Os 
compilation failed to produce executable

 ... due to:

/tmp/cciVc43I.o:(.gnu.offload_vars+0x10): undefined reference to
`A.12.4064'
[...]

..., but after the recent PR94848, PR95551 changes, that problem is now
gone.

libgomp/
PR lto/94848
* testsuite/libgomp.fortran/use_device_ptr-optional-3.f90: Add
'dg-do run'.

(cherry picked from commit 5864930754f63e2dcef9606f2514ae20e80f436e)

[Bug lto/94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:5864930754f63e2dcef9606f2514ae20e80f436e

commit r11-1466-g5864930754f63e2dcef9606f2514ae20e80f436e
Author: Thomas Schwinge 
Date:   Tue Jan 7 17:40:14 2020 +0100

Add 'dg-do run' to 'libgomp.fortran/use_device_ptr-optional-3.f90'
[PR94848]

Fix-up for r279858/commit f760c0c77fe350616da9dbeaea16442b0acfb09c
"Fortran]
OpenMP/OpenACC â fix more issues with OPTIONAL".

With offloading enabled, we then saw:

PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O0  (test for
excess errors)
PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O0  execution
test
PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O1  (test for
excess errors)
PASS: libgomp.fortran/use_device_ptr-optional-3.f90   -O1  execution
test
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -O2  (test for
excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -O2 
compilation failed to produce executable
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
(test for excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
compilation failed to produce executable
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -O3 -g  (test for
excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -O3 -g 
compilation failed to produce executable
FAIL: libgomp.fortran/use_device_ptr-optional-3.f90   -Os  (test for
excess errors)
UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90   -Os 
compilation failed to produce executable

 ... due to:

/tmp/cciVc43I.o:(.gnu.offload_vars+0x10): undefined reference to
`A.12.4064'
[...]

..., but after the recent PR94848, PR95551 changes, that problem is now
gone.

libgomp/
PR lto/94848
* testsuite/libgomp.fortran/use_device_ptr-optional-3.f90: Add
'dg-do run'.

[Bug tree-optimization/95729] Failure to optimize away certain returns when the condition to reach them is a calculation that already results in that value

2020-06-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95729

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/95731] New: Faiilure to optimize a >= 0 && b >= 0 to (a | b) >= 0

2020-06-17 Thread gabravier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95731

Bug ID: 95731
   Summary: Faiilure to optimize a >= 0 && b >= 0 to (a | b) >= 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 a, int b)
{
return a >= 0 && b >= 0;
}

This can be optimized to `return (a | b) >= 0;`. LLVM does this transformation,
but GCC does not.

[Bug libstdc++/94540] stack overflow populating std::vector

2020-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94540

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed in master.

[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"

2020-06-17 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-06-17
 Status|UNCONFIRMED |NEW

--- Comment #2 from Eric Botcazou  ---
The error_mark_node very likely comes from:

DEF_PRIMITIVE_TYPE (BT_UINT128, uint128_type_node
? uint128_type_node
: error_mark_node)

but this is a standard idiom in builtin-types.def so rather strange indeed.

I gather that targetm.scalar_mode_supported_p (TImode) returns false for GCN?

[Bug libstdc++/94540] stack overflow populating std::vector

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

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

https://gcc.gnu.org/g:632183ddcc8f3aead8b4fc63c4ab59a42ef9ad00

commit r11-1464-g632183ddcc8f3aead8b4fc63c4ab59a42ef9ad00
Author: Jonathan Wakely 
Date:   Wed Jun 17 22:49:06 2020 +0100

libstdc++: Avoid stack overflow in std::vector (PR 94540)

The std::__uninitialized_default_n algorithm used by std::vector creates
an initial object as a local variable then copies that into the
destination range. If the object is too large for the stack this
crashes. We should create the first object directly into the
destination and then copy it from there.

This doesn't fix the bug for C++98, because in that case the initial
value is created as a default argument of the vector constructor i.e. in
the user's code, not inside libstdc++. We can't prevent that.

PR libstdc++/94540
* include/bits/stl_uninitialized.h
(__uninitialized_default_1):
Construct the first value at *__first instead of on the stack.
(__uninitialized_default_n_1): Likewise.
Improve comments on several of the non-standard algorithms.
*
testsuite/20_util/specialized_algorithms/uninitialized_default/94540.cc:
New test.
*
testsuite/20_util/specialized_algorithms/uninitialized_default_n/94540.cc:
New test.
*
testsuite/20_util/specialized_algorithms/uninitialized_value_construct/94540.cc:
New test.
*
testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/94540.cc:
New test.
* testsuite/23_containers/vector/cons/94540.cc: New test.

[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"

2020-06-17 Thread ams at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730

--- Comment #1 from Andrew Stubbs  ---
GCN uses TImode for a few special purposes, but lacks real TImode support.

(Basically, it allows TImode loads and stores for the SLP fake vectorization,
and there's one instruction that needs two DImode values in consecutive
registers.)

Probably this is a GCN-specific issue, and we should be finding another way to
handle the quasi-128-bit values.

[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848

2020-06-17 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95710

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Tested against z1.f90.  Untested otherwise.  I don't use CLASSes.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -8798,6 +8798,9 @@ resolve_select (gfc_code *code, bool select_type)
 bool
 gfc_type_is_extensible (gfc_symbol *sym)
 {
+  if (!sym)
+return false;
+
   return !(sym->attr.is_bind_c || sym->attr.sequence
   || (sym->attr.is_class
   && sym->components->ts.u.derived->attr.unlimited_polymorphic));
@@ -12595,9 +12599,13 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
  && !UNLIMITED_POLY (sym)
  && !gfc_type_is_extensible (CLASS_DATA (sym)->ts.u.derived))
{
- gfc_error ("Type %qs of CLASS variable %qs at %L is not extensible",
-CLASS_DATA (sym)->ts.u.derived->name, sym->name,
-&sym->declared_at);
+ if (CLASS_DATA (sym)->ts.u.derived)
+   gfc_error ("Type %qs of CLASS variable %qs at %L is not
extensible",
+CLASS_DATA (sym)->ts.u.derived->name,
+   sym->name, &sym->declared_at);
+ else
+   gfc_error ("CLASS variable %qs at %L is not extensible",
+   sym->name, &sym->declared_at);
  return false;
}

[Bug c++/95727] Add [[gnu::poison]] attribute

2020-06-17 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95727

--- Comment #1 from Andrew Pinski  ---
pragma poison actually does one step further, it poisons it during the
preprocessing stage.  What you are proposing is slightly different.

It is more deprecated attribute but slightly different.

[Bug target/95730] New: GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"

2020-06-17 Thread tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730

Bug ID: 95730
   Summary: GCN offloading ICEs after commit
fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support
for __builtin_bswap128"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: target
  Assignee: ams at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
Target: gcn

For a few libgomp test cases, the recent commit
fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"
is causing ICE regressions with GCN offloading (only, apparently: not seen for
Intel MIC (emulated), or nvptx offloading):

'libgomp.fortran/pr90779.f90':

lto1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in lto_input_tree_1, at lto-streamer-in.c:1561

#0  internal_error (gmsgid=0x163f958 "tree check: expected class %qs, have
%qs (%s) in %s, at %s:%d") at [...]/source-gcc/gcc/diagnostic.c:1706
#1  0x0055f2fd in tree_class_check_failed (node=0x767b4960,
cl=, file=, line=,
function=) at [...]/source-gcc/gcc/tree.c:9738
#2  0x009d7886 in tree_class_check (__g=, __l=1561,
__f=0x15d1208 "[...]/source-gcc/gcc/lto-streamer-in.c", __class=tcc_type,
__t=0x767b4960) at [...]/source-gcc/gcc/tree.h:3424
#3  lto_input_tree_1 (ib=0x7fffd080, data_in=0x1dd4860, tag=, hash=) at [...]/source-gcc/gcc/lto-streamer-in.c:1561
#4  0x005d84b6 in lto_read_decls (resolutions=..., data=0x1e3a630,
decl_data=0x77fee090) at [...]/source-gcc/gcc/lto/lto-common.c:1955
#5  lto_file_finalize (file=0x1d8c900, order=0, file_data=0x77fee090)
at [...]/source-gcc/gcc/lto/lto-common.c:2267
#6  lto_create_files_from_ids (order=0, count=,
file_data=0x77fee090, file=0x1d8c900) at
[...]/source-gcc/gcc/lto/lto-common.c:2277
#7  lto_file_read (count=, resolution_file=, file=) at [...]/source-gcc/gcc/lto/lto-common.c:2332
#8  read_cgraph_and_symbols (nfiles=, fnames=) at [...]/source-gcc/gcc/lto/lto-common.c:2784
#9  0x005b9c23 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:625
#10 0x00b7f6ff in compile_file () at
[...]/source-gcc/gcc/toplev.c:458
#11 0x0059302c in do_compile () at
[...]/source-gcc/gcc/toplev.c:2307
#12 toplev::main (this=this@entry=0x7fffd240, argc=argc@entry=19,
argv=0x1d766e0, argv@entry=0x7fffd348) at
[...]/source-gcc/gcc/toplev.c:2446
#13 0x00595ac7 in main (argc=19, argv=0x7fffd348) at
[...]/source-gcc/gcc/main.c:39
(gdb) frame 3
#3  lto_input_tree_1 (ib=0x7fffd080, data_in=0x1dd4860, tag=, hash=) at [...]/source-gcc/gcc/lto-streamer-in.c:1561
1561  gcc_assert (TYPE_PRECISION (type) <=
MAX_BITSIZE_MODE_ANY_INT);
(gdb) print type
$1 = (tree) 0x767b4960
(gdb) call debug_tree(type)
 

'libgomp.oacc-c-c++-common/firstprivate-mappings-1.c':

lto1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in lto_fixup_prevailing_type, at
lto/lto-common.c:993

#0  internal_error (gmsgid=0x163f958 "tree check: expected class %qs, have
%qs (%s) in %s, at %s:%d") at [...]/source-gcc/gcc/diagnostic.c:1706
#1  0x0055f2fd in tree_class_check_failed (node=0x767b4960,
cl=, file=, line=,
function=) at [...]/source-gcc/gcc/tree.c:9738
#2  0x005d7724 in tree_class_check (__g=, __l=993,
__f=0x1559cc8 "[...]/source-gcc/gcc/lto/lto-common.c", __class=tcc_type,
__t=) at [...]/source-gcc/gcc/tree.h:3424
#3  lto_fixup_prevailing_type (t=0x76883b28) at
[...]/source-gcc/gcc/lto/lto-common.c:993
#4  process_new_tree (t=t@entry=0x76883b28, hm=hm@entry=0x7fffd0b0,
index=index@entry=467, total=total@entry=0x7fffd048,
data_in=data_in@entry=0x1e37560) at [...]/source-gcc/gcc/lto/lto-common.c:1817
#5  0x005d8e24 in lto_read_decls (resolutions=..., data=0x1e44f50,
decl_data=0x77fee090) at [...]/source-gcc/gcc/lto/lto-common.c:1938
#6  lto_file_finalize (file=0x1d8bc30, order=0, file_data=0x77fee090)
at [...]/source-gcc/gcc/lto/lto-common.c:2267
#7  lto_create_files_from_ids (order=0, count=,
file_data=0x77fee090, file=0x1d8bc30) at
[...]/source-gcc/gcc/lto/lto-common.c:2277
#8  lto_file_read (count=, resolution_file=, file=) at [...]/source-gcc/gcc/lto/lto-common.c:2332
#9  read_cgraph_and_symbols (nfiles=, fnames=) at [...]/source-gcc/gcc/lto/lto-common.c:2784
#10 0x005b9c23 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:625
#11 0x00b7f6ff in compile_file () at
[...]/source-gcc/gcc/toplev.c:458
#12 0x0059302c in do_compile () at
[...]/source-gcc/gcc/toplev.c:2307
#13 toplev::m

[Bug tree-optimization/95729] New: Failure to optimize away certain returns when the condition to reach them is a calculation that already results in that value

2020-06-17 Thread gabravier at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95729

Bug ID: 95729
   Summary: Failure to optimize away certain returns when the
condition to reach them is a calculation that already
results in that value
   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 a, int b)
{
if (a != b)
return a - b;
else
return 0;
}

This can be optimized to `return a - b;`. This optimization is done by LLVM,
but not by GCC.

[Bug middle-end/86349] diagnose string overflow for allocations of non-constant sizes

2020-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86349

Martin Sebor  changed:

   What|Removed |Added

 Blocks||88443
  Known to fail||7.3.0, 8.2.0, 9.2.0
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
  Known to work||10.1.0
  Component|tree-optimization   |middle-end
   Target Milestone|--- |10.0
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
Done in GCC 10:

$ gcc -O2 -S -Wall -Wextra pr86349.c
pr86349.c: In function ‘f’:
pr86349.c:5:3: warning: ‘__builtin_strcpy’ writing one too many bytes into a
region of a size that depends on ‘strlen’ [-Wstringop-overflow=]
5 |   __builtin_strcpy (p, s);
  |   ^~~
pr86349.c:4:13: note: at offset 0 to an object allocated by ‘__builtin_malloc’
here
4 |   char *p = __builtin_malloc (n);
  | ^~~~


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

2020-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 86349, which changed state.

Bug 86349 Summary: diagnose string overflow for allocations of non-constant 
sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86349

   What|Removed |Added

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

[Bug libgcc/95712] configure-target-libgcc fails on s390x target because xgcc is not being built

2020-06-17 Thread egorenar at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712

Alexander Egorenkov  changed:

   What|Removed |Added

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

--- Comment #6 from Alexander Egorenkov  ---
Ok, i understand, therefore, i reproduced the problem without buildroot.

My steps:

$ mkdir compiler
$ cd compiler

$ tar xvjf gmp-6.1.0.tar.bz2
$ cd gmp-6.1.0
$ ./configure --prefix=$HOME/compiler/install --disable-shared
$ make -j81
$ make install
$ cd ..

$ tar xvjf mpfr-3.1.4.tar.bz2
$ cd mpfr-3.1.4
$ ./configure --prefix=$HOME/compiler/install --disable-shared
--with-gmp=$HOME/compiler/install
$ make -j81
$ make install
$ cd ..

$ tar xvzf mpc-1.0.3.tar.gz
$ cd mpc-1.0.3
$ ./configure --prefix=$HOME/compiler/install --disable-shared
--with-gmp=$HOME/compiler/install --with-mpfr=$HOME/compiler/install
$ make -j81
$ make install
$ cd ..


$ tar xvzf gcc-9.3.0.tar.xz
$ mkdir build-gcc
$ cd build-gcc
$ ../gcc-9.3.0/configure --prefix=$HOME/compiler/install --enable-shared
--disable-static \
 --disable-gtk-doc --disable-gtk-doc-html --disable-doc
--disable-docs \
 --disable-documentation --disable-debug
--with-xmlto=no --with-fop=no \
 --disable-nls --disable-dependency-tracking 
--target=s390x-buildroot-linux-gnu  \
 --enable-__cxa_atexit --with-gnu-ld --disable-libssp
--disable-multilib \
 --disable-decimal-float
--with-gmp=$HOME/compiler/install \
 --with-mpc=$HOME/compiler/install
--with-mpfr=$HOME/compiler/install \
 --with-pkgversion="Buildroot 2020.08-git-g2d8407f8ab"
\
 --with-bugurl="http://bugs.buildroot.net/";
--disable-libquadmath --enable-tls \
 --enable-threads --without-isl --without-cloog
--with-arch="z196" \
 --with-long-double-128 --enable-languages=c
--disable-shared --without-headers \
 --disable-threads --with-newlib --disable-largefile

$ make -j81 gcc_cv_libc_provides_ssp=yes all-gcc all-target-libgcc


The above steps were executed manually w/o any buildroot infrastructure. 
And i get the same problem, almost the same commands are executed by buildroot.

Again, xgcc is not being built and libgcc fails. I patched nothing, everything
was vanilla.

What i did notice, is that everything seems to work fine and the make commands
succeeds, if i drop "-j81" in the last step.
I did all these steps on a s390x machine with 80 cores, it is a highly parallel
machine.
So the issue seems to depend on it somehow, my guess is that maybe some
dependencies are not correctly
done in libgcc Makefile ? Another workaround i found is to split the last maske
command into 2 like this:
$ make -j81 all-gcc
$ make -j81 all-target-libgcc
This seems to fix it also.

I'm ready to do more test if required. I really want to fix it, it is very
annoying and blocking me.

Regards

[Bug fortran/95088] ICE in gfc_build_class_symbol, at fortran/class.c:653

2020-06-17 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95088

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch.

Backporting further would require backports of other work, so not done.

Thanks for the report!

[Bug fortran/95088] ICE in gfc_build_class_symbol, at fortran/class.c:653

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

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

https://gcc.gnu.org/g:55838f7fbd6e0131c2cc38e0eb903551c7fd2401

commit r10-8316-g55838f7fbd6e0131c2cc38e0eb903551c7fd2401
Author: Harald Anlauf 
Date:   Sun Jun 14 16:12:47 2020 +0200

PR fortran/95088 - Buffer overflows with PDTs, submodules and long symbols

With PDTs (parameterized derived types) and submodules, name mangling
results in variably long internal symbols.  Instead of using a fixed-size
intermediate buffer, which is actually not really needed, just use a
pointer to strings.

2020-06-14  Harald Anlauf  

gcc/fortran/
PR fortran/95088
* class.c (get_unique_type_string): Replace use of fixed size
buffer by internally passing a pointer to strings.

(cherry picked from commit 3ee9d82484bdc0ae5b1b21f4a3d8ff46d40e36fd)

[Bug c++/95728] New: [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594

2020-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728

Bug ID: 95728
   Summary: [11 Regression] tree check: expected tree_list, have
error_mark in tsubst_copy_and_build, at cp/pt.c:19594
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

The code below is invalid (attempting to cast const T* to void*) but dies with
an ICE since r11-423:

PR c++/93286 - ICE with __is_constructible and variadic template.

My GCC 10 patch for 93286 fixed the missing piece in tsubst's handling of
lists vs. that in tsubst_copy_and_build, but it would be better to share
the
code between them.

template
  void
  construct(T* p)
  { ::new(static_cast(p)) T; }

template
void
f(const T* t)
{
  construct(t);
}

int main()
{
  int i[1];
  f(i);
}


ice.cc: In instantiation of 'void construct(T*) [with T = const int]':
ice.cc:10:12:   required from 'void f(const T*) [with T = int]'
ice.cc:16:6:   required from here
ice.cc:4:11: error: invalid 'static_cast' from type 'const int*' to type
'void*'
4 |   { ::new(static_cast(p)) T; }
  |   ^
ice.cc:4:5: internal compiler error: tree check: expected tree_list, have
error_mark in tsubst_copy_and_build, at cp/pt.c:19640
4 |   { ::new(static_cast(p)) T; }
  | ^~
0x81ac46 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/jwakely/src/gcc/gcc/gcc/tree.c:9685
0x67d317 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3301
0x67d317 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:19640
0xa91287 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:18772
0xa93ab7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:17879
0xa92db1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:18173
0xa90ba1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:17834
0xa90ba1 instantiate_decl(tree_node*, bool, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:25653
0xac281b instantiate_pending_templates(int)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:25769
0x9cb4e0 c_parse_final_cleanups()
/home/jwakely/src/gcc/gcc/gcc/cp/decl2.c:4899
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594

2020-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/95727] New: Add [[gnu::poison]] attribute

2020-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95727

Bug ID: 95727
   Summary: Add [[gnu::poison]] attribute
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

GCC supports a pragma for poisoning a variable, but it doesn't respect scope.
It seems useful to be able to poison a variable for the remainder of a scope
(maybe because it's been moved and any further use would be an error), or it's
a pointer that has been invalidated by delete).

This seems to be a good fit for an attribute, because in a program which
doesn't use the variable again after that point it would make no difference
whether the compiler supports the attribute or ignores it.

void f(int*);

void g()
{
  int* p = new int();
  f(p);
  [[poison]] p;
  {
void* p; // ok, not the same p
  }
  int i = *p;  // error, variable was poisoned
}

It would need to be OK for an implicit destructor to run for poisoned
variables, it should only affect explicit uses of the name in the user code.

I'm not sure if it makes sense to allow poisoning non-local variables in a
given scope ... it could do. Limiting it to local variables (including function
parameters) seems reasonable initially.

A related idea is to mark a variable as read-only from a certain point, so that
it can't be written to, can't have non-const member functions called on it, and
can't have non-const references bound to it.

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

2020-06-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726

--- Comment #3 from Jakub Jelinek  ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> They mangle differently, and e.g.:
> 
> void f(float32x4_t);
> void f(V);
> 
> aren't ODR equivalent.  But a lot of code relies on the GNU vector
> extensions being available for float32x4_t as well as V, and on V
> and float32x4_t being mutually and implicitly interconvertible.

But if they mangle differently, then structural_comptypes shouldn't treat them
as same types.

[Bug fortran/95687] ICE in get_unique_hashed_string, at fortran/class.c:508

2020-06-17 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687

--- Comment #4 from anlauf at gcc dot gnu.org ---
Updated / corrected patch posted for review:

https://gcc.gnu.org/pipermail/fortran/2020-June/054548.html

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

2020-06-17 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
(In reply to Jason Merrill from comment #1)
> Does the aarch64 port expect __Float32x4_t type to be considered equivalent
> to the GNU vector type or not?  If so, why use build_distinct_type_copy over
> build_variant_type_copy?  If not, they might want to set TYPE_INDIVISIBLE_P
> so that structural_comptypes treats them as different.
They mangle differently, and e.g.:

void f(float32x4_t);
void f(V);

aren't ODR equivalent.  But a lot of code relies on the GNU vector
extensions being available for float32x4_t as well as V, and on V
and float32x4_t being mutually and implicitly interconvertible.

[Bug fortran/95707] ICE in finish_equivalences, at fortran/trans-common.c:1319

2020-06-17 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95707

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch posted for review:

https://gcc.gnu.org/pipermail/fortran/2020-June/054549.html

[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier

2020-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed on master.

[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier

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

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

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

commit r11-1459-gd392babbeb6cb531ab8b1ec68fde9ffd36373a6e
Author: Jonathan Wakely 
Date:   Wed Jun 17 20:26:13 2020 +0100

c++: Fix bogus "does not declare anything" warning (PR 66159)

G++ gives a bogus warning for 'struct A; using B = struct ::A;'
complaining that the elaborated-type-specifier doesn't declare anything.
That's true, but it's not trying to declare struct ::A, just refer to it
unambiguously. Do not emit the warning unless we're actually parsing a
declaration.

gcc/cp/ChangeLog:

PR c++/66159
* parser.c (cp_parser_elaborated_type_specifier): Do not warn
unless in a declaration.

gcc/testsuite/ChangeLog:

PR c++/66159
* g++.dg/warn/forward-inner.C: Check alias-declaration using
elaborated-type-specifier.

[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.

2020-06-17 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.

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

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

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

commit r11-1458-g4a31a8add56d49867c187d90b3a89e97634543c2
Author: Kaipeng Zhou 
Date:   Wed Jun 17 20:19:16 2020 +0100

vect: CSE for bump and offset in strided load/store operations.

Every time "vect_get_strided_load_store_ops" is called, new bump and offset
variables and a series of stmts are created.  And IVOPTs is not able to
eliminate them.  The patch use "cse_and_gimplify_to_preheader" to CSE them.

2020-06-17  Bin Cheng  
Kaipeng Zhou  

PR tree-optimization/95199
* tree-vect-stmts.c: Eliminate common stmts for bump and offset in
strided load/store operations and remove redundant code.

2020-06-17  Bin Cheng  
Kaipeng Zhou  

PR tree-optimization/95199
* gcc.target/aarch64/sve/pr95199.c: New test.

[Bug target/95722] libatomic crashes on __atomic_load of const object

2020-06-17 Thread foom at fuhm dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95722

James Y Knight  changed:

   What|Removed |Added

 CC||foom at fuhm dot net

--- Comment #1 from James Y Knight  ---
The fix would be to have libatomic use a lock instead of the lock-free
cmpxchg16b instruction to implement atomic_load. But I think this is impossible
without causing incompatibility with older GCCs.

Older versions of GCC (before GCC 7), and Clang to this day, emitted cmpxchg16b
inline for a 16-byte atomic load when you compile with -mcx16.

And thus, unfortunately, I think if libatomic switched to a lock now, it would
not be compatible with those older programs.

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

2020-06-17 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726

Jason Merrill  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-17

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

2020-06-17 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726

--- Comment #1 from Jason Merrill  ---
Does the aarch64 port expect __Float32x4_t type to be considered equivalent to
the GNU vector type or not?  If so, why use build_distinct_type_copy over
build_variant_type_copy?  If not, they might want to set TYPE_INDIVISIBLE_P so
that structural_comptypes treats them as different.

[Bug c/95378] __atomic_load will write to objects of cv-qualified types

2020-06-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95378

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed on master.

[Bug c++/95726] New: ICE with aarch64 __Float32x4_t as template argument

2020-06-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726

Bug ID: 95726
   Summary: ICE with aarch64 __Float32x4_t as template argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Following test ICEs on aarch64-linux:

// { dg-do compile }
// { dg-options "--param=hash-table-verification-limit=500 -O2" }

typedef __Float32x4_t float32x4_t;
typedef float V [[gnu::vector_size(4 * sizeof (float))]];

template 
int
foo ()
{
  return 0;
}

int
bar ()
{
  return foo  () + foo <__Float32x4_t> () + foo  () + foo
 ();
}

On 10.x branch I can reproduce the ICE even on a large unreduceable source
without that extra argument.

The function template is specialized twice, once with  and
once with <__Float32x4_t>.
The former vector type is:
elt:1 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7742a0 precision:32
pointer_to_this  reference_to_this
>
type_6 V4SF size  unit-size

align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea85cf18 nunits:4>>
(and has TYPE_CANONICAL itself), while the other one is some vector type
created by the aarch64 backend:
elt:1 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7742a0 precision:32
pointer_to_this  reference_to_this
>
type_6 V4SF size  unit-size

align:128 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
nunits:4>>
(and has NULL TYPE_CANONICAL).
In iterative_hash_template_arg for these VECTOR_TYPEs we end up:
default:
  if (tree canonical = TYPE_CANONICAL (arg))
val = iterative_hash_object (TYPE_HASH (canonical), val);
and thus hash it differently between vector(4) float and __Float32x4_t.
But spec_hasher::equal calls comp_template_args for that and that in turn calls
same_type_p on those and
structural_comptypes is called because one of those lacks TYPE_CANONICAL, and
there it does:
case VECTOR_TYPE:
  if (gnu_vector_type_p (t1) != gnu_vector_type_p (t2)
  || maybe_ne (TYPE_VECTOR_SUBPARTS (t1), TYPE_VECTOR_SUBPARTS (t2))
  || !same_type_p (TREE_TYPE (t1), TREE_TYPE (t2)))
return false;
and considers the two the same.
Because it hashed differently, it is added twice into the hash table, and when
we are unlucky, the two hash values modulo the size of the hash table are
equal,
so we have two different specializations (instantiations?) for the same thing
and the check that retrieve_specialization returns the one we are considering
fails.

2020-06-17  Jakub Jelinek  

* pt.c (iterative_hash_template_arg): Handle VECTOR_TYPE.

--- gcc/cp/pt.c.jj  2020-06-17 18:48:53.506617982 +0200
+++ gcc/cp/pt.c 2020-06-17 19:34:28.551298600 +0200
@@ -1924,10 +1924,21 @@ iterative_hash_template_arg (tree arg, h
  }
  break;

-   case  DECLTYPE_TYPE:
+   case DECLTYPE_TYPE:
  val = iterative_hash_template_arg (DECLTYPE_TYPE_EXPR (arg), val);
  break;

+   case VECTOR_TYPE:
+ {
+   bool gnu_vec = gnu_vector_type_p (arg);
+   val = iterative_hash_object (gnu_vec, val);
+   val = iterative_hash_template_arg (TREE_TYPE (arg), val);
+   inchash::hash hstate (val);
+   hstate.add_poly_int (TYPE_VECTOR_SUBPARTS (arg));
+   val = hstate.end ();
+ }
+ break;
+
default:
  if (tree canonical = TYPE_CANONICAL (arg))
val = iterative_hash_object (TYPE_HASH (canonical), val);

fixes this for me, but I wonder if we don't need to handle at least
POINTER_TYPE and REFERENCE_TYPE too, because if a template argument
is not a vector type, but e.g. a pointer to vector or reference to vector, due
to the magic backend VECTOR_TYPEs with no TYPE_CANONICAL
pointers to them will also have structural equality and thus would hash
differently from pointers/references to the C++ FE created vector types.

The __Float32x4_t type is created in aarch64_init_simd_builtin_types using
build_distinct_type_copy and
explicitly requests structural equality:
  aarch64_simd_types[i].itype
= build_distinct_type_copy
  (build_vector_type (eltype, GET_MODE_NUNITS (mode)));
  SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);

For POINTER_TYPE/REFERENCE_TYPE, we could do:
case REFERENCE_TYPE:
  {
bool rval = TYPE_REF_IS_RVALUE (arg);
val = iterative_hash_object (rval, val);
  }
  /* FALLTHRU */
case POINTER_TYPE:
  {
machine_mode mode = TYPE_MODE (arg);
val = iterative_hash_object (mode, val);
val = iterative_hash_template_

[Bug c++/95725] Confusing error diagnostic in an invalid template

2020-06-17 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
The diagnostic is usually for false positive/negative warnings or wrong
information in diagnostic messages.  It's not normally used for internal
compiler errors.  But I don't see an ICE on trunk with this test case, just
errors (so diagnostic would seem appropriate).  At the same time, the latest
GCC output seems reasonable.  Clang prints something similar:

pr95725.C:1:20: error: expected expression
template ' in template-parameter-list
pr95725.C:1:22: warning: declaration does not declare anything
  [-Wmissing-declarations]
1 warning and 3 errors generated.

I'm not sure there's a lot to improve here.

[Bug c++/95724] bogue error : "expected '{' before ')' token"

2020-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724

--- Comment #3 from Martin Liška  ---
(In reply to Haoxin Tu from comment #2)
> (In reply to Martin Liška from comment #1)
> > For the next time, can you please add 'ice-on-invalid-code' keyword?
> 
> I got it. So sorry for my mistake!

It's not a mistake, I just wanted to inform you that it's very unlikely that
we'll fix it. We have a lot of these issues..

[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl

2020-06-17 Thread iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700

--- Comment #8 from Ilya Leoshkevich  ---
Created attachment 48750
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48750&action=edit
proposed patch (tests are running)

[Bug c++/95508] [10 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096

2020-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/95508] [10 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096

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

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

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

commit r10-8315-g1bab254fd30c2b94a675b9057349fc80946375b1
Author: Marek Polacek 
Date:   Wed Jun 17 14:38:05 2020 -0400

c++: ICE with IMPLICIT_CONV_EXPR in array subscript [PR95508]

Since r10-7096 convert_like, when called in a template, creates an
IMPLICIT_CONV_EXPR when we're converting to/from array type.

In this test, we have e[f], and we're converting f (of type class A) to
int, so convert_like in build_new_op_1 created the IMPLICIT_CONV_EXPR
that got into cp_build_array_ref which calls maybe_constant_value.  My
patch above failed to adjust this spot to call fold_non_dependent_expr
instead, which can handle codes like I_C_E in a template.  Fixed by
using a new function maybe_fold_non_dependent_expr, which, if the expr
can't be evaluated to a constant, returns the original expression.

gcc/cp/ChangeLog:

PR c++/95508
* constexpr.c (maybe_fold_non_dependent_expr): New.
* cp-tree.h (maybe_fold_non_dependent_expr): Declare.
* typeck.c (cp_build_array_ref): Call maybe_fold_non_dependent_expr
instead of maybe_constant_value.

gcc/testsuite/ChangeLog:

PR c++/95508
* g++.dg/template/conv16.C: New test.

[Bug c++/95724] bogue error : "expected '{' before ')' token"

2020-06-17 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724

--- Comment #2 from Haoxin Tu  ---
(In reply to Martin Liška from comment #1)
> For the next time, can you please add 'ice-on-invalid-code' keyword?

I got it. So sorry for my mistake!

[Bug c++/95725] Confusing error diagnostic in an invalid template

2020-06-17 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

--- Comment #2 from Haoxin Tu  ---
(In reply to Martin Liška from comment #1)
> For the next time, can you please add 'ice-on-invalid-code' keyword?

Ok, so sorry it's my fault. But this is a diagnostic issue I think? I will add
"diagnostic" keywords next time.

[Bug c++/95723] GCC get confused while parsing a code

2020-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from Martin Liška  ---
Note that we have a gazillion of error recovery issues for C++ FE.

[Bug c++/95725] Confusing error diagnostic in an invalid template

2020-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
For the next time, can you please add 'ice-on-invalid-code' keyword?

[Bug c++/95724] bogue error : "expected '{' before ')' token"

2020-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
For the next time, can you please add 'ice-on-invalid-code' keyword?

[Bug c++/95723] GCC get confused while parsing a code

2020-06-17 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
For the next time, can you please add 'ice-on-invalid-code' keyword?

[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807

2020-06-17 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -11740,7 +11740,8 @@ start:
case EXEC_GOTO:
  if (code->expr1 != NULL)
{
- if (code->expr1->ts.type != BT_INTEGER)
+ if (code->expr1->expr_type == EXPR_CONSTANT
+ || code->expr1->ts.type != BT_INTEGER)
gfc_error ("ASSIGNED GOTO statement at %L requires an "
   "INTEGER variable", &code->expr1->where);
  else if (code->expr1->symtree->n.sym->attr.assign != 1)

[Bug c++/95725] New: Confusing error diagnostic in an invalid template

2020-06-17 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725

Bug ID: 95725
   Summary: Confusing error diagnostic in an invalid template
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code test.cc, makes GCC get confused while parsing.

$cat test.cc
template ’ before ‘;’ token
test.cc:1:22: error: expected unqualified-id before ‘;’ token


$g++-10 -w -c test.cc
test.cc:1:20: error: expected primary-expression before ‘=’ token
1 | template ’ before ‘;’ token
1 | template ’ before ‘decltype’
1 | template 

[Bug target/95704] PPC: int128 shifts should be implemented branchless

2020-06-17 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704

--- Comment #6 from Segher Boessenkool  ---
13 insns, but the longest chain is 4.  As I said, not totally awful, and
much better than the branchy code (which does not predict well, for more
general inputs anyway).

[Bug c++/93711] ICE: [[no_unique_address] when constructing via template helper

2020-06-17 Thread leni536 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711

Lénárd Szolnoki  changed:

   What|Removed |Added

 CC||leni536 at gmail dot com

--- Comment #3 from Lénárd Szolnoki  ---
A smaller example:

struct S {
S(S&&) = delete;
};

S foo();

struct A {
[[no_unique_address]] S s = foo();
};

A a{};

Version:
11.0.0 20200616

Command line options:
-std=c++20 -Wall -Wextra -pedantic

Diagnostics:
during RTL pass: expand
: In function 'void __static_initialization_and_destruction_0(int,
int)':
:11:5: internal compiler error: in assign_temp, at function.c:984
   11 | A a{};
  | ^

[Bug c++/95724] New: bogue error : "expected '{' before ')' token"

2020-06-17 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724

Bug ID: 95724
   Summary: bogue error : "expected '{' before ')' token"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code test.cc, GCC-trunk get a bogus error message and then get confused
with following code parsing.

$cat test.cc
template <(union : decltype(a = 0)>)


$g++-trunk -w -c test.cc
test.cc:1:11: error: expected identifier before ‘(’ token
1 | template <(union : decltype(a = 0)>)
  |   ^
test.cc:1:29: error: ‘a’ was not declared in this scope
1 | template <(union : decltype(a = 0)>)
  | ^
test.cc:1:29: error: ‘a’ was not declared in this scope
test.cc:1:34: error: expected ‘{’ before ‘)’ token
1 | template <(union : decltype(a = 0)>)
  |  ^
test.cc:1:36: error: expected unqualified-id before ‘)’ token
1 | template <(union : decltype(a = 0)>)
  |^

$g++-10 -w -c test.cc
test.cc:1:11: error: expected identifier before ‘(’ token
1 | template <(union : decltype(a = 0)>)
  |   ^
test.cc:1:29: error: ‘a’ was not declared in this scope
1 | template <(union : decltype(a = 0)>)
  | ^
test.cc:1:29: error: ‘a’ was not declared in this scope
test.cc:1:35: error: expected ‘{’ before ‘>’ token
1 | template <(union : decltype(a = 0)>)
  |   ^
test.cc:1:35: error: expected ‘,’ or ‘...’ before ‘>’ token
test.cc:1:36: error: expected ‘>’ at end of input
1 | template <(union : decltype(a = 0)>)
  |^
test.cc:1:36: error: expected unqualified-id at end of input

I guess GCC-trunk emits the bogus error message "expected ‘{’ before ‘)’
token", and the following error messages are inconsistent with GCC-10. So,
GCC-trunk might have something wrong with while parsing this code.

[Bug tree-optimization/94969] [8/10 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

2020-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

Richard Biener  changed:

   What|Removed |Added

 Resolution|FIXED   |---
  Known to work||9.3.1
 Status|CLOSED  |ASSIGNED
  Known to fail||10.1.0
Summary|[8/9/10/11 Regression]  |[8/10 Regression] Invalid
   |Invalid loop distribution   |loop distribution since
   |since   |r8-2390-gdfbddbeb1ca912c9
   |r8-2390-gdfbddbeb1ca912c9   |

--- Comment #15 from Richard Biener  ---
I don't see the commit on the GCC 10 branch nor the GCC 8 branch.  Master and
GCC 9 are fixed though.

[Bug c++/95723] New: GCC get confused while parsing a code

2020-06-17 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723

Bug ID: 95723
   Summary: GCC get confused while parsing a code
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code test.cc, GCC might get confused in parsing.

$cat test.cc
template  friend foo ( decltype (b=c

$g++-trunk -w test.cc
test.cc:1:12: error: ‘a’ has not been declared
1 | template  friend foo( decltype (b=c
  |^
test.cc:1:14: error: ‘friend’ used outside of class
1 | template  friend foo( decltype (b=c
  |  ^~
  |  --
test.cc:1:36: error: ‘b’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |^
test.cc:1:36: error: ‘b’ was not declared in this scope
test.cc:1:38: error: ‘c’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |  ^
test.cc:2: error: expected ‘,’ or ‘...’ at end of input
test.cc:1:39: error: expected ‘)’ at end of input
1 | template  friend foo( decltype (b=c
  |~  ^
  |   )
test.cc:2: error: expected initializer at end of input


$g++-10 -w test.cc
test.cc:1:12: error: ‘a’ has not been declared
1 | template  friend foo( decltype (b=c
  |^
test.cc:1:14: error: ‘friend’ used outside of class
1 | template  friend foo( decltype (b=c
  |  ^~
  |  --
test.cc:1:36: error: ‘b’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |^
test.cc:1:36: error: ‘b’ was not declared in this scope
test.cc:1:38: error: ‘c’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |  ^
test.cc:1:36: error: ‘b’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |^
test.cc:1:36: error: ‘b’ was not declared in this scope
test.cc:1:38: error: ‘c’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |  ^
test.cc:1:36: error: ‘b’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |^
test.cc:1:36: error: ‘b’ was not declared in this scope
test.cc:1:38: error: ‘c’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |  ^
test.cc:1:21: error: ISO C++ forbids declaration of ‘foo’ with no type
[-fpermissive]
1 | template  friend foo( decltype (b=c
  | ^~~
test.cc:1:36: error: ‘b’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |^
test.cc:1:36: error: ‘b’ was not declared in this scope
test.cc:1:38: error: ‘c’ was not declared in this scope
1 | template  friend foo( decltype (b=c
  |  ^
test.cc:1:39: error: expected ‘)’ at end of input
1 | template  friend foo( decltype (b=c
  |   ~  ~^
  |   )
test.cc:1:26: error: expected primary-expression before ‘decltype’
1 | template  friend foo( decltype (b=c
  |  ^
test.cc:1:39: error: expected ‘;’ at end of input
1 | template  friend foo( decltype (b=c
  |  ~^
  |   ;

I am sure that some error messages in GCC-10 are duplicated. I am also
wondering why GCC-trunk emits "error: expected initializer at end of input",
that's so confusing.

[Bug fortran/95718] [8/9/10/11 Regression] Wrong pointer associated status without initialization

2020-06-17 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95718

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kargl at gcc dot gnu.org ---
   16.5.2.2 Pointer association status

   A pointer may have a pointer association status of associated,
   disassociated, or undefined.  Its association status may change
   during execution of a program.  Unless a pointer is initialized
   (explicitly or by default), it has an initial association status
   of undefined.  A pointer may be initialized to have an association
   status of disassociated or associated.

   13.7.16 ASSOCIATED (POINTER [, TARGET])

   POINTER shall be a pointer.  It may be of any type or may be a
  procedure pointer.  Its pointer association status shall not
  be undefined.

Your program is invalid.

[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

2020-06-17 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #14 from Andreas Krebbel  ---
Closing

[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

2020-06-17 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #13 from Andreas Krebbel  ---
Fixed by Bin Cheng. Thanks!

[Bug target/95704] PPC: int128 shifts should be implemented branchless

2020-06-17 Thread jens.seifert at de dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704

--- Comment #5 from Jens Seifert  ---
Power9 code is branchfree but not good at all.

_Z3shloy:
.LFB0:
.cfi_startproc
addi 8,5,-64
subfic 6,5,63
srdi 10,3,1
li 7,0
sld 4,4,5
sld 5,3,5
cmpwi 7,8,0
srd 10,10,6
sld 3,3,8
or 4,10,4
isel 5,5,7,28
isel 4,4,3,28
mr 3,5
blr

13 instructions.

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

2020-06-17 Thread guojiufu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398

--- Comment #47 from Jiu Fu Guo  ---
memcmp is using wider reading in glibc; strncmp does not use wider reading.
memcmp is using "void *" as arguments, while strncmp is "char *".

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

2020-06-17 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706

--- Comment #3 from rguenther at suse dot de  ---
On Wed, 17 Jun 2020, seurer at linux dot vnet.ibm.com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706
> 
> --- Comment #2 from Bill Seurer  ---
> No idea, sorry.  Is that the problem?  Supposed to be an error but on a
> different line?

Yes.  On line 5, see the dg-error marker.

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

2020-06-17 Thread seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706

--- Comment #2 from Bill Seurer  ---
No idea, sorry.  Is that the problem?  Supposed to be an error but on a
different line?

[Bug other/95722] New: libatomic crashes on __atomic_load of const object

2020-06-17 Thread luis at luismarques dot eu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95722

Bug ID: 95722
   Summary: libatomic crashes on __atomic_load of const object
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luis at luismarques dot eu
  Target Milestone: ---

With this code in `test.c`:

```
struct S {
int x;
int y;
int z;
};

int main() {
__attribute__((aligned(16))) static const _Atomic struct S a;
struct S b;
b = a;
}
```

On x86_64 I get:

```
$ gcc test.c -latomic && ./a.out 
Segmentation fault (core dumped)
```

It crashes on a `lock cmpxchg16b` with the address of `a`, so I imagine the
libatomic implementation is dispatching to an optimized __atomic_load case
where the code assumes it can get a (mutable) lock from the object itself, and
when it tries to acquire that lock it writes to `.rodata`, causing the crash.

[Bug target/95704] PPC: int128 shifts should be implemented branchless

2020-06-17 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704

--- Comment #4 from Segher Boessenkool  ---
It no longer generates that rldicl in GCC 9 (or GCC 10).

You do get straight-line code already if you use -mcpu=power9, btw
(isel; and not totally awful code, but it isn't super of course).

[Bug c++/67491] [meta-bug] concepts issues

2020-06-17 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 68093, which changed state.

Bug 68093 Summary: [concepts] friend function declarations that differ only by 
constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093

   What|Removed |Added

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

[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions

2020-06-17 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |10.0
 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org

--- Comment #6 from Patrick Palka  ---
Looks like this is fully fixed as of GCC 10.

[Bug c++/95508] [10 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096

2020-06-17 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE on   |[10 Regression] ICE on
   |unexpected expression   |unexpected expression
   |implicit_conv_expr since|implicit_conv_expr since
   |r10-7096|r10-7096

--- Comment #3 from Marek Polacek  ---
Fixed on trunk, testing 10 now.

[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl

2020-06-17 Thread iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700

--- Comment #7 from Ilya Leoshkevich  ---
Would it be OK then to replace last arguments of functions with
__attribute__((sentinel)) from NULLs to nullptrs? I can make a patch for this.

[Bug c++/95508] [10/11 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096

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

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

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

commit r11-1449-gae2ebf011fec926e003645c33c07a03619ea216a
Author: Marek Polacek 
Date:   Wed Jun 17 09:19:02 2020 -0400

c++: ICE with IMPLICIT_CONV_EXPR in array subscript [PR95508]

Since r10-7096 convert_like, when called in a template, creates an
IMPLICIT_CONV_EXPR when we're converting to/from array type.

In this test, we have e[f], and we're converting f (of type class A) to
int, so convert_like in build_new_op_1 created the IMPLICIT_CONV_EXPR
that got into cp_build_array_ref which calls maybe_constant_value.  My
patch above failed to adjust this spot to call fold_non_dependent_expr
instead, which can handle codes like I_C_E in a template.  Fixed by
using a new function maybe_fold_non_dependent_expr, which, if the expr
can't be evaluated to a constant, returns the original expression.

gcc/cp/ChangeLog:

PR c++/95508
* constexpr.c (maybe_fold_non_dependent_expr): New.
* cp-tree.h (maybe_fold_non_dependent_expr): Declare.
* typeck.c (cp_build_array_ref): Call maybe_fold_non_dependent_expr
instead of maybe_constant_value.

gcc/testsuite/ChangeLog:

PR c++/95508
* g++.dg/template/conv16.C: New test.

[Bug testsuite/95716] g++.dg/ext/pr85503.C fails

2020-06-17 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95716

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed.

[Bug testsuite/95716] g++.dg/ext/pr85503.C fails

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

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

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

commit r11-1448-g4d2b0866d760f822c137b69f14d1c51fc760ce53
Author: Patrick Palka 
Date:   Wed Jun 17 09:09:53 2020 -0400

Fix use of inaccessible member in pr85503.C [PR95716]

The recent PR41437 fix exposed a latent use of an inaccessible member in
the below testcase.

gcc/testsuite/ChangeLog:

PR testsuite/95716
* g++.dg/ext/pr85503.C: Give ai::cv public access.

[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848

2020-06-17 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95710

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-17
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. No submodule in r5.

[Bug target/95704] PPC: int128 shifts should be implemented branchless

2020-06-17 Thread jens.seifert at de dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704

--- Comment #3 from Jens Seifert  ---
GCC 8.3 generates:
_Z3shloy:
.LFB0:
.cfi_startproc
addi 9,5,-64
cmpwi 7,9,0
blt 7,.L2
sld 4,3,9
li 3,0
blr
.p2align 4,,15
.L2:
srdi 9,3,1
subfic 10,5,63
sld 4,4,5
srd 9,9,10
sld 3,3,5
or 4,9,4
blr
.long 0
.byte 0,9,0,0,0,0,0,0
.cfi_endproc

8 instructions if taking L2. The branch free code I propsed:

_Z15shl_branch_lessoy:
.LFB1:
.cfi_startproc
rldicl 5,5,0,32
subfic 9,5,64
addi 10,5,-64
sld 10,3,10
srd 9,3,9
sld 4,4,5
or 9,9,10
or 4,9,4
sld 3,3,5
blr

8 instructions no branch. Almost everything can be executed in parallel.

rldicl 5,5,0,32 gets added by gcc, which is not necessary.

[Bug tree-optimization/95717] [9/10 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6

2020-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95717

Richard Biener  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE
   |during GIMPLE pass: vect:   |during GIMPLE pass: vect:
   |verify_ssa failed since |verify_ssa failed since
   |r9-5325-gf25507d041de4df6   |r9-5325-gf25507d041de4df6
  Known to work||11.0
  Known to fail||10.1.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/95717] [9/10/11 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6

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

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

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

commit r11-1447-gd0909f5858ad81e6d8b73fa6193be19cb5e6ed7b
Author: Richard Biener 
Date:   Wed Jun 17 14:57:59 2020 +0200

tree-optimization/95717 - fix SSA update for vectorizer epilogue

This fixes yet another issue with the custom SSA updating in the
vectorizer when we copy from the non-if-converted loop.  We must
not mess with current defs before we updated the BB copies.

2020-06-17  Richard Biener  

PR tree-optimization/95717
* tree-vect-loop-manip.c (slpeel_tree_duplicate_loop_to_edge_cfg):
Move BB SSA updating before exit/latch PHI current def copying.

* g++.dg/torture/pr95717.C: New testcase.

[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807

2020-06-17 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-17

[Bug target/95704] PPC: int128 shifts should be implemented branchless

2020-06-17 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
(In reply to Jens Seifert from comment #0)
> PowerPC processors don't like branches and branch mispredicts lead to large
> overhead.

While that is of course true, the situation isn't worse than on
other CPUs.

The situation here is exactly analogous to 64-bit shifts with -m32.

Fixed distance shifts (and rotates) generate pretty much ideal code
already (sometimes it could save a "mr" insn, by reordering more --
that is because the rl*imi insns use a register as both input and
output).

> shift left/right unsigned __in128 can be implemented in 8 instructions which
> can be processed on 2 pipelines almost in parallel leading to ~5 cycle
> latency on Power 7 and 8.

> shift right algebraic __int128 can be implemented in 10 instructions.
> Overall comparable in latency of the branching code.

This can be done better, using the fact that shifts over 64..127
bits are defined just fine for 64-bit power shift insns.

> The unnecessary rldicl 8,5,0,32 at the beginning of the routines are also
> not necessary.

I see no rldicl?

Confirmed.

[Bug testsuite/95716] g++.dg/ext/pr85503.C fails

2020-06-17 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95716

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-06-17

--- Comment #1 from Patrick Palka  ---
Looking into it.

[Bug c/95699] __builtin_constant_p inconsistencies

2020-06-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699

--- Comment #9 from Jakub Jelinek  ---
Created attachment 48749
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48749&action=edit
gcc11-pr95699.patch

Untested patch to improve the minmax optimization.

[Bug tree-optimization/95717] [9/10/11 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6

2020-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95717

--- Comment #4 from Richard Biener  ---
The bogus def is set via

  if (scalar_loop != loop)
{
  /* If we copied from SCALAR_LOOP rather than LOOP, SSA_NAMEs from
 SCALAR_LOOP will have current_def set to SSA_NAMEs in the new_loop,
 but LOOP will not.  slpeel_update_phi_nodes_for_guard{1,2} expects
 the LOOP SSA_NAMEs (on the exit edge and edge from latch to
 header) to have current_def set, so copy them over.  */ 
  slpeel_duplicate_current_defs_from_edges (single_exit (scalar_loop),
exit);

because that interferes with the renaming process.  The if-conversion
applied the missed optimization to the to-be vectorized loop introducing
a LC PHI (required for the not if-converted copy) which has one invariant
and one non-invariant arg.

So we have to do that copying after renaming in the BBs.  That seems to work,
testing patch.

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

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

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

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

commit r11-1446-g9efbb03616f556dcceabe364f734b5b11fb13587
Author: Martin Liska 
Date:   Wed Jun 17 13:42:20 2020 +0200

testsuite: clean up .gcov files in test-suite.

gcc/testsuite/ChangeLog:

PR testsuite/95720
* gcc.misc-tests/gcov-pr94029.c: Remove not needed remove-gcda.
* lib/gcov.exp: Delete properly .gcov files.

[Bug bootstrap/95721] [11 Regression] bootstrap failure on s390x-linux-gnu

2020-06-17 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95721

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Krebbel  ---
This should be fixed with:

commit 929fd91ba975eebf9e57f7f092041271dcaf0c34
Author: Stefan Schulze Frielinghaus 
Date:   Thu Jun 4 13:50:49 2020 +0200

S/390: Emit vector alignment hints for z13 if AS accepts them

Since 87cb9423add vector alignment hints are emitted for target z13,
too.  This patch changes this behaviour in the sense that alignment
hints are only emitted for target z13 if the assembler accepts them.

gcc/ChangeLog:

* config.in: Regenerate.
* config/s390/s390.c (print_operand): Emit vector alignment hints
for target z13, if AS accepts them.  For other targets the logic
stays the same.
* config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS):
Define
macro.
* configure: Regenerate.
* configure.ac: Check
HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13.

[Bug bootstrap/95721] New: [11 Regression] bootstrap failure on s390x-linux-gnu

2020-06-17 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95721

Bug ID: 95721
   Summary: [11 Regression] bootstrap failure on s390x-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

trunk 20200616 fails to build on s390x-linux-gnu.

/tmp/ccc8NlUQ.s:46: Error: junk at end of line: `,3'
/tmp/ccc8NlUQ.s:49: Error: junk at end of line: `,3'
make[5]: *** [Makefile:501: _absvdi2.o] Error 1
make[5]: *** Waiting for unfinished jobs
/tmp/ccwYynXs.s: Assembler messages:
/tmp/ccwYynXs.s:38: Error: junk at end of line: `,3'
/tmp/ccwYynXs.s:40: Error: junk at end of line: `,3'
/tmp/ccwYynXs.s:42: Error: junk at end of line: `,3'
/tmp/ccwYynXs.s:55: Error: junk at end of line: `,3'
/tmp/ccwYynXs.s:64: Error: junk at end of line: `,3'
make[5]: *** [Makefile:501: _addvdi3.o] Error 1
make[5]: Leaving directory '/<>/build/s390x-linux-gnu/libgcc'

not seen --with-arch=zEC12

seen with --with-arch=z13 --with-tune=z15

[Bug c/95699] __builtin_constant_p inconsistencies

2020-06-17 Thread vincent-gcc at vinc17 dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699

--- Comment #8 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #6)
> I don't see why that should be considered a bug.
> All the tests are using __builtin_constant_p in a way that it wasn't
> designed for, where it changes the behavior of the program whether it
> evaluates to 0 or 1.

Well, this was just meant to be a simplified testcase and to easily see whether
__builtin_constant_p gave true or false. But in GMP's longlong.h file (used by
GNU MPFR), there is similar code for aarch64, where the assembly code is
different whether the variable is regarded as a constant or not:

#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
  do {  \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   \
  __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
   : "=r,r" (sh), "=&r,&r" (sl) \
   : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
 "r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl))
__CLOBBER_CC);\
else\
  __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
   : "=r,r" (sh), "=&r,&r" (sl) \
   : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
 "r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl))
__CLOBBER_CC);\
  } while(0);

The assembly code is actually buggy in the "if" case (this was how one could
find out that there was a difference between GCC 9, where the "if" case was
selected, and GCC 10, where the "else" case was selected), but I doubt that GCC
is aware about this bug:

  https://sympa.inria.fr/sympa/arc/mpfr/2020-06/msg00052.html
  https://sympa.inria.fr/sympa/arc/mpfr/2020-06/msg00059.html

I suppose that the general goal of this test using __builtin_constant_p is to
have faster assembly code when some value is known at compile time. So the
intent (with the fixed assembly code[*]) is to have the same behavior, but have
faster code if possible. This is what we got with GCC 9, but this is no longer
the case with GCC 10.

[*] https://gmplib.org/list-archives/gmp-bugs/2020-June/004807.html

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

2020-06-17 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
   Last reconfirmed||2020-06-17
 CC||aoliva at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|New dump output filename|[11 Regression] New dump
   |strategy invalidates tests  |output filename strategy
   ||invalidates tests

--- Comment #1 from Richard Biener  ---
Indeed that part of the testsuite needs to be adapted but the change was
deliberate (and good).

  1   2   >