[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #20 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-10-11 10:57:45 UTC --- Author: paolo Date: Tue Oct 11 10:57:40 2011 New Revision: 179797 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179797 Log: 2011-10-11 Paolo Carlini paolo.carl...@oracle.com PR c++/33067 * c-family/c-pretty-print.c (pp_c_floating_constant): Output max_digits10 (in the ISO C++ WG N1822 sense) decimal digits. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-pretty-print.c
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-11 11:03:04 UTC --- On x86_64-linux, 4.7 will output: 33067.C:2:18: error: no match for ‘operator’ in ‘1.1001e+0 t’ or, for example, 33067.C:2:19: error: no match for ‘operator’ in ‘1.1002e+0f t’ in case of 1.1f, which are a definite improvement. For other issues in this area, the reference is PR49152.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 10:08:55 UTC --- I guess we should print floating point numbers with std::max_digits10 digits (a C++11 concept: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1822.pdf) Looking into it.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-10 11:46:00 UTC --- (In reply to comment #4) I guess we should print floating point numbers with std::max_digits10 digits (a C++11 concept: I guess g++ should not print expressions but types. I think we discussed such bug already elsewhere, Paolo. Precisely for this no match for operator error.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-10 11:48:03 UTC --- Actually, it was with Jonathan in PR49152. One of this is a duplicate of the other.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 11:53:57 UTC --- I don't understand: this number should not be printed at all?!?
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 11:55:15 UTC --- I'm really confused, I don't understand what we are going to print in 4.7.0 for this error message.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
--- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-10
12:08:28 UTC ---
(In reply to comment #8)
I'm really confused, I don't understand what we are going to print in 4.7.0
for
this error message.
Nothing changed as far as I know, but the suggestion of Jonathan in PR49152 is
to print the types involved in the expression instead of the expression itself,
which will avoid printing weird numbers in this case.
Like Clang does:
/tmp/webcompile/_27664_0.cc:3:16: error: invalid operands to binary expression
('double' and 'struct T')
I agree that this would be an improvement already.
I don't think you can get the number right in general, since the original
representation is gone after the tokens are converted into the internal
representation.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-10 12:12:13 UTC --- (In reply to comment #9) (In reply to comment #8) I'm really confused, I don't understand what we are going to print in 4.7.0 for this error message. Nothing changed as far as I know, but the suggestion of Jonathan in PR49152 is to print the types involved in the expression instead of the expression itself, which will avoid printing weird numbers in this case. Like Clang does: And the C FE: test.cc:2:13: error: invalid operands to binary (have ‘double’ and ‘struct T’)
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 12:14:19 UTC --- (In reply to comment #9) I don't think you can get the number right in general, since the original representation is gone after the tokens are converted into the internal representation. This for sure, it's a long standing, much more general, issue, right? Anyway, ok, let's try to what the C front-end does. Hey, these PRs remained un-triaged for way long time!!!
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 12:26:14 UTC --- Ok, call.c:op_error must be completely changed. Too much work for me at the moment.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-10 12:28:09 UTC --- (In reply to comment #12) Ok, call.c:op_error must be completely changed. Too much work for me at the moment. I think if you agree it is the same issue, at least we could close this one as a duplicate and confirm PR49152 ?
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 12:33:31 UTC --- Frankly, I'm not convinced that before fixing the *whole* PR49152 we couldn't manage to find a way to print floating point constants in a more decent way. Maybe not easy, but not impossible.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 12:37:09 UTC --- For example, as a user of the compiler, seeing 6 digits everywhere would not surprise me at all, together with a correct column number, I would certainly consider the output good enough and not confusing. But this is just a personal opinion.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 12:44:42 UTC --- Harcoding 6 in pp_c_floating_constant leads to: 33067.C:2:18: error: no match for ‘operator’ in ‘1.1e+0 t’
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-10-10 12:45:56 UTC --- (In reply to comment #14) Frankly, I'm not convinced that before fixing the *whole* PR49152 we couldn't manage to find a way to print floating point constants in a more decent way. Maybe not easy, but not impossible. I personally think that if the object of printing the constant is to recreate the source code, but the source code won't match anyway, then it is better to not print it at all. If the goal of printing is some other (debugging, dump files, ...), then it may make sense. Another issue is that if someone comes around a fixes PR49152, then your testcase for printing floating point constants nicely would be broken. Has this person to come up with a new testcase for this? delete the testcase? It just makes PR49152 slightly harder to fix.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 12:54:54 UTC --- Sorry, I'm an engineer (in this context). For me the issue is only the following: if I were a user of 4.7.0, I would rather prefer seeing: 33067.C:2:18: error: no match for ‘operator’ in ‘1.100088817841970012523233890533447265625e+0 t’ or 33067.C:2:18: error: no match for ‘operator’ in ‘1.1e+0 t’ ? Any other discussion, in this context, does not make sense to me, sorry. I'm not going to follow it. If the maintainers will reply on gcc-patches they want the latter, fine I'll do it, otherwise I'll just move to something else.
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067 --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-10 12:56:47 UTC --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00754.html
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
--- Comment #3 from bangerth at dealii dot org 2007-09-08 23:27 --- Confirmed. In particular, the value 1.1 is of type 'double' for which it hardly ever makes sense to print it to 47 digits :-) W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-09-08 23:27:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-14 17:02 --- Well 1.1 is not directly represented in double precission which is why you get that weird number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
[Bug c++/33067] Awkward long decimal expansion for double literal in error.
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2007-08-14 17:19 --- I know that, but that's irrelevant from a user interface perspective. The fact remains that the error message is needlessly messy and would be far clearer and less surprising to the user if it said 1.1 instead of 1.100088817841970012523233890533447265625e+0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
