https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672
--- Comment #12 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to jamespharvey20 from comment #11)
> I can confirm applying Bernd Edlinger's "2018-10-21 18:16:41 UTC" patch on
> current trunk prevents all 3 reported errors, and allows using
> CPPFLAGS="-D_FORTIFY_SOURCE=2" and the additions of "-O2" into
> {libiberty,gcc}/configure.
>
Then you are lucky, because current trunk does not compile for me.
I had to roll back to r265240 first.
>
> Obviously, no one is obligated to provide me any insight. (Of course, no
> one was even obligated to fix this, thanks Bernd for doing so!) I'd love
> hearing: (1) how stage 2 was succeeding but stage 3 was failing, in a short
> "explain it to me like I can compile and use gcc and know the theory of
> bootstrapping, but have no idea what this patch is really doing"; and (2) if
> this patch fixes a somewhat "hidden/silent" bug that needed to be fixed even
> for people not compiling using these compilation flags, or if the fix is
> limited in scope to those using these flags who would run into the
> compilation error.
I think stage 2 uses -fno-checking while stage 3 does -fchecking=1,
that explains why only stage 3 runs into the assertions.
My patch does two things, first it gimplifies the expression
"(long unsigned int) ((ssizetype) _19 <= 7 ? 7 - (ssizetype) _19 : 0);"
This fixes the ICE that was exposed by my patch.
And secondly it fixes the length parameter of the transformation
strcat_chk => strcpy_chk. This wrong transformation is likely
already there in 8.0.
So yes, this is a real bug, and thanks for reporting, by the way.
