[Bug c++/113966] New: Internal compiler error in `do_auto_deduction`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966
Bug ID: 113966
Summary: Internal compiler error in `do_auto_deduction`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mateusz.pusz at gmail dot com
Target Milestone: ---
The following ICE has been happening for a longer time now for
https://godbolt.org/z/7EK64PPr6:
```
quantity.h:316:9: internal compiler error: in do_auto_deduction, at
cp/pt.cc:31135
315 | {
| ~
316 | a += b
| ^~
317 | } -> std::same_as;
| ~~~
0x264d1cc internal_error(char const*, ...)
???:0
0xa526c5 fancy_abort(char const*, int, char const*)
???:0
0xad5976 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0xacf547 maybe_substitute_reqs_for(tree_node*, tree_node const*)
???:0
0xcb4d66 instantiate_class_template(tree_node*)
???:0
0xd0b594 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0xd0b6ac require_complete_type(tree_node*, int)
???:0
0xa6d24d build_cxx_call(tree_node*, int, tree_node**, int, tree_node*)
???:0
0xa87af8 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xd0e002 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xc555aa c_parse_file()
???:0
0xda9739 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug testsuite/113965] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails with qemu due to _Float16 rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 --- Comment #3 from Andrew Pinski --- Created attachment 57443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57443=edit Reduced testcase Attached is the reduced testcase that I was using here.
[Bug testsuite/113965] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails with qemu due to _Float16 rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |testsuite Blocks|53947 | Target Milestone|14.0|--- Summary|[14 Regression] |gcc.target/aarch64/sve/mask |gcc.target/aarch64/sve/mask |_struct_load_3_run.c still |_struct_load_3_run.c still |fails with qemu due to |fails |_Float16 rounding error --- Comment #2 from Andrew Pinski --- I think this might be a rounding issue with qemu and _Float16 I think. So _Float16 has 10/11 bits of Significand precision which means it can represent 0 - 2047 and then outside of that it will need to truncate some bits. In the testcase the first time where we get a failure is: i: 40 mask: 1 out[i]: 2906.00 if_true: 2904.00 if_false: 140.00 expected[i]: 2904.00 As you can see there is one bit difference at the end. I have not looked into why not using SVE here we are able to get the correct value though. But I can say for sure that the vectorizer is doing the correct thing in that using "unsigned short" instead produces the exact same .optimized file out for the function (test_f16_f16_i8_4). So removing the regression markers and moving this to testsuite as I think this is not an issue with the code generation. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/113965] [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 --- Comment #1 from Andrew Pinski --- Hmm, debugging this a little further, this might be a qemu issue with fp16 support
[Bug c++/113958] support visibility attribute for typeinfo symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958 --- Comment #3 from Noel Grandin --- Andrew, the specific application here is a very large (10MLoc) codebase (LibreOffice), where we have lots of very large classes with tons of methods, where I want to limit symbol visibility to only the symbols that are needed for running unit tests. So sure, technically I could make the whole class visibility=default, and then annotate most of the methods with visibility=hidden. Or I could use linker scripts. But ergonomically, the easiest thing to do is to compile with visibility=hidden, and then annotate the small subset of symbols I want exposed. So this is an ergonomic / quality-of-life feature request, not a bug.
[Bug tree-optimization/113965] [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Blocks||53947 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/113965] New: [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Bug ID: 113965 Summary: [14 Regression] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu I thought this was a dup of bug mask_struct_store_4.c issue but nope, gcc.target/aarch64/sve/mask_struct_load_3_run.c testcase still fails for me after the fix for that. Note I am using the trunk of qemu to run the testcase so maybe there is a bug in qemu ...
[Bug tree-optimization/113964] [11/12/13/14/15 Regression] repeat copy of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964 Andrew Pinski changed: What|Removed |Added Summary|repeat copy of struct |[11/12/13/14/15 Regression] ||repeat copy of struct Known to fail||4.6.4, 4.7.1, 4.9.0, 5.1.0 Known to work||4.1.2, 4.4.7, 4.5.3 Last reconfirmed||2024-02-17 Target Milestone|--- |11.5 Keywords||missed-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. There is no DSE before esra And ESRA goes wrong because of that. Before ESRA we have: ``` _1 = e.f0.f4; _2 = (unsigned char) _1; e.f3 = _2; e.f0 = g_50; g_16 = MEM[(const struct S1 &)]; ``` And SRA thinks it should do: ``` Created a replacement for e offset: 0, size: 8: e$f3D.4642 Created a replacement for e offset: 192, size: 32: e$f0$f4D.4643 ``` But the store to e.f3 is dead due to the store to e.f0. I suspect this should be defered until GCC 15 and maybe we should try to reorg the optimization pipeline there ...
[Bug tree-optimization/113964] New: repeat copy of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
Bug ID: 113964
Summary: repeat copy of struct
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: absoler at smail dot nju.edu.cn
Target Milestone: ---
here's the code:
```
struct S1 {
uint32_t f0;
uint8_t f1;
uint64_t f2;
uint64_t f3;
int32_t f4;
};
union U8 {
struct S1 f0;
int32_t f1;
int64_t f2;
uint8_t f3;
const int64_t f4;
};
/* --- GLOBAL VARIABLES --- */
struct S1 g_16 = {4294967293UL,1UL,1UL,0xA9C1C73B017290B1LL,0x5ADF851FL};
union U8 g_37 = {{1UL,1UL,0x2361AE7D51263067LL,0xEEFD7F9B64A47447LL,0L}};
struct S1 g_50 =
{0x0CFC2012L,1UL,0x43E1243B3BE7B8BBLL,0x03C5CEC10C1A6FE1LL,1L};
/* --- FORWARD DECLARATIONS --- */
void func_32(union U8 e) {
e.f3 = e.f0.f4;
g_16 = e.f0 = g_50;
}
```
and compiled with gcc-13.2.0 -O2, generated binary code is:
```
00401400 :
func_32():
/root/myCSmith/test/output2.c:54
401400: movzbl 0x2c79(%rip),%eax# 404080
401407: movdqa 0x2c71(%rip),%xmm0# 404080
40140f: movdqa 0x2c79(%rip),%xmm1# 404090
401417: movups %xmm0,0x8(%rsp)
40141c: mov%al,0x8(%rsp)
401420: mov0x2c72(%rip),%eax# 404098
401426: movups %xmm1,0x18(%rsp)
40142b: movdqu 0x8(%rsp),%xmm2
401431: mov%eax,0x20(%rsp)
401435: movdqu 0x18(%rsp),%xmm3
40143b: movaps %xmm2,0x2c7e(%rip)# 4040c0
401442: movaps %xmm3,0x2c87(%rip)# 4040d0
/root/myCSmith/test/output2.c:55
401449: retq
40144a: nopw 0x0(%rax,%rax,1)
```
we can see that g_50.f0 and g_50.f4 have been repeatedly copy to e.
[Bug analyzer/113963] analyzer-null-dereference, analyzer-malloc-leak false alarms in Gnulib savedir.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113963 --- Comment #1 from Paul Eggert --- Created attachment 57442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57442=edit test program without line number directives (also compressed) This is the same program as savedir.i, except without line number directives. Like the other test program, it's compressed with gzip.
[Bug analyzer/113963] New: analyzer-null-dereference, analyzer-malloc-leak false alarms in Gnulib savedir.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113963
Bug ID: 113963
Summary: analyzer-null-dereference, analyzer-malloc-leak false
alarms in Gnulib savedir.c
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Created attachment 57441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57441=edit
test program with line number directives
I ran into this problem when compiling programs using Gnulib's lib/savedir.c
code.
This is gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6) on x86-64. Compile the
attached programs with:
gcc -O2 -fanalyzer -S savedir.i
gcc -O2 -fanalyzer -S savedis.i
Two problems. First, although savedis.i is merely a copy of savedir.i with line
number directives removed, the second command outputs an extra
-Wanalyzer-null-argument warning that the first command does not. Surely the
presence of line number directives should not affect which warnings are issued.
Second and more important, all the warnings are false positives. The pointers
can't possibly be null when the sizes are nonzero, and there is no memory leak.
The source files savedir.i and savedis.i are attached, compressed.
Here are the incorrect warnings that I get:
$ gcc -O2 -fanalyzer -S savedir.i
savedir.c: In function ‘streamsavedir’:
savedir.c:135:42: warning: dereference of NULL ‘entries’ [CWE-476]
[-Wanalyzer-null-dereference]
135 | entries[entries_used].name = used;
| ~~~^~
‘streamsavedir’: event 1
|
|savedir.c:106:6:
| 106 | if (dirp == NULL)
| | ^
| | |
| | (1) following ‘false’ branch (when ‘dirp’ is non-NULL)...
|
‘streamsavedir’: event 2
|
|cc1:
| (2): ...to here
|
‘streamsavedir’: events 3-5
|
|savedir.c:116:10:
| 116 | if (! dp)
| | ^
| | |
| | (3) following ‘false’ branch (when ‘dp’ is non-NULL)...
|..
| 121 | entry = dp->d_name;
| | ~~
| | |
| | (4) ...to here
| 122 | if (entry[entry[0] != '.' ? 0 : entry[1] != '.' ? 1 : 2] !=
'\0')
| | ~
| | |
| | (5) following ‘true’ branch...
|
‘streamsavedir’: event 6
|
|savedir.c:124:30:
| 124 | idx_t entry_size = _D_EXACT_NAMLEN (dp) + 1;
|
‘streamsavedir’: event 7
|
|savedir.c:125:14:
| 125 | if (allocated - used <= entry_size)
| | ^
| | |
| | (7) following ‘true’ branch...
|
‘streamsavedir’: event 8
|
| 126 | name_space = xpalloc (name_space, ,
|
‘streamsavedir’: events 9-14
|
|savedir.c:130:14:
| 130 | if (cmp)
| | ^
| | |
| | (9) following ‘true’ branch (when ‘cmp’ is
non-NULL)...
| 131 | {
| 132 | if (entries_allocated == entries_used)
| | ~~
| | | |
| | | (10) ...to here
| | (11) following ‘false’ branch...
|..
| 135 | entries[entries_used].name = used;
| | ~
| | | |
| | (12) ...to here (14) dereference of NULL
‘entries + (long unsigned int)entries_used * 16’
| | (13) ‘entries’ is NULL
|
savedir.c:169:3: warning: leak of ‘name_space’ [CWE-401]
[-Wanalyzer-malloc-leak]
169 | free (entries);
| ^~
‘savedir’: events 1-2
|
| 179 | savedir (char const *dir, enum savedir_option option)
| | ^~~
| | |
| | (1) entry to ‘savedir’
|..
| 182 | if (! dirp)
| | ~
| | |
| | (2) following ‘false’ branch (when ‘dirp’ is non-NULL)...
|
‘savedir’: events 3-5
|
|savedir.c:186:26:
| 186 | char *name_space = streamsavedir (dirp, option);
| | ^~~~
| | |
| | (3) ...to here
| | (4) allocated here
| | (5) calling ‘streamsavedir’ from
‘savedir’
|
+--> ‘streamsavedir’: event 6
|
|savedir.c:96:1:
| 96 | streamsavedir (DIR *dirp, enum
[Bug libgcc/113497] error: implicit declaration of function 'abort' on enable-execute-stack.c on i686-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113497 Sam James changed: What|Removed |Added Last reconfirmed||2024-02-17 Ever confirmed|0 |1 CC||law at gcc dot gnu.org, ||sjames at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #3 from Sam James --- Fixed in r14-8753-g2c27aa8d75113f. It should probably be backported though to 11/12/13.
[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219 Sam James changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #7 from Sam James --- Fixed for 14?
[Bug c/88687] redundant -Wbuiltin-declaration-mismatch after -Wimplicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88687 Sam James changed: What|Removed |Added Last reconfirmed||2024-02-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Sam James --- Confirmed. I wasn't sure if this would've gone away with some of the earlier diagnostic fixups wrt permerror but it hasn't.
[Bug tree-optimization/87313] attribute malloc not used for alias analysis when it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106850 --- Comment #5 from Sam James --- (In reply to Petr Skocik from comment #4) PR106850 for that, pretty much.
[Bug tree-optimization/83194] Possibly missed simplification with strcmp(s, t) == strcmp(t, s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83194 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-17 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Confirmed. Though I am not sure if this will happen in real code but with C++ code who knows.
[Bug target/111935] gcc ICE with risc-v vector intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111935 Alexandre Oliva changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from Alexandre Oliva --- Does the test pass in gcc-13 for anyone? ISTM that it doesn't. I bisected it and got to commit 973eb0deb467c79cc21f265a710a81054cfd3e8c AKA r14-3535, for bug 110943, as the first in which the test generates the expected number of matches of the vs... pattern.
[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
All of the following is in except.cc.
The problem is that the count in the label is relative to 'call_site_base'.
In convert_to_eh_region_ranges, those get bumped - but the function reset it at
the end. They do get accumulated via, e.g., dw2_output_call_site_table but, in
GCN, the output_function_exception_table is exit early because of:
3229 if (!crtl->uses_eh_lsda
3230 || targetm_common.except_unwind_info (_options) ==
UI_NONE)
3231return;
Thus, the next time convert_to_eh_region_ranges is called, it starts with the
very same numbers.
The reason that this gets produced is because there is an ERT_MUST_NOT_THROW
("MUST_NOT_THROW regions prevent all exceptions from propagating. This region
type is used in C++ to surround destructors being run inside a CLEANUP
region.")
As there are both "-1" (implies no action) and "-2" (MUST_NOT_THROW), GCN
produces this output. For whatever reason, nvptx has no "-1" actions in the
function, thus, after the change to "-2", there is no flip and - hence, no
output is produced - avoiding the issue.
→ I bet that both gcn and nvptx are affected (unless luck or compiled with
-fno-exceptions).
[Bug middle-end/113959] Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #2 from Harald van Dijk --- See also bug #66462: the code currently generated is wrong under -fsignaling-nans, a patch has been posted to fix that, and had then been forgotten. The patch may possibly improve codegen regardless of -fsignaling-nans.
[Bug target/113960] std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- I can reproduce it w/ 13.2.1 20231216 although I'd prefer to leave it to someone else to confirm...
[Bug c++/113958] support visibility attribute for typeinfo symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958 --- Comment #2 from Andrew Pinski --- I am not 100% sure if type_visibility is needed here or in general. You can also use -fvisibility-inlines-hidden to hide methods that are declared as inline which I suspect you want really too.
[Bug c++/113958] support visibility attribute for typeinfo symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958
--- Comment #1 from Andrew Pinski ---
You can use visibility on the type even Like:
```
struct __attribute__ ((visibility("default"))) Foo1{
virtual void some_member() = 0;
};
struct __attribute__ ((visibility("default"))) Foo : Foo1 {
virtual void some_member();
};
```
Which changes the visibility back to default for the whole class.
This is documented here:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Type-Attributes.html#index-visibility-type-attribute
You can also use the `pragma GCC visibility` too in the same way:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Visibility-Pragmas.html#index-pragma_002c-visibility
#pragma GCC visibility push(default)
Though visibility on the struct applies to all methods too. Which I suspect you
want really instead of marking each method as being default.
The pragma push/pop makes it easier to mark the classes you want to be exported
too. E.g. you can wrap including a header file with that to make sure those are
exported.
[Bug target/113779] Very inefficient m68k code generated for simple copy loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #7 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #6) > The auto-inc pass is well > structured, so it should be possible to extend it. Or just replace it, as it doesn't look far enough to be able to handle all incdec-opportunities.
[Bug middle-end/113959] Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959 --- Comment #1 from Andrew Pinski --- Created attachment 57440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57440=edit testcase from the godbolt link Next time attach the testcase or put it in line instead of just linking to godbolt.
[Bug middle-end/113959] Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #8 from Jerry DeLisle ---
After a bit of sleuthing it turns out that the '(' in the name was being
ignored and the comma in '(1,2)' was being treated as a delimiter. Since the
following '=' was not seen yet, the 2 was seen as a repeat value and we get the
error.
This is fixed with the following patch:
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index f8ca64422de..0b7884fdda7 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -888,6 +888,14 @@ read_logical (st_parameter_dt *dtp, int length)
for(i = 0; i < 63; i++)
{
c = next_char (dtp);
+ if (c == '(')
+ {
+ l_push_char (dtp, c);
+ dtp->u.p.nml_read_error = 1;
+ dtp->u.p.line_buffer_enabled = 1;
+ dtp->u.p.line_buffer_pos = 0;
+ return;
+ }
if (is_separator(c))
{
/* All done if this is not a namelist read. */
[Bug libgcc/113850] condition variables timed wait does a lot of spurious wakeups on Win32 threading implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Yong
:
https://gcc.gnu.org/g:b5def8fd08976fc2514426ecb1f263f13ba3e2af
commit r13-8337-gb5def8fd08976fc2514426ecb1f263f13ba3e2af
Author: Matteo Italia
Date: Fri Feb 9 15:04:20 2024 +0100
libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
Fix a typo in __gthr_win32_abs_to_rel_time that caused it to return a
relative time in seconds instead of milliseconds. As a consequence,
__gthr_win32_cond_timedwait called SleepConditionVariableCS with a
1000x shorter timeout; this caused ~1000x more spurious wakeups in
CV timed waits such as std::condition_variable::wait_for or wait_until,
resulting generally in much higher CPU usage.
This can be demonstrated by this sample program:
```
int main() {
std::condition_variable cv;
std::mutex mx;
bool pass = false;
auto thread_fn = [&](bool timed) {
int wakeups = 0;
using sc = std::chrono::system_clock;
auto before = sc::now();
std::unique_lock ml(mx);
if (timed) {
cv.wait_for(ml, std::chrono::seconds(2), [&]{
++wakeups;
return pass;
});
} else {
cv.wait(ml, [&]{
++wakeups;
return pass;
});
}
printf("pass: %d; wakeups: %d; elapsed: %d ms\n", pass, wakeups,
int((sc::now() - before) / std::chrono::milliseconds(1)));
pass = false;
};
{
// timed wait, let expire
std::thread t(thread_fn, true);
t.join();
}
{
// timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, true);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
{
// non-timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, false);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
return 0;
}
```
On builds based on non-affected threading models (e.g. POSIX on Linux,
or winpthreads or MCF on Win32) the output is something like
```
pass: 0; wakeups: 2; elapsed: 2000 ms
pass: 1; wakeups: 2; elapsed: 991 ms
pass: 1; wakeups: 2; elapsed: 996 ms
```
while with the Win32 threading model we get
```
pass: 0; wakeups: 1418; elapsed: 2000 ms
pass: 1; wakeups: 479; elapsed: 988 ms
pass: 1; wakeups: 2; elapsed: 992 ms
```
(notice the huge number of wakeups in the timed wait cases only).
This commit fixes the conversion, adjusting the final division by
NSEC100_PER_SEC to use NSEC100_PER_MSEC instead (already defined in the
file and not used in any other place, so probably just a typo).
libgcc/ChangeLog:
PR libgcc/113850
* config/i386/gthr-win32-cond.c (__gthr_win32_abs_to_rel_time):
fix absolute timespec to relative milliseconds count
conversion (it incorrectly returned seconds instead of
milliseconds); this avoids spurious wakeups in
__gthr_win32_cond_timedwait
(cherry picked from commit 05ad8fb55a55f1e201fd781c84682a7c0bbd4d97)
[Bug libgcc/113850] condition variables timed wait does a lot of spurious wakeups on Win32 threading implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:05ad8fb55a55f1e201fd781c84682a7c0bbd4d97
commit r14-9042-g05ad8fb55a55f1e201fd781c84682a7c0bbd4d97
Author: Matteo Italia
Date: Fri Feb 9 15:04:20 2024 +0100
libgcc: fix Win32 CV abnormal spurious wakeups in timed wait [PR113850]
Fix a typo in __gthr_win32_abs_to_rel_time that caused it to return a
relative time in seconds instead of milliseconds. As a consequence,
__gthr_win32_cond_timedwait called SleepConditionVariableCS with a
1000x shorter timeout; this caused ~1000x more spurious wakeups in
CV timed waits such as std::condition_variable::wait_for or wait_until,
resulting generally in much higher CPU usage.
This can be demonstrated by this sample program:
```
int main() {
std::condition_variable cv;
std::mutex mx;
bool pass = false;
auto thread_fn = [&](bool timed) {
int wakeups = 0;
using sc = std::chrono::system_clock;
auto before = sc::now();
std::unique_lock ml(mx);
if (timed) {
cv.wait_for(ml, std::chrono::seconds(2), [&]{
++wakeups;
return pass;
});
} else {
cv.wait(ml, [&]{
++wakeups;
return pass;
});
}
printf("pass: %d; wakeups: %d; elapsed: %d ms\n", pass, wakeups,
int((sc::now() - before) / std::chrono::milliseconds(1)));
pass = false;
};
{
// timed wait, let expire
std::thread t(thread_fn, true);
t.join();
}
{
// timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, true);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
{
// non-timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, false);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
return 0;
}
```
On builds based on non-affected threading models (e.g. POSIX on Linux,
or winpthreads or MCF on Win32) the output is something like
```
pass: 0; wakeups: 2; elapsed: 2000 ms
pass: 1; wakeups: 2; elapsed: 991 ms
pass: 1; wakeups: 2; elapsed: 996 ms
```
while with the Win32 threading model we get
```
pass: 0; wakeups: 1418; elapsed: 2000 ms
pass: 1; wakeups: 479; elapsed: 988 ms
pass: 1; wakeups: 2; elapsed: 992 ms
```
(notice the huge number of wakeups in the timed wait cases only).
This commit fixes the conversion, adjusting the final division by
NSEC100_PER_SEC to use NSEC100_PER_MSEC instead (already defined in the
file and not used in any other place, so probably just a typo).
libgcc/ChangeLog:
PR libgcc/113850
* config/i386/gthr-win32-cond.c (__gthr_win32_abs_to_rel_time):
fix absolute timespec to relative milliseconds count
conversion (it incorrectly returned seconds instead of
milliseconds); this avoids spurious wakeups in
__gthr_win32_cond_timedwait
[Bug target/113913] [14] RISC-V: suboptimal code gen for intrinsic vcreate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113913 --- Comment #2 from JuzheZhong --- It's the known issue we are trying to fix it in GCC-15. My colleague Lehua is taking care of it. CCing Lehua.
[Bug c++/104836] ice in unify, at cp/pt.cc:24055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104836
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
// PR c++/104836
template struct X {};
template typename> struct Y {};
template struct Z {};
template struct A {
template A(X, Ts (*...qs)[Ns]);
};
int arr1[3], arr2[3];
short arr3[4];
A a(X<, >{}, , , );
using AT = decltype(a);
using AT = A;
[Bug c++/57527] [C++11] Nested variadic templates cause internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57527
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #6 from Marek Polacek ---
// PR c++/57527
template
struct X {};
template
struct Y {
template
Y(X... xs);
};
void
g ()
{
X x;
Y y(x);
}
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-02-16 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-February/060233.html
[Bug analyzer/109802] [13 Regression] ICE using dubious flexible arrays in unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109802 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-16 Summary|[regression] during IPA |[13 Regression] ICE using |pass: analyzer: internal|dubious flexible arrays in |compiler error (using |unions |dubious flexible arrays in | |unions) | --- Comment #5 from David Malcolm --- Thanks for filing this bug report. (In reply to Alejandro Colomar from comment #2) > Here's a simplified version that will cause the same internal compiler error. Trunk (GCC 14): ok: https://godbolt.org/z/4cjf6Khh3 GCC 13.2: ICE: https://godbolt.org/z/K4j97a4eb GCC 12.3: ok: https://godbolt.org/z/1jfz8YTPj ...so it seems like this is fixed on trunk (for GCC 14) but still affects GCC 13.
[Bug target/113934] Switch avr to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- LRA does not use LEGITIMIZE_RELOAD_ADDRESS. The LRA code knows how to make all addresses legal by itself.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #47 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #46)
> (In reply to Jan Hubicka from comment #43)
> > > // See discussion here:
> > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
> > Discussion says:
> >
> > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL
> > will tell the truth. However, this will mean that we will no longer
> > remove the first __builtin_unreachable combo. But ISTM, that would be
> > correct behavior ??."
> >
> > So perhaps, we could remove that special case for default def and phi?
> > It is an odd thing and we clearly lose info here.
> >
>
> legacy VRP has been removed now. So in theory we are free to do as we
> want.. but I don't remember the specific details.
>
> So do you just want to always use get_range_global() ? and not do the check?
>
> I can try changing it to just get_global and see what happens.
FWIW,
diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index 040c843c566..0ab10bc5a46 100644
--- a/gcc/value-query.cc
+++ b/gcc/value-query.cc
@@ -353,16 +353,9 @@ get_range_global (vrange , tree name, struct function
*fun = cfun)
void
gimple_range_global (vrange , tree name, struct function *fun)
{
- tree type = TREE_TYPE (name);
gcc_checking_assert (TREE_CODE (name) == SSA_NAME);
- if (SSA_NAME_IS_DEFAULT_DEF (name) || (fun && fun->after_inlining)
- || is_a (SSA_NAME_DEF_STMT (name)))
-{
- get_range_global (r, name, fun);
- return;
-}
- r.set_varying (type);
+ get_range_global (r, name, fun);
}
bootstraps and runs the testsuites clean on x86-64 now...
[Bug analyzer/110285] [13/14 Regression] -Wanalyzer-infinite-recursion false positive involving floating-point values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 David Malcolm changed: What|Removed |Added Last reconfirmed||2024-02-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|-Wanalyzer-infinite-recursi |[13/14 Regression] |on false positive involving |-Wanalyzer-infinite-recursi |floating-point values |on false positive involving ||floating-point values
[Bug analyzer/108562] [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562 Bug 108562 depends on bug 105755, which changed state. Bug 105755 Summary: -Wanalyzer-null-dereference regression compiling Emacs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |---
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2024-02-16 Ever confirmed|0 |1 CC||iains at gcc dot gnu.org Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #7 from Iain Sandoe --- see comment #5 and #6
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 --- Comment #5 from seurer at gcc dot gnu.org --- Indeed you did, thanks!
[Bug analyzer/109851] [13/14 Regression] False positive va_arg when iterating through format string with for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109851 David Malcolm changed: What|Removed |Added Summary|False positive va_arg when |[13/14 Regression] False |iterating through format|positive va_arg when |string with for-loop|iterating through format ||string with for-loop Last reconfirmed||2024-02-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this bug report. The analyzer isn't looking at the content of the string literal and assumes that any character is possible. In particular, it isn't attempting to correlate between the ordering of matches in the string and the ordering of the variadic arguments. Still affects trunk and gcc 13: Trunk: https://godbolt.org/z/bMP7sq3ea GCC 13.2: https://godbolt.org/z/e7eE8Eo4d
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 --- Comment #6 from nightstrike --- (In reply to nightstrike from comment #5) > If I open your godbolt links, they aren't using a Windows target compiler, > so they aren't exercising an LLP64 target. For instance: https://godbolt.org/z/4Mx96Wjvd : In function 'XLI': :15:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 15 | return (EMACS_INT) o; | ^ ASM generation compiler returned: 0 ERROR: The inherited access control list (ACL) or access control entry (ACE) could not be built. : In function 'XLI': :15:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 15 | return (EMACS_INT) o; | ^ Execution build compiler returned: 0 Program returned: 254
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755
--- Comment #5 from nightstrike ---
(In reply to David Malcolm from comment #4)
> Looks like this was fixed sometime in GCC 13; resolving as WORKSFORME.
>
> Feel free to reopen if you have a reproducer that triggers on a more recent
> GCC.
The testcase still fails. To be clear, I'm referring to null-deref-pr105755.c:
Executing on host: /tmp/gcc/src/gcc-git/_w/gcc/xgcc
-B/tmp/gcc/src/gcc-git/_w/gcc/ exceptions_enabled705865.cc
-fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o
exceptions_enabled705865.s(timeout = 300)
spawn -ignore SIGHUP /tmp/gcc/src/gcc-git/_w/gcc/xgcc
-B/tmp/gcc/src/gcc-git/_w/gcc/ exceptions_enabled705865.cc
-fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o
exceptions_enabled705865.s^M
FAIL: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors)
Excess errors:
/tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c:19:10:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
testcase /tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/analyzer.exp
completed in 0 seconds
With this change:
--- a/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c
+++ b/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c
@@ -2,7 +2,7 @@
/* { dg-additional-options "-Wno-analyzer-too-complex
-Wno-analyzer-symbol-too-complex -O2" } */
typedef long int ptrdiff_t;
-typedef long int EMACS_INT;
+typedef __UINTPTR_TYPE__ EMACS_INT;
typedef long int intmax_t;
enum Lisp_Type
Then I get this:
PASS: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors)
If I open your godbolt links, they aren't using a Windows target compiler, so
they aren't exercising an LLP64 target.
Generally speaking, most of the analyzer testsuite assumes incorrect
definitions of things. For instance, in the diff I just posted, you can see
that the lines before and after also assume the underlying types of ptrdiff_t
and intmax_t instead of using compiler builtins or just including the relevant
headers. This is really needs to be fixed across the whole testsuite.
[Bug analyzer/109579] -Wanalyzer-out-of-bounds false positive in Emacs mapping stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109579 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from David Malcolm --- Thanks for filing this bug report. Trunk: unaffected: https://godbolt.org/z/EaeP1e1d5 GCC 13.2: affected: https://godbolt.org/z/WvcKh9s9Y Presumably fixed by one of my patches to trunk; marking as RESOLVED WORKSFORME. Feel free to reopen if you can reproduce it with GCC 14 or later.
[Bug analyzer/109628] -Wanalyzer-use-of-uninitialized-value false positive on static storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109628 David Malcolm changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #1 from David Malcolm --- Thanks for filing this bug. Seems to be fixed on trunk (for GCC 14): https://godbolt.org/z/ecYGxa3nh Affects GCC 13.2: https://godbolt.org/z/sxs3G1KEc Affects GCC 12.3: https://godbolt.org/z/v4nz19Mj1 I'm going to assume that one of my other fixes on trunk covered this; marking as RESOLVED WORKSFORME. Feel free to reopen if you still see it with GCC 14 onwards.
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- I think I got it right this time!
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c74131e77f1a6b7afe700d3526a8992dc9744b0c commit r14-9038-gc74131e77f1a6b7afe700d3526a8992dc9744b0c Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc again [PR113961] PR libstdc++/87744 PR libstdc++/113961 libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number.
[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744 --- Comment #17 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c74131e77f1a6b7afe700d3526a8992dc9744b0c commit r14-9038-gc74131e77f1a6b7afe700d3526a8992dc9744b0c Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc again [PR113961] PR libstdc++/87744 PR libstdc++/113961 libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number.
[Bug c++/97990] [11/12/13 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 --- Comment #13 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5f1438db419c9eb8901d1d1d7f98fb69082aec8e commit r14-9037-g5f1438db419c9eb8901d1d1d7f98fb69082aec8e Author: Andrew Pinski Date: Fri Feb 16 10:55:43 2024 -0800 c++: Add testcase for this PR [PR97990] This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add one to make sure it does not regress again. Committed as obvious after a quick test on the testcase. PR c++/97990 gcc/testsuite/ChangeLog: * g++.dg/torture/vector-struct-1.C: New test. Signed-off-by: Andrew Pinski
[Bug target/112103] [14 regression] gcc.target/powerpc/rlwinm-0.c fails after r14-4941-gd1bb9569d70304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So, let's just adjust the testcase then?
[Bug c++/109859] [12/13/14 Regression] ICE on concept mis-typed as template type parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109859
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
We're hitting the assert here:
/* In a template parameter list, a type-parameter can be introduced
by type-constraints alone. */
if (processing_template_parmlist && !placeholder)
{
/* In a default argument we may not be creating new parameters. */
if (parser->local_variables_forbidden_p & LOCAL_VARS_FORBIDDEN)
{
/* If this assert turns out to be false, do error() instead. */
gcc_assert (tentative);
return error_mark_node;
}
so presumably we should change it to error() as the comment says.
[Bug c++/97990] [11/12/13 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 Andrew Pinski changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE: |ICE: ‘verify_type’ failed |‘verify_type’ failed with |with vector types and |vector types and non-PODs |non-PODs since |since |r6-5222-gba6a6a1d44c17f25 |r6-5222-gba6a6a1d44c17f25 Known to work||14.0 --- Comment #12 from Andrew Pinski --- (In reply to Marek Polacek from comment #11) > Looks like r14-5934-gf26d68d5d128c8: > > commit f26d68d5d128c86faaceeb81b1e8f22254ad53df > Author: Richard Biener > Date: Tue Nov 28 12:36:21 2023 +0100 > > middle-end/112732 - stray TYPE_ALIAS_SET in type variant > > fixed this. Yes that looks like the correct fix even and PR 112732 does look like the same issue here except a different path to create the type variant.
[Bug c++/97990] [11/12/13/14 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #11 from Marek Polacek --- Looks like r14-5934-gf26d68d5d128c8: commit f26d68d5d128c86faaceeb81b1e8f22254ad53df Author: Richard Biener Date: Tue Nov 28 12:36:21 2023 +0100 middle-end/112732 - stray TYPE_ALIAS_SET in type variant fixed this.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #8 from Antoni ---
(In reply to David Malcolm from comment #2)
> inlined_call_event's ctor should probably assert that params
> tree apparent_callee_fndecl,
> tree apparent_caller_fndecl,
> are both non-NULL, which might catch the issue slightly early.
I added an assert and here's the stacktrace:
during IPA pass: analyzer
libgccjit.so: internal compiler error: : in inlined_call_event, at
analyzer/checker-event.h:578
0x73d4eafbf076 ana::inlined_call_event::inlined_call_event(unsigned int,
tree_node*, tree_node*, int, int)
../../../gcc/gcc/analyzer/checker-event.h:578
0x73d4eafbe7dd ana::checker_path::inject_any_inlined_call_events(ana::logger*)
../../../gcc/gcc/analyzer/checker-path.cc:319
0x73d4eafd415f
ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph const&,
ana::saved_diagnostic&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1599
0x73d4eafd981d ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1472
0x73d4eafd3dcb
ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1524
0x73d4e9a0327a ana::impl_run_checkers(ana::logger*)
../../../gcc/gcc/analyzer/engine.cc:6226
0x73d4e9a03613 ana::run_checkers()
../../../gcc/gcc/analyzer/engine.cc:6300
0x73d4e99f484c execute
../../../gcc/gcc/analyzer/analyzer-pass.cc:87
I can also confirm that this is related to always_inline as there are no
segfaults when removing the #[inline(always)] in the following example (see
comment):
#![no_std]
#![allow(internal_features)]
#![feature(core_intrinsics, lang_items, start)]
#![feature(transparent_unions)]
use core::mem::ManuallyDrop;
#[panic_handler]
fn panic_handler(_: ::panic::PanicInfo<'_>) -> ! {
core::intrinsics::abort();
}
#[lang="eh_personality"]
fn eh_personality(){}
#[derive(Clone, Copy)]
#[repr(transparent)]
pub union MaybeUninit {
uninit: (),
value: ManuallyDrop,
}
impl MaybeUninit {
// NOTE: there are no segfaults when removing the next line.
#[inline(always)]
pub const fn uninit() -> MaybeUninit {
MaybeUninit { uninit: () }
}
}
#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
let mut x = MaybeUninit::<>::uninit();
0
}
[Bug c++/111974] internal error: Segmentation fault on Ubuntu 23.10 (x86-64) - compiling RefPerSys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Marek Polacek --- No testcase; please reopen when/if you find one.
[Bug c++/89336] internal compiler error when compiling a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- Assuming fixed.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 89336, which changed state. Bug 89336 Summary: internal compiler error when compiling a constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 87536, which changed state. Bug 87536 Summary: Illegal recursive concept leads to compiler ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87536 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/87536] Illegal recursive concept leads to compiler ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87536 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- I no longer get any crashes here: $ xg++ -c -std=c++20 87536.C 87536.C:2:6: error: C++20 concept definition syntax is ‘concept = ’ 2 | bool concept X = X; | ^~~ $ xg++ -c -std=c++17 87536.C -fconcepts-ts cc1plus: note: ‘-fconcepts-ts’ is deprecated and will be removed in GCC 15; please convert your code to C++20 concepts
[Bug c++/87331] if delete "node->operator_type = kADD; " will report "internal compiler error: Segmentation fault"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87331 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug c++/85908] Internal error with concepts and polymorphic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85908 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Compiles fine with -std=c++17 -fconcepts-ts. There's error: the ‘bool’ keyword is not allowed in a C++20 concept definition [-fpermissive] so I'm not adding the test.
[Bug c++/29040] missing access control checks in subclasses for nested types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29040 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW CC||mpolacek at gcc dot gnu.org Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org
[Bug c++/26278] ambiguous overload candidates list contains duplicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26278
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #7 from Marek Polacek ---
Still happens:
$ xg++ -c 26278.C
26278.C: In function ‘int main()’:
26278.C:14:5: error: ambiguous overload for ‘operator==’ (operand types are
‘coEnum’ and ‘X’)
14 | c == p;
| ~ ^~ ~
| ||
| |X
| coEnum
26278.C:14:5: note: candidate: ‘operator==(X, X)’ (built-in)
14 | c == p;
| ~~^~~~
26278.C:14:5: note: candidate: ‘operator==(int, int)’ (built-in)
26278.C:14:5: note: candidate: ‘operator==(X, X)’ (built-in)
26278.C:7:8: note: candidate: ‘bool coEnum::operator==(coEnum)
const [with e1 = A; e2 = X]’
7 | bool operator==(coEnum e) const { return 0; }
|^~~~
[Bug c++/19073] cp_binding_level::names not returning all decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073 Marek Polacek changed: What|Removed |Added Resolution|--- |WORKSFORME CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #13 from Marek Polacek --- It doesn't appear there's anything to do here.
[Bug c++/17000] parse error calling member template function of non-lvalue from within template class member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek --- We say 17000.C: In member function ‘void b::func()’: 17000.C:10:17: warning: expected ‘template’ keyword before dependent template name [-Wmissing-template-keyword] 10 | get_a().func2 (); | ^ | template and clang++ says 17000.C:10:17: error: use 'template' keyword to treat 'func2' as a dependent template name 10 | get_a().func2 (); | ^ | template I think we can close this.
[Bug c++/113789] [13 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #10 from Arthur O'Dwyer ---
FWIW, I think I agree with your analysis. To reiterate what you already said
(and I think GCC already gets the following snippet correct): in
X g (X x) try {
throw x;
} catch (...) {
return x;
}
the `throw x` copies but the `return x` moves. That is, `throw x` treats `x` as
an lvalue because it could be used again later (in the function-catch-block),
but `return x` treats it as an rvalue because it can't[*] be used again later.
[* — except if you sneakily use a captured reference within a destructor, but
C++ implicit move doesn't care — has never cared — about such sneaky uses]
[Bug c++/111682] [14 regression] valgrind error in tsubst_template_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111682 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113612 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Incidentally fixed.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #7 from Antoni --- I don't know if this helps, but I added a small Rust reproducer that can trigger the segfault when compiled with rustc_codegen_gcc and the corresponding GIMPLE for this Rust reproducer.
[Bug c++/111682] [14 regression] valgrind error in tsubst_template_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111682 --- Comment #2 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c95dc611a6203f0564722975acff4ad866b9c45e commit r14-9035-gc95dc611a6203f0564722975acff4ad866b9c45e Author: Patrick Palka Date: Fri Feb 16 12:44:27 2024 -0500 c++: add fixed testcase [PR111682] Fixed by the PR113612 fix r14-8960-g19ac327de421fe. PR c++/111682 gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ86.C: New test.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #6 from Antoni --- Created attachment 57439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57439=edit Rust reproducer
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #5 from Antoni --- Created attachment 57438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57438=edit GIMPLE for the Rust reproducer
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed in 13+.
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:e501a279fb4298c9b23637d573287e059b3b06c8 commit r13-8336-ge501a279fb4298c9b23637d573287e059b3b06c8 Author: Marek Polacek Date: Fri Feb 16 12:25:26 2024 -0500 c++: ICE with reinterpret_cast and switch [PR113545] Jason, this is the patch you proposed for PR113545. It looks very safe so I'm posting it here so that it's not forgotten. PR c++/113545 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_switch_expr): If the condition doesn't reduce to an INTEGER_CST, consider it non-constant. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-reinterpret3.C: New test. * g++.dg/cpp1y/constexpr-reinterpret4.C: New test. (cherry picked from commit 39d989022dd0eacf1a7b95b7b20621acbe717d70)
[Bug c++/113158] [11/12/13/14 Regression] Erroneous "looser exception specification" error for class template and depedent noexcept value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645767.html
[Bug c++/113789] [13 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Summary|[13/14 Regression] ICE on |[13 Regression] ICE on |P2266/C++23 `decltype(throw |P2266/C++23 `decltype(throw |x)` where x is |x)` where x is |move-eligible parameter |move-eligible parameter Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Should be fully fixed now.
[Bug c++/98388] Throwing move-only parameter results in hard error in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98388 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Should be fixed now.
[Bug c++/113853] implicit move in throw in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed in GCC 14.
[Bug c++/113853] implicit move in throw in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:254ff3d0e34835b4de93d5e5763a7366dc7d989d
commit r14-9034-g254ff3d0e34835b4de93d5e5763a7366dc7d989d
Author: Marek Polacek
Date: Wed Feb 14 17:53:52 2024 -0500
c++: implicit move with throw [PR113853]
Here we have
template
auto is_throwable(T t) -> decltype(throw t, true) { ... }
where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have been chosen. Jason figured out it's because
we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
says that an id-expression is move-eligible if
"the id-expression (possibly parenthesized) is the operand of
a throw-expression, and names an implicitly movable entity that belongs
to a scope that does not contain the compound-statement of the innermost
lambda-expression, try-block, or function-try-block (if any) whose
compound-statement or ctor-initializer contains the throw-expression."
I worked out that it's trying to say that given
struct X {
X();
X(const X&);
X(X&&) = delete;
};
the following should fail: the scope of the throw is an sk_try, and it's
also x's scope S, and S "does not contain the compound-statement of the
*try-block" so x is move-eligible, so we move, so we fail.
void f ()
try {
X x;
throw x; // use of deleted function
} catch (...) {
}
Whereas here:
void g (X x)
try {
throw x;
} catch (...) {
}
the throw is again in an sk_try, but x's scope is an sk_function_parms
which *does* contain the {} of the *try-block, so x is not move-eligible,
so we don't move, so we use X(const X&), and the code is fine.
The current code also doesn't seem to handle
void h (X x) {
void z (decltype(throw x, true));
}
where there's no enclosing lambda or sk_try so we should move.
I'm not doing anything about lambdas because we shouldn't reach the
code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
shouldn't let us go further.
PR c++/113789
PR c++/113853
gcc/cp/ChangeLog:
* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
reflect [expr.prim.id.unqual]#4.2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
* g++.dg/cpp0x/sfinae70.C: New test.
* g++.dg/cpp0x/sfinae71.C: New test.
* g++.dg/cpp0x/sfinae72.C: New test.
* g++.dg/cpp2a/implicit-move4.C: New test.
[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:254ff3d0e34835b4de93d5e5763a7366dc7d989d
commit r14-9034-g254ff3d0e34835b4de93d5e5763a7366dc7d989d
Author: Marek Polacek
Date: Wed Feb 14 17:53:52 2024 -0500
c++: implicit move with throw [PR113853]
Here we have
template
auto is_throwable(T t) -> decltype(throw t, true) { ... }
where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have been chosen. Jason figured out it's because
we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
says that an id-expression is move-eligible if
"the id-expression (possibly parenthesized) is the operand of
a throw-expression, and names an implicitly movable entity that belongs
to a scope that does not contain the compound-statement of the innermost
lambda-expression, try-block, or function-try-block (if any) whose
compound-statement or ctor-initializer contains the throw-expression."
I worked out that it's trying to say that given
struct X {
X();
X(const X&);
X(X&&) = delete;
};
the following should fail: the scope of the throw is an sk_try, and it's
also x's scope S, and S "does not contain the compound-statement of the
*try-block" so x is move-eligible, so we move, so we fail.
void f ()
try {
X x;
throw x; // use of deleted function
} catch (...) {
}
Whereas here:
void g (X x)
try {
throw x;
} catch (...) {
}
the throw is again in an sk_try, but x's scope is an sk_function_parms
which *does* contain the {} of the *try-block, so x is not move-eligible,
so we don't move, so we use X(const X&), and the code is fine.
The current code also doesn't seem to handle
void h (X x) {
void z (decltype(throw x, true));
}
where there's no enclosing lambda or sk_try so we should move.
I'm not doing anything about lambdas because we shouldn't reach the
code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
shouldn't let us go further.
PR c++/113789
PR c++/113853
gcc/cp/ChangeLog:
* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
reflect [expr.prim.id.unqual]#4.2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
* g++.dg/cpp0x/sfinae70.C: New test.
* g++.dg/cpp0x/sfinae71.C: New test.
* g++.dg/cpp0x/sfinae72.C: New test.
* g++.dg/cpp2a/implicit-move4.C: New test.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #46 from Andrew Macleod --- (In reply to Jan Hubicka from comment #43) > > // See discussion here: > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html > Discussion says: > > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL > will tell the truth. However, this will mean that we will no longer > remove the first __builtin_unreachable combo. But ISTM, that would be > correct behavior ??." > > So perhaps, we could remove that special case for default def and phi? > It is an odd thing and we clearly lose info here. > legacy VRP has been removed now. So in theory we are free to do as we want.. but I don't remember the specific details. So do you just want to always use get_range_global() ? and not do the check? I can try changing it to just get_global and see what happens.
[Bug c++/104919] [modules] enum in constexpr function causes "failed to read compiled module cluster 1: Bad file data"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104919 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-16 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106009 Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- s/constexpr/inline also triggers the bug, unsurprisingly. PR106009 about templated local enums might be related.
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-16 --- Comment #2 from Jonathan Wakely --- Gah, now I see what's going on ... I have another patch for bits/random.h in my local tree which is affecting those line numbers.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #45 from Jan Hubicka --- > > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL > > will tell the truth. However, this will mean that we will no longer > > remove the first __builtin_unreachable combo. But ISTM, that would be > > correct behavior ??." > ... > > But that doesn't cause these problems, just perhaps losing some info, right? > If so, trying to change that feels like stage1 material to me. Yep. It would be nice to not forget about that - it kept me confused for over an hour :)
[Bug c++/113929] GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug c++/113929] GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5286b0761b5dfac4348d1c5bfdcc162a66f338ee commit r14-9033-g5286b0761b5dfac4348d1c5bfdcc162a66f338ee Author: Jakub Jelinek Date: Fri Feb 16 17:42:32 2024 +0100 c++: Diagnose this specifier on template parameters [PR113929] For template parameters, the optional this specifier is in the grammar template-parameter-list -> template-parameter -> parameter-declaration, just [dcl.fct/6] says that it is only valid in parameter-list of certain functions. So, unlike the case of decl-specifier-seq used in non-terminals other than parameter-declaration, I think it is better not to fix this by cp_parser_decl_specifier_seq (parser, -flags | CP_PARSER_FLAGS_PARAMETER, +flags | (template_parameter_p ? 0 + : CP_PARSER_FLAGS_PARAMETER), _specifiers, _class_or_enum); which would be pretending it isn't in the grammar, but by diagnosing it separately, which is what the following patch does. 2024-02-16 Jakub Jelinek PR c++/113929 * parser.cc (cp_parser_parameter_declaration): Diagnose this specifier on template parameter declaration. * g++.dg/parse/pr113929.C: New test.
[Bug c++/98752] wrong "error: ‘this’ is not a constant expression" with consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752 --- Comment #7 from Marek Polacek --- Comment 5 test was fixed by r14-5979-g99d114c15523e0 commit 99d114c15523e0bfe7a89ef1947f82eb5ff0260b Author: Marek Polacek Date: Fri Nov 17 14:48:44 2023 -0500 c++: P2280R4, Using unknown refs in constant expr [PR106650] the comment 6 one still doesn't work.
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 --- Comment #1 from seurer at gcc dot gnu.org --- < previous run: g:1aef0a9b07766d100a218ef3e9576d0a0dd35a2d, r14-9027-g1aef0a9b07766d > this run: g:7f3d900684ad989164114f25eb46a33871c6533d, r14-9028-g7f3d900684ad98 < FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 271) > FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 3350)
[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802 --- Comment #5 from Jan Hubicka --- I don't think we can reasonably expect every caller of lambda function to be early inlined, so we need to extend ipa-prop to understand the obfuscated code. I disucussed that with Martin some time ago - I think this is quite common problem with modern C++, so we will need to pattern match this, which is quite unfortunate.
[Bug analyzer/111213] -Wanalyzer-out-of-bounds false negative with `return arr[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213 David Malcolm changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #4 from David Malcolm --- Marking this one as SUSPENDED since it would require the big rewrite for PR 111312.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #44 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #43) > > // See discussion here: > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html > Discussion says: > > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL > will tell the truth. However, this will mean that we will no longer > remove the first __builtin_unreachable combo. But ISTM, that would be > correct behavior ??." ... But that doesn't cause these problems, just perhaps losing some info, right? If so, trying to change that feels like stage1 material to me.
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #5 from Jan Hubicka ---
hmm. cfg.cc:815 for me is:
fputs (", maybe hot", outf);
which seems quite safe.
The problem does not seem to reproduce for me:
jh@ryzen3:~/gcc/build/gcc> ./xgcc -B ./ tt.c -O
--param=max-inline-recursive-depth=100 -fdump-tree-rebuild_frequencies-all
-wrapper valgrind
==25618== Memcheck, a memory error detector
==25618== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==25618== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==25618== Command: ./cc1 -quiet -iprefix
/home/jh/gcc/build/gcc/../lib64/gcc/x86_64-pc-linux-gnu/14.0.1/ -isystem
./include -isystem ./include-fixed tt.c -quiet -dumpdir a- -dumpbase tt.c
-dumpbase-ext .c -mtune=generic -march=x86-64 -O
-fdump-tree-rebuild_frequencies-all --param=max-inline-recursive-depth=100
-o /tmp/ccpkfjdK.s
==25618==
==25618==
==25618== HEAP SUMMARY:
==25618== in use at exit: 1,818,714 bytes in 1,175 blocks
==25618== total heap usage: 39,645 allocs, 38,470 frees, 12,699,874 bytes
allocated
==25618==
==25618== LEAK SUMMARY:
==25618==definitely lost: 0 bytes in 0 blocks
==25618==indirectly lost: 0 bytes in 0 blocks
==25618== possibly lost: 8,032 bytes in 1 blocks
==25618==still reachable: 1,810,682 bytes in 1,174 blocks
==25618== suppressed: 0 bytes in 0 blocks
==25618== Rerun with --leak-check=full to see details of leaked memory
==25618==
==25618== For lists of detected and suppressed errors, rerun with: -s
==25618== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==25627== Memcheck, a memory error detector
==25627== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==25627== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==25627== Command: ./as --64 -o /tmp/ccp5TNme.o /tmp/ccpkfjdK.s
==25627==
==25637== Memcheck, a memory error detector
==25637== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==25637== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==25637== Command: ./collect2 -plugin ./liblto_plugin.so
-plugin-opt=./lto-wrapper -plugin-opt=-fresolution=/tmp/cclWZD7F.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /lib/../lib64/crt1.o /lib/../lib64/crti.o
./crtbegin.o -L. -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccp5TNme.o -lgcc
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed
-lgcc_s --pop-state ./crtend.o /lib/../lib64/crtn.o
==25637==
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld:
/lib/../lib64/crt1.o: in function `_start':
/home/abuild/rpmbuild/BUILD/glibc-2.38/csu/../sysdeps/x86_64/start.S:103:(.text+0x2b):
undefined reference to `main'
collect2: error: ld returned 1 exit status
==25637==
==25637== HEAP SUMMARY:
==25637== in use at exit: 89,760 bytes in 39 blocks
==25637== total heap usage: 175 allocs, 136 frees, 106,565 bytes allocated
==25637==
==25637== LEAK SUMMARY:
==25637==definitely lost: 0 bytes in 0 blocks
==25637==indirectly lost: 0 bytes in 0 blocks
==25637== possibly lost: 0 bytes in 0 blocks
==25637==still reachable: 89,760 bytes in 39 blocks
==25637== of which reachable via heuristic:
==25637== newarray : 1,544 bytes in 1 blocks
==25637== suppressed: 0 bytes in 0 blocks
==25637== Rerun with --leak-check=full to see details of leaked memory
==25637==
==25637== For lists of detected and suppressed errors, rerun with: -s
==25637== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #43 from Jan Hubicka --- > // See discussion here: > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html Discussion says: "Once legacy evrp is removed, this won't be an issue, as ranges in the IL will tell the truth. However, this will mean that we will no longer remove the first __builtin_unreachable combo. But ISTM, that would be correct behavior ??." So perhaps, we could remove that special case for default def and phi? It is an odd thing and we clearly lose info here. The problem is that value of parameter i itself does not have global value range [0...10] so I need to compute new SSA name to get it preserved through ipa-split. Maybe ipa-split can be extended to fire up ranger and try to get better value ranges on function parameters from the split function header. Not sure if that is worth the effort though. If we go with merging functions with different ranges, we indeed need to update ranges and bits both in SSA_NAME infos and in ipa-prop's jump functions. At the time sem_fuction::merge calls ipa_merge_profiles we do have both function bodies in memory and thus we can do the job. If we just drop the info instead of merging, we do limited harm on SSA_NAME infos since they mostly will be recomputed again. For ipa-prop this may cause more interesting precision loss. So perhaps for backportability we may want to just limit ICF to functions wth same ranges in SSA_NAME infos. Let me cook up a patch and see if there is significant loss in merged functions. I think it should be quite small given that ranges seem to only diverge through ipa-split in very specific cases for now. (and given how much time I spent on producing the testcase)
[Bug other/113961] New: [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 Bug ID: 113961 Summary: [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:7f3d900684ad989164114f25eb46a33871c6533d, r14-9028-g7f3d900684ad98 make -k check RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc" FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 3350) FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors) commit 7f3d900684ad989164114f25eb46a33871c6533d (HEAD) Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc [PR113931] This commit fixed the previous error in pr60037-neg.cc but caused a new one. In file included from /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/random:48,^M from /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu/bits/stdc++.h:179,^M from :^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h: In instantiation of 'struct std::__detail::_Adaptor, long unsigned int>':^M /home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc:8: required from here^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:270: error: static assertion failed: template argument must be a floating point type^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:270: note: 'std::integral_constant::value' evaluates to false^M In file included from /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/random:50:^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc: In instantiation of '_RealType std::generate_canonical(_UniformRandomNumberGenerator&) [with _RealType = long unsigned int; long unsigned int __bits = 64; _UniformRandomNumberGenerator = mersenne_twister_engine]':^M /home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc:11: required from here^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3351: error: static assertion failed: template argument must be a floating point type^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3351: note: 'std::integral_constant::value' evaluates to false^M compiler exited with status 1 PASS: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 270) FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 3350)
[Bug libstdc++/113841] Can't swap two std::hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |12.4
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #42 from Jakub Jelinek --- So guess we need to union the ranges and for earlier gccs also the zero bits stuff upon ICF, right?
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jan Hubicka changed:
What|Removed |Added
Summary|[14 regression] ICU |[12/13/14 regression] ICU
|miscompiled since on x86|miscompiled since on x86
|since |since
|r14-5109-ga291237b628f41|r14-5109-ga291237b628f41
--- Comment #41 from Jan Hubicka ---
OK, the reason why this does not work is that ranger ignores earlier value
ranges on everything but default defs and phis.
// This is where the ranger picks up global info to seed initial
// requests. It is a slightly restricted version of
// get_range_global() above.
//
// The reason for the difference is that we can always pick the
// default definition of an SSA with no adverse effects, but for other
// SSAs, if we pick things up to early, we may prematurely eliminate
// builtin_unreachables.
//
// Without this restriction, the test in g++.dg/tree-ssa/pr61034.C has
// all of its unreachable calls removed too early.
//
// See discussion here:
// https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
void
gimple_range_global (vrange , tree name, struct function *fun)
{
tree type = TREE_TYPE (name);
gcc_checking_assert (TREE_CODE (name) == SSA_NAME);
if (SSA_NAME_IS_DEFAULT_DEF (name) || (fun && fun->after_inlining)
|| is_a (SSA_NAME_DEF_STMT (name)))
{
get_range_global (r, name, fun);
return;
}
r.set_varying (type);
}
This makes ipa-prop to ignore earlier known value range and mask the bug.
However adding PHI makes the problem to reproduce:
#include
#include
int data[100];
int c;
static __attribute__((noinline))
int bar (int d, unsigned int d2)
{
if (d2 > 30)
c++;
return d + d2;
}
static int
test2 (unsigned int i)
{
if (i > 100)
__builtin_unreachable ();
if (__builtin_expect (data[i] != 0, 1))
return data[i];
for (int j = 0; j < 100; j++)
data[i] += bar (data[j], i&1 ? i+17 : i + 16);
return data[i];
}
static int
test (unsigned int i)
{
if (i > 10)
__builtin_unreachable ();
if (__builtin_expect (data[i] != 0, 1))
return data[i];
for (int j = 0; j < 100; j++)
data[i] += bar (data[j], i&1 ? i+17 : i + 16);
return data[i];
}
int
main ()
{
int ret = test (1) + test (2) + test (3) + test2 (4) + test2 (30);
if (!c)
abort ();
return ret;
}
This fails with trunk, gcc12 and gcc13 and also with Jakub's patch.
[Bug libstdc++/113294] constexpr error from accessing inactive union member in basic_string after move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.3 Status|NEW |RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 13.3/14 thanks for the report and patch!
[Bug libstdc++/113294] constexpr error from accessing inactive union member in basic_string after move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ebe00c9d3a0436dec5c354a62d98e444d763ff95 commit r13-8335-gebe00c9d3a0436dec5c354a62d98e444d763ff95 Author: Paul Keir Date: Mon Feb 12 18:15:49 2024 + libstdc++: Fix constexpr basic_string union member [PR113294] A call to `basic_string::clear()` in the std::string move assignment operator leads to a constexpr error from an access of inactive union member `_M_local_buf` in the added test (`test_move()`). Changing `__str._M_local_buf` to `__str._M_use_local_data()` in `operator=(basic_string&& __str)` fixes this. PR libstdc++/113294 libstdc++-v3/ChangeLog: * include/bits/basic_string.h (basic_string::operator=): Use _M_use_local_data() instead of _M_local_buf on the moved-from string. * testsuite/21_strings/basic_string/modifiers/constexpr.cc (test_move): New test. Signed-off-by: Paul Keir Reviewed-by: Patrick Palka Reviewed-by: Jonathan Wakely (cherry picked from commit 065dddc6e07a917c57c7955db13b1fe77abbcabc)
[Bug libstdc++/99117] [11/12/13 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117 --- Comment #24 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3a72c717b311ce8093042d927a1f2f2b940a969c commit r13-8334-g3a72c717b311ce8093042d927a1f2f2b940a969c Author: Jonathan Wakely Date: Thu Feb 8 13:59:42 2024 + libstdc++: Avoid aliasing violation in std::valarray [PR99117] The call to __valarray_copy constructs an _Array object to refer to this->_M_data but that means that accesses to this->_M_data are through a restrict-qualified pointer. This leads to undefined behaviour when copying from an _Expr object that actually aliases this->_M_data. Replace the call to __valarray_copy with a plain loop. I think this removes the only use of that overload of __valarray_copy, so it could probably be removed. I haven't done that here. libstdc++-v3/ChangeLog: PR libstdc++/99117 * include/std/valarray (valarray::operator=(const _Expr&)): Use loop to copy instead of __valarray_copy with _Array. * testsuite/26_numerics/valarray/99117.cc: New test. (cherry picked from commit b58f0e5216a3053486e7f1aa96c3f2443b14d630)
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #40 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #39)
> This testcase
> #include
> int data[100];
>
> __attribute__((noinline))
> int bar (int d, unsigned int d2)
> {
> if (d2 > 10)
> printf ("Bingo\n");
> return d + d2;
> }
So, while d2 should have [17, 27] range when called from test2 and [17, 117]
from test,
I don't see anything that would limit ranges of data[?], it can be anything
(say some global constructor modifying the data array). So bar has to return
VARYING.
[Bug other/113957] [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 Iain Sandoe changed: What|Removed |Added Component|c++ |other Keywords|wrong-code |error-recovery URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Februar ||y/645814.html --- Comment #2 from Iain Sandoe --- patch posted.
