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

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Joshua Cogliati from comment #9)
--- snip ---
> I could look into either method of fixing this if you want.  (And for what
> it is worth, I do have copyright assignment paperwork from both myself and
> my employer for GCC filed)

First, thank you very much for the offer to help. Truthfully we do need more
contributors and it does take time to get familiar with the code base, and it
can be fun to work on.

This bug is my doing for sure.  I did a significant re-factoring of the code
and lost track of that variable, res_len. The intent is that it does not get
modified outside of those functions that are allocating the buffers.

In fact it is getting modified by build_float_string in write_float.def. The
build_float_string is being called within the macros of get_float_string. A
variable needs to be used by thos macros, but I don't think it needs to be
passed up the call chain.  The simplest thing would be to give a different
variable to get float string.

@@ -1566,19 +1568,19 @@ write_float_0 (st_parameter_dt *dtp, const fnode *f,
const char *source, int kin
   char buf_stack[BUF_STACK_SZ];
   char str_buf[BUF_STACK_SZ];
   char *buffer, *result;
-  size_t buf_size, res_len;
+  size_t buf_size, res_len, flt_str_len;

   /* Precision for snprintf call.  */
   int precision = get_precision (dtp, f, source, kind);

   /* String buffer to hold final result.  */
   result = select_string (dtp, f, str_buf, &res_len, kind);

   buffer = select_buffer (dtp, f, precision, buf_stack, &buf_size, kind);

   get_float_string (dtp, f, source , kind, 0, buffer,
-                           precision, buf_size, result, &res_len);
-  write_float_string (dtp, result, res_len);
+                           precision, buf_size, result, &flt_str_len);
+  write_float_string (dtp, result, flt_str_len);

   if (buf_size > BUF_STACK_SZ)
     free (buffer);

I also noticed that the buffer size for this small float is 323 which seems
crazy big, but there are other use cases where we need to hold much higher
precision numbers of digits. It seems pointless to do an alloc for this case so
I also suggest we do this:  

@@ -1465,7 +1466,7 @@ write_character (st_parameter_dt *dtp, const char
*source, int kind, size_t leng

 /* Floating point helper functions.  */

-#define BUF_STACK_SZ 256
+#define BUF_STACK_SZ 384


This eliminates 3 allocs in one I/O operation. The purpose of all this alloc
logic is to eliminate them.  The stack size change will mask the problem
uncovered in this test case, so I have tested with and without it.

Since I pretty much have this figured out, I will go ahead and do the commit.
However, please dont hesitate to take on other bugs and join the gfortranners
club. Much appreciated.

Reply via email to