https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
--- Comment #6 from Martin Sebor ---
Author: msebor
Date: Wed Dec 14 21:58:19 2016
New Revision: 243672
URL: https://gcc.gnu.org/viewcvs?rev=243672&root=gcc&view=rev
Log:
PR middle-end/78786 - GCC hangs/out of memory calling sprintf with large
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code, patch
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
--- Comment #4 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #3)
> On -33 0, this program outputs:
>
> 2147483616
> 10487712
I forgot to say that I used "/usr/bin/time -f %M ..." to get the second output
number, which is th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
--- Comment #3 from Vincent Lefèvre ---
Well, concerning "%.*Rf", indeed, mpfr_snprintf allocates 2 GB for a short
period. But I notice that glibc is much worse. Consider the following program.
#include
#include
#include
#include
int main (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
--- Comment #2 from Vincent Lefèvre ---
With "%.*f", the problem comes from GMP (and possibly glibc) since MPFR calls
the GMP functions to handle non-MPFR format specifiers.
But the patch seems to use "%.*Rf", for which I cannot reproduce the pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78786
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|
