[Bug tree-optimization/96513] building terminated with -O3

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
What you could do, even if it is private code, is reduce it
(https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction) until it is very small
and doesn't give away any IP, and then post it. Otherwise, there is not much we
can do from your report and we are probably just going to close it...

[Bug c/96460] Warn about signed modulo that is converted to unsigned value

[fw at gcc dot gnu.org]

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

--- Comment #4 from Florian Weimer  ---
(In reply to Eric Gallager from comment #3)
> There already is a warning from -Wsign-conversion for it:

It's for the conversion, not the modulo. My hypothesis is that for the modulo,
the warning is much more helpful and can perhaps even enabled by -Wall.

[Bug c++/96515] New: [concepts] Segfault on ill-formed pack expansions in requires-expression

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 96515
   Summary: [concepts] Segfault on ill-formed pack expansions in
requires-expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/rafY6G
template
concept PackHasAdd = (requires(Args... args) {
   (args+1);
} && ...);

static_assert(PackHasAdd);
int main() {}


Compile with GCC trunk (11.0.0), "g++ -std=c++20":

:7:31: internal compiler error: Segmentation fault
7 | static_assert(PackHasAdd);
  |   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/96493] powerpc local call linkage failure

[cvs-commit at gcc dot gnu.org]

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

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

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

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

PR96493, powerpc local call linkage failure

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

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

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

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

[Bug fortran/96486] get_environment_variable fails for zero-length values

[kargl at gcc dot gnu.org]

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

--- Comment #18 from kargl at gcc dot gnu.org ---
Created attachment 49015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49015&action=edit
Bring get_environment_variable almost to F2018 conformance

* check.c (gfc_check_get_environment_variable):  New function.  Implement
  checking for get_environment_variable.

* gfortran.h: Add member for 6-argument subroutine to gfc_check_f.

* intrinsic.c (do_check): Deal with 6-argument subroutine checking.
  (add_sym_6s): Add 6-argument subroutine to subroutine list.
  (add_subroutines): Use add_sym_6s to add get_envronment_variable.

* intrinsic.h: Prototype for gfc_check_get_environment_variable.

* libgfortran/intrinsics/env.c:
  . Add F2018 errmsg variable.
  . Remove runtime error for missing name variable.  This is caught in
check.c.

[Bug middle-end/39398] verify_flow_info failed

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Arseny Solokha  ---
Is it still an issue?

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

[asolokha at gmx dot com]

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

Bug ID: 96514
   Summary: [9/10/11 Regression] ICE: verify_flow_info failed
(error: control flow in the middle of basic block 3)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-11.0.0-alpha20200802 snapshot (g:6e46b3f3da5c03bc529b3690dd0995927feb9142)
ICEs when compiling the following testcase w/ -O1:

int __attribute__ ((pure, returns_twice))
r0 (void);

void
vy (int t7)
{
  while (t7 == 0)
r0 ();
}

void
qw (int t7)
{
  vy (t7);

  if (0)
r0 ();
}

void __attribute__ ((simd))
un (int t7)
{
  qw (t7);
  qw (t7);
}

% x86_64-pc-linux-gnu-gcc-11.0.0 -O1 -c sylqgldf.c
sylqgldf.c: In function 'un.simdclone.0':
sylqgldf.c:21:1: error: control flow in the middle of basic block 3
   21 | un (int t7)
  | ^~
