[Bug c++/105446] New: [modules] Partitions: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105446
Bug ID: 105446
Summary: [modules] Partitions: Segfault
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deco33000 at yandex dot com
Target Milestone: ---
Hi,
I have a segfault at runtime with no compilation issue, even without calling
the function in the partition:
---
mod.cxx:
module;
#include
#include
#include
export module hello;
export import :sub_mod;
namespace X {
inline unsigned gv = 52;
void greeter2 ( std::string_view const &name ){
std::string h = "non 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("greet2");
}
}
}
---
mod_sub.cxx:
module;
#include
export module hello:sub_mod;
namespace Y {
auto g (){
std::cout << "in out" << std::endl;
}
}
---
main.cpp
import hello;
int main ( void ){
X::greeter( "world" );
return 0;
}
---
compilation:
/path/custom/g++ g++ -std=gnu++20 -fmodules-ts mod_sub.cxx mod.cxx main.cpp
Result: Segfault at runtime.
Thanks,
[Bug c/105447] New: load introduction when reading an adjacent variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105447
Bug ID: 105447
Summary: load introduction when reading an adjacent variable
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
given the following code:
#include
#pragma pack(1)
struct S2 {
int f0;
short f1;
};
struct S2 g_32[2][2][1] =
0x200CC90FL,0x27C9L}},{{0x9A802726L,0x125BL}}},{{{0xE23F1199L,-4L}},{{4294967292UL,0xD72EL;
void f1(struct S2 p1){
p1.f1+=1;
int* p=(void*)&p1;
printf("%x\n",p[1]);
}
int main(){
scanf("%d", &g_32[0][1][0].f0);
f1(g_32[0][0][0]);
}
when it's compiled on gcc-11.3.0 with -O2/-O1 option, the second statement in
main() will be translated as:
0x00401044 <+4>: mov0x2fe5(%rip),%rdi# 0x404030
0x0040104b <+11>:callq 0x401150
it just load first 8 bytes of g_32 directly as argument, thus in f1(), the
first 2 bytes of g_32[0][1][0] can be read. For example, when executing this
program and input 1, then the output would be 127ca, which could lead to
vulnerabilities
[Bug c++/105446] [modules] Partitions: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105446 --- Comment #1 from KL --- gcc-12.1.0-RC-20220429
[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105432 --- Comment #11 from CVS Commits --- The trunk branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:75bbc3da3e5f75f683fa33e309045c582efd20eb commit r13-60-g75bbc3da3e5f75f683fa33e309045c582efd20eb Author: Aldy Hernandez Date: Fri Apr 29 22:46:25 2022 +0200 Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw. We are ICEing in set_range_info_raw because value_range_kind cannot be VR_VARYING, since SSA_NAME_RANGE_TYPE can only hold VR_RANGE / VR_ANTI_RANGE. Most of the time setting a VR_VARYING as a global range makes no sense. However, we can have a range spanning the entire domain (VR_RANGE of [MIN,MAX] which is essentially a VR_VARYING), if the nonzero bits are set. This was working before because set_range_info_raw allows setting VR_RANGE of [MIN, MAX]. However, when going through an irange, we normalize this to a VR_VARYING, thus causing the ICE. It's interesting that other calls to set_range_info with an irange haven't triggered this. One solution would be to just ignore VR_VARYING and bail, since set_range_info* is really an update of the current range semantic wise. After all, we keep the nonzero bits which provide additional info. But this would be a change in behavior, so not suitable until after GCC 12 is released. So in order to keep with current behavior we can just denormalize the varying to VR_RANGE. Tested on x86-64 Linux. PR tree-optimization/105432 gcc/ChangeLog: * tree-ssanames.cc (set_range_info): Denormalize VR_VARYING to VR_RANGE before passing a piecewise range to set_range_info_raw.
[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105432 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Aldy Hernandez --- Fixed in mainline. Sorry for the delay. I had previous weekend commitments I wasn't able to reschedule. Hopefully it didn't cause too much pain over the weekend.
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 --- Comment #14 from Avi Kivity --- Do you confirm that my observation about the generated gimple corresponds to the bug? If so, is there a central point where this anonymous variables are named? Perhaps we can breakpoint on D.2741 and see where the copy is generated.
[Bug target/105448] New: load introduced when passing a struct as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105448
Bug ID: 105448
Summary: load introduced when passing a struct as argument
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
Created attachment 52915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52915&action=edit
C source file where a struct field has been loaded repeatedly
Hi, I find in this code: (the full file has been uploaded)
...
struct S0 {
const uint64_t f0;
int32_t f1;
int64_t f2;
int32_t f3;
int64_t f4;
const int32_t f5;
};
struct S0 g_19 = {0xF4275799D45EB447LL,0xD326D35DL,1L,1L,9L,0L};
...
const int16_t func_2(uint32_t p_3, const struct S1 p_4)
{
if (func_7(g_19, 0, g_20))
{
return 0;
}
return g_6.f1;
}
int32_t func_7(struct S0 p_10, uint32_t p_11, int32_t p_12)
{
func_21(0, g_26, p_10);
return p_10.f1;
}
int32_t func_21(int32_t p_22, int64_t p_23, struct S0 p_24)
{
if ((g_5[0] - (g_5[1] != p_23)) )
{
g_19.f3 = p_24.f4;
}
return g_5[4];
}
int main(){
...
func_2(0, g_6);
...
}
when compiled on gcc-11.3.0 with O1 option, func_2 will be compiled as:
...
0x0040118a <+5>: movdqa 0x2ece(%rip),%xmm0 # 0x404060
0x00401192 <+13>:movaps %xmm0,(%rsp)
0x00401196 <+17>:mov0x2ecc(%rip),%ebx # 0x404068
0x0040119c <+23>:mov%ebx,0x8(%rsp)
0x004011a0 <+27>:pushq 0x2ee2(%rip)# 0x404088
0x004011a6 <+33>:pushq 0x2ed4(%rip)# 0x404080
0x004011ac <+39>:pushq 0x2ec6(%rip)# 0x404078
0x004011b2 <+45>:pushq 0x2eb8(%rip)# 0x404070
...
it's obvious that g_19.f1 has been loaded twice in the first and third
instruction abnormally.
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #7 from Eric Gallager --- (In reply to Jonathan Wakely from comment #5) > Patch posted to https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01511.html I thought the format code for size_t was %zu?
[Bug c++/105351] [concepts] Constraint checking does correctly match static member attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105351 --- Comment #4 from Gawain Bolton --- I am confused as to how the requirement expression be valid and yet not be evaluated. This is also not consistent with how the requirement check is done for functions. Finally, this also begs the question as to how one could write a requirement to ensure a class has a static attribute.
[Bug c/105449] New: suspicious optimization since GCC 10.1.0 from -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105449 Bug ID: 105449 Summary: suspicious optimization since GCC 10.1.0 from - Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gilles.gouaillardet at gmail dot com Target Milestone: ---
[Bug c/105449] suspicious optimization since GCC 10.1.0 from -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105449 --- Comment #1 from Gilles Gouaillardet --- Created attachment 52916 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52916&action=edit a simple reproducer
[Bug c/105449] suspicious optimization since GCC 10.1.0 from -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105449 Gilles Gouaillardet changed: What|Removed |Added CC||gilles.gouaillardet at gmail dot c ||om Summary|suspicious optimization |suspicious optimization |since GCC 10.1.0 from - |since GCC 10.1.0 from -O2 --- Comment #2 from Gilles Gouaillardet --- The attached reproducer works fine when using -O1 or less aggressive optimization and on all GCC versions I tested. However, starting from GCC 10.1.0 and when using -O2 or more aggressive optimization, the local_pos() subroutine behaves differently compared to the global_pos() and volatile_pos() subroutines. All these subroutines do virtually the same things, but only the declaration of the bogus variable changes. I suspect recent GCC versions perform some register inlining when the bogus variable is declared as local and non volatile. Can you please have a look at the reproducer and establish whether: - this reproducer has an undefined behavior, and the recent optimizations are legit - this is a bug in GCC >= 10.1.0 For the record, here are my logs (on a x86_64 system, same behavior on aarch64. Though I did not test, a different behavior is expected on a 64 bits big endian processor). $ gcc --version gcc (GCC) 11.2.0 Copyright (C) 2021 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. $ gcc bug.c && ./a.out global: 0 local: 0 volatile: 0 $ gcc -O2 bug.c && ./a.out global: 0 local: 2 <--- UNEXPECTED VALUE volatile: 0 FWIW, a consequence of this optimization is an issue that has been reported at https://github.com/open-mpi/ompi/issues/10339
[Bug c/105449] suspicious optimization since GCC 10.1.0 from -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105449
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
You are violating C/C++ aliasing rules.
You have a store as "void*" but then access it as an "int*"
void * bogus = (void*) 1;
int *p = (int *) &bogus;
...
if (p[pos] == 1) {
[Bug c/105449] suspicious optimization since GCC 10.1.0 from -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105449 --- Comment #4 from Gilles Gouaillardet --- Thanks for the clarification!
[Bug libstdc++/105450] New: get_time %y reads more than 2 digits (and differ from strptime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105450
Bug ID: 105450
Summary: get_time %y reads more than 2 digits (and differ from
strptime)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fsb4000 at yandex dot ru
Target Milestone: ---
Hi.
MattStephanson found that std::get_time with %y differ from strptime.
I decided to inform you.
https://godbolt.org/z/YaMM5PdnT
```c++
#include
#include
#include
#include
#include
#include
using namespace std;
void test_get_time(const vector& dates) {
for (const auto& date : dates) {
tm time{};
istringstream iss{date};
iss >> get_time(&time, "%y");
cout << "get_time: \"" << date << "\"; 1900 + time.tm_year: " << 1900 +
time.tm_year << endl;
}
}
void test_get_year(const vector& dates) {
const auto& f = use_facet>(locale{});
for (const auto& date : dates) {
tm time{};
ios_base::iostate err = ios_base::goodbit;
istringstream iss{date};
f.get_year({iss}, {}, iss, err, &time);
cout << "get_year: \"" << date << "\"; 1900 + time.tm_year: " << 1900 +
time.tm_year << endl;
}
}
void test_strptime(const vector& dates) {
for (const auto& date : dates) {
tm time{};
strptime(date.c_str(), "%y", &time);
cout << "strptime: \"" << date << "\"; 1900 + time.tm_year: " << 1900 +
time.tm_year << endl;
}
}
int main() {
vector dates = {"1"s, "01"s, "85"s, "085"s, "111"s};
test_get_time(dates);
cout << '\n';
test_get_year(dates);
cout << '\n';
test_strptime(dates);
}
```
This code prints:
get_time: "085"; 1900 + time.tm_year: 85
get_time: "111"; 1900 + time.tm_year: 111
and
strptime: "085"; 1900 + time.tm_year: 2008
strptime: "111"; 1900 + time.tm_year: 2011
[Bug libstdc++/105450] get_time %y reads more than 2 digits (and differ from strptime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105450 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 103612. *** This bug has been marked as a duplicate of bug 103612 ***
[Bug libstdc++/103612] get_time parsing error for two digits year
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103612 Andrew Pinski changed: What|Removed |Added CC||fsb4000 at yandex dot ru --- Comment #3 from Andrew Pinski --- *** Bug 105450 has been marked as a duplicate of this bug. ***
[Bug libstdc++/103612] get_time %y parsing error for two digits year
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103612 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77760 --- Comment #4 from Andrew Pinski --- Looks like this actually might have gotten fixed for GCC 12. See bug #77760 comment #2 for the commit.
[Bug target/105435] clang warning about Wtautological-constant-compare for a target macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105435 Andrew Pinski changed: What|Removed |Added Keywords|diagnostic | Summary|Wtautological-constant-comp |clang warning about |are warning in trunk build |Wtautological-constant-comp ||are for a target macro --- Comment #3 from Andrew Pinski --- The easiest fix is to change: if (TARGET_ARM_FP) To: if (TARGET_ARM_FP != 0) But then again clang maybe should not warn when this is coming from a macro.
[Bug libstdc++/103612] get_time %y parsing error for two digits year
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103612 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- %y and %Y behave differently, %Y is always the full year, 0-, up to 4 digits. %y is if 0-99, up to 2 digits using the POSIX rules 0-68 is 2000 to 2068, 69-99 is 1969 to 1999, but intentionally for backwards compatibility if it is actually 3 or 4 digits, it is treated as %Y because that is how libstdc++ has been treating it for years.
[Bug libstdc++/103612] get_time %y parsing error for two digits year
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103612 --- Comment #6 from Jakub Jelinek --- Note, the above is GCC 12 behavior, in 11.x and earlier it has been indeed broken and %y and %C were aliases to %Y.
[Bug target/105435] clang warning about Wtautological-constant-compare for a target macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105435
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Andrew Pinski ---
The problem is clang tries to be smart and then recusively warn but that is
broken.
Take:
TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0
clang will even warn about that case.
That is:
#define TARGET_ARM_FP \
(TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0)
#define TARGET_VFP_DOUBLE (1)
#define TARGET_FP16 (1)
int f(int t, int tt)
{
if (TARGET_ARM_FP) return 1;
return 2;
}
And yes just changing it to:
if (TARGET_ARM_FP != 0)
fixes the "warning" but the warning should really be fixed instead.
[Bug c++/105438] Incorrect array-bounds warning with array size carried over from a previous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438 --- Comment #2 from Bernie Innocenti --- GCC 12.0.1 20220413 (Red Hat 12.0.1-0) gives a more helpful diagnostic with inlining backtrace: In function ‘void configure(const int (&)[N], int) [with int N = 7]’, inlined from ‘void configure(const int (&)[N], int) [with int N = 2]’ at testcase.cc:8:6, inlined from ‘int main()’ at gcc-array-bounds-bug-testcase.cc:22:12: testcase.cc:14:24: warning: array subscript ‘const int [7][0]’ is partly outside array bounds of ‘int [2]’ [-Warray-bounds] 14 | out[i] = in[i]; | ~~^ Note how configure() was inlined into configure().
[Bug c++/105438] Incorrect array-bounds warning with array size carried over from a previous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438 --- Comment #3 from Bernie Innocenti --- Not sure if this is helpful, but the IPA dump also shows two calls to configure() with N=7 and none with N=2: IPA function summary for int main()/3 inlinable global time: 26.00 self size: 9 global size: 9 min size: 6 self stack: 0 global stack:0 size:0.00, time:0.00 size:3.00, time:2.00, executed if:(not inlined) calls: void configure(const int (&)[N], int) [with int N = 7]/6 function not considered for inlining freq:1.00 loop depth: 0 size: 3 time: 12 callee size: 5 stack: 0 op0 is compile time invariant op1 is compile time invariant void configure(const int (&)[N], int) [with int N = 7]/6 function not considered for inlining freq:1.00 loop depth: 0 size: 3 time: 12 callee size: 5 stack: 0 op0 is compile time invariant op1 is compile time invariant
[Bug c++/105438] Incorrect array-bounds warning with array size carried over from a previous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438 --- Comment #4 from Bernie Innocenti --- Furthermore, after the inline pass main() has a reference to the shorter array with an annotation of int[7], which is clearly wrong: [local count: 939524097]: _5 = MEM[(const int[7] &)&shorter][i_4]; out[i_4] = _5; i_6 = i_4 + 1;
[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/105437] [11/12/13 Regression] ICE on GIMPLE pass slp when vectorizer is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105437 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||ice-on-valid-code Summary|ICE on GIMPLE pass slp when |[11/12/13 Regression] ICE |vectorizer is enabled |on GIMPLE pass slp when ||vectorizer is enabled Target Milestone|--- |11.4 Last reconfirmed||2022-05-02 Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug ipa/105438] Incorrect array-bounds warning with array size carried over from a previous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |ipa Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Last reconfirmed||2022-05-02 Blocks||56456 --- Comment #5 from Richard Biener --- It's IPA ICF that merges the two functions. We then end up inlining but not using the original function body but the merged one. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c/105444] Support for disabling all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105444 Richard Biener changed: What|Removed |Added Severity|normal |enhancement Version|unknown |12.0
[Bug ipa/105438] [11/12/13 Regression] Incorrect array-bounds warning with array size carried over from a previous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4 Summary|Incorrect array-bounds |[11/12/13 Regression] |warning with array size |Incorrect array-bounds |carried over from a |warning with array size |previous template |carried over from a |instantiation |previous template ||instantiation --- Comment #6 from Andrew Pinski --- (In reply to Richard Biener from comment #5) > It's IPA ICF that merges the two functions. We then end up inlining but not > using the original function body but the merged one. I wonder if we could get wrong code because of that ...
