Re: Possible GCC optimization bug

On Thu, 12 Feb 2026 at 01:02, Anubis 1101 via Gcc-help <[email protected]>
wrote:

> I've encountered some very strange behavior in this string class I'm
> working on, and I think I've narrowed it down to being a compiler bug.
> Here's the Godbolt link: https://godbolt.org/z/axPjzP1Eq
> All unnecessary members have been commented out, but left in for reference.
>
> The basic idea is that I'm measuring the free space between the current
> size of the string and the string's capacity, and then using that to
> properly concatenate a single char (conditionally followed by a terminator).
> However, the size check goes awry once it's inside an if() or switch()
> check, seemingly changing to the wrong value, and then changing back.
> Additionally, even if I abstract the subscript operation to the member
> function (which has its own explicit bounds checking), now THAT check fails
> as well, in the same way! It seems to happen most noticeably when
> 'available' is zero, but because this is a single-char concatenation, it's
> difficult to test it any other way (the const char* version after it has no
> such issues).
>
> constexpr simpleString& concatenate(constchar input)noexcept{
> const std::size_t currentLength = length();
> const std::size_t available = Capacity-currentLength;
>
> //the bug starts happening here, in this check
> if(available >0){
> std::cout <<"\n value is greater than zero. value: "<< available<<
> std::endl;
> this->operator[](currentLength)= input; //the bounds check inside this
> operator ALSO exhibits the bug
> }
> if(available >1){
> std::cout <<"\n value is greater than one. value: "<< available<<
> std::endl;
> this->operator[](currentLength)='\0';
> }
>

If available is 2 then you append the character, then overwrite it with the
null terminator. Should the nul be written to operator[](currentLength+1)
instead?

That's not the bug though.



>
> return*this;}
> No amount of reformatting, code cleaning, code malformation, or
> misdirection seems to unstick this bug. I tried rewriting it in different
> ways, and even as a fallthrough switch statement, to no avail. Even if I
> removed all instances of UB and did everything explicitly, the behavior did
> not change. I've tried to isolate it by separating out the member function,
> but then the bug goes away; it only seems to happen in the context of this
> class. I've also never had this problem before in any other context, so I'm
> not sure how to narrow it down further. I'm not experienced enough with
> assembly to pinpoint exactly what's going wrong, either.
>
> The only thing that made any difference was dropping it to a lower
> optimization level. On -O1 and -O0, it works just fine, but -O2 and -O3, it
> expresses the bug.
> Am I just missing something really simple here, or is this a legitimate
> bug?