[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I believe the really problematic change was r14-2389-g3cce8d98f270f48f
which introduced at least in theory the buffer overflow, before that the
maximum string length no matter what m_val was was 62 chars.

Now, I wonder what is the reason to have methods dump it into a buffer and then
dump the buffer to FILE *, when the former method is only used in the latter
method and nowhere else.

2024-02-21  Jakub Jelinek  <jakub@redhat.com>

        PR ipa/111960
        * profile-count.h (profile_count::dump): Remove overload with
        char * first argument.
        * profile-count.cc (profile_count::dump): Change overload with char *
        first argument which uses sprintf into the overfload with FILE *
        first argument and use fprintf instead.  Remove overload which wrapped
        it.

--- gcc/profile-count.h.jj      2024-01-03 11:51:30.309748150 +0100
+++ gcc/profile-count.h 2024-02-21 21:04:22.338905728 +0100
@@ -1299,9 +1299,6 @@ public:
   /* Output THIS to F.  */
   void dump (FILE *f, struct function *fun = NULL) const;

-  /* Output THIS to BUFFER.  */
-  void dump (char *buffer, struct function *fun = NULL) const;
-
   /* Print THIS to stderr.  */
   void debug () const;

--- gcc/profile-count.cc.jj     2024-01-03 11:51:40.782602796 +0100
+++ gcc/profile-count.cc        2024-02-21 21:05:28.521994913 +0100
@@ -84,34 +84,24 @@ const char *profile_quality_display_name
   "precise"
 };

-/* Dump THIS to BUFFER.  */
+/* Dump THIS to F.  */

 void
-profile_count::dump (char *buffer, struct function *fun) const
+profile_count::dump (FILE *f, struct function *fun) const
 {
   if (!initialized_p ())
-    sprintf (buffer, "uninitialized");
+    fprintf (f, "uninitialized");
   else if (fun && initialized_p ()
           && fun->cfg
           && ENTRY_BLOCK_PTR_FOR_FN (fun)->count.initialized_p ())
-    sprintf (buffer, "%" PRId64 " (%s, freq %.4f)", m_val,
+    fprintf (f, "%" PRId64 " (%s, freq %.4f)", m_val,
             profile_quality_display_names[m_quality],
             to_sreal_scale (ENTRY_BLOCK_PTR_FOR_FN (fun)->count).to_double
());
   else
-    sprintf (buffer, "%" PRId64 " (%s)", m_val,
+    fprintf (f, "%" PRId64 " (%s)", m_val,
             profile_quality_display_names[m_quality]);
 }

-/* Dump THIS to F.  */
-
-void
-profile_count::dump (FILE *f, struct function *fun) const
-{
-  char buffer[64];
-  dump (buffer, fun);
-  fputs (buffer, f);
-}
-
 /* Dump THIS to stderr.  */

 void

patch certainly fixes the buffer overflow...  Or of course just enlarge the
buffer.
But, I don't really see anything that would bound sreal values to be within
some small double range, the range of m_exp is range of int, so in theory the
ldexp can always overflow to infinity or result in close to maximum finite
representable doubles.