[Bug libstdc++/114325] std::format gives incorrect results for negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114325
Michael Duggan changed:
What|Removed |Added
CC||mwd at md5i dot com
--- Comment #1 from Michael Duggan ---
I will note that, in experiments, this seems to solely happen with "{}". If
anything else is in the format string, it works correctly. This is probably a
bug in the fairly recent codepath that optimizes the "{}" case.
[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #10 from Michael Duggan --- To sum up what I have figured out, C++ transforms the coroutine "function" into a trio of functions: a ramp function, an actor function, and a destruction function. The ramp function acts as the actual function (by name). The actor function contains the original body of the written function (with some transformations), and thus contains the code associated with most of the lines that need coverage information. Since the actor function is generated artificially, it is marked as artificial. The gcov program explicitly ignores functions that are marked as artificial. Also, even if that were not the case, it looks to me like the line coverage information for the actor function only includes the initial line of the function. This seems to be due to the way the artificial function gets inserted into the list of functions of the program. In order to solve this problem, we would need to at least the following: Find a way to not ignore the actor function. This would involve either not marking it as artificial or by marking it in some other way that would be recognized by gcov. Ensure that the actor function properly includes the line number information from the original coroutine body. Most of this work would probably need to be done in the c++ code (where the coroutine transformation happens) rather than in the coverage code. Should this be reassigned to the c++ component?
[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #9 from Michael Duggan --- More data: The coroutine actor is marked as artificial in coro_build_actor_or_destroy_function. As a result, it is completely ignored by gcov. In gcov's process_all_functions function, artificial functions are removed from the set of functions to consider. This may not be the only problem, but this will definitely prevent things from working. The marking is not incorrect. The actor function is artificial. But, unlike most artificial functions, it is built using the body of an actual function. I'm not certain how that should be dealt with.
[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #8 from Michael Duggan --- Using the better test case, I have determined that the coroutine _is_ being instrumented with gcov counters. When disassembled, the output contains the following in the bar() actor function: Dump of assembler code for function bar(_Z3barv.Frame *): ... 0x67a3 <+527>: mov0x5286(%rip),%rax# 0xba30 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+112> 0x67aa <+534>: add$0x1,%rax 0x67ae <+538>: mov%rax,0x527b(%rip)# 0xba30 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+112> => 0x67b5 <+545>: call 0x6359 <_Z5emptyv> 0x67ba <+550>: mov0x5277(%rip),%rax# 0xba38 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+120> 0x67c1 <+557>: add$0x1,%rax 0x67c5 <+561>: mov%rax,0x526c(%rip)# 0xba38 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+120> 0x67cc <+568>: call 0x6359 <_Z5emptyv> 0x67d1 <+573>: mov0x5268(%rip),%rax# 0xba40 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+128> 0x67d8 <+580>: add$0x1,%rax 0x67dc <+584>: mov%rax,0x525d(%rip)# 0xba40 <__gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor+128> 0x67e3 <+591>: call 0x6359 <_Z5emptyv> Therefore, the problem probably lies in either in the mapping from the counters to the line numbers or in gcov itself, possibly by missing the "actor" version of bar in favor of the ramp function. I'll note the following entries in the symbol table, from readelf: 36: 7aa096 OBJECT LOCAL DEFAULT 27 __gcov0._Z3barv 37: 2594 943 FUNCLOCAL DEFAULT 15 bar(bar()::_Z3barv.Frame*) [clone .actor] 38: 294383 FUNCLOCAL DEFAULT 15 bar(bar()::_Z3barv.Frame*) [clone .destroy] 39: 79c0 216 OBJECT LOCAL DEFAULT 27 __gcov0._Z3barPZ3barvE13_Z3barv.Frame.actor 40: 79b016 OBJECT LOCAL DEFAULT 27 __gcov0._Z3barPZ3barvE13_Z3barv.Frame.destroy 107: 23e2 434 FUNCGLOBAL DEFAULT 15 bar()
[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 Michael Duggan changed: What|Removed |Added Attachment #55648|0 |1 is obsolete|| --- Comment #7 from Michael Duggan --- Created attachment 55812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55812=edit Better example This example has both a coroutine and a non-coroutine with the same contents. Rather than using cout, it calls an empty function that is designed to not be optimized away.
[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 --- Comment #4 from Michael Duggan --- I should be more explicit. The `std::cout` line in the example is just a placeholder for "does some work here," and this example is specifically the simplest version of a coroutine I could come up with that would demonstrate the problem. When I initially encountered this problem, I was doing coverage testing that included a coroutine that was over 70 lines long, includes lots of loops and branching, and exited and re-entered multiple times via `co_yield`. I wanted to know if my test programs properly covered all of the branches. It is not enough to know how many times the coroutine itself is called.
[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827
--- Comment #3 from Michael Duggan ---
(In reply to Richard Biener from comment #1)
> I'm seeing all code properly instrumented. The coverage I see is
>
> -:1:#include
> -:2:#include
> -:3:
> -:4:struct task {
> -:5: struct promise {
> -:6:using handle_t = std::coroutine_handle;
> 1:7:task get_return_object() {
> 1:8: return task{handle_t::from_promise(*this)};
> -:9:}
> 1: 10:std::suspend_never initial_suspend() noexcept { return
> {}; }
> 1: 11:std::suspend_always final_suspend() noexcept { return
> {}; }
> #: 12:void unhandled_exception() { std::terminate(); }
> 1: 13:void return_void() noexcept {}
> -: 14:friend task;
> -: 15: };
> -: 16: using promise_type = promise;
> 1: 17: task(promise_type::handle_t handle) : handle_{handle} {}
> 1: 18: ~task() {
> 1: 19:if (handle_) {
> 1: 20: handle_.destroy();
> -: 21:}
> 1: 22: }
> -: 23: private:
> -: 24: promise_type::handle_t handle_;
> -: 25:};
> -: 26:
> 1: 27:task foo() {
> -: 28: std::cout << "Running..." << std::endl;
> -: 29: co_return;
> 2: 30:}
> -: 31:
> 1: 32:int main(int argc, char **argv) {
> 1: 33: foo();
> 1: 34: return 0;
> -: 35:}
>
> I have no idea why for example line 28 isn't marked executed.
The point is that no matter what is put in the coroutine, foo, nothing within
the coroutine will ever be marked as having been run.
[Bug gcov-profile/110827] New: C++20 coroutines aren't being measured by gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110827 Bug ID: 110827 Summary: C++20 coroutines aren't being measured by gcov Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: mwd at md5i dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 55648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55648=edit Simple bug exemplar When compiling with `--coverage` and running a program that utilizes C++20 coroutines, the statements in the coroutines aren't measured by gcov. Compile the attached file, `foo.cpp`, with: `g++ -std=c++20 --coverage -O0 -ggdb3 -o foo foo.cpp` Then run the resulting `foo`, followed by `gcov foo.cpp`. The resulting output in `foo.cpp.gcov` does not include lines 28 or 29 of `foo.cpp`, the contents of the coroutine `foo()`. In my tests this happens with any coroutine of any size, though functions called by a coroutine are covered properly.
[Bug libstdc++/108265] New: chrono::hh_mm_ss can't be constructed from unsigned durations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265
Bug ID: 108265
Summary: chrono::hh_mm_ss can't be constructed from unsigned
durations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mwd at md5i dot com
Target Milestone: ---
chrono::hh_mm_ss can't be constructed from unsigned durations.
For example:
#include
int main()
{
std::chrono::duration dur{};
auto hms = std::chrono::hh_mm_ss(dur);
}
This fails because the hh_mm_ss constructor calls chrono::abs on the passed in
duration, and chrono::abs doesn't participate in overload resolution when the
duration is unsigned.
[Bug libstdc++/108258] std::ranges::begin() fails on zero sized std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108258 --- Comment #1 from Michael Duggan --- Preprocessed source will be added once I've reduced it. In the meantime, the non-preprocessed source in the comment should be enough to trigger the problem with the specified version of gcc.
[Bug libstdc++/108258] New: std::ranges::begin() fails on zero sized std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108258 Bug ID: 108258 Summary: std::ranges::begin() fails on zero sized std::array Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mwd at md5i dot com Target Milestone: --- The following snippet fails to compile (with -std=c++20) in snapshot gcc-13-20221225. #include #include static constexpr std::array a; static constexpr auto b = std::ranges::begin(a); This appears to be because __array_traits::Type's members aren't constexpr. This compiled in gcc-12. Preprocessed sources attached.
[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247 --- Comment #8 from Michael Duggan --- Created attachment 53533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53533=edit Reduced bug exemplar
[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
Michael Duggan changed:
What|Removed |Added
CC||mwd at md5i dot com
--- Comment #7 from Michael Duggan ---
I am working with some code that exhibits a similar problem. I've run creduce
on the preprocessed code to create an exemplar, which I have attached as
bug-mwd.cpp. Here's the relevant warnings from g++ 12.2.0 using '-std=c++14
-Wall -O2':
In member function ‘void i< >::m(k*) [with ab = s]’,
inlined from ‘void i< >::m(k*) [with ab = I]’ at
bug.cpp:25:26,
inlined from ‘i< >::i(n) [with n = I*; ab = I]’ at
bug.cpp:23:39,
inlined from ‘am I::u()’ at bug.cpp:48:3:
bug.cpp:27:5: warning: array subscript ‘i::k {aka s}[0]’ is partly outside
array bounds of ‘unsigned char [40]’ [-Warray-bounds]
27 | e(p->aa);
| ^~~~
bug.cpp: In member function ‘am I::u()’:
bug.cpp:48:9: note: object of size 40 allocated by ‘operator new’
48 | o(new I);
| ^
The example is convoluted, I am afraid. One very strange bit is that if I
change the 'o's in 'class I' to, say, 'p', I get a completely different error.
If you think this is unrelated, let me know, and I will submit a new bug
report.
