[Bug tree-optimization/80635] [9/10 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Paul Fee changed:
What|Removed |Added
CC||paul.f.fee at gmail dot com
--- Comment #65 from Paul Fee ---
Below is some code that produces unexpected -Wmaybe-uninitialized warnings. Is
this a variant of this bug or a separate bug?
I've tried a few configurations:
Unexpected warnings:
$ g++-10 -Wall -O2 warn.cpp -DBOOST
warn.cpp: In function ‘int main()’:
warn.cpp:19:10: warning: ‘*((void*)& i +1)’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
19 | m_i(i)
| ^
warn.cpp:32:10: note: ‘*((void*)& i +1)’ was declared here
32 | optb i;
| ^
No warnings (c++17 flag not needed with GCC 11).
$ g++-10 -Wall -O2 warn.cpp -std=c++17
$ g++-11 -Wall -O2 warn.cpp -DBOOST
$ g++-11 -Wall -O2 warn.cpp
The constructor takes three optional and one optional.
Adjusting the number and types of parameters makes a difference, but I don't
see why. Perhaps with less parameters, passing by register rather than stack
memory affects warning generation. However 4 x optional gives no
warning and that would be larger than 3 x optional plus 1 x
optional.
It's not clear why std::optional would be free from warnings, yet
boost::optional not. Is adoption of std::optional an effective way of avoiding
unnecessary -Wmaybe-uninitialized warnings?
It seems that GCC 11 has better behaviour. Is this expected or would some
other (perhaps larger) collection of parameters trigger the same warning with
GCC 11?
If GCC 11 incorporates a specific fix, will that be backported to GCC 10?
Tested with GCC on openSUSE Tumbleweed. Package versions:
gcc10-c++-10.3.0+git1587-2.1.x86_64
gcc11-c++-11.1.1+git340-1.1.x86_64
The source for warn.cpp:
#include
#ifdef BOOST
#include
using opts = boost::optional;
using optb = boost::optional;
#else
#include
using opts = std::optional;
using optb = std::optional;
#endif
class foo
{
public:
foo(opts a, opts b, opts c,
optb i)
: m_a(a), m_b(b), m_c(c),
m_i(i)
{}
private:
opts m_a;
opts m_b;
opts m_c;
optb m_i;
};
int main()
{
opts a, b, c;
optb i;
foo bar(a, b, c, i);
}
[Bug libstdc++/96850] format missing from std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96850 Paul Fee changed: What|Removed |Added CC||paul.f.fee at gmail dot com --- Comment #3 from Paul Fee --- Duplicate of bug 104166. I'd change the status, but I don't have the necessary bugzilla privileges.
[Bug c++/109548] New: Detect c_str() dangling problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109548
Bug ID: 109548
Summary: Detect c_str() dangling problems
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: paul.f.fee at gmail dot com
Target Milestone: ---
Thanks to bug 106393, G++ 13 can now catch simple dangling references, such as:
const int& f(const int& i) { return i; }
const int& i = f(10);
However, more complex examples do not trigger warnings:
#include
std::string foo();
auto ptr = foo().c_str();
ASAN can detect stack-use-after-scope at runtime. Clang can catch the issue at
build time.
$ clang++ -c small.cpp
small.cpp:3:12: warning: object backing the pointer will be destroyed at the
end of the full-expression [-Wdangling-gsl]
auto ptr = foo().c_str();
^
1 warning generated.
Another example:
std::stringstream ss;
ss << "foo";
auto ptr = ss.str().c_str();
We're warned against this in the notes on cppreference.com, however it would be
better if GCC could detect such issues and warn during compilation.
https://en.cppreference.com/w/cpp/io/basic_stringstream/str
[Bug c/119148] New: Inconsistent -Wstringop-truncation warning when using strncpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119148
Bug ID: 119148
Summary: Inconsistent -Wstringop-truncation warning when using
strncpy
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: paul.f.fee at gmail dot com
Target Milestone: ---
I'm seeing an unexpected warning with GCC relating to strncpy(). First some
minimal code to illustrate the issue:
1 #include
2 #include
3
4 int main()
5 {
6 const char *src = "123456";
7 char arr[6] = {1,2,3,4,5,6};
8 size_t l = 5;
9 [[maybe_unused]] char *ptr = arr;
10
11 #define dst arr
12 // #define dst ptr
13
14 strncpy(dst, src, l);
15 dst[l] = '\0';
16 assert(strlen(dst) == l);
17 }
Compiled with: cc truncation.c -Wall -O1 && ./a.out
When the destination is an array, lines 14 and 15 in combination are safe,
there's no warning. However, when we swap macros on lines 11 and 12, we get a
warning, though the assert still passes.
truncation.c:14:5: warning: ‘strncpy’ output truncated copying 5 bytes from a
string of length 6 [-Wstringop-truncation]
Why do we get a warning when the destination is a pointer rather than an array?