during GIMPLE pass: ifcvt
sylqgldf.c:21:1: internal compiler error: verify_flow_info failed
0x917096 verify_flow_info()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/cfghooks.c:269
0xe15db4 checking_verify_flow_info
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/cfghooks.h:212
0xe15db4 cleanup_tree_cfg_noloop
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-cfgcleanup.c:1114
0xe163c8 cleanup_tree_cfg(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-cfgcleanup.c:1165
0xe3db5c execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-if-conv.c:3201
0xe3db5c execute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200802/work/gcc-11-20200802/gcc/tree-if-conv.c:3170

[Bug c/96513] New: building terminated with -O3

[zhenglin.huang at qdreamer dot com]

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

Bug ID: 96513
   Summary: building terminated with -O3
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhenglin.huang at qdreamer dot com
  Target Milestone: ---

gcc -o wtk/core/fft/wtk_fixfft.o -c -O3 -DHAVE_MATH_H -DDEBUG_VAD_DELAY
-DUSE_LINUX -DUSE_STDLIB_MALLOC -DHAVE_STDIO_H -DVAD_MLF_DEBUG -I. -Ipublic/inc
-Itest wtk/core/fft/wtk_fixfft.c

when I compile use above command I got this

during GIMPLE pass: vect
wtk/core/fft/wtk_fixfft.c: In function ‘wtk_fixfft_work.isra.0.constprop’:
wtk/core/fft/wtk_fixfft.c:672:13: internal compiler error: in
vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1552
  672 | static void wtk_fixfft_work(wtk_fixfft_substate_t *st, wtk_fixcpx_t
*Fout,
  | ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

only -O3 got this error, -O2 is normal. Sorry, I can't submit source code as it
is not my personal code.

gcc -v output

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-10ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)

[Bug tree-optimization/96512] wrong code generated with avx512 intrinsics in some cases

[nathanael.schaeffer at gmail dot com]

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

--- Comment #1 from N Schaeffer  ---
Created attachment 49014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49014&action=edit
even simpler bug demonstrator

[Bug tree-optimization/96512] New: wrong code generated with avx512 intrinsics in some cases

[nathanael.schaeffer at gmail dot com]

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

Bug ID: 96512
   Summary: wrong code generated with avx512 intrinsics in some
cases
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanael.schaeffer at gmail dot com
  Target Milestone: ---

Created attachment 49013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49013&action=edit
bug demonstrator

with gcc 8.3.0 (and also possibly some other versions), I found a nasty bug
that messes up the results of my calculations.
I worked hard to produce a simple reproduced, which is attached.

With gcc 8.3.0, compiling with
   gcc -O1 -g -D_GCC_VEC_=1 -march=skylake-avx512 bug_gcc_avx512.c

running ./a.out leads to a wrong result, displayed like so:
   ERROR :: 0.874347 == 0

Examining the generated assembly, I suspect this instruction to be wrong:
0x00401186 <+100>:   vbroadcastsd zmm0,QWORD PTR [r8*8+0x1]
because r8 is aligned, and the 0x1 offset does not seem right...

When compiling with -march=skylake the problem goes away.
When using "alloca" instead of variable length array, the problem goes away
When inserting a printf, the problem goes away.

See in the attached source file. The lines commented with "NO BUG" make the bug
go away.

This has been a nightmare to spot, as it does not happen on all compiler
versions. I hope somebody can reproduce it and fix it...
Note that the assembly generated on godbolt does not seem to have this issue...

[Bug target/96493] powerpc local call linkage failure

[amodra at gmail dot com]

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

--- Comment #2 from Alan Modra  ---
Yes, it is a bug present in any gcc version supporting pcrel.

[Bug fortran/96486] get_environment_variable fails for zero-length values

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #17 from Steve Kargl  ---
On Thu, Aug 06, 2020 at 08:33:12PM +, jussilehtola at fedoraproject dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
> 
> --- Comment #16 from Susi Lehtola  ---
> Yes, then I installed missing libgfortran debuginfos and the backtrace
> shortened to
> 
> #0  0x401267 in zerolen_value
> at /tmp/readvar2.f90:17
> #1  0x4012c4 in main
> at /tmp/readvar2.f90:22
> 

I cannot reproduce the issue.

[Bug c++/96511] New: Incorrect placement-new warning

[mserdarsanli at gmail dot com]

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

Bug ID: 96511
   Summary: Incorrect placement-new warning
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mserdarsanli at gmail dot com
  Target Milestone: ---

Below code causes the warning in the last line, which seems to be incorrect. It
affects all versions starting from GCC 8
Compiler explorer: https://godbolt.org/z/xhf6cr

#include 

struct Foo {
Foo() = default;
Foo(int _a) : a(_a) {}
int a = 0;
};

void f()
{
Foo arr[2];

new (arr) Foo(10); // ok
new (arr + 0) Foo(10); // ok
new (&arr[0]) Foo(10); // ok

new (&arr[1]) Foo(15); // ok
new (arr + 1) Foo(15); // warning: placement new constructing an object of
type 'Foo' and size '4' in a region of type 'Foo [2]' and size '0'
[-Wplacement-new=]
}

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
I have a patch (since yesterday; just no time to send it :-/ )

[Bug c++/96510] New: Unexpected constexpr deallocation error after implicit conversion

[pkeir at outlook dot com]

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

Bug ID: 96510
   Summary: Unexpected constexpr deallocation error after implicit
conversion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkeir at outlook dot com
  Target Milestone: ---

Created attachment 49012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49012&action=edit
A C++ file containing the code described.

In the C++20 code below (also attached), the Foo class allocates and
deallocates to an int pointer member in the constructor and destructor
respectively. Comparing a Foo object to an integer (via `operator==`) makes use
of another member function `compare` which expects a `Foo&`; and so a `Foo`
object is implicitly created. Somehow, within a `constexpr` context (e.g. the
`static_assert` below), the `constexpr` memory is not being freed, and an error
message is issued (error: ‘do_stuff()’ is not a constant expression because
allocated storage has not been deallocated).

struct Foo {
  constexpr  Foo(int i) { p = new int(i); }
  constexpr ~Foo()  { delete p;   }

  constexpr bool compare(const Foo&) const { return true; }
  constexpr bool operator==(int y)   const { return compare(y); }
  int *p;
};

constexpr bool do_stuff()
{
  Foo f(0);
  bool b = f == 42;
  return b;
}

int main(int argc, char *argv[])
{
  static_assert(do_stuff());

  return do_stuff() ? 0 : -1;
}

[Bug c/96460] Warn about signed modulo that is converted to unsigned value

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|Warn about signed module|Warn about signed modulo
   |that is converted to|that is converted to
   |unsigned value  |unsigned value

--- Comment #3 from Eric Gallager  ---
There already is a warning from -Wsign-conversion for it:

$ /usr/local/bin/gcc -c -Wall -Wextra -Wconversion  96460.c
96460.c: In function 'f2':
96460.c:4:12: warning: conversion to 'long unsigned int' from 'int' may change
the sign of the result [-Wsign-conversion]
4 |   return i % 16;
  |  ~~^~~~
$

[Bug c/96468] Warn when an empty while loop could have been a do-while

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
Huh, I thought it might have been possible to get a warning from -Wempty-body
for this code with some other version of gcc or clang, but I can't seem to find
which one at the moment...

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
> I'd be really grateful for advice on how to test and improve this. Is there a 
> test suite somewhere that I've missed? Ideally, one that works with a free 
> simulator?

Probably best to ask on the gcc-patches mailing list or one of the AVR forums
(avrfreaks maybe).

[Bug fortran/96486] get_environment_variable fails for zero-length values

[jussilehtola at fedoraproject dot org]

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

--- Comment #16 from Susi Lehtola  ---
Yes, then I installed missing libgfortran debuginfos and the backtrace
shortened to

#0  0x401267 in zerolen_value
at /tmp/readvar2.f90:17
#1  0x4012c4 in main
at /tmp/readvar2.f90:22

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 8.5, 9.4, 10.3 and 11.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

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

libstdc++-v3/ChangeLog:

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

(cherry picked from commit 6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184)

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

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

libstdc++-v3/ChangeLog:

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

(cherry picked from commit 6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184)

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

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

libstdc++-v3/ChangeLog:

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

(cherry picked from commit 6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184)

[Bug libstdc++/96161] istream::ignore sets eofbit too soon

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
See also g:4e39f563c0cd25401f689c2093cb8c13692156ef

[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2019-09-08 00:00:00 |2020-8-6

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #10)
> I'm only going by what the issues list says. If that's wrong we should ask
> Mike to update it.

FTAOD, what I meant was that I *was* only going by what the issues list says
when I claimed it's not a DR. I didn't mean to imply that I *will* only go by
what the issues list says in all cases.

So when GCC implements it, it should be for every mode.

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to DV Henkel-Wallace from comment #7)
> Thanks.  That is clear.
> 
> BTW FWIW, defining <=> myself and then defining == default does appear to do
> what I want (i.e. I don't have to use. = default with both operators).

Right, that's what I said (or tried to say) in comment 3:

  "I think to get what you expect, you need to either define <=> as defaulted,
   or define == as defaulted."

Either works fine, it doesn't need to be both.

> saw that cppreference claims that `== default` will do `<=> < 0` -- though I
> know that site isn't authoritative, merely close to authorotative.

https://en.cppreference.com/w/cpp/language/default_comparisons seems correct,
although it notes:

  This section is incomplete
  Reason: Defaulted equality comparisons

[Bug tree-optimization/96509] out of bounds access silently makes a bounded loop infinite with inlining

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|out of bounds access makes  |out of bounds access
   |a bounded loop infinite |silently makes a bounded
   |with inlining   |loop infinite with inlining

--- Comment #1 from Martin Sebor  ---
Actually, I spoke too soon about the warning.  Calling f() with a value greater
than 7 suppresses the warning while keeping the loop unbounded:

$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
struct { char a[4], b[4]; } x;

static inline void f0 (const char *s, int n)
{
  for (int i = 0; i != n; ++i) // warning (good)...
x.a[i] = s[i];
}

void f1 (const char *s)
{
  f0 (s, 9);   // ...infinite loop (pr96509)
}

;; Function f1 (f1, funcdef_no=1, decl_uid=1943, cgraph_uid=2, symbol_order=2)
(executed once)

Merging blocks 3 and 4
f1 (const char * s)
{
  unsigned long ivtmp.5;
  char _6;

   [local count: 10631108]:

   [local count: 1073741824]:
  # ivtmp.5_11 = PHI <0(2), ivtmp.5_10(3)>
  _6 = MEM[base: s_2(D), index: ivtmp.5_11, offset: 0B];
  MEM[symbol: x, index: ivtmp.5_11, offset: 0B] = _6;
  ivtmp.5_10 = ivtmp.5_11 + 1;
  goto ; [100.00%]

}

[Bug tree-optimization/96509] New: out of bounds access makes a bounded loop infinite with inlining

[msebor at gcc dot gnu.org]

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

Bug ID: 96509
   Summary: out of bounds access makes a bounded loop infinite
with inlining
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The one-byte buffer overflow turns the bounded loop in the test case below into
an infinite one.  GCC does issue a warning which is enabled by default, but the
transformation is still obviously problematic due to its security implications.

$ cat x.c && gcc -O2 -S -fdump-tree-evrp=/dev/stdout x.c
struct { char a[4], b[4]; } x;

static inline void f (const char *s, int n)
{
  for (int i = 0; i != n; ++i) // warning (good)...
x.a[i] = s[i];
}

void g (const char *s)
{
  f (s, 5);   // ...but loop doesn't terminate
}

;; Function f (f, funcdef_no=0, decl_uid=1936, cgraph_uid=1, symbol_order=1)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5
;;
;; Loop 1
;;  header 4, latch 3
;;  depth 1, outer 0
;;  nodes: 4 3
;; 2 succs { 4 }
;; 3 succs { 4 }
;; 4 succs { 3 5 }
;; 5 succs { 1 }

Value ranges after Early VRP:

_1: sizetype [0, 4]
_2: const char * VARYING
_3: char VARYING
i_4: int [0, 4]
n_8(D): int VARYING
s_9(D): const char * VARYING
i_11: int [1, 5]


f (const char * s, int n)
{
  int i;
  sizetype _1;
  const char * _2;
  char _3;

   :
  goto ; [INV]

   :
  _1 = (sizetype) i_4;
  _2 = s_9(D) + _1;
  _3 = *_2;
  x.a[i_4] = _3;
  i_11 = i_4 + 1;

   :
  # i_4 = PHI <0(2), i_11(3)>
  if (i_4 != n_8(D))
goto ; [INV]
  else
goto ; [INV]

   :
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1943, cgraph_uid=2, symbol_order=2)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5
;;
;; Loop 1
;;  header 4, latch 3
;;  depth 1, outer 0
;;  nodes: 4 3
;; 2 succs { 4 }
;; 3 succs { 4 }
;; 4 succs { 3 5 }
;; 5 succs { 1 }
x.c: In function ‘g’:
x.c:6:12: warning: iteration 4 invokes undefined behavior
[-Waggressive-loop-optimizations]
6 | x.a[i] = s[i];
  | ~~~^~
x.c:5:3: note: within this loop
5 |   for (int i = 0; i != n; ++i) // warning (good)...
  |   ^~~

Value ranges after Early VRP:

s_2(D): const char * VARYING
i_4: int [0, 4]
_5: sizetype [0, 4]
_6: const char * VARYING
_7: char VARYING
i_8: int [1, 5]


Removing basic block 5
Merging blocks 4 and 3
g (const char * s)
{
  int i;
  sizetype _5;
  const char * _6;
  char _7;

   :

   :
  # i_4 = PHI <0(2), i_8(3)>
  _5 = (sizetype) i_4;
  _6 = s_2(D) + _5;
  _7 = *_6;
  x.a[i_4] = _7;
  i_8 = i_4 + 1;
  goto ; [100.00%]

}

[Bug target/96191] aarch64 stack_protect_test canary leak

[cvs-commit at gcc dot gnu.org]

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

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

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

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

arm: Clear canary value after stack_protect_test [PR96191]

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

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

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

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk and GCC 10 branch.

[Bug c++/96223] DR 1787 and indeterminate values in constexpr context

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|rejects-valid   |
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Last reconfirmed||2020-08-06
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Aaah, I see.  Thanks a lot!

I'll add the test at least.

[Bug c++/96223] DR 1787 and indeterminate values in constexpr context

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #2 from Richard Smith  ---
P1331R2 explicitly disallows in a constant evaluation:

"- an lvalue-to-rvalue conversion that is applied to an object with
indeterminate value ([basic.indet]);"

so GCC is correct to reject such cases.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

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

libstdc++-v3/ChangeLog:

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

[Bug c++/96501] [C++11] Should warn when classes only have copy constructor defined

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Also, how would users suppress this warning for cases where it's not wanted?

Plenty of classes don't need a move constructor because moving is not more
efficient than copying, but they don't want a defaulted move constructor.

Basically, the code isn't necessarily wrong, and there's no easy way to tell
whether the lack of a move constructor is a problem, or should be changed.

[Bug middle-end/96508] New: missing warning for invalid calls to builtins from inline functions defined in system headers

[msebor at gcc dot gnu.org]

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

Bug ID: 96508
   Summary: missing warning for invalid calls to builtins from
inline functions defined in system headers
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prompted by the discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551526.html, the test
case below shows that warnings aren't issued for invalid calls to built-in
functions like memcpy called from inline functions defined in system headers
unless those inline functions are also declared artificial.

Since the artificial attribute is used only rarely (there are only two
instances of it in all of libstdc++), this limitation defeats most
out-of-bounds checking in such wrappers.

$ gcc -O2 -S -Wall -Wextra x.c
#ifndef SYSTEM_HEADER_H
#define SYSTEM_HEADER_H

#pragma GCC system_header

__attribute__ ((access (write_only, 1, 3))) void
sys_func (void*, const void*, int);

__attribute__ ((access (write_only, 1, 3), artificial)) static inline void
sys_func_artificial_inline (void *d, const void *s, int n)
{
  __builtin_memcpy (d, s, n);
}

__attribute__ ((access (write_only, 1, 3))) static inline void
sys_func_inline (void *d, const void *s, int n)
{
  __builtin_memcpy (d, s, n);
}

#endif   // SYSTEM_HEADER_H
#include "system-header.h"

__attribute__ ((access (write_only, 1, 3))) static inline void
func_inline (void *d, const void *s, int n)
{
  sys_func (d, s, n);
}

void* f1 (const void *s)
{
  void *d = __builtin_malloc (3);
  sys_func (d, s, 5);// warning (good)
  return d;
}

void* f2 (const void *s)
{
  void *d = __builtin_malloc (3);
  sys_func_artificial_inline (d, s, 6);  // warning (good)
  return d;
}

void* f3 (const void *s)
{
  void *d = __builtin_malloc (3);
  sys_func_inline (d, s, 7); // missing warning!
  return d;
}

void* f4 (const void *s)
{
  void *d = __builtin_malloc (3);
  func_inline (d, s, 8); // warning (good)
  return d;
}
x.c: In function ‘f1’:
x.c:12:3: warning: ‘sys_func’ writing 5 bytes into a region of size 3 overflows
the destination [-Wstringop-overflow=]
   12 |   sys_func (d, s, 5);// warning (good)
  |   ^~
In file included from x.c:1:
system-header.h:7:1: note: in a call to function ‘sys_func’ declared with
attribute ‘write_only (1, 3)’
7 | sys_func (void*, const void*, int);
  | ^~~~
In function ‘sys_func_artificial_inline’,
inlined from ‘f2’ at x.c:19:3:
system-header.h:12:3: warning: ‘__builtin_memcpy’ writing 6 bytes into a region
of size 3 [-Wstringop-overflow=]
   12 |   __builtin_memcpy (d, s, n);
  |   ^~
x.c: In function ‘f2’:
x.c:18:13: note: at offset 0 to an object with size 3 allocated by
‘__builtin_malloc’ here
   18 |   void *d = __builtin_malloc (3);
  | ^~~~
In function ‘func_inline’,
inlined from ‘f4’ at x.c:33:3:
x.c:6:3: warning: ‘sys_func’ writing 8 bytes into a region of size 3 overflows
the destination [-Wstringop-overflow=]
6 |   sys_func (d, s, n);
  |   ^~
In file included from x.c:1:
x.c: In function ‘f4’:
system-header.h:7:1: note: in a call to function ‘sys_func’ declared with
attribute ‘write_only (1, 3)’
7 | sys_func (void*, const void*, int);
  | ^~~~

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[gu...@henkel-wallace.org]

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

--- Comment #7 from DV Henkel-Wallace  ---
Thanks.  That is clear.

BTW FWIW, defining <=> myself and then defining == default does appear to do
what I want (i.e. I don't have to use. = default with both operators).  I saw
that cppreference claims that `== default` will do `<=> < 0` -- though I know
that site isn't authoritative, merely close to authorotative.

Sorry about reporting a non-bug and thanks for your patience in your response.

[Bug c++/96501] [C++11] Should warn when classes only have copy constructor defined

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Nuno Lopes from comment #0)
> I see a lot of old code that has copy constructors defined, but not move
> constructors. This pessimizes code since the definition of the copy
> constructor hides the default move constructor.

If you need a user-defined copy constructor, a defaulted move constructor
probably isn't going to do the right thing anyway.

[Bug c++/96507] New: Feature request: improve "-Waddress" (or equivalent) for function references inside structs

[federico.kircheis at gmail dot com]

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

Bug ID: 96507
   Summary: Feature request: improve "-Waddress" (or equivalent)
for function references inside structs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

This is a feature request.


I'm compiling the code with "-Wall -Wextra -pedantic"


#include 

void foo(){}

int main(){
void(&f)() = foo;
static_assert(!std::is_pointer::value, "should not be a
pointer");
return f != 0;
}


gcc correctly triggers the warning "warning: the address of 'void foo()' will
never be NULL [-Waddress]" (nitpick nullptr in the error message would be
better than NULL).

Also for following example gcc emits the desired diagnostic


#include 

void foo(){}

using fun = void();

fun& get_fun();

int main(){
fun& f = get_fun();
static_assert(!std::is_pointer::value, "should not be a
pointer");
return f != 0;
}


But if the function reference is inside a struct:


#include 

void foo(){}

using fun = void();

struct s{
fun& f;
};

s get_fun();

int main(){
s ss = get_fun();
static_assert(!std::is_pointer::value, "should not be a
pointer");
return ss.f != 0;
}



then gcc does not emit any diagnostic (notice: it does if it can inline
get_fun()), even if "knows" that it cannot be null, as the static_assert does
not fire.

As reference: https://godbolt.org/z/vqohqM

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[mikpelinux at gmail dot com]

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

--- Comment #5 from Mikael Pettersson  ---
I can't reproduce on {ppc64le, ppc64, aarch64, m68k, x86_64}-linux-gnu, they
all inline the dispatcher at the end of each handler, w/ gcc-10.2.0 -O2. 
However, for sparc64 gcc-10.2.0 -O2 does end each handler with a branch to a
shared dispatcher (which is not what we want).

[Bug libstdc++/93502] std::regex_match uses stack space proportional to input string length

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug libstdc++/86164] std::regex crashes when matching long lines

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/96506] ICE when using an MMA type as a function param

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-06
 Status|UNCONFIRMED |ASSIGNED
 Target||powerpc*-*
 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
Confirmed and mine.  This is broken in GCC 10 as well.

[Bug target/96506] New: ICE when using an MMA type as a function param

[bergner at gcc dot gnu.org]

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

Bug ID: 96506
   Summary: ICE when using an MMA type as a function param
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

We ICE on the following invalid code.  It's invalid because we do not support
passing __vector_quad or __vector_pair as function arguments or as function
return values.

void
foo (void)
{
  __vector_quad v;
  bar (v);
}

bergner@pike:~/gcc/BUGS$ gcc -S -O2 -mcpu=power10 test.c
test.c: In function ‘foo’:
test.c:5:3: warning: implicit declaration of function ‘bar’
[-Wimplicit-function-declaration]
5 |   bar (v);
  |   ^~~
during RTL pass: reload
test.c:6:1: internal compiler error: maximum number of generated reload insns
per insn achieved (90)
6 | }
  | ^
0x108ce483 lra_constraints(bool)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/lra-constraints.c:4954
0x108aed5f lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/lra.c:2415
0x1083d49b do_reload
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/ira.c:5525
0x1083d49b execute
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/ira.c:5711
Please submit a full bug report,

[Bug ipa/96505] New: attribute access effect lost after inlining

[msebor at gcc dot gnu.org]

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

Bug ID: 96505
   Summary: attribute access effect lost after inlining
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Prompted by the discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551526.html, the
following test case shows that the effect of attribute access is lost after a
function declared with it has been inlined.  This makes the attribute next to
useless in code like libstdc++ that makes heavy use of inlining and/or
templates.

See also pr96502 and pr96503 for similar problems involving other function
attributes.  I've raised these as separate issues because I expect each to need
a different solution.

$ cat x.c && gcc -O2 -S -Wall -Wextra x.c
void f (void*, int);

__attribute__ ((access (write_only, 1, 2), noinline)) void
 f0 (void *p, int n) { f (p, n); }

void h0 (void)
{
  char a[3];
  f0 (a, 5);   // warning (good)
}

__attribute__ ((access (write_only, 1, 2))) void
f1 (void *p, int n) { f (p, n); }

void h1 (void)
{
  char a[3];
  f1 (a, 5);   // missing warning
}
x.c: In function ‘h0’:
x.c:9:3: warning: ‘f0’ writing 5 bytes into a region of size 3 overflows the
destination [-Wstringop-overflow=]
9 |   f0 (a, 5);   // warning (good)
  |   ^
x.c:4:2: note: in a call to function ‘f0’ declared with attribute ‘write_only
(1, 2)’
4 |  f0 (void *p, int n) { f (p, n); }
  |  ^~

[Bug fortran/96486] get_environment_variable fails for zero-length values

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl  ---
On Thu, Aug 06, 2020 at 08:42:20AM +, jussilehtola at fedoraproject dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
> 
> --- Comment #13 from Susi Lehtola  ---
> The gdb output is the same
> 
> (gdb) r
> Starting program: /tmp/a.out 
> Fortran runtime error: Zero-length string passed as value to
> get_environment_variable.
> 
> Error termination. Backtrace:
> #0  0x401267 in zerolen_value
> at /tmp/readvar2.f90:17
> #1  0x4012c4 in main
> at /tmp/readvar2.f90:22
> [Inferior 1 (process 122282) exited with code 02]
> 

I cannot reproduce your error.  Your original backtrace was

Error termination. Backtrace:
#0  0x7f25c93aadf1 in ???
#1  0x7f25c93ab939 in ???
#2  0x7f25c93abe60 in ???
#3  0x7f25c960ce53 in ???
#4  0x401267 in ???
#5  0x4012c4 in ???
#6  0x7f25c903a041 in __libc_start_main
 at ../csu/libc-start.c:308
#7  0x4010ad in ???
#8  0x in ???

I would expect a long backtrace under gdb.  Don't know
what [Inferior 1...] means.

[Bug fortran/93671] gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug fortran/96486] get_environment_variable fails for zero-length values

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #14 from Steve Kargl  ---
On Thu, Aug 06, 2020 at 08:03:29AM +, markeggleston at gcc dot gnu.org
wrote:
> (In reply to kargl from comment #6)
> > I do note there are other problems with get_environment_variable.
> 
> It looks to me that this intrinsic supports the Fortran 2003
> standard. Changes were introduced with the Fortran 2018 and
> support has not yet been implemented.

Yep

> > 
> > 1) Neither length nor status can be integer(1).  gfortran should issue
> >an error.
> 
> Fortran 2003 has default kind for these arguments.
> 

As does F2008.

> > 
> > 2) Fortran 2018 has added an optional errmsg argument.  This is not
> >supported.
> > 
> > 3) gfortran is issuing errors that don't make sence (to me).
> > 
> > program foo
> >integer( 1) i01
> >integer( 2) i02
> >integer( 4) i04
> >integer( 8) i08
> > #ifdef __GFC_INT_16__
> >integer(16) i16
> > #endif
> >character(len=20) name
> > 
> >print '(A,I0)', 'range(i01) = ', range(i01)
> >print '(A,I0)', 'range(i02) = ', range(i02)
> >print '(A,I0)', 'range(i04) = ', range(i04)
> >print '(A,I0)', 'range(i08) = ', range(i08)
> > #ifdef __GFC_INT_16__
> >print '(A,I0)', 'range(i16) = ', range(i16)
> > #endif
> > 
> >name = ''
> >! Although valid Fortran, this should probably raise a warning.
> >call get_environment_variable(name);
> > 
> >name = 'FOO'
> >call get_environment_variable(name,length=i01);  ! Should be an error
> >call get_environment_variable(name,length=i02);  ! Should be ok
> >call get_environment_variable(name,length=i04);  ! Should be ok
> >call get_environment_variable(name,length=i08);  ! Should be ok
> > #ifdef __GFC_INT_16__
> >call get_environment_variable(name,length=i16);  ! Should be ok
> > #endif
> > 
> > end program foo
> > 
> > mobile:kargl[256] gfcx -o z a.F90 && ./z
> > a.F90:29:45:
> > 
> >29 |call get_environment_variable(name,length=i01);  ! Should be an
> > error
> >   | 1
> > Error: In call to 'get_environment_variable' at (1), type mismatch in
> > argument length'; pass 'INTEGER(1)' to 'INTEGER(4)'
> > a.F90:30:45:
> > 
> >30 |call get_environment_variable(name,length=i02);
> >   | 1
> > Error: In call to 'get_environment_variable' at (1), type mismatch in
> > argument length'; pass 'INTEGER(2)' to 'INTEGER(4)'
> > a.F90:32:45:
> > 
> >32 |call get_environment_variable(name,length=i08);
> >   | 1
> > Error: In call to 'get_environment_variable' at (1), type mismatch in
> > argument length'; pass 'INTEGER(8)' to 'INTEGER(4)'
> 
> The mismatch errors are consistent with Fortran 2003 support.
> 
> I think these issues should be in a separate PR for Fortran 2018 support.
> 

