[Bug gcov-profile/89959] New: gcov: "--long-file-names" is ignored when used in combination with "--hash-filenames"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89959 Bug ID: 89959 Summary: gcov: "--long-file-names" is ignored when used in combination with "--hash-filenames" Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: christian.morales.vega at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Fedora 29, gcc-8.3.1-2.fc29.x86_64 (no related patch AFAICT -> https://src.fedoraproject.org/rpms/gcc/tree/a050417cd5cb9b3269bcce2e324fab8d081e4355) a) Running "gcov -r -s -o <.gcda file>" I get files like .gcov b) Running "gcov -p -r -s -o <.gcda file>" I get files like .gcov c) Running "gcov -x -r -s -o <.gcda file>" I get files like ##.gcov d) Running "gcov -p -l -r -s -o <.gcda file>" I get files like ##.gcov e) Running "gcov -x -l -r -s -o <.gcda file>" I get files like ##.gcov Notice that 'c' and 'e' are identical, "-l" in 'e' has had no effect. I would have expected 'e' to be .gcov Also, notice that the documentation for --hash-filenames starts by saying: "By default, gcov uses the full pathname of the source files to create an output filename." That's incorrect, by default it uses only the filename. The documentation would be more clear if it would describe "--hash-filenames" as an alternative to "--preserve-paths". Interestingly, when "-x" is being used "-l" is ignored... but "-p" isn't. So it's possible to use "-p" and "-x" simultaneously, which makes no sense. You are using "-x" to avoid long filenames, but by using it together with "-p" you are just making the filename *longer*. FWIW the reason I'm using "-l" is not because I "want to see the individual contributions". My problem is that I'm using CDash (www.cdash.org), which runs gcov once per .gcda instead of running it a single time taking all the .gcda files as input (they should fix this https://gitlab.kitware.com/cmake/cmake/issues/19124#note_554321, but there may be others). By running gcov once per .gcda file the .gcov file for a header created by one invocation can get overwritten by the next .gcov invocation. Using "-l" works around this issue. Again, the problem is that CDash is using gcov incorrectly and they should fix the issue. But since I suspect they are not the only ones... maybe it makes sense to have another option to use the hash of the .gcda file? Meaning, running "gcov -x --hash-long-file-names -r -s -o <.gcda file>" I would get files like .gcov Which would let me, using short file names, call gcov once per .gcda file without the risk of overwriting .gcov files.
[Bug gcov-profile/89959] gcov: "--long-file-names" is ignored when used in combination with "--hash-filenames"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89959 --- Comment #1 from Cristian Morales Vega --- At the end of my previous comment .gcov should actually be ##.gcov
[Bug gcov-profile/89961] New: When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 Bug ID: 89961 Summary: When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: christian.morales.vega at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Fedora 29, gcc-8.3.1-2.fc29.x86_64 (no related patch AFAICT -> https://src.fedoraproject.org/rpms/gcc/tree/a050417cd5cb9b3269bcce2e324fab8d081e4355) In issue #89959 I described an issue I had because cmake runs gcov once per .gcda file. Unfortunately I noticed that it would not be possible to run gcov only once, with all the .gcda files, since the "--object-directory" is not the same for all the .gcda files. Fortunately gcov has the "--intermediate-format" option. Since "The output is a single .gcov file per .gcda file" I don't have the gcov files overwriting problems I had before, which required the use of "-l". But the reason why "--preserve-paths"/"--hash-filenames" exist doesn't go away because of the use of "--intermediate-format". Even when using "--intermediate-format", "--preserve-paths"/"--hash-filenames" are "useful if sourcefiles are in several different directories". Unfortunately there seems to be a bug in gcov: when "--intermediate-format" is used, "--preserve-paths"/"--hash-filenames" is ignored.
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #3 from Cristian Morales Vega --- I have just took a look inside one of the intermediate format .gcov files and didn't see any "current_working_directory". There is a full path "file" variable though. Not sure if that's what you mean. In any case anything inside the .gcov files would not solve my issue. My problem is that all the .gcov files are being created in the same directory and the .gcov files themselves get overwritten. So I have ./CMakeFiles/.dir/src/error.cpp.o ./CMakeFiles/.dir/src/error.cpp.gcda ./CMakeFiles/.dir/src/error.cpp.gcno ./test/CMakeFiles/catch_tests.dir/error.cpp.o ./test/CMakeFiles/catch_tests.dir/error.cpp.gcda ./test/CMakeFiles/catch_tests.dir/error.cpp.gcno And a single "error.cpp.gcda.gcov" file since cmake has run /usr/bin/gcov -x -i -o /CMakeFiles/.dir/src /CMakeFiles/cmake_target_name.dir/src/error.cpp.gcda and /usr/bin/gcov -x -i -o /test/CMakeFiles/catch_tests.dir /test/CMakeFiles/catch_tests.dir/error.cpp.gcda from the same directory, put all the files in a flat tarball and sent it to a CDash server. So I need the file names written to my hard drive to be different (i.e. -x to have effect).
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #5 from Cristian Morales Vega --- OK, trying to catch you here, from my gcc-8.3.1. So with gcc 9 "--intermediate-format" is gone and we now have "--json-format" (keeping the "-i" version)? The "--intermediate-format" documentation used to say "can be used by lcov or other tools". I guess the lcov devs know about this, but aren't the devs of "other tools" going to be cross? I mean, I was suggesting to cmake to use "--intermediate-format" (https://gitlab.kitware.com/cmake/cmake/issues/19124#note_554428)... now they would need to support two formats to be able to support different gcov versions. In any case I'm unsure how "current_working_directory" or "data_file" help with the cmake case. The problem is that cmake is going to call gcov once and it's going to create /tmp/error.cpp.gcda.gcov.json.gz with whatever contents, based on what CMakeFiles/.dir/src/error.cpp.gcda says. Then it's going to call gcov again, it's going to overwrite/destroy the /tmp/error.cpp.gcda.gcov.json.gz file created one second ago, and in its place is going to create a new /tmp/error.cpp.gcda.gcov.json.gz file based on what test/CMakeFiles/.dir/error.cpp.gcda says. So all the information contained on CMakeFiles/.dir/src/error.cpp.gcda gets lost. Sure, cmake could put the files in different directories to avoid overwriting them, but it doesn't. And if cmake could do "-x -i" I would end up with two files: /tmp/error.cpp.gcda##3626990101906c77dbd16dea3f1aab07.gcov.json.gz /tmp/error.cpp.gcda##39f7c940c3bc30bbedebd034d8c16a68.gcov.json.gz and so no information would be lost.
[Bug c++/93490] New: -Wsuggest-attribute=const suggests const attribute for non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93490 Bug ID: 93490 Summary: -Wsuggest-attribute=const suggests const attribute for non-static member function Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: christian.morales.vega at gmail dot com Target Milestone: --- I can't share the code triggering it. But gcc 9.2.1 from Fedora 31 is saying "function might be candidate for attribute ‘const’" for a member function. AFAIU since the member function takes the "this" pointer as argument it can't use the const attribute. FWIW the method - It already has the "pure" attribute - It just returns a reference to a member of the object - Is in a class derived from another using the CRTP It does it when building the class tests, with LTO. I have not checked, but it's possible the tests only ever use one object, so "this" couldn't ever change... in that specific code. If this is the problem I would argue that's a dangerous warning to give.
[Bug c++/93490] -Wsuggest-attribute=const suggests const attribute for non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93490 --- Comment #1 from Cristian Morales Vega --- The warning is not there when using ubsan/asan or tsan.
[Bug c++/93490] -Wsuggest-attribute=const suggests const attribute for non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93490
--- Comment #3 from Cristian Morales Vega ---
This seems to show the issue: https://godbolt.org/z/-VRgtF
class Class1 {
public:
auto member() -> int&
#ifdef INLINE
{
return member_;
}
#else
;
#endif
private:
int member_;
};
#ifndef INLINE
auto Class1::member() -> int& { return member_; }
#endif
extern Class1 obj1;
extern Class1 obj2;
int main() {
auto value = obj1.member();
auto value2 = obj2.member();
return value + value2;
}
With "INLINE" defined there is no warning.
[Bug c++/93490] -Wsuggest-attribute=const suggests const attribute for non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93490
--- Comment #6 from Cristian Morales Vega ---
Yes,
--
struct Class1 {
int member_;
};
int &f(Class1 *a) { return a->member_; }
--
also generates the warning.
This is a bug, right? I'm basing this issue on
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
saying "Note that a function that has pointer arguments and examines the data
pointed to must not be declared const if the pointed-to data might change
between successive invocations of the function."
[Bug c++/93490] -Wsuggest-attribute=const suggests const attribute for non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93490 --- Comment #7 from Cristian Morales Vega --- Oh, it isn't a bug because it's returning a reference and even if the value of member_ changes the reference (i.e. pointer) will always be the same?
[Bug c++/93490] -Wsuggest-attribute=const suggests const attribute for non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93490 Cristian Morales Vega changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Cristian Morales Vega --- Yeah, my bad. It says "examines the data pointed to", and that function is not really examining it. Sorry, closing.
[Bug libstdc++/105616] New: Using regex_replace throws "maybe-uninitialized" warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616
Bug ID: 105616
Summary: Using regex_replace throws "maybe-uninitialized"
warnings
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: christian.morales.vega at gmail dot com
Target Milestone: ---
As can be seen in https://godbolt.org/z/qK976bqzf
Building
#include
#include
#include
#include
int main()
{
std::string text = "Quick brown fox";
std::regex vowel_re("a|e|i|o|u");
// write the results to an output iterator
std::regex_replace(std::ostreambuf_iterator(std::cout),
text.begin(), text.end(), vowel_re, "*");
// construct a string holding the results
std::cout << '\n' << std::regex_replace(text, vowel_re, "[$&]") << '\n';
}
(taken from https://en.cppreference.com/w/cpp/regex/regex_replace)
with "-fsanitize=address -O1 -Wmaybe-uninitialized" creates a long list of
warnings
In file included from
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/regex:48,
from :3:
In constructor 'std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {char}]',
inlined from
'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&)
[with _Char_type = char]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:149:4,
inlined from 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:290:24:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:405:42:
warning: '*(std::function*)((char*)&__tmp +
offsetof(std::__detail::_StateT,
std::__detail::_State::.std::__detail::_State_base::)).std::function::_M_invoker'
may be used uninitialized [-Wmaybe-uninitialized]
405 | : _Function_base(), _M_invoker(__x._M_invoker)
| ^~
In file included from
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/regex:63:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h: In
member function 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]':
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:287:17:
note: '__tmp' declared here
287 | _StateT __tmp(_S_opcode_subexpr_end);
| ^
In member function 'bool std::_Function_base::_M_empty() const',
inlined from 'std::function<_Res(_ArgTypes ...)>::operator bool() const
[with _Res = bool; _ArgTypes = {char}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:574:25,
inlined from 'std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {char}]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:407:6,
inlined from
'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&)
[with _Char_type = char]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:149:4,
inlined from 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]' at
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:290:24:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:247:37:
warning: '*(const std::_Function_base*)((char*)&__tmp +
offsetof(std::__detail::_StateT,
std::__detail::_State::.std::__detail::_State_base::)).std::_Function_base::_M_manager'
may be used uninitialized [-Wmaybe-uninitialized]
247 | bool _M_empty() const { return !_M_manager; }
| ^~
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h: In
member function 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits]':
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/regex_automaton.h:287:17:
note: '__tmp' declared here
287 | _StateT __tmp(_S_opcode_subexpr_end);
| ^
In constructor 'std::function<_Res(_ArgTypes
...)>
[Bug c++/105671] New: Unexplained "undefined reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671 Bug ID: 105671 Summary: Unexplained "undefined reference" error Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: christian.morales.vega at gmail dot com Target Milestone: --- Created attachment 53005 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53005&action=edit Full verbose build log I have found a strange issue in my project build that reproduces is Ubuntu 22.04 (gcc 11.2) and Fedora 36 (gcc 12.1.1). This is the most I have been able to reduce it: $ tar xf boost_1_79_0.tar.bz2 $ cd boost_1_79_0/ $ ./bootstrap.sh $ ./b2 --with-program_options link=static --user-config=$PWD/../user-config.jam $ cd .. $ g++ -o /dev/null test.cpp -Iboost_1_79_0 boost_1_79_0/stage/lib/libboost_program_options.a -Os -flto /usr/bin/ld: /tmp/cccbpRrv.ltrans0.ltrans.o: in function `boost::program_options::options_description::get_option_column_width() const': :(.text+0x28cd): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' /usr/bin/ld: /tmp/cccbpRrv.ltrans0.ltrans.o: in function `boost::program_options::(anonymous namespace)::format_one(std::ostream&, boost::program_options::option_description const&, unsigned int, unsigned int) [clone .constprop.0]': :(.text+0x2d80): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' /usr/bin/ld: :(.text+0x2e13): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' /usr/bin/ld: :(.text+0x3d40): undefined reference to `std::__cxx11::basic_stringbuf, std::allocator >::_M_high_mark() const' collect2: error: ld returned 1 exit status $ I'm attaching a log showing the whole Boost.Program_options verbose build log. - Change "-Os" for "-O1" and it works - Remove the -supposedly unused- "#include " line and it works.
[Bug c++/105671] Unexplained "undefined reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671
--- Comment #1 from Cristian Morales Vega ---
It's in the full verbose build log, but failed to include it here. These are
the contents of the files:
$ cat user-config.jam
using gcc : : g++ : "-flto" ;
$ cat test.cpp
#include
#include
#include
int
main()
{
auto generic = boost::program_options::options_description{};
std::cout << generic;
}
[Bug libstdc++/105671] [11/12/13 Regression] Unexplained "undefined reference" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105671 --- Comment #4 from Cristian Morales Vega --- I can confirm adding "__attribute__((always_inline))" in _M_high_mark() solves the issue.
[Bug libstdc++/105616] Using regex_replace throws "maybe-uninitialized" warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616 --- Comment #2 from Cristian Morales Vega --- I don't think so. Supposedly it was fixed 2 months ago in trunk (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562#c14). But in https://godbolt.org/z/8a979Gha8 the warnings are still present (even if the full compilation doesn't complete because it takes too long for compiler explorer).
[Bug libstdc++/109703] New: __builtin_unreachable() reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109703
Bug ID: 109703
Summary: __builtin_unreachable() reached
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: christian.morales.vega at gmail dot com
Target Milestone: ---
This
(https://github.com/gcc-mirror/gcc/commit/bf78b43873b0b7e8f9a430df38749b8b61f9c9b8#diff-c8a656ef205ec6452ef0bed111a387dc9e7eb2404fb3222a48f9f93b2460bd55R278)
__builtin_unreachable() is reached using this code
--
#include
#include
int main() {
auto lower = std::string{"0123456789ABCDEF"};
auto upper = boost::algorithm::to_upper_copy(lower);
}
--
with Boost 1.82.
Doing "g++ -O1 -fsanitize=undefined -o main main.cpp && ./main" results in
/usr/include/c++/13/bits/basic_string.h:278:29: runtime error: execution
reached an unreachable program point
This is with gcc-13.1.1-1.fc38.x86_64 from Fedora 38.
AFAICT the bug is in libstdc++.
During the first iteration, is not until
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L201
that the data pointer is replaced from the SSO to the heap one; but one line
before, in
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.tcc#L200
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.h#L293
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13.1.0/libstdc%2B%2B-v3/include/bits/basic_string.h#L275
, it checks whether it should destroy the data based on whether _M_data() ==
_M_local_data().
