[Bug c++/105512] New: compilation with -fmodules-ts and std=c++20 leads to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105512
Bug ID: 105512
Summary: compilation with -fmodules-ts and std=c++20 leads to
segfault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deco33000 at yandex dot com
Target Milestone: ---
Hi,
compiling with -fmodules-ts and -std=c++20 leads to a segfault. With c++17 no
errors. Without std= switch, no segfault.
But c++20 is required in my code, hence the report.
Here is the reduced code:
- main.cpp
import hello;
int main ( void ){
X::greeter("ok");
return 0;
}
-mod.cxx
module;
#include
#include
#include
export module hello;
import sub_mod;
namespace X {
void greeter2 ( std::string_view const &name ){
std::string h = "exported greeter";
std::cout << "Bye " << name << "!" << h << "\n";
Y::g();
}
}
export {
namespace X {
void greeter ( std::string_view const &name ){
std::string h = "exported greeter";
std::cout << "Hello " << name << "!" << h << "\n";
greeter2("ff");
}
}
}
-mod_sub.cxx
module;
#include
export module sub_mod;
export {
namespace Y {
auto g (){
std::cout << "in out " << std::endl;
}
}
}
The following works with c++17 and c++20 flags (no issue):
- mod_sub.cxx corrected (no global fragment):
export module sub_mod;
export {
namespace Y {
auto g ()-> int{
//std::cout << "in out " << std::endl;
return 54;
}
}
}
and
- mod.cxx corrected (prints g() directly):
module;
#include
#include
#include
export module hello;
import sub_mod;
namespace X {
void greeter2 ( std::string_view const &name ){
std::string h = "exported greeter";
std::cout << "Bye " << name << "!" << h << " " <<
Y::g() <<"\n";
}
}
export {
namespace X {
void greeter ( std::string_view const &name ){
std::string h = "exported greeter";
std::cout << "Hello " << name << "!" << h << "\n";
greeter2("ff");
}
}
}
Thanks,
[Bug target/99754] [sse2] new _mm_loadu_si16 and _mm_loadu_si32 implemented incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99754 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- .
[Bug c/100902] pointer attachment issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100902 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/105513] New: [9/10/11/12/13 Regression] Unnecessary SSE spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
Bug ID: 105513
Summary: [9/10/11/12/13 Regression] Unnecessary SSE spill
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
Minimized from PR 105504.
Compile with -O2 -mtune=haswell -mavx (other -mtune variants are affected too):
static int as_int(float x)
{
return (union{float x; int i;}){x}.i;
}
float f(double y, float x)
{
int i = as_int(x);
if (__builtin_expect(i > 99, 0)) return 0;
if (i*2u < 77) if (i==2) return 0;
return y*x;
}
GCC moves 'x' to 'i' via stack and then reloads from stack again when computing
'y*x':
f:
vmovss DWORD PTR [rsp-4], xmm1
mov eax, DWORD PTR [rsp-4]
cmp eax, 99
jg .L5
lea edx, [rax+rax]
cmp edx, 76
ja .L6
cmp eax, 2
je .L5
.L6:
vcvtss2sd xmm1, xmm1, DWORD PTR [rsp-4]
vmulsd xmm0, xmm1, xmm0
vcvtsd2ss xmm0, xmm0, xmm0
ret
.L5:
vxorps xmm0, xmm0, xmm0
ret
This is a regression relative to gcc-8. Interestingly, flipping '0' to '1' in
__builtin_expect (i.e. making early exit likely) results in good code, so
perhaps RA costing takes block probabilities backwards somewhere?
[Bug target/105504] Fails to break dependency for vcvtss2sd xmm, xmm, mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105504 --- Comment #5 from Alexander Monakov --- The strange xmm0 spill issue may affect more code, so I reported an isolated testcase: PR 105513 (regression vs. gcc-8, the complete testcase in this PR also does not spill with gcc-8).
[Bug c/105514] New: rv64 qsort gets wrong result when '-O2 -DDEBUG'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105514 Bug ID: 105514 Summary: rv64 qsort gets wrong result when '-O2 -DDEBUG'. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chenglulu at loongson dot cn Target Milestone: --- Created attachment 52936 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52936&action=edit riscv64-linux-gnu %riscv64-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=riscv64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/.../libexec/gcc/riscv64-linux-gnu/13.0.0/lto-wrapper Target: riscv64-linux-gnu Configured with: /.../configure --target=riscv64-linux-gnu --with-arch=rv64g --with-abi=lp64d --enable-shared --disable-emultls --disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220507 (experimental) (GCC) There is no problem with the execution result of the following compiler. % riscv64-linux-gnu-gcc qsort.c -o qsort -O2 --static -march=rv64g -mabi=lp64d % ./qsort ./qsort But, When I add a line to the code to print,program execution result is wrong. % riscv64-linux-gnu-gcc qsort.c -o qsort -O2 --static -march=rv64g -mabi=lp64d -DDEBUG ./qsort test simple_qsort array with function pointer failed. When add option '-DDEBUG -fno-reorder-blocks', The program execution result is no problem again.
[Bug target/105514] rv64 qsort gets wrong result when '-O2 -DDEBUG'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105514 --- Comment #1 from Andrew Pinski --- Just looking at the code, there seems to be some aliasing violations going on which is causing the problem. Sometimes accessing via unsigned long and others by double. Does -fno-strict-aliasing fixes the issue?
[Bug c++/105515] New: const vector inside a module namespace. Error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105515
Bug ID: 105515
Summary: const vector inside a module namespace. Error.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deco33000 at yandex dot com
Target Milestone: ---
Hi,
when using this extremely reduced code:
--
module;
#include
export module common_vals;
using std::vector;
export {
namespace My_vals {
const vector val{4209};
}
}
--
The error:
error: ‘val’ is not a member of ‘My_vals’.
Remove const and it works.
With the traditional headers, const causes no issue.
GCC 12.1.0 - Linux
Thanks
[Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105460 --- Comment #4 from Eric Gallager --- This seems like it might be related to bug 105460
[Bug c++/105516] New: auto() is incorrectly parsed as declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105516
Bug ID: 105516
Summary: auto() is incorrectly parsed as
declaration
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cooky.ykooc922 at gmail dot com
Target Milestone: ---
>From the code snippet below:
int main() {
int x = 1;
auto(1); // ok
static_cast(auto(x)); // ok
auto{x}; // ok
auto(x); // error
}
The compiler emits an error with a message:
: In function 'int main()':
:6:3: error: declaration of 'auto x' has no initializer
6 | auto(x); // error
| ^~~~
Compiler returned: 1
This should be valid because the expression statement line 6 contains a valid
explicit type conversion `auto(expression)`, where a parser may misinterpret it
as a declaration with an `auto` specifier that contains an identifier and no
initializer but is obviously enclosed with parenthesis or maybe because it
would parse as function reference or pointer declaration that has `auto`
declared return type just like:
auto (*fn)() = +[]{ return 0; };
But i'm unsure, it's just a guest anyway :>
Flag: -std=c++23
Compiler Explorer Link: https://godbolt.org/z/xoKa9Kzch
[Bug c++/105516] auto() is incorrectly parsed as declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105516 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Not a bug, "auto(x);" is interpreted as "auto x;". Use +auto(x); if you want that to be an expression.
[Bug c++/105516] auto() is incorrectly parsed as declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105516 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #2 from 康桓瑋 --- Dup of PR103653?
[Bug c++/47634] Incorrect checking of attribute format printf on constructor of derived class with virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:0c723bb4be2a67657828b692997855afcdc5d286
commit r13-167-g0c723bb4be2a67657828b692997855afcdc5d286
Author: Marek Polacek
Date: Thu Mar 31 18:31:39 2022 -0400
c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63030 clarified that "Since non-static C++ methods have
an implicit this argument, the arguments of such methods should be counted
from two, not one, when giving values for string-index and first-to-check."
Therefore one has to write
struct D {
D(const char *, ...) __attribute__((format(printf, 2, 3)));
};
However -- and this is the problem in this PR -- ctors with virtual
bases also get two additional parameters: the in-charge parameter and
the VTT parameter (added in maybe_retrofit_in_chrg). In fact we'll end up
with two clones of the ctor: an in-charge and a not-in-charge version (see
build_cdtor_clones). That means that the argument position the user
specified in the attribute argument will refer to different arguments,
depending on which constructor we're currently dealing with. This can
cause a range of problems: wrong errors, confusing warnings, or crashes.
This patch corrects that; for C we don't have to do anything, and in C++
we can use num_artificial_parms_for. It would be wrong to rewrite the
attributes the user supplied, so I've changed POS to be passed by
reference so that we don't have to change all the call sites of
positional_argument and we still get the default_conversion adjustment.
Attribute format_arg is not affected, because it requires that the
function returns "const char *" which will never be the case for cdtors.
PR c++/101833
PR c++/47634
gcc/c-family/ChangeLog:
* c-attribs.cc (positional_argument): Pass POS by reference. Deal
with FN being either a function declaration or function type. Use
maybe_adjust_arg_pos_for_attribute.
* c-common.cc (check_function_arguments): Maybe pass FNDECL down to
check_function_format.
* c-common.h (maybe_adjust_arg_pos_for_attribute): Declare.
(positional_argument): Adjust.
* c-format.cc (get_constant): Rename to ...
(validate_constant): ... this. Take EXPR by reference. Return
bool
instead of tree.
(handle_format_arg_attribute): Don't overwrite FORMAT_NUM_EXPR by
the
return value of validate_constant.
(decode_format_attr): Don't overwrite FORMAT_NUM_EXPR and
FIRST_ARG_NUM_EXPR by the return value of validate_constant.
(check_function_format): Adjust a parameter name.
(handle_format_attribute): Maybe pass FNDECL down to
decode_format_attr.
gcc/c/ChangeLog:
* c-objc-common.cc (maybe_adjust_arg_pos_for_attribute): New.
gcc/cp/ChangeLog:
* tree.cc (maybe_adjust_arg_pos_for_attribute): New.
gcc/ChangeLog:
* tree-core.h (struct attribute_spec): Update comment for HANDLER.
gcc/testsuite/ChangeLog:
* g++.dg/ext/attr-format-arg1.C: New test.
* g++.dg/ext/attr-format1.C: New test.
* g++.dg/ext/attr-format2.C: New test.
* g++.dg/ext/attr-format3.C: New test.
[Bug c++/101833] [9/10/11/12/13 Regression] ICE with -Wformat on a constructor with a virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101833
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:0c723bb4be2a67657828b692997855afcdc5d286
commit r13-167-g0c723bb4be2a67657828b692997855afcdc5d286
Author: Marek Polacek
Date: Thu Mar 31 18:31:39 2022 -0400
c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63030 clarified that "Since non-static C++ methods have
an implicit this argument, the arguments of such methods should be counted
from two, not one, when giving values for string-index and first-to-check."
Therefore one has to write
struct D {
D(const char *, ...) __attribute__((format(printf, 2, 3)));
};
However -- and this is the problem in this PR -- ctors with virtual
bases also get two additional parameters: the in-charge parameter and
the VTT parameter (added in maybe_retrofit_in_chrg). In fact we'll end up
with two clones of the ctor: an in-charge and a not-in-charge version (see
build_cdtor_clones). That means that the argument position the user
specified in the attribute argument will refer to different arguments,
depending on which constructor we're currently dealing with. This can
cause a range of problems: wrong errors, confusing warnings, or crashes.
This patch corrects that; for C we don't have to do anything, and in C++
we can use num_artificial_parms_for. It would be wrong to rewrite the
attributes the user supplied, so I've changed POS to be passed by
reference so that we don't have to change all the call sites of
positional_argument and we still get the default_conversion adjustment.
Attribute format_arg is not affected, because it requires that the
function returns "const char *" which will never be the case for cdtors.
PR c++/101833
PR c++/47634
gcc/c-family/ChangeLog:
* c-attribs.cc (positional_argument): Pass POS by reference. Deal
with FN being either a function declaration or function type. Use
maybe_adjust_arg_pos_for_attribute.
* c-common.cc (check_function_arguments): Maybe pass FNDECL down to
check_function_format.
* c-common.h (maybe_adjust_arg_pos_for_attribute): Declare.
(positional_argument): Adjust.
* c-format.cc (get_constant): Rename to ...
(validate_constant): ... this. Take EXPR by reference. Return
bool
instead of tree.
(handle_format_arg_attribute): Don't overwrite FORMAT_NUM_EXPR by
the
return value of validate_constant.
(decode_format_attr): Don't overwrite FORMAT_NUM_EXPR and
FIRST_ARG_NUM_EXPR by the return value of validate_constant.
(check_function_format): Adjust a parameter name.
(handle_format_attribute): Maybe pass FNDECL down to
decode_format_attr.
gcc/c/ChangeLog:
* c-objc-common.cc (maybe_adjust_arg_pos_for_attribute): New.
gcc/cp/ChangeLog:
* tree.cc (maybe_adjust_arg_pos_for_attribute): New.
gcc/ChangeLog:
* tree-core.h (struct attribute_spec): Update comment for HANDLER.
gcc/testsuite/ChangeLog:
* g++.dg/ext/attr-format-arg1.C: New test.
* g++.dg/ext/attr-format1.C: New test.
* g++.dg/ext/attr-format2.C: New test.
* g++.dg/ext/attr-format3.C: New test.
[Bug c++/101833] [9/10/11/12 Regression] ICE with -Wformat on a constructor with a virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101833 Marek Polacek changed: What|Removed |Added Summary|[9/10/11/12/13 Regression] |[9/10/11/12 Regression] ICE |ICE with -Wformat on a |with -Wformat on a |constructor with a virtual |constructor with a virtual |base|base Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed for GCC 13. I don't have plans to backport this.
[Bug c++/47634] Incorrect checking of attribute format printf on constructor of derived class with virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Fixed for GCC 13.
[Bug tree-optimization/105517] New: [13 Regression] Missing diagnostic after recent optimizer improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105517 Bug ID: 105517 Summary: [13 Regression] Missing diagnostic after recent optimizer improvements Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- This change: commit ee1cb43bc76de800efa0ade687b0cd28e62a5f82 Author: Richard Biener Date: Wed Jan 26 15:34:54 2022 +0100 tree-optimization/104162 - CSE of &MEM[ptr].a[i] and ptr + CST This adds the capability to value-numbering of treating complex address expressions where the offset becomes invariant as equal to a POINTER_PLUS_EXPR. This restores CSE that is now prevented by early lowering of &MEM[ptr + CST] to a POINTER_PLUS_EXPR. Unfortunately this regresses gcc.dg/asan/pr99673.c again, so the testcase is adjusted accordingly. 2022-01-26 Richard Biener PR tree-optimization/104162 * tree-ssa-sccvn.cc (vn_reference_lookup): Handle &MEM[_1 + 5].a[i] like a POINTER_PLUS_EXPR if the offset becomes invariant. (vn_reference_insert): Likewise. * gcc.dg/tree-ssa/ssa-fre-99.c: New testcase. * gcc.dg/asan/pr99673.c: Adjust. Is causing various ports (ft32-elf for example) to fail the Warray-bounds.c test: Running /home/jlaw/test/gcc/gcc/testsuite/gcc.dg/dg.exp ... FAIL: c-c++-common/Warray-bounds.c -Wc++-compat (test for warnings, line 187) FAIL: c-c++-common/Warray-bounds.c -Wc++-compat (test for warnings, line 188) I think you ought to be able to see this with just a cross compiler and shouldn't need a full cross environment. I haven't debugged this in any way other than bisection.
[Bug c++/105518] New: [rejects valid] nested lambda using an outer type alias fails with constexpr integer in that alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105518
Bug ID: 105518
Summary: [rejects valid] nested lambda using an outer type
alias fails with constexpr integer in that alias
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leventyilmaz at gmail dot com
Target Milestone: ---
The following valid code is fails to compile.
https://godbolt.org/z/v1sd9snGx
// Simple run-time to compile-time integer conversion:
template
auto toStatic(int i, F f) {
switch(i) {
case 0: return f( std::integral_constant{} );
case 1: return f( std::integral_constant{} );
case 2: return f( std::integral_constant{} );
default: assert("too big");
}
}
// example types:
struct Base {
virtual void show() const = 0;
};
template struct F {
template struct K : Base {
void show() const override {
std::cout << I << " " << J << std::endl;
}
};
};
// nested lambda complains "I" is not captured
// even though it is only being used at compile-time
void show(int i, int j) {
return toStatic(i, [j](auto I) {
using A = F;
// using A = F; // this works
return toStatic(j, [](auto J) {
using impl = typename A::template K;
impl{}.show();
});
});
}
source>:32:19: error: 'I' is not captured
32 | using impl = typename A::template K;
| ^~~~
[Bug target/96248] Closing quote in wrong position in config/rs6000/rs6000.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96248 Göran Uddeborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Göran Uddeborg --- This has been fixed in 12.1-b20220403.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 96248, which changed state. Bug 96248 Summary: Closing quote in wrong position in config/rs6000/rs6000.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96248 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug testsuite/105486] new test case gcc.dg/vect/bb-slp-pr104240.c from r13-71-g41e3db05d69740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Roger Sayle --- Fixed on mainline. According to https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761073.html neither pr102950.c nor vect/bb-slp-pr104240.c are currently failing on powerpc64.
[Bug tree-optimization/102950] [11/12 Regression] Dead Code Elimination Regression at -O3 (11.2.0 vs 10.3.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102950 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|NEW Summary|[11/12/13 Regression] Dead |[11/12 Regression] Dead |Code Elimination Regression |Code Elimination Regression |at -O3 (trunk&11.2.0 vs |at -O3 (11.2.0 vs 10.3.0) |10.3.0) | Target Milestone|11.4|13.0 Known to work||13.0 Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot gnu.org --- Comment #7 from Roger Sayle --- This has now been fixed on mainline.
[Bug rtl-optimization/105519] New: Unnecessary memcpy() copy for empty asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105519
Bug ID: 105519
Summary: Unnecessary memcpy() copy for empty asm volatile
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alexgpg at gmail dot com
Target Milestone: ---
Created attachment 52937
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52937&action=edit
Source code preprocessed file
Use asm volatile("" : "+m,r"(value) : : "memory") with specific constraints
("+m,r") with large objects(array or structs with size > 8192) cause full copy
for object and that copy stay unused.
Maybe it's an issue in the register allocator. The compiler uses "r" instead of
"m" even for large objects.
The following code cause caused unnecessary copying with memcpy()
```
struct Large {
int arr[2049];
};
extern Large obj;
namespace {
template
inline __attribute__((always_inline)) void DoNotOptimize(Tp& value) {
asm volatile("" : "+m,r"(value) : : "memory");
}
}
void foo() {
DoNotOptimize(obj);
}
```
Generate assembly code
g++ -Wall -Wextra -O3 -save-temps -fno-stack-protector -S do_not_optimize.cpp
Generated assembly code (x86_64)
```
foo():
subq $8216, %rsp # 1. Extend stack size
movl $8196, %edx # 2. %edx = 8196 = sizeof(Large) = sizeof(int) * 2049.
#Prepare 3d arg (n - size) for memcpy()
leaq obj(%rip), %rsi # 3. %rsi = &obj. Prepare 2d arg (src) for memcpy().
movq %rsp, %rdi # 4. %rdi = %rsp. %rdi points to the top of the stack.
#Prepace 1-st arg (dest) for memcpy().
call memcpy@PLT # 5. Call memcpy(dest=%rdi, src=%rsi ,n=%edx=8196)
addq $8216, %rsp # 6. Reduce stack size
ret# 7. Return from function
```
What code do?
1. Extent stack size (line 1)
2. Copy data to new extended space in stack (line 2-7)
3. Reduce stack size back (line 6)
Looks like copy is not needed.
Notes
* -fno-stack-protector used just for small assembly code. Enable stack
protection doesn't change behavior
* gcc generates memcpy() call only if size of object > 8192
* https://godbolt.org/z/hPYfcrqbW - Godbolt Compiler Explorer Playground
Versions: 11.2.0, but looks like versions 4.1.2 - 11.12(all available on
godbolt) is also affected
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=
/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style
=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-defaul
t-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-sh
ared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror --with-build-config=bootstrap-lto --enable-link-serialization
=1 gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)
[Bug rtl-optimization/105519] Unnecessary memcpy() copy for empty asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105519
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
There is a tempory because of r and such.
asm volatile("" : "+m,r"(*(Tp*)&value) : : "memory");
That is r requires a copy and such.
[Bug rtl-optimization/105519] Unnecessary memcpy() copy for empty asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105519 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71246 --- Comment #2 from Andrew Pinski --- If you don't want to optimize out a store to DoNotOptimize, there are other ways of doing it.
[Bug rtl-optimization/105519] Unnecessary memcpy() copy for empty asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105519
--- Comment #3 from Andrew Pinski ---
template
__attribute__((noipa)) void DoNotOptimize(Tp& value) {}
Is a better way. Yes it will still have a function call but really this is just
all to do microbenchmarking so it is not even a high thing to deal with.
[Bug c++/105520] New: Ignores constraint in auto declaration with braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105520
Bug ID: 105520
Summary: Ignores constraint in auto declaration with
braced-init-list
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cooky.ykooc922 at gmail dot com
Target Milestone: ---
>From the code snippet below:
#include
#include
template
concept always_true = true;
template
concept always_false = false;
template
inline constexpr bool is_init_list_v = false;
template
inline constexpr bool is_init_list_v> = true;
template
concept not_init_list = !is_init_list_v>;
int main() {
always_true auto a = 10; // ok
always_true auto b = {1, 2, 3}; // ok
// always_false auto c = 10; // error as expected
// always_false auto d = {1, 2, 3}; // error as expected
not_init_list auto e = 10; // ok
not_init_list auto f = {1, 2, 3}; // no error but unexpected
// error as expected below:
// not_init_list auto g = std::initializer_list{1, 2, 3};
}
GCC accepts invalid code from `not_init_list auto f = {1, 2, 3}`, while Clang
rejects it as expected showing:
:27:5: error: deduced type 'std::initializer_list' does not
satisfy 'not_init_list'
not_init_list auto f = {1, 2, 3}; // no error but unexpected
^~
:17:25: note: because
'!is_init_list_v > >' evaluated to
false
concept not_init_list = !is_init_list_v>;
^
compiler flag: -std=c++20
compiler explorer link: https://godbolt.org/z/G569rxb8f
[Bug c++/105520] Ignores constraint in auto declaration with braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105520 Desmond Gold changed: What|Removed |Added Version|12.0|10.0 --- Comment #1 from Desmond Gold --- GCC 10.1 to GCC trunk accept this invalid code
[Bug c/105521] New: missed optimization in modulo arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521
Bug ID: 105521
Summary: missed optimization in modulo arithmetic
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
I'm trying to compute (a*a)%n for uint64_t types on x86_64 using "gcc -O2 -W
-Wall" like this:
#include
#include
uint64_t sqrmod(uint64_t a, uint64_t n) {
assert(a < n);
unsigned __int128 x = a;
x *= a;
return x % n;
}
I expected to get the following code:
sqrmod:
cmpq%rsi, %rdi
jnb .L13 // assert(a < n) failure
movq%rdi, %rax
mul %rdi
div %rsi
movq%rdx, %rax
ret
The compiler does get the "mul" right but instead of the "div" it throws in a
call to "__umodti3". The "__umodti3" function is horribly long code that will
be worlds slower than a simple div.
Note: The "asset(a < n);" should tell the compiler that the "div" instruction
can not overflow and will not cause a #DivisionError. Without the assert the
compiler could (conditionally) add "a %= n;" for the same effect.
https://godbolt.org/z/cd57Wd4oo
[Bug target/105521] missed optimization in modulo arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521 Andrew Pinski changed: What|Removed |Added Component|middle-end |target Target||x86_64-*-* --- Comment #1 from Andrew Pinski --- This requires having a, 64bit/32bit (and 128bit/64bit) pattern really. So this is both a middle-end issue and a target issue. Note there might be another bug asking for the same optimization. Also note x86_64 might be the only popular target which has this kind of div instruction so this might not get any attention as it is also a small peephole where most people don't use 128bit integers either (they are non-standard even).
[Bug target/105521] missed optimization in modulo arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-05-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- .
[Bug target/105521] missed optimization in modulo arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/105522] New: gcc11: internal compiler error: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 Bug ID: 105522 Summary: gcc11: internal compiler error: in decode_addr_const, at varasm.c:3059 Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vital.had at gmail dot com CC: iains at gcc dot gnu.org Target Milestone: --- Target: powerpc-apple-darwin Created attachment 52938 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52938&action=edit Build log in a case needed ``` 36-111% /opt/local/bin/gcc-mp-11 -DSDL2_EXPORTS -DUSING_GENERATED_CONFIG_H -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/build/include -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/include -pipe -Os -DNDEBUG -I/opt/local/include -idirafter "/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/video/khronos" -I/opt/local/include/libusb-1.0 -D_THREAD_SAFE -Wshadow -fvisibility=hidden -Wdeclaration-after-statement -fno-strict-aliasing -Wall -arch ppc -mmacosx-version-min=10.6 -fPIC -MD -MT CMakeFiles/SDL2.dir/src/hidapi/SDL_hidapi.c.o -MF CMakeFiles/SDL2.dir/src/hidapi/SDL_hidapi.c.o.d -o CMakeFiles/SDL2.dir/src/hidapi/SDL_hidapi.c.o -c /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/SDL_hidapi.c In file included from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/SDL_hidapi.c:578: /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c: In function 'PLATFORM_free_hid_device': /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:163:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 163 | struct input_report *rpt = dev->input_reports; | ^~ /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c: In function 'get_string_property': /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:265:17: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 265 | CFIndex str_len = CFStringGetLength(str); | ^~~ /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:269:17: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 269 | CFIndex used_buf_len; | ^~~ /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c: In function 'get_string_property_utf8': /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:304:17: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 304 | CFIndex str_len = CFStringGetLength(str); | ^~~ /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:308:17: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 308 | CFIndex used_buf_len; | ^~~ In file included from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/SDL_hidapi.c:578: /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c: In function 'PLATFORM_hid_enumerate': /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:530:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 530 | CFSetRef device_set = IOHIDManagerCopyDevices(hid_mgr); | ^~~~ /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:540:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 540 | IOHIDDeviceRef *device_array = (IOHIDDeviceRef*)calloc(num_devices, sizeof(IOHIDDeviceRef)); | ^~ /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c: In function 'PLATFORM_read_thread': /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2/libsdl2/work/SDL2-2.0.22/src/hidapi/mac/hid.c:742:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 742 | CFRunLoo