gfortran is using the default argument checking routine, which
is based on the information from intrinsic.c.  With f2018,
making (almost?) everything generic, a gfc_check_environment_variable
is needed.  This then may allow some of the runtime checking
to be removed.

[Bug c++/96504] New: [coroutines] test failures with glibc-2.32

[xry111 at mengyan1223 dot wang]

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

Bug ID: 96504
   Summary: [coroutines] test failures with glibc-2.32
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at mengyan1223 dot wang
  Target Milestone: ---

With the state-of-art glibc-2.32, gcc-10.2.0 test suite reports several FAILs
about coroutine:

FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C execution test
FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C   -O0  execution test
FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C   -O1  execution test
FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C   -O2  execution test
FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C   -O3 -g  execution
test
FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C   -Os  execution test
FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O0  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O1  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O3 -g  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -Os  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: g++.dg/coroutines/torture/pr95519-05-gro.C   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test

The test program terminates with SIGABRT.

[Bug ipa/96503] New: attribute alloc_size effect lost after inlining

[msebor at gcc dot gnu.org]

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

Bug ID: 96503
   Summary: attribute alloc_size effect lost after inlining
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Similar to pr96502, the test case below shows that the effect of attribute
alloc_size on warnings is also lost after inlining.  I open this as a separate
bug (and expect to raise others) because I expect the "fixes" to be different
in each case.   Like pr96502, this also came up in the following discussion:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551526.html

$ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout x.c
int* f (int);

__attribute__ ((alloc_size (1), noinline)) int*
 f0 (int n) { return f (n); }

void h0 (void)
{
  int *p = f0 (3);
  __builtin_memset (p, 0, 3 * sizeof p);   // warning (good)
}

__attribute__ ((alloc_size (1))) int*
f1 (int n) { return f (n); }

void h1 (void)
{ 
  int *p = f1 (3);
  __builtin_memset (p, 0, 3 * sizeof p);   // missing warning
}

x.c: In function ‘h0’:
x.c:9:3: warning: ‘__builtin_memset’ forming offset [3, 23] is out of the
bounds [0, 3] [-Warray-bounds]
9 |   __builtin_memset (p, 0, 3 * sizeof p);   // warning (good)
  |   ^

[Bug target/96493] powerpc local call linkage failure

[bergner at gcc dot gnu.org]

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

--- Comment #1 from Peter Bergner  ---
We will want this backported to GCC 10 too, correct?

[Bug ipa/96502] New: attribute malloc effect lost after inlining

[msebor at gcc dot gnu.org]

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

Bug ID: 96502
   Summary: attribute malloc effect lost after inlining
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The test case below demonstrates that the effect of the malloc function
attribute (as well as others) on subsequent optimizations is lost after a
function declared with it has been inlined.  This came up in the following
discussion:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551526.html

$ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout x.c
void* f (void);

__attribute__ ((malloc, noinline)) int* f0 (void) { return f (); }

void h0 (void)
{
  int *p = f0 ();
  int x = *p;
  int *q = f0 ();
  *q = 0;
  if (*p != x) // folded to false
__builtin_abort ();
}

__attribute__ ((malloc)) int* f1 (void) { return f (); }

void h1 (void)
{
  int *p = f1 ();
  int x = *p;
  int *q = f1 ();
  *q = 0;
  if (*p != x) // not folded
__builtin_abort ();
}


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

__attribute__((noinline, malloc))
f0 ()
{
  int * _3;

   [local count: 1073741824]:
  _3 = f (); [tail call]
  return _3;

}



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

h0 ()
{
   [local count: 1073741824]:
  f0 ();
  f0 (); [tail call]
  return;

}



;; Function f1 (f1, funcdef_no=2, decl_uid=1942, cgraph_uid=3, symbol_order=2)

__attribute__((malloc))
f1 ()
{
  int * _3;

   [local count: 1073741824]:
  _3 = f (); [tail call]
  return _3;

}



