[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259

--- Comment #39 from Richard Biener <rguenth at gcc dot gnu.org> ---
Martin - this is another one, is there sth simple safe that can be done on the
8 branch?

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259

--- Comment #40 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #39)
> Martin - this is another one, is there sth simple safe that can be done on
> the 8 branch?

The patch series that resolved this while also avoiding the otherwise
considerable test suite fallout was very large and intrusive.  The series was
further split up and ultimately committed by Jeff in r267482, r267483, r267498,
r267503, r267505, r267520, and r267537.  I don't think it's suitable for
backporting.

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
   Target Milestone|8.5                         |9.0
         Resolution|---                         |FIXED
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The GCC 8 branch is being closed, fixed in GCC 9.1.

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[alx at kernel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259

--- Comment #42 from Alejandro Colomar <alx at kernel dot org> ---
I'm very confused by this ticket.

The discussion seems to be settled by Martin Sebor that the presented
code has UB due to pointer provenance issues, according to the WG14
interpretation of the standard.

GCC historically had relaxed rules on mem*() functions, to let old code
work as expected.  This is by no means required by ISO C, and is only
a GNU extension.  ISO C is stricter and under its rules, memcpy(3)
cannot cross subobject boundaries.  This is the ideal behavior, and the
intention is to tighten the rules so that code analysis becomes easier.

Nobody seemed to rebute Martin's analysys that it's UB with solid
ground, and I agree that it looks like UB.

Did I understand that correctly?

And then I see that something has been 'fixed' in GCC, and that the
ticket is marked as RESOLVED FIXED.  This is very confusing, since
nothing in the ticket really documents what was broken.  It seems that
GCC's relaxed rules on mem*() functions were extended to cover str*()
functions too.

May I ask why?  And may I ask a -fprovenance to get strict provenance
rules?  I find very confusing when code breaks provenance rules, because
simlarly to how a compiler will have trouble analyzing the code, a human
brain will have trouble understanding where some copy data came from (at
least that's true for mine).

See the following question, which seems to be very related to pointer
provenance rules: <https://software.codidact.com/posts/288138>.

I'd like to be able to guarantee that in my code nobody messes with
pointers to get magic copies out of nowhere.

Thanks.

[Bug tree-optimization/86259] [8 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[alx at kernel dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259

--- Comment #43 from Alejandro Colomar <alx at kernel dot org> ---
GCC's manual also doesn't seem to document any deviation from ISO C
rules regarding mem*() functions.  It would be good to document what is
the GCC interpretation of ISO C regarding those rules, and what GCC
considers extensions.  And it would also be interesting to note the
reason for such extensions being old code, and that the idea is getting
rid of them at some point, maybe as default, or maybe via some flags
such as -fprovenance.

If str*() functions got the same exception recently, it would also be
good to mention that.