[Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 --- Comment #1 from Willy Tarreau --- Re-reading godbolt's version more closely, it's just 1 day old (I thought I read 20201010) so the issue is still valid.
[Bug c/98503] New: [11 regression] -Warray-bounds false positive with global variables at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503
Bug ID: 98503
Summary: [11 regression] -Warray-bounds false positive with
global variables at -O2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: w at 1wt dot eu
Target Milestone: ---
First, please note that I saw a handful of related reports but couldn't judge
if this one might be merged with another one; if you think it can, feel free to
do so!
We've had build errors reported on haproxy with gcc-11 due to walking over a
list whose head is in a global variable. We could simplify the reproducer to
this and confirm it on godbolt.org:
#include
struct list {
struct list *n;
struct list *p;
};
struct list head;
struct ref {
struct list list;
char *filename;
};
struct list *first(void)
{
struct ref *tmp;
/*tmp = (struct ref *)((char *) - (size_t)&((struct ref
*)0)->list);*/
tmp = (struct ref *)
//asm("" : "+rm"(tmp)); // hide tmp's origin to shut the warning.
//asm("" : "=rm"(tmp) : "0"()); // discretely assign tmp from head
return tmp->list.n;
}
Note that only the "ref->list" part is accessed here, hence it exactly matches
"head" (both of type struct list). But since gcc 11 (and only this one, 1.27 to
10.2 are OK), we're getting this:
: In function 'first':
:22:19: warning: array subscript 'struct ref[0]' is partly outside
array bounds of 'struct list[1]' [-Warray-bounds]
22 | return tmp->list.n;
| ^~
:8:13: note: while referencing 'head'
8 | struct list head;
| ^~~~
Compiler returned: 0
Changing "head" to a function argument makes the warning disappear, building at
-O1 as well, and obviously, cheating with the asm statement to hide "tmp"
solves it (though it degrades the code quality).
Removing the unused "filename" from struct "ref" removes the warning. It looks
to me as if the compiler doesn't know what part of a structure is being
dereferenced when we access any member, making the warning systematically bogus
for embedded members accessed via container_of() and friends when the list's
head is global.
For now we can disable the warning, I've confirmed the generated code is
correct, but since it's the first time we have a false positive on this one,
I'd prefer if we can keep it as much as possible as it's one which can
definitely help spot real bugs.
I've just verified the version used on godbolt.org, it's "gcc version 11.0.0
20210101 (experimental) (Compiler-Explorer-Build)". I haven't rebuilt the trunk
locally so it might be possible this bug got solved since as part of one of the
few related ones.
Thanks!
Willy
[Bug c/98502] New: Optimised memcpy breaks __scalar_storage_order__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98502
Bug ID: 98502
Summary: Optimised memcpy breaks __scalar_storage_order__
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noring at nocrew dot org
Target Milestone: ---
Compiling with -O1 or greater breaks __scalar_storage_order__ with memcpy. The
expected output of the test program below (sso.c) is "1234" but "3412" is
produced with compiler optimisations:
% gcc -Wall -o sso sso.c && ./sso
1234
% gcc -Wall -O1 -o sso sso.c && ./sso
3412
sso.c:
#include
#include
#include
int main()
{
const uint8_t b[] = { 0x12, 0x34 };
struct __attribute__(( __scalar_storage_order__("big-endian") )) {
uint16_t word;
} s;
memcpy(, b, sizeof(s));
printf("%04x\n", s.word);
}
[Bug c++/98501] New: potential optimization for base<->derived pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98501
Bug ID: 98501
Summary: potential optimization for base<->derived pointer
casts
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Consider this code:
struct base1 { int a; };
struct base2 { int b; };
struct derived : base1, base2 {};
derived& to_derived_bad(base2* b)
{
return *static_cast(b);
}
derived& to_derived_good(base2* b)
{
return static_cast(*b);
}
I believe both of these functions are functionally equivalent and should
generate the same code. Both functions cast pointer from base to derived if it
is not nullptr and both cause undefined behavior if it is nullptr.
GCC optimizes to_derived_good() to a single subtraction, but it inserts
nullptr-check into to_derived_bad():
to_derived_good(base2*):
lea rax, [rdi-4]
ret
to_derived_bad(base2*):
lea rax, [rdi-4]
test rdi, rdi
mov edx, 0
cmove rax, rdx
ret
Could GCC omit the nullptr-check in to_derived_bad?
[Bug c++/95768] [11 Regression] -march=sandybridge -O2 -Wall crashes as 'during GIMPLE pass: uninit ... Segmentation fault'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95768 --- Comment #8 from Martin Sebor --- Updated patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562665.html
[Bug c++/98499] [11 Regression] Possibly bad std::string initialization in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
--- Comment #1 from Sergei Trofimovich ---
Managed to get rid of external dependency:
```
struct string {
char * _M_buf;
// local store
char _M_local_buf[16];
string(const string &__str) : _M_buf(_M_local_buf) {}
string(const char *__s) : _M_buf(_M_local_buf) {}
~string() {
if (_M_buf != _M_local_buf)
__builtin_trap();
}
// not defined
string();
};
// main.cc
__attribute__((noinline)) static string dir_name() { return "c"; }
__attribute__((noinline)) static string make_canonical_path(string path) {
return path;
}
class Importer {
public:
string imp_path;
string ctx_path;
string base_path;
public:
__attribute__((noinline)) Importer(string imp_path, string ctx_path)
: imp_path(make_canonical_path(imp_path)),
ctx_path(make_canonical_path(ctx_path)), base_path(dir_name()) {}
};
struct Include {
Include(const Importer ) {}
};
int main() { const Include = {{"a", "b"}}; }
```
Note: all our string() constructors shoudl have `_M_buf == _M_local_buf`
invariant. But gcc-11 generates always-crashing program:
```
; g++-11.0.0 -O2 -std=c++11 -S main.cc
main:
.cfi_startproc
subq$152, %rsp
.cfi_def_cfa_offset 160
movq%fs:40, %rax
movq%rax, 136(%rsp)
xorl%eax, %eax
leaq8(%rsp), %rax
movq%rsp, %rsi
leaq32(%rsp), %rdx
movq%rax, (%rsp)
leaq64(%rsp), %rdi
leaq40(%rsp), %rax
movq%rax, 32(%rsp)
call_ZN8ImporterC1E6stringS0_
ud2
```
[Bug c++/80016] error is positioned incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80016 Ivan Sorokin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Ivan Sorokin --- (In reply to Jonathan Wakely from comment #5) > I'd even argue the stating location still isn't right in this version, as > the error comes from ns::trait::value not the logical expression > containing it. On GCC 10.2 the error location is very nice: :13:46: error: incomplete type 'ns::trait' used in nested name specifier 13 | && ns::trait::value; | ^ https://godbolt.org/z/E7P7P8 I believe the bug can be considered fixed now. Thank you!
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
--- Comment #7 from Steve Kargl ---
On Sat, Jan 02, 2021 at 04:12:27AM +, jvdelisle at charter dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
>
> --- Comment #5 from Jerry DeLisle ---
> Patch regresses several test cases.
>
This regresses okay.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 14361a10f68..b860f7eaa26 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2537,7 +2537,9 @@ gfc_conv_substring (gfc_se * se, gfc_ref * ref, int kind,
if (!CONSTANT_CLASS_P (tmp) && !DECL_P (tmp))
end.expr = gfc_evaluate_now (end.expr, >pre);
- if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+ if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+ && (ref->u.ss.start->symtree
+ && !ref->u.ss.start->symtree->n.sym->attr.implied_index))
{
tree nonempty = fold_build2_loc (input_location, LE_EXPR,
My test program without the dejagnu stuff.
program test
implicit none
call sub('Lorem ipsum')
contains
subroutine sub( text )
character(len=*), intent(in) :: text
character(len=1), allocatable ::c(:)
integer :: i
c = [ ( text(i:i), i = 1, len(text) ) ]
if (c(1) /= 'L') stop 1
end subroutine sub
end program test
[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 --- Comment #7 from Steve Kargl --- On Sat, Jan 02, 2021 at 07:53:17PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 > > --- Comment #6 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #5) > >If the ENTRY statement is in a subroutine subprogram, an additional > >subroutine is defined by that subprogram. The name of the subroutine > >is entry-name. The dummy arguments of the subroutine are those > >specified in the ENTRY statement > > Well, I stumbled over the "additional subroutine". > > I assume that the "additional subroutine" wouldn't exist without the > containing > subprogram in the first place. Maybe a consultation of c.l.f. could help. > Not sure what you think clf will provide. Seems clear to me that subroutine volatile_test() integer, volatile :: va entry fun_a() return entry fun_b(va) call fun_c() return end subroutine volatile_test is equivalent subroutine volatile_test() integer, volatile :: va return call fun_c() return end subroutine volatile_test subroutine fun_a() integer, volatile :: va return call fun_c() return end subroutine fun_a() subroutine fun_b(va) integer, volatile :: va call fun_c() return end subroutine fun_b Here, only fun_b() requires an explicit interface if it is used in another scoping unit. AFAICT, a programmer is required to add interface subroutine fun_b(va) integer, volatile :: va end subroutine fun_b end interface to that scoping unit.
[Bug fortran/96986] [8/9/10/11 Regression] Explicit interface required: volatile argument for ENTRY subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96986 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #5) >If the ENTRY statement is in a subroutine subprogram, an additional >subroutine is defined by that subprogram. The name of the subroutine >is entry-name. The dummy arguments of the subroutine are those >specified in the ENTRY statement Well, I stumbled over the "additional subroutine". I assume that the "additional subroutine" wouldn't exist without the containing subprogram in the first place. Maybe a consultation of c.l.f. could help.
[Bug tree-optimization/98393] [11 Regression] valgrind error for ./gcc.target/m68k/pr52573.c since r11-5928-gfc7b4248172561a9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98393
--- Comment #10 from David Binderman ---
Reduced test case:
typedef struct {
short a;
struct {
unsigned short b;
unsigned short c
} d[]
} e;
enum { f, g, h, i };
e j;
char k, l;
e *m;
void n(void) {
int o;
char *q, *r = 0, *s, *t, *p =
for (; *p; ++p)
switch (o) {
case f:
o = s = p;
case g:
switch (*p) {
case '@':
t = p;
o = h;
}
break;
case h:
q = p;
case i:
if (p == '#')
r = p;
}
j.d[0].b = q -
j.d[0].c = r - q;
if (s) {
j.d[0].b = s -
j.d[0].c = t - s;
}
if (m)
j.d[0].b = j.d[0].c = l;
}
[Bug tree-optimization/95771] Failure to optimize popcount idiom when argument is unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95771 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-01-02 --- Comment #1 from Jakub Jelinek --- Created attachment 49868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49868=edit gcc11-pr95771.patch Untested fix.
[Bug web/32927] Online installation instructions only for mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927 Gerald Pfeifer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Gerald Pfeifer --- I dislike it when it appears to reports of mine, still allow me to close this as WONTFIX since it's very unlikely to ever be addressed if it hasn't for 13 years (and it's more of an enhancement, not a critical issue). If anyone wants to give it a go, embedding invocations of gcc/doc/install.texi2html into maintainer-scripts/update_web_docs_git probably is the way to go.
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 --- Comment #3 from Svante Signell --- On Sat, 2021-01-02 at 17:49 +, doko at debian dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496 > > Matthias Klose changed: > >What|Removed |Added > --- > - > Status|RESOLVED|UNCONFIRMED > Resolution|FIXED |--- > > --- Comment #2 from Matthias Klose --- > now fails with: > > ../../../src/libgo/go/crypto/x509/root_unix.go:52:17: error: > reference to > undefined name 'certDirectories' >52 | dirs := certDirectories > | ^ I'm onto it. Patch will follow soon. A simple fix if this is the only issue. Thanks!
[Bug target/98461] Suboptimal codegen for negating a movemask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98461 --- Comment #8 from Denis Yaroshevskiy --- Thank you for the fast fix. I can already see that the code is in trunk and works for both 256 and 128 bit registers. 256: https://godbolt.org/z/5sT48f 128: https://godbolt.org/z/Exo3d9 I am a bit confused as to why 128 bit codegen differs in two cases but both seem to be reasonable at glance.
[Bug go/98496] [11 Regression] bootstrap broken in libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
Matthias Klose changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED |---
--- Comment #2 from Matthias Klose ---
now fails with:
../../../src/libgo/go/crypto/x509/root_unix.go:52:17: error: reference to
undefined name 'certDirectories'
52 | dirs := certDirectories
| ^
../../../src/libgo/go/crypto/x509/root_unix.go:61:9: error: range clause must
have array, slice, string, map, or channel type
61 | for _, directory := range dirs {
| ^
../../../src/libgo/go/crypto/x509/root_unix.go:61:13: error: invalid type for
range clause
61 | for _, directory := range dirs {
| ^
Makefile:2962: recipe for target 'crypto/x509.lo' failed
make[6]: *** [crypto/x509.lo] Error 1
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-01-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least GCC7 up to GCC11.
[Bug bootstrap/98493] [11 regression] bootstrap build fails in go part of build after r11-6371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98493 seurer at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED Last reconfirmed||2021-01-02 --- Comment #2 from seurer at gcc dot gnu.org --- I am still seeing build errors: libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/gccgo -B/home/seurer/gcc/git/build/gcc-test/./gcc/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include -O2 -g -I . -c -fgo-pkgpath=internal/cpu /home/seurer/gcc/git/gcc-test/libgo/go/internal/cpu/cpu.go /home/seurer/gcc/git/gcc-test/libgo/go/internal/cpu/cpu_no_name.go /home/seurer/gcc/git/gcc-test/libgo/go/internal/cpu/cpu_ppc64x_linux.go cpugen.go -fPIC -o internal/.libs/cpu.o /home/seurer/gcc/git/gcc-test/libgo/go/internal/cpu/cpu.go:123:9: error: reference to undefined name 'doinit' 123 | doinit() | ^ /home/seurer/gcc/git/gcc-test/libgo/go/internal/cpu/cpu_ppc64x_linux.go:26:26: error: reference to undefined name 'isSet' 26 | PPC64.IsPOWER9 = isSet(HWCap2, hwcap2_ARCH_3_00) | ^ /home/seurer/gcc/git/gcc-test/libgo/go/internal/cpu/cpu_ppc64x_linux.go:27:25: error: reference to undefined name 'isSet' 27 | PPC64.HasDARN = isSet(HWCap2, hwcap2_DARN) | ^ /home/seurer/gcc/git/gcc-test/libgo/go/internal/cpu/cpu_ppc64x_linux.go:28:24: error: reference to undefined name 'isSet' 28 | PPC64.HasSCV = isSet(HWCap2, hwcap2_SCV) |^ make[4]: *** [internal/cpu.lo] Error 1
[Bug tree-optimization/96921] Failure to optimize combined boolean not patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96921
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
On:
_Bool
foo (_Bool a, _Bool b)
{
int c = 1 - a;
int d = 1 - b;
int e = c & d;
return 1 - e;
}
_Bool
bar (_Bool a, _Bool b)
{
int c = 1 - a;
int d = 1 - b;
_Bool e = c & d;
return 1 - e;
}
_Bool
baz (_Bool a, _Bool b)
{
_Bool c = 1 - a;
_Bool d = 1 - b;
_Bool e = c & d;
return 1 - e;
}
we are able to optimize just baz. Rather than duplicating the bit_not vs.
bit_and/bit_ior etc. simplifications, I wonder if it wouldn't be better to
perform type demotion here, see that 1 - x is used in a boolean context and
that
x is ssa_name_has_boolean_range and turn that into bit_not on _Bool. Similarly
for the bit_and/ior/xor whose result is used in a boolean context and where
both operands are ssa_name_has_boolean_range. Thoughts on that?
[Bug c++/98500] New: ICE template template parameter with default parameter lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98500
Bug ID: 98500
Summary: ICE template template parameter with default parameter
lambda
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bastien.penavayre at epitech dot eu
Target Milestone: ---
The following causes an ICE:
template struct X {};
template class H = X, class = H<>>
struct A
{
};
static_assert(sizeof(A<>));
Message:
:5:24: internal compiler error: in tsubst, at cp/pt.c:15258
5 | template class H = X, class = H<>>
|^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/98499] New: [11 Regression] Possibly bad std::string initialization in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
Bug ID: 98499
Summary: [11 Regression] Possibly bad std::string
initialization in constructors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially bug is observed on a usage crash of libsass-3.6.4. Code snippet
around the crash:
https://github.com/sass/libsass/blob/3.6.4/src/context.cpp#L621
I think I extracted a small example that illustrates the problem:
```c++
// cat main.cc
#include
__attribute__((noinline))
static std::string dir_name() { return "c"; }
__attribute__((noinline))
static std::string make_canonical_path (std::string path) { return path; }
class Importer {
public:
std::string imp_path;
std::string ctx_path;
std::string base_path;
public:
__attribute__((noinline)) Importer(std::string imp_path, std::string
ctx_path)
: imp_path(make_canonical_path(imp_path))
, ctx_path(make_canonical_path(ctx_path))
, base_path(dir_name())
{}
};
struct Include {
Include(const Importer& imp){}
};
int main() {
const Include & inc = {{"a", "b"}};
}
```
g++-11 generates crashing binaries, g++-10 does not:
```
$ g++-11.0.0 -O2 -std=c++11 main.cc -o a-11; ./a-11; echo $?
free(): invalid pointer
Aborted (core dumped)
134
$ g++-10.2.0 -O2 -std=c++11 main.cc -o a-10; ./a-10; echo $?
0
```
I was not able to easily get rid of std::string as it uses something from
libstdc++.so.
Thus I'm not sure where the bug is. My suspictions are:
1. invalid c++
2. std::string implementation bug
3. g++'s code generation problem around lifetimes of temporary values
I suspect `[3.]`.
```
$ g++-11.0.0 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-11.0.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.0.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.0.0/python
--enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 11.0.0_pre p5, commit
12ae2bc70846a2be8255eaa41322cd1a5a7b7350' --disable-esp --enable-libstdcxx-time
--enable-host-shared --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-systemtap
--enable-valgrind-annotations --enable-vtable-verify --with-zstd --enable-lto
--with-isl --disable-isl-version-check --enable-default-pie
--enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201228 (experimental) (Gentoo 11.0.0_pre p5, commit
12ae2bc70846a2be8255eaa41322cd1a5a7b7350)
```
[Bug tree-optimization/96930] Failure to optimize out arithmetic with bigger size when it can't matter with division transformed into right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930 --- Comment #3 from Jakub Jelinek --- I guess it could be either optimized using a match.pd pattern like we have for: /* Convert (outertype)((innertype0)a+(innertype1)b) into ((newtype)a+(newtype)b) where newtype is the widest mode from all of these. */ (for op (plus minus mult rdiv) (simplify (convert (op:s@0 (convert1?@3 @1) (convert2?@4 @2))) but for the *_div and trunc_mod/floor_mod the C/C++ FEs optimize using shorten_binary_op without the outer convert, but instead requiring that at least one of the operands is actually converted from narrower type and that the other one fits into the range of that narrower type and for signed div/mod the second operand is known not to be -1, or do it instead in: simplify_using_ranges::simplify_div_or_mod_using_ranges with the same rules. Any preferences?
[Bug tree-optimization/96930] Failure to optimize out arithmetic with bigger size when it can't matter with division transformed into right shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96930
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The testcase seems to be optimized into return a >> b; and already e.g. GCC 4.4
does that.
So it is unclear why this has been reported and what difference you found.
That said, given:
unsigned
foo (unsigned a, unsigned b)
{
return a / (unsigned long long) (1U << b);
}
unsigned
bar (unsigned a, unsigned b)
{
return a / (1U << b);
}
unsigned
baz (unsigned a, unsigned b)
{
unsigned long long c = 1U << b;
return a / c;
}
I see that while we optimize foo and bar into a >> b, by the:
/* (A / (1 << B)) -> (A >> B).
Only for unsigned A. For signed A, this would not preserve rounding
toward zero.
For example: (-1 / ( 1 << B)) != -1 >> B.
Also also widening conversions, like:
(A / (unsigned long long) (1U << B)) -> (A >> B)
or
(A / (unsigned long long) (1 << B)) -> (A >> B).
If the left shift is signed, it can be done only if the upper bits
of A starting from shift's type sign bit are zero, as
(unsigned long long) (1 << 31) is -2147483648ULL, not 2147483648ULL,
so it is valid only if A >> 31 is zero. */
but for baz we actually perform the shift in the wider mode unnecessarily,
because both operands are zero-extended from 32 bits.
Given:
unsigned
qux (unsigned a, unsigned b)
{
unsigned long long c = a;
unsigned long long d = b;
return c / d;
}
unsigned
corge (unsigned a, unsigned b)
{
return ((unsigned long long) a) / (unsigned long long) b;
}
we only optimize it in corge to return a / b; and not in qux, so some
fold-const optimization is not done on GIMPLE.
[Bug fortran/98498] Interp request: defined operators and unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498 Paul Thomas changed: What|Removed |Added Last reconfirmed||2021-01-02 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug tree-optimization/96782] Failure to optimize comparison with bitwise not-ed with self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96782 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|prathamesh3492 at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 49867 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49867=edit gcc11-pr96782.patch Untested fix.
[Bug fortran/98498] New: Interp request: defined operators and unlimited polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498
Bug ID: 98498
Summary: Interp request: defined operators and unlimited
polymorphic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pault at gcc dot gnu.org
Target Milestone: ---
It looks as if gfortran is standard defying;
J3/yy-nnn
To: J3 Members
From: Steve Lionel
Subject: F2018 interp: Extending intrinsic operator with class(*) dummies
Date: 01-Jan-2021
--
NUMBER: F08/! /interp assigns number after submission
TITLE: Extending intrinsic operator with class(*) dummies
KEYWORDS: unlimited polymorphic, defined operator, intrinsic operator
DEFECT TYPE:! /interp assigns
STATUS: J3 consideration in progress
QUESTION:
Consider the following program (created by Paul Richard Thomas):
MODULE mytypes
IMPLICIT none
TYPE pvar
character(len=20) :: name
integer :: level
end TYPE pvar
interface operator (==)
module procedure pvar_eq
end interface
contains
function pvar_eq(a,b)
implicit none
class(*), intent(in) ::a,b
logical ::pvar_eq
if (.not. same_type_as (a, b)) then
pvar_eq = .false.
return
end if
select type (a)
type is (pvar)
select type (b)
type is (pvar)
print *, "a & b are type pvar"
if((a%level.eq. b%level) .and. (a%name .eq. b%name)) then !A
pvar_eq = .true.
else
pvar_eq = .false.
end if
end select
class default
print *, "class default: returning false"
pvar_eq = .false.
end select
end function pvar_eq
end MODULE mytypes
program test_eq
use mytypes
implicit none
type(pvar) x, y
x = pvar('test 1', 100)
y = pvar('test 1', 100)
write(*, *) x == y
x = pvar('test 1', 100)
y = pvar('test 2', 100)
write(*, *) x == y
end program test_eq
The intrinsic equality operator is extended with a function where both
dummy arguments are unlimited polymorphic. Three compilers accept this;
two use the extension for comparisons of any type, such as the one between
two integers at "!A" - the other applies the intrinsic meaning to the
integer comparison.
15.4.3.4.2p1 (Defined operation) says:
"If the operator is an intrinsic-operator (R608), the number of dummy
arguments shall be consistent with the intrinsic uses of that operator,
and the types, kind type parameters, or ranks of the dummy arguments
shall differ from those required for the intrinsic operation (10.1.5)."
The phrase "shall differ" here is not the same as in 15.4.3.4.5
(Restrictions on generic declarations) which instead talks about TKR
compatibility and the ability to "distinguish" dummy arguments.
"C1511 Within the scope of a generic operator, if two procedures with
that identifier have the same number of arguments, one shall have a
dummy argument that corresponds by position in the argument list to a
dummy argument of the other that is distinguishable from it."
Was it intended that the standard treat extending intrinsic operators in
a different manner than other generic interfaces? If so, how should this
program be interpreted?
ANSWER:
No, such a treatment was not intended. Extending a generic intrinsic
operator follows the same rules as other generic extensions. The
example program violates C1511 in that the unlimited polymorphic
dummy arguments are not distinguishable from arguments of any type
for which the intrinsic operator is valid (Table 10.2). Consider also
Note 1 in 10.1.6.1 (Defined Operations > Definitions) says:
"An intrinsic operator can be used as the operator in a defined operation.
In such a case, the generic properties of the operator are extended"
An edit is proposed to correct the deficiency.
EDITS to 18-007r1:
[295:10, 15.4.3.4.2 (Defined operations)]
In the last sentence, remove the text "types, kind type parameters, or
ranks of the" and replace "replace "differ from" with "be distinguishable
from", with "distinguishable" linked to 15.4.3.4.5 (Restrictions on
generic declarations). The sentence now reads:
"If the operator is an intrinsic-operator (R608), the number of dummy
arguments shall be consistent with the intrinsic uses of that operator,
and the dummy arguments shall be distinguishable from those required
for the intrinsic operation (10.1.5)."
SUBMITTED BY: Steve Lionel
HISTORY: yy-nnnm223 F08/ submitted
--
[Bug tree-optimization/96697] Failure to optimize mod+div to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697
--- Comment #3 from Jakub Jelinek ---
On the other side, we do have:
/* X % Y is smaller than Y. */
(for cmp (lt ge)
(simplify
(cmp (trunc_mod @0 @1) @1)
(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == LT_EXPR, type); })))
(for cmp (gt le)
(simplify
(cmp @1 (trunc_mod @0 @1))
(if (TYPE_UNSIGNED (TREE_TYPE (@0)))
{ constant_boolean_node (cmp == GT_EXPR, type); })))
patterns.
[Bug tree-optimization/96707] Failure to optimize right shift+unsigned compare of two variables optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96707 Jakub Jelinek changed: What|Removed |Added CC||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I think another case for ranger symbolic ranges?
[Bug tree-optimization/96696] Failure to optimize div+mul to mod+sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96696 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Do we want to do it in match.pd though, perhaps with :s or single_use check? For GIMPLE it is 2 operations to 2 operations transformation, although multiplication might often be more expensive than subtraction. Or in backends only based on costs? I mean, x - (x % y) is actually longer so might not the best idea e.g. for -Os. But I'm more worried about the CSE possibilities if some code around does x / y.
[Bug tree-optimization/96697] Failure to optimize mod+div to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697 Jakub Jelinek changed: What|Removed |Added CC||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Shall we do that as a specific matcher or e.g. in the ranger once it gets code for symbolic comparisons? I mean, for signed t = x % y note that t is in [-y + 1, y + 1] and on the division use that information to determine the division result range to be [0, 0] ? It could then handle even e.g. ((unsigned) x % y) / (y + 32) for signed y etc.
[Bug tree-optimization/98443] Failure to optimize out vector operations into a constant when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98443 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- We'd probably need VRP on the vector elements for this.
[Bug rtl-optimization/94798] Failure to optimize subtraction and 0 literal properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798 --- Comment #5 from Jakub Jelinek --- Related to what I wrote in PR94802 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802#c5
[Bug tree-optimization/94802] Failure to recognize identities with __builtin_clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
--- Comment #5 from Jakub Jelinek ---
Even when the optimization is restricted to GIMPLE only, the single_use in
there doesn't work really well before fre1 optimizes it, because the above
mentioned testcase doesn't reuse the same expression, but has a different
subtraction that just needs to be CSEd first.
An alternative would be to treat (signed undefined overflow) x >= y and x - y
interchangeably by SCCVN, i.e. hash them the same and if we find both forms (in
either order), transform the x >= y back into (x - y) >= 0 (similar for other
non-equality comparisons). I guess that would fix both that testcase and
PR94798 which also suffers from that:
int
foo (int a, int b)
{
return (b >= a) ? (b - a) : 0;
}
int
bar (int a, int b)
{
return ((b - a) >= 0) ? (b - a) : 0;
}
bar is optimized more than foo - but in this case it is a user that wrote it in
two different forms rather than one.
Another option is to enable the x - y op 0 to x op y canonicalization only
after SCCVN got a chance to CSE stuff after inlining, while that would fix the
por45397.c testcase, it wouldn't the above PR94798 one.
Richi, any thoughts on this?