;; Function h1 (h1, funcdef_no=3, decl_uid=1945, cgraph_uid=4, symbol_order=3)

h1 ()
{
  int x;
  int _1;
  int * _6;
  int * _7;

   [local count: 1073741824]:
  _7 = f ();
  x_3 = *_7;
  _6 = f ();
  *_6 = 0;
  _1 = *_7;
  if (_1 != x_3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

[Bug c++/96500] enum of underlying type bool does not accept enumerators with integer constant values other than 0 and 1

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #2 from Florian Weimer  ---
I was wrong, conversions from int to bool are supposed to be narrowing, and Two
+ 1 has type int, and getting from there to bool is not permitted in a
converted constant expression.

I still have some concerns about narrowing conversions to bool, but those are
independent of the enum issue.

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

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

--- Comment #5 from Peter Bergner  ---
Fixed on trunk.  Waiting for it to bake there for a day or two before
backporting to the GCC 10 branch.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

rs6000: Don't ICE when spilling an MMA accumulator

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

2020-08-06  Peter Bergner  

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

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

[Bug c++/96500] enum of underlying type bool do not

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Note that here we don't have an enumerator-definition with " =
constant-expression" and that converted constant expressions don't allow
narrowing.

I'd much prefer if this was ill-formed, but probably at the moment it isn't.

[Bug bootstrap/96492] : internal compiler error: Segmentation fault

[townsend at astro dot wisc.edu]

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

--- Comment #4 from Rich Townsend  ---
(In reply to Jakub Jelinek from comment #3)
> Can you run
> gdb --args ./cc1 -quiet -fself-test=../../gcc/gcc/testsuite/selftests
> /dev/null -o /dev/null
> and do
> run
> bt
> ?

[user@6d6cb5609b91 gcc]$ gdb --args ./cc1 -quiet
-fself-test=../../gcc/gcc/testsuite/selftests /dev/null -o /dev/null
GNU gdb (GDB) CentOS (7.0.1-45.el5.centos)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/user/sdk2-tmp/build/gcc-build/gcc/cc1...done.
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in
module /home/user/sdk2-tmp/build/gcc-build/gcc/cc1]
/home/user/sdk2-tmp/build/gcc-build/gcc/.gdbinit:14: Error in sourced command
file:
/home/user/sdk2-tmp/build/gcc/gcc/gdbinit.in:311: Error in sourced command
file:
Undefined command: "alias".  Try "help".
(gdb) run
Starting program: /home/user/sdk2-tmp/build/gcc-build/gcc/cc1 -quiet
-fself-test=../../gcc/gcc/testsuite/selftests /dev/null -o /dev/null
warning: Error disabling address space randomization: Operation not permitted
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7ffe393bf000

Program received signal SIGSEGV, Segmentation fault.
0x7f10b4696ca0 in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x7f10b4696ca0 in strlen () from /lib64/libc.so.6
#1  0x00ac1e79 in get_identifier(char const*) ()
#2  0x009304fd in build_builtin_function(unsigned int, char const*,
tree_node*, int, built_in_class, char const*, tree_node*) ()
#3  0x00c5 in ?? ()
#4  0xb4547c00 in ?? ()
#5  0x01593374 in ix86_builtin_func_args ()
#6  0x0002 in ?? ()
#7  0x00ae in ?? ()
#8  0x0002 in ?? ()
#9  0x0001 in ?? ()
#10 0x in ?? ()

[Bug c++/96501] New: [C++11] Should warn when classes only have copy constructor defined

[nunoplopes at sapo dot pt]

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

Bug ID: 96501
   Summary: [C++11] Should warn when classes only have copy
constructor defined
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunoplopes at sapo dot pt
  Target Milestone: ---

I see a lot of old code that has copy constructors defined, but not move
constructors. This pessimizes code since the definition of the copy constructor
hides the default move constructor.
Would be nice to get a warning for this to recover perf.

```
#include 
using namespace std;

struct foo {
  int a,b,c;
  // expect-warning
  foo(const foo &);
};

foo fn(foo &&f) {
  foo g(move(f));
  return g;
}
```

https://gcc.godbolt.org/z/5r8erG

[Bug c++/96500] New: enum of underlying type bool do not

[fw at gcc dot gnu.org]

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

Bug ID: 96500
   Summary: enum of underlying type bool do not
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

I believe this needs to be accepted:

enum E : bool { One, Two, Three };

See , “If the underlying type is fixed, the
type of each enumerator prior to the closing brace is the underlying type and
the constant-expression in the enumerator-definition shall be a converted
constant expression of the underlying type.”.

Converted constant expressions include integral conversions. Conversion from
int to bool is not a narrowing conversion.  So Three should have the value
true, just like Two.

[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression

[barry.revzin at gmail dot com]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #1 from Barry Revzin  ---
Reduced (https://godbolt.org/z/1bY545):

#include 

// this one is okay
static_assert(std::partial_ordering(std::strong_ordering::less) < 0);

// this one fails with non-constant condition
static_assert(std::partial_ordering(1 <=> 2) < 0);

[Bug c++/96496] Conversion to enum with underlying type bool produces wrong result

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
As a consequence of the
andl$1, %eax
we produce 1 for odd numbers only:

enum E : bool { One, Two };

int
f1 (int x)
{
  return (E) x;
}

int
main ()
{
  if (f1 (6) != 1)
__builtin_abort ();
  if (f1 (7) != 1)
__builtin_abort ();
}

[Bug c++/96499] New: Compare std::variant with int using C++20 <=> occurs internal compiler error

[hewillk at gmail dot com]

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

Bug ID: 96499
   Summary: Compare std::variant with int using C++20 <=> occurs
internal compiler error
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

constexpr auto operator<=>(const auto& v, const auto& u) {
  return std::visit([&u](const auto& t) { return t <=> u; }, v);
}

constexpr std::variant v{1};
static_assert(v < 2);

This will occurs internal compiler error for gcc-trunk.

godbolt link:
https://godbolt.org/z/EcGKc3

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] missed
   |missed optimisation:|optimisation: unnecessary
   |unnecessary compare in  |compare in standard
   |standard algorithms |algorithms

--- Comment #6 from Jakub Jelinek  ---
Should be fixed on the trunk.
As it is essentially a new optimization, not sure if it is a good idea to
backport it, even when it has been a regression on this testcase.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

reassoc: Improve maybe_optimize_range_tests [PR96480]

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

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

   [local count: 79512730]:

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

   [local count: 79512730]:

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

This patch handles those special cases.

2020-08-06  Jakub Jelinek  

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

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

[Bug c++/96498] Wrong location for function first declared as a friend in a template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This happens even if the function has already been declared at namespace scope
prior to the friend declaration in the class template:

__attribute__((nonnull(1))) void foo(void*);

template
struct T {
  friend void foo(void*);
};

void bar()
{
  foo(0);
  T t;
  foo(0);
}

attr.C: In function 'void bar()':
attr.C:11:8: warning: argument 1 null where non-null expected [-Wnonnull]
   11 |   foo(0);
  |^
attr.C:1:34: note: in a call to function 'void foo(void*)' declared 'nonnull'
1 | __attribute__((nonnull(1))) void foo(void*);
  |  ^~~
attr.C:13:8: warning: argument 1 null where non-null expected [-Wnonnull]
   13 |   foo(0);
  |^
attr.C:5:15: note: in a call to function 'void foo(void*)' declared 'nonnull'
5 |   friend void foo(void*);
  |   ^~~
attr.C:12:10: warning: unused variable 't' [-Wunused-variable]
   12 |   T t;
  |  ^

I think the friend in the template should not change anything here, since the
function is already visible.

[Bug c++/96496] Conversion to enum with underlying type bool produces wrong result

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/96498] New: Wrong location for function first declared as a friend in a template

[redi at gcc dot gnu.org]

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

Bug ID: 96498
   Summary: Wrong location for function first declared as a friend
in a template
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct S {
  friend void foo(void*);
};

template
struct T {
  friend void foo(void*);
};

__attribute__((nonnull(1))) void foo(void*);

void bar()
{
  S s;
  foo(0);
  T t;
  foo(0);
}


attr.C: In function 'void bar()':
attr.C:15:8: warning: argument 1 null where non-null expected [-Wnonnull]
   15 |   foo(0);
  |^
attr.C:10:34: note: in a call to function 'void foo(void*)' declared 'nonnull'
   10 | __attribute__((nonnull(1))) void foo(void*);
  |  ^~~
attr.C:17:8: warning: argument 1 null where non-null expected [-Wnonnull]
   17 |   foo(0);
  |^
attr.C:7:15: note: in a call to function 'void foo(void*)' declared 'nonnull'
7 |   friend void foo(void*);
  |   ^~~
attr.C:14:5: warning: unused variable 's' [-Wunused-variable]
   14 |   S s;
  | ^
attr.C:16:10: warning: unused variable 't' [-Wunused-variable]
   16 |   T t;
  |  ^


The first note is fine, it shows the function declaration on line 10, where the
attributes are declared. The friend declaration in struct S doesn't affect
anything.

The second note shows the location as line 7, which is the friend declaration
inside the class template T. Why is the location not line 10 again?

It seems that instantiating T injects the friend into the surrounding namespace
in a different way to the friend declaration in a non-template.

[Bug c++/96497] New: Compare std::variant with int using C++20 <=> is not a constant expression

[hewillk at gmail dot com]

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

Bug ID: 96497
   Summary: Compare std::variant with int using C++20 <=> is not a
constant expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 
#include 

using variant = std::variant;

constexpr auto operator<=>(const variant& v, const auto& u) {
  return std::visit([&u](const auto& t) -> std::partial_ordering { return t <=>
u; }, v);
}

constexpr variant v{1};
static_assert(v < 2);

This fails on gcc 11.0 with:
: In function 'int main()':
:12:19: error: non-constant condition for static assertion
   12 |   static_assert(v < 2);
  | ~~^~~
:12:19: error: '' is not a constant expression

but if I initialize the v with double, it can compile:

constexpr variant v{1.0};
static_assert(v < 2);

godbolt link:
https://godbolt.org/z/eE9c97

[Bug c++/96496] New: Conversion to enum with underlying type bool produces wrong result

[fw at gcc dot gnu.org]

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

Bug ID: 96496
   Summary: Conversion to enum with underlying type bool produces
wrong result
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---

enum E : bool { One, Two };

int
f1 (int x)
{
  return (E) x;
}

The conversion must first be to type bool, according to:

“If the enumeration type has a fixed underlying type, the value is first
converted to that type by integral conversion, if necessary, and then to the
enumeration type.”



And that must produce a comparison against zero:

“A zero value, null pointer value, or null member pointer value is converted to
false; any other value is converted to true.”



Currently, GCC performs a bit mask (at -O2):

_Z2f1i:
movl%edi, %eax
andl$1, %eax
ret

[Bug fortran/96495] New: [gfortran] MERGE does not copy ALLOCATABLE property of derived type

[paul.luck...@rwth-aachen.de]

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

Bug ID: 96495
   Summary: [gfortran] MERGE does not copy ALLOCATABLE property of
derived type
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.luck...@rwth-aachen.de
  Target Milestone: ---

Created attachment 49011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49011&action=edit
proof of concept code

There is a bug in gfortran and I singled out the problem this far:

- a derived type with ALLOCATABLE data 
- a MERGE call
- an operator overloading used as argument to the MERGE call
- ELEMENTAL procedure

it is best to look at the proof of concept codes attached.
There are 4 highlighted code sections which should all yield similar results
but only one works whereas the others are broken.

The bug arises when called using a vector (using the ELEMENTAL feature).


Supplementary information
$ gfortran --version
GNU Fortran (GCC) 10.1.0

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/exports/gcc-10.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.1.0-source/gcc-10.1.0/configure
--enable-languages=c,c++,fortran --enable-checking=release
--disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=gold --prefix=/usr/local/gcc-10.1.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC) 

