[Bug c++/33067] Awkward long decimal expansion for double literal in error.

[Bug c++/33067] Awkward long decimal expansion for double literal in error.

[paolo.carlini at oracle dot com]

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.

[manu at gcc dot gnu.org]

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.

[manu at gcc dot gnu.org]

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.

[paolo.carlini at oracle dot com]

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.

[paolo.carlini at oracle dot com]

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.

[manu at gcc dot gnu.org]

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.

[manu at gcc dot gnu.org]

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.

[paolo.carlini at oracle dot com]

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.

[paolo.carlini at oracle dot com]

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.

[manu at gcc dot gnu.org]

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.

[paolo.carlini at oracle dot com]

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.

[paolo.carlini at oracle dot com]

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.

[paolo.carlini at oracle dot com]

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.

[manu at gcc dot gnu.org]

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.

[paolo.carlini at oracle dot com]

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.100000000000000088817841970012523233890533447265625e+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.

[paolo.carlini at oracle dot com]

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.

[paolo at gcc dot gnu.org]

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=gcc&view=rev&rev=179797
Log:
2011-10-11  Paolo Carlini  <paolo.carlini@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.

[paolo.carlini at oracle dot com]

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.1000000000000001e+0 < t’

or, for example,

33067.C:2:19: error: no match for ‘operator<’ in ‘1.10000002e+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] New: Awkward long decimal expansion for double literal in error.

[gcc-bugzilla at contacts dot eelis dot net]

Consider:

  struct T {} t;
  bool b = 1.1 < t;

The code is invalid, but GCC's error message is peculiar:

  "error: no match for 'operator<' in
'1.100000000000000088817841970012523233890533447265625e+0 < t'"

The long decimal expansion makes for a messy error that suggests the user typed
something he did not.

It should just say:

  "error: no match for 'operator<' in '1.1 < t'"


-- 
           Summary: Awkward long decimal expansion for double literal in
                    error.
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gcc-bugzilla at contacts dot eelis dot net
  GCC host triplet: x86_64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067

[Bug c++/33067] Awkward long decimal expansion for double literal in error.

[pinskia at gcc dot gnu dot org]

------- 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.

[gcc-bugzilla at contacts dot eelis dot net]

------- 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.100000000000000088817841970012523233890533447265625e+0.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067

[Bug c++/33067] Awkward long decimal expansion for double literal in error.

[bangerth at dealii dot org]

------- 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|0000-00-00 00:00:00         |2007-09-08 23:27:54
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067