gcc 11.0.1 is cranky

Sam

unread,

Apr 30, 2021, 9:23:11 PM4/30/21

to

Who can see a problem with this:

#include <vector>
#include <memory>

static char UTC[4];

void func(std::vector<char> &vec)
{
vec.clear();
vec.insert(vec.end(), UTC, UTC+4);
}

Preeety sure there's nothing wrong here. Either that, or it's time for me to
retire. So:

<mock-chroot> sh-5.1# g++ --version
g++ (GCC) 11.0.1 20210324 (Red Hat 11.0.1-0)
Copyright © 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

<mock-chroot> sh-5.1# g++ -O2 -Wall -Werror -c -o t.o t.C

[ massive shitstorm, ending with: ]

/usr/include/c++/11/bits/stl_algobase.h:431:30: error: ‘void* __builtin_memcpy(v
oid*, const void*, long unsigned int)’ writing 1 or more bytes into a region
of size 0 overflows the destination [-Werror=stringop-overflow=]

Removing the "vec.clear()" line makes gcc shut up.

Before I drop something into gcc's bugzilla, can someone convince me that
it's time for me to retire?

Chris M. Thomasson

unread,

Apr 30, 2021, 9:55:08 PM4/30/21

to

On 4/30/2021 6:22 PM, Sam wrote:
> #include <vector>
> #include <memory>
>
> static char UTC[4];
>
> void func(std::vector<char> &vec)
> {
> vec.clear();
> vec.insert(vec.end(), UTC, UTC+4);
> }

Checked this on GodBolt, x86-64 gcc 11.1:
_________________
#include <vector>
#include <iostream>

static char UTC[4];

std::vector<char>::size_type

func(std::vector<char> &vec)
{
vec.clear();
vec.insert(vec.end(), UTC, UTC+4);

return vec.size();
}

int main()
{
std::vector<char> vec;
std::vector<char>::size_type n = func(vec);
std::cout << "n = " << n << "\n";

return 0;
}
_________________

I get the following output with -Wall and -pedantic:
_________________
#1 with x86-64 gcc 11.1
ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0
n = 4
_________________

Not sure what is wrong with 11.0.1.

Chris M. Thomasson

unread,

Apr 30, 2021, 10:05:17 PM4/30/21

to

On 4/30/2021 6:22 PM, Sam wrote:

I wonder if the compiler is barfing up on vec.end() using an empty
vector? Just guessing.

Sam

unread,

Apr 30, 2021, 10:11:16 PM4/30/21

to

Looks likely. Adding "vec.reserve(4);" immediately after "vec.clear();"
makes this go away, too.

Here's 11.0.1's mess:

https://godbolt.org/z/8vnjfMcbE

But thanks for confirming that I am not missing something obvious.

Ben Bacarisse

unread,

Apr 30, 2021, 10:23:38 PM4/30/21

to

Hmm... not when I just tried it.

By the way, as far as I can tell, the #include <memory> is just clutter.
It's not need for the code, and removing it does not alter that error
messages. You'll get a cleaner bug report without it.

--
Ben.

Chris M. Thomasson

unread,

Apr 30, 2021, 10:27:09 PM4/30/21

to

Oh, try it without the -O2? Works for me. Even -O1 works. Humm...

Sam

unread,

Apr 30, 2021, 10:34:59 PM4/30/21

to

The question to resolve: is this a false positive from -O2 and -Wstringop-
overflow, or is gcc miscompiling it…

I don't grok assembler to be able to tell the difference.

Chris M. Thomasson

unread,

Apr 30, 2021, 10:50:09 PM4/30/21

to

Here are some screenshots I took:

Working fine:

https://i.ibb.co/nCHq5zv/godbolt-0.png

Not working with -O2:

https://i.ibb.co/Qp2Pzpz/godbolt-1.png

Keith Thompson

unread,

Apr 30, 2021, 11:46:23 PM4/30/21

to

I see a similar flurry of error messages using g++ 11.1.0 (built from
source on Ubuntu 20.04). It compiles without error using g++ 10.1.0,
10.2.0, and 10.3.0 (and earlier versions). No version of clang++ up to
and including 12.0.0 complains.

This looks similar to an error reported in another thread here last
December, posted by TDH1978, subject "Strange compiler warning...". But
that problem was a spurious warning issued by g++ 10.2.1 and apparently
corrected by g++ 11.0.1.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Chris M. Thomasson

unread,

May 3, 2021, 5:32:15 PM5/3/21

to

It sure does. Using -O2 makes gcc 11.1 barf errors up. However, it does
work on 11.1 without -O2.

Chris M. Thomasson

unread,

May 6, 2021, 10:35:12 PM5/6/21

to

> -Wstringop-overflow, or is gcc miscompiling it…

>
> I don't grok assembler to be able to tell the difference.

It must be a compiler error. The assembly aside for a moment, its been a
while since I wrote asm from scratch. The MEMBAR instruction in the
SPARC was very fun in RMO mode! ;^)