$ cat /etc/os-release 
NAME="openSUSE Leap"
VERSION="15.1"

[Bug middle-end/32911] Function __attribute__ ((idempotent))

[matthew at wil dot cx]

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

Matthew Wilcox  changed:

   What|Removed |Added

 CC||matthew at wil dot cx

--- Comment #6 from Matthew Wilcox  ---
I actually have a use for a real idempotent function, that is f(f(x)) == f(x).
I think it's different from the behaviour wanted here which is more of an
initialiser functionality.

The concrete example is Linux's compound_head() macro which takes a pointer to
a struct page and returns a pointer to a (potentially different) struct page. 
A page is its own head, and calls to compound_head can be buried inside macros.

So I'd like gcc to know that given this program:

struct page *compound_head(struct page *) __attribute__((idempotent));

int g(struct page *page)
{
struct page *head = compound_head(page);
return page->refcount;
}

int f(struct page *page)
{
struct page *head = compound_head(page);
return g(head);
}

if it inlines g() into f(), it only needs to make one call to compound_head().

[Bug fortran/93826] [OpenMP][OpenACC] Collapsed loop – code silently ignored

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

  Attachment #49006|0   |1
is obsolete||

--- Comment #5 from Iain Buclaw  ---
Created attachment 49010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49010&action=edit
inline memset v2

Slight tweak to the patch to use indirect_ref instead (as mem_ref wasn't
understood either).

Generated code looks a lot more sensible now.

x86_64 -O1:
  // 0..128 = 0
  MEM[(uint128_t *)&D.4341] = 0;
  // 128..192 = 0
  MEM[(ulong *)&D.4341 + 16B] = 0;
  // 0..32 = 12
  D.4341.payload = 12;
  // 64..128 = 18446744073709551615
  D.4341.hook.var1 = 18446744073709551615;
  // 128..160 = 4294967295
  D.4341.hook.var2 = 4294967295;

x86_64 -O2:
  // 0..64 = 12
  MEM  [(void *)&D.4341] = 12;
  // 64..128 = 18446744073709551615
  MEM  [(void *)&D.4341 + 8B] = 18446744073709551615;
  // 128..192 = 4294967295
  MEM  [(void *)&D.4341 + 16B] = 4294967295;

SPARC64 -O1:
  // 0..128 = 0
  MEM[(uint128_t *)&D.1303] = 0;
  // 128..192 = 0
  MEM[(ulong *)&D.1303 + 16B] = 0;
  // 0..32 = 12
  D.1303.payload = 12;
  // 64..128 = 18446744073709551615
  D.1303.hook.var1 = 18446744073709551615;
  // 128..160 = 4294967295
  D.1303.hook.var2 = 4294967295;

SPARC64 -O2:
  // 0..64 = 12, 64..128 = 18446744073709551615
  MEM  [(void *)&D.1048] = 0xc;
  // 128..192 = 18446744069414584320
  MEM  [(void *)&D.1048 + 16B] = 18446744069414584320;

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[jakub at gcc dot gnu.org]

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

--- Comment #44 from Jakub Jelinek  ---
Sorry if my comment sounded harsh.
Anyway, the older issue I was referring to was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 with SPEC2k6 464.h264ref.

[Bug middle-end/95499] ICE: during GIMPLE pass: ssa / segfault in verify_ssa / OpenMP target with deferred-length CHARACTER

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  ---
For 'character(len=:),allocatable :: str' there is '_str' with the string
length. 

One can map it explicitly when mapping 'from(str)' by also mapping
'firstprivate(_str)' but the compiler will later remove it as '_str' is
(initially) unused.
Later, gfc_omp_clause_default_ctor is called for 'private(str) – the generated
tree uses "malloc(max(1, _str))", but at that point is too late for the mapping
analysis – hence, '_str' is not mapped. Note: gfc_omp_finish_clause is not
called for 'str' and '_str' is not yet used at this point.

This has to be supported for a scalar 'str', an array str, and either as
derived-type component. (For the latter, see also PR95837 for kind=4 issues.)

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

[vries at gcc dot gnu.org]

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

Bug ID: 96494
   Summary: [nvptx] Enable effective target sync_int_long
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The effective target sync_int_long currently doesn't include nvptx.

Consequently, when running gcc.dg/ia64-sync-*.c, we get "UNSUPPORTED".

If we add nvptx to sync_int_long, those tests pass.

AFAICT, from the point of view of the PTX isa, there's no reason why we
couldn't support this.

So, unless a testsuite run points to some problem, we should enable the
sync_int_long for nvptx.

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[rguenth at gcc dot gnu.org]

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

--- Comment #43 from Richard Biener  ---
(In reply to john henning from comment #42)
> A comment, an invitation, and some questions from one of those "SPEC people".
> 
> The comment: 
> 
> SPEC CPU starts from real applications (rather than artificial kernels). 
> Therefore, yes, it begins with code that includes practices that are less
> than perfect - including standards violations and mistakes in numerical
> methods.  
> 
> SPEC then weeds out benchmark candidates when they are discovered to be
> inadequate.  Many have been weeded out due to numerical malpractice, when
> they cannot be relied upon to produce correct answers within some predefined
> tolerance.  
> 
> The remaining candidates get pushed toward the standard, get pushed toward
> better numerical practices.
> 
> But all this is driven by testing.   If there's nobody pushing hard on
> compiler X advanced optimization feature Y, and if Y quietly relies on
> source code to be virtuous as regards Z, it is entirely possible that sins
> against virtue Z will escape notice until after release of a SPEC benchmark
> suite.
> 
> Pre-release, fixes are easy to sponsor and apply.   Post-release, it is much
> harder, because of SPEC's preference for "no moving targets". 
> 
> The invitation:
> 
> Thus I would invite any of the individuals who commented about "those SPEC
> people" to consider becoming one, and helping with the testing of benchmark
> candidates for the next benchmark suite.  SPEC has a mechanism to accept
> free volunteer labor :-) and if you would like to volunteer, please write to
> info at SPEC dot org.  If you like, you could mention my name and this bug
> when you do.

