[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #28 from Hongtao.liu --- > Probably you can try to tweak it in ix86_add_stmt_cost? when the statement Yes, it's the place. > is UB to UH conversion statement, further check if the def of the input UB > is MEM. Only if there's no multi-use for UB. More generally, it's quite difficult to guess later optimizations for the purpose of more accurate vectorization cost model, :(.
[Bug c++/97195] construct_at on a union member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97195
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment #1 from David Stone ---
This is actually a broader bug in construct_at, unrelated to unions:
```
#include
constexpr bool test() {
int a = 5;
std::construct_at(
,
-1
);
return true;
}
constexpr bool b = test();
```
is also rejected. See it live: https://godbolt.org/z/KWK8n1
The real problem here appears to be that std::construct_at is not a constant
expression for values with non-constant addresses. The following code, for
example, is accepted:
```
#include
struct S {
constexpr S() {
std::construct_at(
,
-1
);
}
int m;
};
constexpr S s;
```
See it live: https://godbolt.org/z/Wdx9Kx
[Bug c++/97222] GCC discards attributes aligned and may_alias for typedefs passed as template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||ABI Last reconfirmed||2020-09-28 Status|UNCONFIRMED |SUSPENDED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Actually this is more complex than what is mentioned here. THIS REQUIRES An ABI addition. Due to the way templates cause name managling to come into play. There is NO way defined at this point to mange for some attributes including but not limited to may_alias and alignment. Suspending until there is a definition of that defined.
[Bug c++/91212] [8/9/10/11 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212 Alfred Agrell changed: What|Removed |Added CC||blubban at gmail dot com --- Comment #10 from Alfred Agrell --- *** Bug 97221 has been marked as a duplicate of this bug. ***
[Bug c++/97221] Returning an array unexpectedly favors const overload in return value's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97221 Alfred Agrell changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Alfred Agrell --- Ah, indeed it is. I should've checked gcc-trunk on CE, I keep forgetting it exists. Thanks, and sorry for the noise. *** This bug has been marked as a duplicate of bug 91212 ***
[Bug middle-end/96750] 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 --- Comment #6 from Matt Bentley --- Created attachment 49278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49278=edit Demonstration of code which doesn't trigger the performance anomaly. plf_colony_fast.h does not trigger the problem, has one branch eliminated in each insert/emplace function.
[Bug middle-end/96750] 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 --- Comment #5 from Matt Bentley --- If anyone out there is interested in working on this, I found the smallest change possible to create the same performance as GCC8- it is literally eliminating one branch possibility in one function (move-insert). The branch in question questions whether there are existing memory blocks to re-use or if we need to create a new memory block. For example, if the reserve() function has been called there will be existing memory blocks to re-use. However the performance drop occurs whether or not there are memory blocks to reuse. The actual if statement is irrelevant. I have tested and can remove all instances of memory block storage (reserve(), erase()) and problem still exists if this one branch is still in insert. I've attached the source files to demonstrate this above, including one plf_colony.h with the branch removed (renamed to plf_colony_fast.h), so you can see what difference there is. This code is all zlib license, free to share, but is early beta so don't redistribute please. Thanks, Matt ps. For consistency I've also removed the non-move-insert and emplace instances of this branch statement, even though they won't be called by the benchmark code in a C++11-compliant compiler.
[Bug c++/97221] Returning an array unexpectedly favors const overload in return value's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97221 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Seems to be fixed in mainline with r11-2411.
[Bug c++/97222] New: GCC discards attributes aligned and may_alias for typedefs passed as template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97222
Bug ID: 97222
Summary: GCC discards attributes aligned and may_alias for
typedefs passed as template arguments
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mte.zych at gmail dot com
Target Milestone: ---
Hello!
GCC discards aligned attribute, applied on a typdef, when it's passed as a
template argument.
Compiler Expolorer:
GCC -> https://godbolt.org/z/bj8v1T
C++ Source Code:
#include
typedef float vec __attribute__((vector_size(8)));
typedef float fp __attribute__((aligned(16)));
template struct identity { typedef t type; };
int main ()
{
std::cout << sizeof(typename identity::type) << std::endl;
std::cout << sizeof(vec ) << std::endl;
std::cout << alignof(typename identity::type) << std::endl;
std::cout << alignof(fp ) << std::endl;
}
Program Output:
8
8
4
16
Compilation Log:
warning: ignoring attributes on template argument 'fp' {aka 'float'}
[-Wignored-attributes]
13 | std::cout << alignof(typename identity::type) << std::endl;
| ^
The above program shows that alignment of the fp typedef changes, after it's
been
passed through the identity meta-function - it's 4-bytes instead of expected
16-bytes.
What's interesting is not all type attributes are discarded - the type
attribute vector_size
is preserved after being passed through the identity meta-function.
This behavior is required, since removal of the vector_size attribute
would be a semantic change of the vec type, affecting even its size,
because the vec type would represent a single float, instead of a vector of 2
floats.
The same could be said about the aligned attribute - discarding it is also a
semantic change,
since alignment is a fundamental property of a type, affecting among others
code generation,
that is, two types are not equivalent if they have different alignment.
This is the reason why I argue that, passing a typedef as a template argument
should preserve its aligned attribute, instead of discarding it.
Moreover, the Intel C++ compiler implements this behavior correctly.
Compiler Expolorer:
ICC -> https://godbolt.org/z/9vr9se
Program Output:
8
8
16
16
The issue described above doesn't apply only to the aligned type attribute,
but also to the may_alias type attribute.
Compiler Expolorer:
GCC -> https://godbolt.org/z/6EqsnP
C++ Source Code:
typedef int integer __attribute__((may_alias));
template struct identity { typedef t type; };
int main ()
{
typename identity::type i;
}
Compilation Log:
warning: ignoring attributes on template argument 'integer' {aka 'int'}
[-Wignored-attributes]
7 | typename identity::type i;
| ^
Again, discarding attribute may_alias is a semantic change,
because aliasing rules can affect code generation.
Why this issue is important?
Well, because it prevents generic programming, via C++ templates, using x86
SIMD types.
If we would look at definitions of x86 SIMD types, we will notice that
they are essentially typedefs with attributes vector_size and may_alias applied
on them:
- immintrin.h
typedef float __m256 __attribute__((__vector_size__(32),
__may_alias__));
- emmintrin.h
typedef long long __m128i __attribute__((__vector_size__(16),
__may_alias__));
typedef double__m128d __attribute__((__vector_size__(16),
__may_alias__));
- xmmintrin.h
typedef float __m128 __attribute__((__vector_size__(16),
__may_alias__));
Note that, the may_alias attributes is required and cannot be removed:
- /usr/lib/gcc/x86_64-linux-gnu/10/include/immintrin.h
/* The Intel API is flexible enough that we must allow aliasing with other
vector types, and their scalar components. */
Compiler Expolorer:
GCC -> https://godbolt.org/z/vz4fWK
C++ Source Code:
#include
template struct identity { typedef t type; };
int main ()
{
typename identity<__m128>::type fvec4;
}
Compilation Log:
warning: ignoring attributes on template argument '__m128'
[-Wignored-attributes]
8 | typename identity<__m128>::type fvec4;
| ^
What's the root cause of this problem?
Well, the problem is in C++ a typedef is just an alias (a new name) for the old
type,
that is, it does *not* introduce a new type.
Implementing support for attributes vector_size, aligned and may_alias
in C++ typedefs requires an opaque/strong typedef,
introducing a brand new type and storing information about applied attributes.
typedef float fp __attribute__((aligned(16)));
Think about it - a typedef introducing the fp type has to create a new type,
because even though both fp and
[Bug c++/97221] New: Returning an array unexpectedly favors const overload in return value's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97221
Bug ID: 97221
Summary: Returning an array unexpectedly favors const overload
in return value's constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct string {
const char * m;
template string(const char ()[N]) { m = "CONST"; }
template string(char ()[N]) { m = "MUT"; }
};
string foo()
{
char bar[8];
return bar;
}
With Clang 10.0.1 -O2 -std=c++11, this returns "MUT".
With GCC 10.2 -O2 -std=c++98, this returns "MUT".
With GCC 7.5 -O2 -std=c++11, this returns "MUT".
With GCC 10.2 -O2 -std=c++11, this returns "CONST".
This one should give same result for every configuration, or at least throw a
warning from -Wc++11-compat, right?
Compiler Explorer: https://godbolt.org/z/r3Yo64
(Context: I encountered this when trying to make my string class distinguish
between string literals and char arrays/pointers, and call sizeof instead of
strlen for the former.)
[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Jakub Jelinek --- Fixed.
[Bug c++/97220] Overload resolution works wrong when implicit conversion not exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97220 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-27 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97220] New: Overload resolution works wrong when implicit conversion not exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97220
Bug ID: 97220
Summary: Overload resolution works wrong when implicit
conversion not exists
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: konstantin.vladimirov at gmail dot com
Target Milestone: ---
Minimal reproducer is here: https://godbolt.org/z/rd4e9a
struct S {
explicit S(int, int, int) {}
};
struct T {
T(int, int, int) {}
};
void foo(struct S) {} // 1
void foo(struct T) {} // 2
int main() {
S s{1, 2, 3};
foo({1, 2, 3});
}
By C++ standard, [over.match.viable], "for F to be a viable function, there
shall exist for each argument an implicit conversion sequence (12.4.3.1) that
converts that argument to the corresponding parameter of F"
So 1 is not viable overload and resolution shall peek 2
But in reality now error produced:
error: call of overloaded 'foo()' is ambiguous
[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073 --- Comment #12 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0ed1ce77f876cb05cd3e403c6c28e86fe0692f93 commit r8-10540-g0ed1ce77f876cb05cd3e403c6c28e86fe0692f93 Author: Jakub Jelinek Date: Sun Sep 27 23:18:26 2020 +0200 optabs: Don't reuse target for multi-word expansions if it overlaps operand(s) [PR97073] The following testcase is miscompiled on i686-linux, because we try to expand a double-word bitwise logic operation with op0 being a (mem:DI u) and target (mem:DI u+4), i.e. partial overlap, and thus end up with: movl4(%esp), %eax andlu, %eax movl%eax, u+4 ! movl u+4, %eax optimized out andl8(%esp), %eax movl%eax, u+8 rather than with the desired: movl4(%esp), %edx movl8(%esp), %eax andlu, %edx andlu+4, %eax movl%eax, u+8 movl%edx, u+4 because the store of the first word to target overwrites the second word of the operand. expand_binop for this (and several similar places) already check for target == op0 or target == op1, this patch just adds reg_overlap_mentioned_p calls next to it. Pedantically, at least for some of these it might be sufficient to force a different target if there is overlap but target is not rtx_equal_p to the operand (e.g. in this bitwise logical case, but e.g. not in the shift cases where there is reordering), though that would go against the preexisting target == op? checks and the rationale that REG_EQUAL notes in that case isn't correct. 2020-09-27 Jakub Jelinek PR middle-end/97073 * optabs.c (expand_binop, expand_absneg_bit, expand_unop, expand_copysign_bit): Check reg_overlap_mentioned_p between target and operand(s) and if it returns true, force a pseudo as target. * gcc.c-torture/execute/pr97073.c: New test. (cherry picked from commit a4b31d5807f2bc67c8999b3d53369cf2a5c6e1ec)
[Bug libstdc++/93602] Missing reference to libiconv in 9.x libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602 Alexios Zavras (zvr) changed: What|Removed |Added CC||zvr+gcc at zvr dot gr --- Comment #14 from Alexios Zavras (zvr) --- I can confirm this bug also in gcc-9.3.0, gcc-10.1.0 and gcc-10.2.0. To recap: if the system has a libiconv installed, the generated and installed libstdc++.so depends on it. However the compiler, when using it when compiling a C++ program, does not link libiconv, resulting in an error: $ g++ foo.cc /usr/local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libstdc++.so: undefined reference to `libiconv' /usr/local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libstdc++.so: undefined reference to `libiconv_close' /usr/local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libstdc++.so: undefined reference to `libiconv_open' collect2: error: ld returned 1 exit status
[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:aa42c1ac24a0427a27aec19c483780662cd150b8 commit r9-8943-gaa42c1ac24a0427a27aec19c483780662cd150b8 Author: Jakub Jelinek Date: Sun Sep 27 23:18:26 2020 +0200 optabs: Don't reuse target for multi-word expansions if it overlaps operand(s) [PR97073] The following testcase is miscompiled on i686-linux, because we try to expand a double-word bitwise logic operation with op0 being a (mem:DI u) and target (mem:DI u+4), i.e. partial overlap, and thus end up with: movl4(%esp), %eax andlu, %eax movl%eax, u+4 ! movl u+4, %eax optimized out andl8(%esp), %eax movl%eax, u+8 rather than with the desired: movl4(%esp), %edx movl8(%esp), %eax andlu, %edx andlu+4, %eax movl%eax, u+8 movl%edx, u+4 because the store of the first word to target overwrites the second word of the operand. expand_binop for this (and several similar places) already check for target == op0 or target == op1, this patch just adds reg_overlap_mentioned_p calls next to it. Pedantically, at least for some of these it might be sufficient to force a different target if there is overlap but target is not rtx_equal_p to the operand (e.g. in this bitwise logical case, but e.g. not in the shift cases where there is reordering), though that would go against the preexisting target == op? checks and the rationale that REG_EQUAL notes in that case isn't correct. 2020-09-27 Jakub Jelinek PR middle-end/97073 * optabs.c (expand_binop, expand_absneg_bit, expand_unop, expand_copysign_bit): Check reg_overlap_mentioned_p between target and operand(s) and if it returns true, force a pseudo as target. * gcc.c-torture/execute/pr97073.c: New test. (cherry picked from commit a4b31d5807f2bc67c8999b3d53369cf2a5c6e1ec)
[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9389e3abc1fc4881f22c7376aae2dd650af2b792 commit r10-8804-g9389e3abc1fc4881f22c7376aae2dd650af2b792 Author: Jakub Jelinek Date: Sun Sep 27 23:18:26 2020 +0200 optabs: Don't reuse target for multi-word expansions if it overlaps operand(s) [PR97073] The following testcase is miscompiled on i686-linux, because we try to expand a double-word bitwise logic operation with op0 being a (mem:DI u) and target (mem:DI u+4), i.e. partial overlap, and thus end up with: movl4(%esp), %eax andlu, %eax movl%eax, u+4 ! movl u+4, %eax optimized out andl8(%esp), %eax movl%eax, u+8 rather than with the desired: movl4(%esp), %edx movl8(%esp), %eax andlu, %edx andlu+4, %eax movl%eax, u+8 movl%edx, u+4 because the store of the first word to target overwrites the second word of the operand. expand_binop for this (and several similar places) already check for target == op0 or target == op1, this patch just adds reg_overlap_mentioned_p calls next to it. Pedantically, at least for some of these it might be sufficient to force a different target if there is overlap but target is not rtx_equal_p to the operand (e.g. in this bitwise logical case, but e.g. not in the shift cases where there is reordering), though that would go against the preexisting target == op? checks and the rationale that REG_EQUAL notes in that case isn't correct. 2020-09-27 Jakub Jelinek PR middle-end/97073 * optabs.c (expand_binop, expand_absneg_bit, expand_unop, expand_copysign_bit): Check reg_overlap_mentioned_p between target and operand(s) and if it returns true, force a pseudo as target. * gcc.c-torture/execute/pr97073.c: New test. (cherry picked from commit a4b31d5807f2bc67c8999b3d53369cf2a5c6e1ec)
[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a4b31d5807f2bc67c8999b3d53369cf2a5c6e1ec commit r11-3489-ga4b31d5807f2bc67c8999b3d53369cf2a5c6e1ec Author: Jakub Jelinek Date: Sun Sep 27 23:18:26 2020 +0200 optabs: Don't reuse target for multi-word expansions if it overlaps operand(s) [PR97073] The following testcase is miscompiled on i686-linux, because we try to expand a double-word bitwise logic operation with op0 being a (mem:DI u) and target (mem:DI u+4), i.e. partial overlap, and thus end up with: movl4(%esp), %eax andlu, %eax movl%eax, u+4 ! movl u+4, %eax optimized out andl8(%esp), %eax movl%eax, u+8 rather than with the desired: movl4(%esp), %edx movl8(%esp), %eax andlu, %edx andlu+4, %eax movl%eax, u+8 movl%edx, u+4 because the store of the first word to target overwrites the second word of the operand. expand_binop for this (and several similar places) already check for target == op0 or target == op1, this patch just adds reg_overlap_mentioned_p calls next to it. Pedantically, at least for some of these it might be sufficient to force a different target if there is overlap but target is not rtx_equal_p to the operand (e.g. in this bitwise logical case, but e.g. not in the shift cases where there is reordering), though that would go against the preexisting target == op? checks and the rationale that REG_EQUAL notes in that case isn't correct. 2020-09-27 Jakub Jelinek PR middle-end/97073 * optabs.c (expand_binop, expand_absneg_bit, expand_unop, expand_copysign_bit): Check reg_overlap_mentioned_p between target and operand(s) and if it returns true, force a pseudo as target. * gcc.c-torture/execute/pr97073.c: New test.
[Bug c++/97219] Generic lambda does not find function declaration from enclosing block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97219 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org CC||nathan at gcc dot gnu.org --- Comment #1 from Nathan Sidwell --- ah, another local extern decl thing
[Bug middle-end/94195] missing warning reading a smaller object via an lvalue of a larger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94195 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Implemented for GCC 11 in r11-3306.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 94195, which changed state. Bug 94195 Summary: missing warning reading a smaller object via an lvalue of a larger type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94195 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/94195] missing warning reading a smaller object via an lvalue of a larger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94195 --- Comment #4 from Martin Sebor --- (In reply to Dmitry G. Dyachenko from comment #3) The warning is expected. The access to pS->s1.x implies that there must be an object at pS that's at least sizeof *pS large, even though only the leading 4 bytes of it are being accessed.
[Bug c++/97217] C++ program compiled with GCC crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97217 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-09-27 Status|UNCONFIRMED |WAITING --- Comment #1 from Jonathan Wakely --- Please read https://gcc.gnu.org/bugs/ as requested when creating a bug report.
[Bug c++/97214] ICE in lookup_template_class_1, at cp/pt.c:9896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97214
--- Comment #1 from Steven Franzen ---
Bug 97219 looks similar. Unqualified name lookup should consider the scope
containing the lambda, which here is a member function and also includes the
full scope of its class. Similar example at
http://en.cppreference.com/w/cpp/language/lambda:
For the purpose of name lookup, determining the type and value of the this
pointer and for accessing non-static class members, the body of the closure
type's function call operator is considered in the context of the
lambda-expression.
struct X {
int x, y;
int operator()(int);
void f()
{
// the context of the following lambda is the member function X::f
[=]()->int
{
return operator()(this->x + y); // X::operator()(this->x +
(*this).y)
// this has type X*
};
}
};
[Bug libstdc++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #9 from Ville Voutilainen --- LEWG says NO: https://cplusplus.github.io/LWG/issue3440
[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:e28cc38ac34cb4de31b983f817c6e5f7dde55e2c commit r8-10539-ge28cc38ac34cb4de31b983f817c6e5f7dde55e2c Author: Mark Eggleston Date: Thu Jun 11 14:33:51 2020 +0100 Fortran : ICE in build_field PR95614 Local identifiers can not be the same as a module name. Original patch by Steve Kargl resulted in name clashes between common block names and local identifiers. A local identifier can be the same as a global identier if that identifier represents a common. The patch was modified to allow global identifiers that represent a common block. 2020-09-27 Steven G. Kargl Mark Eggleston gcc/fortran/ PR fortran/95614 * decl.c (gfc_get_common): Use gfc_match_common_name instead of match_common_name. * decl.c (gfc_bind_idents): Use gfc_match_common_name instead of match_common_name. * match.c : Rename match_common_name to gfc_match_common_name. * match.c (gfc_match_common): Use gfc_match_common_name instead of match_common_name. * match.h : Rename match_common_name to gfc_match_common_name. * resolve.c (resolve_common_vars): Check each symbol in a common block has a global symbol. If there is a global symbol issue an error if the symbol type is known as is not a common block name. 2020-09-27 Mark Eggleston gcc/testsuite/ PR fortran/95614 * gfortran.dg/pr95614_1.f90: New test. * gfortran.dg/pr95614_2.f90: New test. (cherry picked from commit e5a76af3a2f3324efc60b4b2778ffb29d5c377bc)
[Bug c++/97219] New: Generic lambda does not find function declaration from enclosing block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97219
Bug ID: 97219
Summary: Generic lambda does not find function declaration from
enclosing block scope
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The unqualified lookup for `q` in the instantiation of the generic lambda
should resolve to the block-scope function declaration.
Such a lookup result should furthermore suppress argument dependent lookup.
GCC resolves `q` using argument dependent lookup at the point of instantiation
and chooses a worse candidate.
### SOURCE ():
struct B;
template
auto f(T *) {
void q(B *, void * = static_cast(0));
return [](auto *p) { q(p); };
}
void q(void *) = delete;
int main(void) {
B *bp = 0;
f(bp)(bp);
}
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++20 -Wall -Wextra -pedantic-errors -xc++ -
### ACTUAL OUTPUT:
: In instantiation of 'f:: [with auto:1 = B]':
:13:11: required from here
:6:25: error: use of deleted function 'void q(void*)'
:9:6: note: declared here
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200925 (experimental) (GCC)
[Bug fortran/97218] gcc/fortran/resolve.c:6807: pointless Assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97218 Dominique d'Humieres changed: What|Removed |Added CC||pault at gcc dot gnu.org Last reconfirmed||2020-09-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Still present. Note that the comment above doesn't help.
[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:7a8c40bca889785fc4664e5e11c430e31d297696 commit r9-8942-g7a8c40bca889785fc4664e5e11c430e31d297696 Author: Mark Eggleston Date: Thu Jun 11 14:33:51 2020 +0100 Fortran : ICE in build_field PR95614 Local identifiers can not be the same as a module name. Original patch by Steve Kargl resulted in name clashes between common block names and local identifiers. A local identifier can be the same as a global identier if that identifier represents a common. The patch was modified to allow global identifiers that represent a common block. 2020-09-27 Steven G. Kargl Mark Eggleston gcc/fortran/ PR fortran/95614 * decl.c (gfc_get_common): Use gfc_match_common_name instead of match_common_name. * decl.c (gfc_bind_idents): Use gfc_match_common_name instead of match_common_name. * match.c : Rename match_common_name to gfc_match_common_name. * match.c (gfc_match_common): Use gfc_match_common_name instead of match_common_name. * match.h : Rename match_common_name to gfc_match_common_name. * resolve.c (resolve_common_vars): Check each symbol in a common block has a global symbol. If there is a global symbol issue an error if the symbol type is known as is not a common block name. 2020-09-27 Mark Eggleston gcc/testsuite/ PR fortran/95614 * gfortran.dg/pr95614_1.f90: New test. * gfortran.dg/pr95614_2.f90: New test. (cherry picked from commit e5a76af3a2f3324efc60b4b2778ffb29d5c377bc)
[Bug fortran/97218] New: gcc/fortran/resolve.c:6807: pointless Assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97218 Bug ID: 97218 Summary: gcc/fortran/resolve.c:6807: pointless Assignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I can't quite remember if we have had this one before. My apologies if this is already known about. Source code is for (; args; args = args->next) if (expr == args->expr) expr = args->expr; git blame says: 94fae14bf8aa (Paul Thomas 2012-01-02 12:46:08 + 6805) for (; args; args = args->next) 94fae14bf8aa (Paul Thomas 2012-01-02 12:46:08 + 6806) if (expr == args->expr) 94fae14bf8aa (Paul Thomas 2012-01-02 12:46:08 + 6807) expr = args->expr;
[Bug c++/97217] New: C++ program compiled with GCC crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97217 Bug ID: 97217 Summary: C++ program compiled with GCC crashes Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: carsten.schmidt-achim at gmx dot de Target Milestone: --- Created attachment 49277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49277=edit Example assembly listing causing the crash. During development of my vector/matrix library using template meta programming, I discovered that my test program crashes on some occasions when being compiled with GCC. When inspecting the assembly code generated by GCC, the instruction crashing the program seems to be unrelated to the data flow of the program. I will attach the generated assembly of one of my test cases, which crashes the program. Please let me know if you would like to investigate further and how I can be of service!
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 Tim Ruffing changed: What|Removed |Added CC||public at timruffing dot de --- Comment #17 from Tim Ruffing --- Created attachment 49276 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49276=edit Hacky patch that makes GCC print a diagnostic message if hitting the bug We hit this bug in a test case in secp256k1, the cryptography library used in Bitcoin Core. The bug appeared pretty scary to us at first glance because memcmp is widely used. After looking at the GCC patch that fixes this, we believe that this bug only occurs when * at least one of the compared byte arrays is constant and has a zero byte in position 0, 1, 2, or 3, *and* * the result of the memcmp isn't immediately used in a "== 0" or "!= 0" test (or equivalently "if(memcmp(...))" or "if(!memcmp(...))"). In particular the second condition makes this bug pretty rare and explains why it's mostly hit in non-inlined memcmp wrappers. (But in our case we hit it with a "<" comparison. ) For anyone else who's concerned about this bug, we've created a hacky patch (co-authored by Russell O'Connor) for the GCC versions with this bug that makes GCC print a diagnostic message if it emits wrong code due to this bug. We think the message is sound but it would be great if someone could confirm this.
[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:4a67941a956003dcce8866604ba25f5a0bfd16cf commit r10-8803-g4a67941a956003dcce8866604ba25f5a0bfd16cf Author: Mark Eggleston Date: Thu Jun 11 14:33:51 2020 +0100 Fortran : ICE in build_field PR95614 Local identifiers can not be the same as a module name. Original patch by Steve Kargl resulted in name clashes between common block names and local identifiers. A local identifier can be the same as a global identier if that identifier represents a common. The patch was modified to allow global identifiers that represent a common block. 2020-09-27 Steven G. Kargl Mark Eggleston gcc/fortran/ PR fortran/95614 * decl.c (gfc_get_common): Use gfc_match_common_name instead of match_common_name. * decl.c (gfc_bind_idents): Use gfc_match_common_name instead of match_common_name. * match.c : Rename match_common_name to gfc_match_common_name. * match.c (gfc_match_common): Use gfc_match_common_name instead of match_common_name. * match.h : Rename match_common_name to gfc_match_common_name. * resolve.c (resolve_common_vars): Check each symbol in a common block has a global symbol. If there is a global symbol issue an error if the symbol type is known as is not a common block name. 2020-09-27 Mark Eggleston gcc/testsuite/ PR fortran/95614 * gfortran.dg/pr95614_1.f90: New test. * gfortran.dg/pr95614_2.f90: New test. (cherry picked from commit e5a76af3a2f3324efc60b4b2778ffb29d5c377bc)
[Bug target/97184] Incorrect MOVDIRI and MOVDIR64B patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97184 H.J. Lu changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Septemb ||er/554933.html Keywords||patch Target Milestone|--- |11.0 Last reconfirmed||2020-09-27 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554933.html
[Bug fortran/97070] Discrepancy in results between OpenMP/OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97070 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-09-27 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I don't see that with 10.2.1 or 11.0, the output for both cases is ISOUR = * XMO =1. DCP =2. IS1 = 3 IS2 = 24
[Bug fortran/95614] ICE in build_field, at fortran/trans-common.c:301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95614 --- Comment #5 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc commit r11-3487-ge5a76af3a2f3324efc60b4b2778ffb29d5c377bc Author: Mark Eggleston Date: Thu Jun 11 14:33:51 2020 +0100 Fortran : ICE in build_field PR95614 Local identifiers can not be the same as a module name. Original patch by Steve Kargl resulted in name clashes between common block names and local identifiers. A local identifier can be the same as a global identier if that identifier represents a common. The patch was modified to allow global identifiers that represent a common block. 2020-09-27 Steven G. Kargl Mark Eggleston gcc/fortran/ PR fortran/95614 * decl.c (gfc_get_common): Use gfc_match_common_name instead of match_common_name. * decl.c (gfc_bind_idents): Use gfc_match_common_name instead of match_common_name. * match.c : Rename match_common_name to gfc_match_common_name. * match.c (gfc_match_common): Use gfc_match_common_name instead of match_common_name. * match.h : Rename match_common_name to gfc_match_common_name. * resolve.c (resolve_common_vars): Check each symbol in a common block has a global symbol. If there is a global symbol issue an error if the symbol type is known as is not a common block name. 2020-09-27 Mark Eggleston gcc/testsuite/ PR fortran/95614 * gfortran.dg/pr95614_1.f90: New test. * gfortran.dg/pr95614_2.f90: New test.
[Bug c++/97216] ICE with (incorrect) spaceship operator declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97216 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Most likely dup of PR97121
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
--- Comment #27 from Kewen Lin ---
(In reply to Hongtao.liu from comment #22)
> >One of my workmates found that if we disable vectorization for SPEC2017
> >>525.x264_r function sub4x4_dct in source file x264_src/common/dct.c with
> >?>explicit function attribute
> >__attribute__((optimize("no-tree-vectorize"))), it >can speed up by 4%.
>
> For CLX, if we disable slp vectorization in sub4x4_dct by
> __attribute__((optimize("no-tree-slp-vectorize"))), it can also speed up by
> 4%.
>
> > Thanks Richi! Should we take care of this case? or neglect this kind of
> > extension as "no instruction"? I was intent to handle it in target specific
> > code, but it isn't recorded into cost vector while it seems too heavy to do
> > the bb_info slp_instances revisits in finish_cost.
>
> For i386 backend unsigned char --> unsigned short is no "no instruction",
Thanks for the information, it means it's target specific.
> but in this case
> ---
> 1033 _134 = MEM[(pixel *)pix1_295 + 2B];
>
> 1034 _135 = (short unsigned int) _134;
> ---
>
> It could be combined and optimized to
> ---
> movzbl 19(%rcx), %r8d
> ---
>
> So, if "unsigned char" variable is loaded from memory, then the convertion
> would also be "no instruction", i'm not sure if backend cost model could
> handle such situation.
Probably you can try to tweak it in ix86_add_stmt_cost? when the statement is
UB to UH conversion statement, further check if the def of the input UB is MEM.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #26 from Kewen Lin --- > > By following this idea, to release the restriction on loop_outer > > (loop_father) when setting the father_bbs, I can see FRE works as > > expectedly. But it actually does the rpo_vn from cfun's entry to its exit. > > Yeah, that's the reason we do not do it. We could possibly restrict it > to a containing loop, or if the containing loop is the whole function, > restrict it to the original preheader block to the loop exits (which are > no longer there, we'd need to pre-record those I think) Thanks for the suggestion! I tried the idea to restrict it to run from the original preheader block to the loop exits (pre-record both as you said), but it can't support the array d eliminated finally, unfortunately this case requires VN to run across the boundary between the original loops. Now I ended up to run one time the whole function VN if there isn't any loops after unrolling. I guess if there are no loops, the CFG should be simple in most times and then not so costly? > > Besides, when SLP happens, FRE gen the bit_field_ref and remove array d, but > > for scalar codes it needs one more time dse run after cunroll to get array d > > eliminated. I guess it's not costly? Can one pass be run or not controlled > > by something in another pass? via global variable and add one parameter in > > passes.def seems weird. If it's costly, probably we can go by factoring out > > one routine to be called instead of running a pass, like do_rpo_vn? > > No, we don't have a good way to schedule passes from other passes. And yes, > the way forward is to support key transforms on regions. Oh, and every > pass that does memory alias analysis (DSE, DCE, VN, etc.) is costly. > OK, I'll have a look at DSE and try to get it to support region style. Although it may not help this case since it needs to operate things across loop boundary.
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789 --- Comment #25 from Kewen Lin --- > > > > Got it! For > > > > else if (vect_nop_conversion_p (stmt_info)) > > continue; > > > > Is it a good idea to change it to call record_stmt_cost like the others? > > 1) introduce one vect_cost_for_stmt enum type eg: nop_stmt > > 2) builtin_vectorization_cost return zero for it by default as before. > > 3) targets can adjust the cost according to its need > > I think this early-out was added for the case where there was no cost but > the target costed it. So at least go back and look what target that was > and see if it can be adjusted. OK, thanks. The change is from commit r10-4592, I think most of its handled objects are no costs for all targets, like VIEW_CONVERT_EXPR, UL/SL bi-direction conversions etc, so it's good to differentiate it from scalar_stmt, but the "continue" way makes target hard to tweak for some tree_nop_conversion_p stmts.
[Bug c++/97216] New: ICE with (incorrect) spaceship operator declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97216
Bug ID: 97216
Summary: ICE with (incorrect) spaceship operator declaration
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: GCCBugzilla at DRHouck dot me
Target Milestone: ---
Created attachment 49275
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49275=edit
Tarball of original file (.cpp), preprocessed file (.ii), and compiler output
(.log)
Attempting to compile the following code produces an ICE. The code may be
ill-formed (I don't know if I'm reading the standard correctly when trying to
figure that out), and if not should probably still generate a warning, but
either way an ICE is not the right output.
Minimized test case, with a commented-out line used in additional notes:
```
#include
class C
{
public:
int a;
constexpr bool operator<=>(C const& other) const = default;
};
// auto b = C{17} <=> C{23};
```
This file, the preprocessed file, and the output from the compiler are
attached.
---
Additional notes from my experimenting, may or may not be useful:
* I can reproduce this on Compiler Explorer trunk, which claims to be version
"11.0.0 20200926 (experimental)", but the answers and log file below are for my
personal machine, which is still on 10.2.0. Because of this, I am reporting
the bug here, instead of the Arch bug tracker linked in the compiler log.
* Removing the `constexpr` doesnʼt generate any ICE or diagnostic at -Wall
-Wextra, but uncommenting the last line adds back the ICE (referencing line 7,
the declaration, instead of the last line).
* Removing the #include line (with or without the `constexpr`) results in the
no ICE or diagnostic at -Wall -Wextra; uncommenting the last line results in
"error: use of deleted function 'constexpr bool C::operator<=>(const C&)
const'" and "note: 'constexpr bool C::operator<=>(const C&) const' is
implicitly deleted because the default definition would be ill-formed".
Additional details as requested at https://gcc.gnu.org/bugs/:
the exact version of GCC:
g++ (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
the system type: Arch Linux, x86-64
the options given when GCC was configured/built: Included in the -v output
attached
the complete command line that triggers the bug: `g++ -v -save-temps -std=c++2a
-c spaceship_ice.cpp > spaceship_ice.log 2>&1`; the same appears if I use the
attached .ii file.
the compiler output (error messages, warnings, etc.): attached
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command: attached
[Bug target/97194] optimize vector element set/extract at variable position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194 --- Comment #5 from Hongtao.liu --- > > There's ongoing patch iteration on the ml adding variable index vec_set > > expanders for powerpc (and the related middle-end changes). The question > > is whether optabs can try many things or the target should have the choice > > (probably better). > > The patch has been on trunk, will you add expander?
[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
--- Comment #24 from rguenther at suse dot de ---
On September 27, 2020 4:56:43 AM GMT+02:00, crazylht at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96789
>
>--- Comment #22 from Hongtao.liu ---
>>One of my workmates found that if we disable vectorization for
>SPEC2017 >525.x264_r function sub4x4_dct in source file
>x264_src/common/dct.c with ?>explicit function attribute
>__attribute__((optimize("no-tree-vectorize"))), it >can speed up by 4%.
>
>For CLX, if we disable slp vectorization in sub4x4_dct by
>__attribute__((optimize("no-tree-slp-vectorize"))), it can also speed
>up by 4%.
>
>> Thanks Richi! Should we take care of this case? or neglect this kind
>of
>> extension as "no instruction"? I was intent to handle it in target
>specific
>> code, but it isn't recorded into cost vector while it seems too heavy
>to do
>> the bb_info slp_instances revisits in finish_cost.
>
>For i386 backend unsigned char --> unsigned short is no "no
>instruction", but
>in this case
>---
>1033 _134 = MEM[(pixel *)pix1_295 + 2B];
>
>1034 _135 = (short unsigned int) _134;
>---
>
>It could be combined and optimized to
>---
>movzbl 19(%rcx), %r8d
>---
>
>So, if "unsigned char" variable is loaded from memory, then the
>convertion
>would also be "no instruction", i'm not sure if backend cost model
>could handle
>such situation.
I think all attempts to address this from the side of the scalar cost is going
to be difficult and fragile..
[Bug tree-optimization/78427] missed optimization of loop condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78427 bin cheng changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #5 from bin cheng --- (In reply to Antony Polukhin from comment #4) > Any progress? Oh, I missed this one. Will try to find time later. Thanks
[Bug tree-optimization/78427] missed optimization of loop condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78427 Antony Polukhin changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #4 from Antony Polukhin --- Any progress?