Thanks.  But all testing effort is limited.  We do test SPEC before the
release (but I am not aware that sources are available freely before
release - I mean, including the data and scripts).  But the issue required
flags to be reproduced that we didn't test in time.  A full review of
the source packages is of course not possible.

> The questions:
> 
> (q1) Do I correctly gather that the fix described here would have gone into
> GCC 8?

Yes.

> (q2) On aarch64 with GCC 8.2, GCC 9.3, and GCC 10.1 (Red Hat 7.8, glibc
> 2.17-307.0.2.el7.1) I am seeing the following 628.pop2_s miscompare and
> abort.  Is this the same problem or a different problem as the one described
> in this bug?
> 
> Miscompare:
>1513:Chlorophyll transmission table computed
>Could not find range for chlamnt =  1.E-03
> 
> Abort: 
> 
>Contents of pop2_s.err
>
>Note: The following floating-point exceptions are signalling:
> IEEE_UNDERFLOW_FLAG
>
>POP aborting...
>  set_chl_trans range error for chlamnt

It looks like the same issue, yes.

> (q3) The text mentions that -funsafe-math-optimizations as a workaround. 
> Was this tested?  Was it narrowed to any of the components of
> -funsafe-math-optimizations which apparently are -fno-signed-zeros,
> -fno-trapping-math, -fassociative-math and -freciprocal-math?  
> 
> I am just about to start such testing on my aarch64 system, but if someone
> has already done such, it would be useful to know.

I'm not aware that anyone tried to narrow down a workaround.

> (q4) *Is* there a proposed patch for 628.pop2_s?   Although such may be
> unlikely to be applied to CPU 2017, it is conceivable that there might be an
> updated version of 628.pop2_s in a future suite.  So, it would be good to
> have the proposed patch on record.

>From what I understand the proposed workaround is something like the
following if not rewriting the problematic loop in another way.

diff --git a/benchspec/CPU/628.pop2_s/src/sw_absorption.F90
b/benchspec/CPU/628.pop2_s/src/sw_absorption.F90
index 1aa25904..489e88f2 100644
--- a/benchspec/CPU/628.pop2_s/src/sw_absorption.F90
+++ b/benchspec/CPU/628.pop2_s/src/sw_absorption.F90
@@ -134,7 +134,7 @@

real (r8), parameter, dimension(nchl) :: &!chl for table look-up
  chlcnc = (/&
- .001_r8, .005_r8, .01_r8,  .02_r8, &
+ .000_r8, .005_r8, .01_r8,  .02_r8, &
  .03_r8,  .05_r8,  .10_r8,  .15_r8, &
  .20_r8,  .25_r8,  .30_r8,  .35_r8, &
  .40_r8,  .45_r8,  .50_r8,  .60_r8, &

[Bug target/96347] note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

  Attachment #48953|0   |1
is obsolete||

--- Comment #5 from Iain Buclaw  ---
Created attachment 49009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49009&action=edit
favour tls_mem_loc_descriptor

Patch leaves delegitimize alone and instead plugs the warning in dwarf2out.c. 
If MEM is a TLS reference, then try tls_mem_loc_descriptor() first.

No observed changes in either assembly or debug as a result of the patch.

[Bug bootstrap/96492] : internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Can you run
gdb --args ./cc1 -quiet -fself-test=../../gcc/gcc/testsuite/selftests /dev/null
-o /dev/null
and do
run
bt
?

[Bug bootstrap/96492] : internal compiler error: Segmentation fault

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
(In reply to Richard Biener from comment #1)
> Did GCC 10.1 work or any older version you tried to build this way in the
> past?

It's worked in 9.2, 9.3, and earlier releases; but not in 10.1.

If I try the build outside the Docker container, it works fine. So, there's
something about the Centos 5.11 toolchain/libraries that make it break.

[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare

[mailboxnotfound at yahoo dot com]

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

john henning  changed:

   What|Removed |Added

 CC||mailboxnotfound at yahoo dot 
com

--- Comment #42 from john henning  ---
A comment, an invitation, and some questions from one of those "SPEC people".

The comment: 

SPEC CPU starts from real applications (rather than artificial kernels). 
Therefore, yes, it begins with code that includes practices that are less than
perfect - including standards violations and mistakes in numerical methods.  

SPEC then weeds out benchmark candidates when they are discovered to be
inadequate.  Many have been weeded out due to numerical malpractice, when they
cannot be relied upon to produce correct answers within some predefined
tolerance.  

The remaining candidates get pushed toward the standard, get pushed toward
better numerical practices.

But all this is driven by testing.   If there's nobody pushing hard on compiler
X advanced optimization feature Y, and if Y quietly relies on source code to be
virtuous as regards Z, it is entirely possible that sins against virtue Z will
escape notice until after release of a SPEC benchmark suite.

Pre-release, fixes are easy to sponsor and apply.   Post-release, it is much
harder, because of SPEC's preference for "no moving targets". 

The invitation:

Thus I would invite any of the individuals who commented about "those SPEC
people" to consider becoming one, and helping with the testing of benchmark
candidates for the next benchmark suite.  SPEC has a mechanism to accept free
volunteer labor :-) and if you would like to volunteer, please write to info at
SPEC dot org.  If you like, you could mention my name and this bug when you do.

The questions:

(q1) Do I correctly gather that the fix described here would have gone into GCC
8?

(q2) On aarch64 with GCC 8.2, GCC 9.3, and GCC 10.1 (Red Hat 7.8, glibc
2.17-307.0.2.el7.1) I am seeing the following 628.pop2_s miscompare and abort. 
Is this the same problem or a different problem as the one described in this
bug?

Miscompare:
   1513:Chlorophyll transmission table computed
   Could not find range for chlamnt =  1.E-03

Abort: 

   Contents of pop2_s.err
   
   Note: The following floating-point exceptions are signalling:
IEEE_UNDERFLOW_FLAG
   
   POP aborting...
 set_chl_trans range error for chlamnt

(q3) The text mentions that -funsafe-math-optimizations as a workaround.  Was
this tested?  Was it narrowed to any of the components of
-funsafe-math-optimizations which apparently are -fno-signed-zeros,
-fno-trapping-math, -fassociative-math and -freciprocal-math?  

I am just about to start such testing on my aarch64 system, but if someone has
already done such, it would be useful to know.

(q4) *Is* there a proposed patch for 628.pop2_s?   Although such may be
unlikely to be applied to CPU 2017, it is conceivable that there might be an
updated version of 628.pop2_s in a future suite.  So, it would be good to have
the proposed patch on record.

[Bug c/96427] Missing align attribute for anchor section from local variables

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to vfdff from comment #4)
> I test your case base on x86-64 gcc 10.1 with -O2 -S -mavx512f, the .rodata
> aligned to 64 bytes, and it aligned to 32 bytes on x86-64 gcc 9.3 with -O2
> -S -mavx512f, i.e. it have different behaviour base on different gcc version.
> 
> so it is a undefined behaviour ?

Well, it's an optimization so it's unspecified, not undefined behavior.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.  Thanks for the report!

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail|11.0|10.2.0
 Resolution|--- |FIXED
  Known to work||10.2.1, 11.0
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Richard Biener  ---
Fixed.

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

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

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

2020-08-06  Richard Biener  

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

(cherry picked from commit 1f4c8afa1b2dac97f2ee78eacafe6eee246a4dae)

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

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

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

2020-08-06  Richard Biener  

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

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

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

[cvs-commit at gcc dot gnu.org]

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

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

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

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

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

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

2020-08-06  Richard Biener  

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

[Bug debug/96471] ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Created attachment 49008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49008&action=edit
hackish patch

The following implements this (just the very special case of a single location
expression with a direct DIE ref).  It also re-orders note_variable_value
which might be an obvious part.

Now the question is whether such a type unit makes sense:

 <0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
<18>   DW_AT_language: 14   (Fortran 95)
<19>   DW_AT_stmt_list   : 0x0
 <1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e>   DW_AT_name: (indirect string, offset: 0x1d0):
FRAME.cmumps_sc
atter_dist_rhs
<22>   DW_AT_byte_size   : 32
<23>   DW_AT_sibling : <0x58>
 <2><27>: Abbrev Number: 3 (DW_TAG_member)
<28>   DW_AT_name: (indirect string, offset: 0x1b6):
posinrhscomp_fw
d
<2c>   DW_AT_decl_file   : 1
<2d>   DW_AT_decl_line   : 1
<2e>   DW_AT_type: <0x58>
<32>   DW_AT_data_member_location: 0
...
 <1><58>: Abbrev Number: 4 (DW_TAG_restrict_type)
<59>   DW_AT_type: <0x64>
...
 <1><64>: Abbrev Number: 6 (DW_TAG_pointer_type)
<65>   DW_AT_byte_size   : 8
<66>   DW_AT_type: <0x70>
...
 <1><70>: Abbrev Number: 8 (DW_TAG_array_type)
<71>   DW_AT_type: <0x83>
<75>   DW_AT_sibling : <0x83>
 <2><79>: Abbrev Number: 9 (DW_TAG_subrange_type)
<7a>   DW_AT_type: <0x8a>
<7e>   DW_AT_upper_bound : <0x9a>
...
 <1><91>: Abbrev Number: 11 (DW_TAG_subprogram)
<92>   DW_AT_external: 1
<92>   DW_AT_name: (indirect string, offset: 0x1e):
cmumps_scatter_dist_rhs
<96>   DW_AT_linkage_name: (indirect string, offset: 0x5c):
cmumps_scatter_dist_rhs_
<9a>   DW_AT_declaration : 1
 <2><9a>: Abbrev Number: 12 (DW_TAG_variable)
<9b>   DW_AT_type: <0x8a>
<9f>   DW_AT_artificial  : 1

[Bug debug/96471] ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So the DIEs in question are

DIE0: DW_TAG_subrange_type (0x769f3e10)
  abbrev id: 0 offset: 0 mark: 1
  DW_AT_type: die -> 0 (0x769f3eb0)
  DW_AT_upper_bound: die -> 0 (0x769f30f0)

refering to

DIE0: DW_TAG_variable (0x769f30f0)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_type: die -> 0 (0x769d1d70)
  DW_AT_artificial: 1

where the subrange type is part of a type unit.

I think type units do not work this way and a type die like this should
disqualify the whole thing from becoming externalized into a type unit in the
first place?  There is should_move_die_to_comdat which already excludes
DIEs containing subprogram definitions, shouldn't all references to
non-type non-declaration DIEs also prevent a DIE from being externalized?

So for the specific case that's too early(?), after comdat breakout we still
see

DIE0: DW_TAG_array_type (0x769f8140)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_type: die -> 0 (0x769f8000)
DIE0: DW_TAG_subrange_type (0x769f8190)
  abbrev id: 0 offset: 0 mark: 0
  DW_AT_type: die -> 0 (0x769f8050)
  DW_AT_upper_bound: location descriptor:
(0x769d1eb0) DW_OP_GNU_variable_value die -> 0
(0x769f30f0), 0

but then resolve_addr this into a direct DIE ref which eventually
copy_decls_walk would handle.  There's also note_variable_value
doing some location frobbing from decls to DIEs which is done after
comdat breakout and which would expose more such situations, so
re-ordering that would make sense.  Note I think
that even location lists are unwanted in type units.  Unfortunately
the DWARF standard doesn't list what is and what is not allowed in type
units.  Eventually one could strip the type unit off those unsupported
constructs and instead "complete" them in the main unit somehow.

Since resolve_addr runs only at dwarf2out_finish time we need to look
at the location case either disqualifying stuff or doing magic in
copy_decls_for_unworthy_types.

[Bug fortran/93826] [OpenMP][OpenACC] Collapsed loop – code silently ignored

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
Missed to list the PR in the commit :-(

* OpenMP 4.5 patch which rejects this is the following:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551338.html
and https://gcc.gnu.org/g:57dd9f3bfca8bb752c630431dc033c761e2ad382 (= r11-2553)

→ FIXED for OpenMP (4.5)
-
Tue, 4 Aug 2020 16:17:53 + (18:17 +0200)
Fortran/OpenMP: Fix detecting not perfectly nested loops

gcc/fortran/ChangeLog:

* openmp.c (resolve_omp_do): Detect not perfectly
nested loop with innermost collapse.

gcc/testsuite/ChangeLog:

* gfortran.dg/gomp/collapse1.f90: Add dg-error.
* gfortran.dg/gomp/collapse2.f90: New test.
-


TODO:

* OpenMP 5.x permits this (see also review comment)

* OpenACC: Still needs to be rejected

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1185r2.html

Your understanding of <=> is from 2018, that's not how C++20 works.

[Bug c++/96490] Template code with function pointers fails with very cryptic error message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-06
 Ever confirmed|0   |1
   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW

[Bug fortran/96486] get_environment_variable fails for zero-length values

[jussilehtola at fedoraproject dot org]

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

--- Comment #13 from Susi Lehtola  ---
The gdb output is the same

(gdb) r
Starting program: /tmp/a.out 
Fortran runtime error: Zero-length string passed as value to
get_environment_variable.

Error termination. Backtrace:
#0  0x401267 in zerolen_value
at /tmp/readvar2.f90:17
#1  0x4012c4 in main
at /tmp/readvar2.f90:22
[Inferior 1 (process 122282) exited with code 02]

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

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I have a simple patch.

[Bug bootstrap/96492] : internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Did GCC 10.1 work or any older version you tried to build this way in the past?

[Bug fortran/96486] get_environment_variable fails for zero-length values

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #12 from markeggleston at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> I do note there are other problems with get_environment_variable.

It looks to me that this intrinsic supports the Fortran 2003 standard. Changes
were introduced with the Fortran 2018 and support has not yet been implemented.

> 
> 1) Neither length nor status can be integer(1).  gfortran should issue
>an error.

Fortran 2003 has default kind for these arguments.

> 
> 2) Fortran 2018 has added an optional errmsg argument.  This is not
>supported.
> 
> 3) gfortran is issuing errors that don't make sence (to me).
> 
> program foo
>integer( 1) i01
>integer( 2) i02
>integer( 4) i04
>integer( 8) i08
> #ifdef __GFC_INT_16__
>integer(16) i16
> #endif
>character(len=20) name
> 
>print '(A,I0)', 'range(i01) = ', range(i01)
>print '(A,I0)', 'range(i02) = ', range(i02)
>print '(A,I0)', 'range(i04) = ', range(i04)
>print '(A,I0)', 'range(i08) = ', range(i08)
> #ifdef __GFC_INT_16__
>print '(A,I0)', 'range(i16) = ', range(i16)
> #endif
> 
>name = ''
>! Although valid Fortran, this should probably raise a warning.
>call get_environment_variable(name);
> 
>name = 'FOO'
>call get_environment_variable(name,length=i01);  ! Should be an error
>call get_environment_variable(name,length=i02);  ! Should be ok
>call get_environment_variable(name,length=i04);  ! Should be ok
>call get_environment_variable(name,length=i08);  ! Should be ok
> #ifdef __GFC_INT_16__
>call get_environment_variable(name,length=i16);  ! Should be ok
> #endif
> 
> end program foo
> 
> mobile:kargl[256] gfcx -o z a.F90 && ./z
> a.F90:29:45:
> 
>29 |call get_environment_variable(name,length=i01);  ! Should be an
> error
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(1)' to 'INTEGER(4)'
> a.F90:30:45:
> 
>30 |call get_environment_variable(name,length=i02);
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(2)' to 'INTEGER(4)'
> a.F90:32:45:
> 
>32 |call get_environment_variable(name,length=i08);
>   | 1
> Error: In call to 'get_environment_variable' at (1), type mismatch in
> argument length'; pass 'INTEGER(8)' to 'INTEGER(4)'

The mismatch errors are consistent with Fortran 2003 support.

I think these issues should be in a separate PR for Fortran 2018 support.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.0
   Last reconfirmed||2020-08-06

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/96487] cddce1 optimizer depends on order of basic blocks

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-06
 Ever confirmed|0   |1
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
I think the issue is that control dependence looks different - for C the latch
is control dependent on itself while for C++ it ends up being control dependent
on the outgoing edges from the conditional that ends up being marked necessary.
I guess both answers are somewhat "wrong" but it boils down to the
testcase not having any edges to exit and thus post-dominance being somewhat
ill-defined.  Doing connect_infinite_loops_to_exit () doesn't help because
that as well makes different decisions based on the BB order.

So the question is whether DCE should do sth different than marking
control dependent edges of each non-finites loop latch, especially in
the case where the loop has no exit (if there are exits we should get
to the "first" exit test - that's the whole idea here).  That is,
if there's no exit maybe simply mark the latch as bb_contains_live_stmts?

diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index fae5ae72340..a66fc34c9e5 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -450,7 +450,10 @@ find_obviously_necessary_stmts (bool aggressive)
  {
if (dump_file)
  fprintf (dump_file, "cannot prove finiteness of loop %i\n",
loop->num);
-   mark_control_dependent_edges_necessary (loop->latch, false);
+   if (loop->exits->next->e)
+ mark_control_dependent_edges_necessary (loop->latch, false);
+   else
+ bitmap_set_bit (bb_contains_live_stmts, loop->latch->index);
  }
 }
 }

[Bug target/96493] powerpc local call linkage failure

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-06
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug c++/96485] [9/10/11 Regression] Lambda parsing regression in GCCs 9 and onwards

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |9.3.1
   Keywords||rejects-valid
  Known to work||8.3.0
  Known to fail||9.1.0
   Target Milestone|--- |9.4
Summary|Lambda parsing regression   |[9/10/11 Regression] Lambda
   |in GCCs 9 and onwards   |parsing regression in GCCs
   ||9 and onwards