Patchwork [C++,/,RFC] PR 33067

login
register
mail settings
Submitter Paolo Carlini
Date Oct. 10, 2011, 12:47 p.m.
Message ID <4E92E968.4020107@oracle.com>
Download mbox | patch
Permalink /patch/118731/
State New
Headers show

Comments

Paolo Carlini - Oct. 10, 2011, 12:47 p.m.
On 10/10/2011 02:13 PM, Paolo Carlini wrote:
> . looks like we want to do something else, not printing the number at 
> all. See audit trail.
An option, for 4.7 at least, would be, instead of just closing 33067 as 
a duplicate of the much more general 49152, doing something like:


which gives:

33067.C:2:18: error: no match for ‘operator<’ in ‘1.1e+0 < t’

Given in particular that we now have column numbers, as a user of GCC I 
would certainly consider it a good improvement.

Just let me know...

Paolo.
Gabriel Dos Reis - Oct. 10, 2011, 5:13 p.m.
On Mon, Oct 10, 2011 at 7:47 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/10/2011 02:13 PM, Paolo Carlini wrote:
>>
>> . looks like we want to do something else, not printing the number at all.
>> See audit trail.
>
> An option, for 4.7 at least, would be, instead of just closing 33067 as a
> duplicate of the much more general 49152, doing something like:
>
> Index: c-family/c-pretty-print.c
> ===================================================================
> --- c-family/c-pretty-print.c   (revision 179745)
> +++ c-family/c-pretty-print.c   (working copy)
> @@ -1019,7 +1019,7 @@ static void
>  pp_c_floating_constant (c_pretty_printer *pp, tree r)
>  {
>   real_to_decimal (pp_buffer (pp)->digit_buffer, &TREE_REAL_CST (r),
> -                  sizeof (pp_buffer (pp)->digit_buffer), 0, 1);
> +                  sizeof (pp_buffer (pp)->digit_buffer), 6, 1);
>   pp_string (pp, pp_buffer(pp)->digit_buffer);
>   if (TREE_TYPE (r) == float_type_node)
>     pp_character (pp, 'f');
>
> which gives:
>
> 33067.C:2:18: error: no match for ‘operator<’ in ‘1.1e+0 < t’
>
> Given in particular that we now have column numbers, as a user of GCC I
> would certainly consider it a good improvement.
>
> Just let me know...

on this particular input, '6' looks OK.  However, the
question is why '6'?
Why can't we retain the original number spelling from the
source code and use that instead?
Paolo Carlini - Oct. 10, 2011, 5:16 p.m.
On 10/10/2011 07:13 PM, Gabriel Dos Reis wrote:
> on this particular input, '6' looks OK. However, the question is why 
> '6'? Why can't we retain the original number spelling from the source 
> code and use that instead? 
Yes, that would be 49152, no? It's quite a bit of work, I don't think 
somebody will be able to do that in time for 4.7.0, right? I I were a 
user of gcc, I would not be suprised to see 6 used, which after all it's 
the historical printf default, I would find it much better anyway than 
the current behavior. But I don't have a strong opinion, I already 
unassigned myself from the PR, fwiw.

Paolo.
Gabriel Dos Reis - Oct. 10, 2011, 5:28 p.m.
On Mon, Oct 10, 2011 at 12:16 PM, Paolo Carlini
<paolo.carlini@oracle.com> wrote:
> On 10/10/2011 07:13 PM, Gabriel Dos Reis wrote:
>>
>> on this particular input, '6' looks OK. However, the question is why '6'?
>> Why can't we retain the original number spelling from the source code and
>> use that instead?
>
> Yes, that would be 49152, no? It's quite a bit of work, I don't think
> somebody will be able to do that in time for 4.7.0, right? I I were a user
> of gcc, I would not be suprised to see 6 used, which after all it's the
> historical printf default, I would find it much better anyway than the
> current behavior. But I don't have a strong opinion, I already unassigned
> myself from the PR, fwiw.

I bet most C++ programers don't know what printf default is :-)

In any case that is a compiler implementation detail that has no bearing
with the input program.

A GCC user not interested in numerics probably won't care.
However, I do not think that extends to people who do care about numerics
and have literals in their program.  If GCC displays an error message
with literals truncated, it is not at clear to the user that GCC is
behaving correctly:
for one thing, the error might be mysterious and hard to understand,
now the compiler
is indicating that apparently it does not even parse and understand
correctly his or
her numbers.  How if you have several numbers like that that differs
only on the 10th
digit?  If the user is using an IDE that pattern match the output on
the source code, it
would be even more confusing (as it is now.)


>
> Paolo.
>
Paolo Carlini - Oct. 10, 2011, 5:30 p.m.
On 10/10/2011 07:28 PM, Gabriel Dos Reis wrote:
> A GCC user not interested in numerics probably won't care. However, I 
> do not think that extends to people who do care about numerics and 
> have literals in their program. If GCC displays an error message with 
> literals truncated, it is not at clear to the user that GCC is 
> behaving correctly: for one thing, the error might be mysterious and 
> hard to understand, now the compiler is indicating that apparently it 
> does not even parse and understand correctly his or her numbers. How 
> if you have several numbers like that that differs only on the 10th 
> digit? If the user is using an IDE that pattern match the output on 
> the source code, it would be even more confusing (as it is now.) 
Would you like to see the max_digits10 - inspired patch for 4.7.0? 
Again, no strong opinion, just let me know. Personally, I find that too 
quite a bit better than the current behavior.

Paolo.
Gabriel Dos Reis - Oct. 10, 2011, 5:59 p.m.
On Mon, Oct 10, 2011 at 12:30 PM, Paolo Carlini
<paolo.carlini@oracle.com> wrote:
> On 10/10/2011 07:28 PM, Gabriel Dos Reis wrote:
>>
>> A GCC user not interested in numerics probably won't care. However, I do
>> not think that extends to people who do care about numerics and have
>> literals in their program. If GCC displays an error message with literals
>> truncated, it is not at clear to the user that GCC is behaving correctly:
>> for one thing, the error might be mysterious and hard to understand, now the
>> compiler is indicating that apparently it does not even parse and understand
>> correctly his or her numbers. How if you have several numbers like that that
>> differs only on the 10th digit? If the user is using an IDE that pattern
>> match the output on the source code, it would be even more confusing (as it
>> is now.)
>
> Would you like to see the max_digits10 - inspired patch for 4.7.0? Again, no
> strong opinion, just let me know. Personally, I find that too quite a bit
> better than the current behavior.

Yes, I suspect the max_digits10 patch would be definitely an improvement.

Of course, the actual fix would be to write back what was in the
input source program, but I understand that is more work that you would
like to tackle or have time for.
Paolo Carlini - Oct. 10, 2011, 6:07 p.m.
On 10/10/2011 07:59 PM, Gabriel Dos Reis wrote:
> Yes, I suspect the max_digits10 patch would be definitely an improvement.
Good. It's at the beginning of this thread, passes testing. Please have 
a closer look.

If you like it, we can have it for 4.7.0 and otherwise also mark this 
specific PR as duplicate of 49152 (which, actually, for this *specific* 
case leans toward not printing any constant at all, similarly to the 
status quo of the C front end)

Paolo.
Gabriel Dos Reis - Oct. 10, 2011, 6:15 p.m.
On Mon, Oct 10, 2011 at 1:07 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> On 10/10/2011 07:59 PM, Gabriel Dos Reis wrote:
>>
>> Yes, I suspect the max_digits10 patch would be definitely an improvement.
>
> Good. It's at the beginning of this thread, passes testing. Please have a
> closer look.

I did, but you seemed to show a preference for '6' digits which
prompted my comments.

OK for 4.6

>
> If you like it, we can have it for 4.7.0 and otherwise also mark this
> specific PR as duplicate of 49152 (which, actually, for this *specific* case
> leans toward not printing any constant at all, similarly to the status quo
> of the C front end)

I suspect printing the literal is better.  I believe the actual fix is to
print the lexeme as it appears in the source code.
Paolo Carlini - Oct. 10, 2011, 6:20 p.m.
Hi,
>> On 10/10/2011 07:59 PM, Gabriel Dos Reis wrote:
>>> Yes, I suspect the max_digits10 patch would be definitely an improvement.
>> Good. It's at the beginning of this thread, passes testing. Please have a
>> closer look.
> I did, but you seemed to show a preference for '6' digits which
> prompted my comments.
>
> OK for 4.6
Did I understand correctly, only 4.6, not 4.7? Works for me but seems a 
little unusual not applying anything to mainline.
>> If you like it, we can have it for 4.7.0 and otherwise also mark this
>> specific PR as duplicate of 49152 (which, actually, for this *specific* case
>> leans toward not printing any constant at all, similarly to the status quo
>> of the C front end)
> I suspect printing the literal is better.  I believe the actual fix is to print the lexeme as it appears in the source code.
I would suggest adding something to the audit trail of 49152. I 
understand that otherwise for this specific type of error message people 
will lean toward not printing the constants. In general, I (we) hear 
you, of course, it's a lond standing issue, isn't it?

Paolo.

Patch

Index: c-family/c-pretty-print.c
===================================================================
--- c-family/c-pretty-print.c   (revision 179745)
+++ c-family/c-pretty-print.c   (working copy)
@@ -1019,7 +1019,7 @@  static void
  pp_c_floating_constant (c_pretty_printer *pp, tree r)
  {
    real_to_decimal (pp_buffer (pp)->digit_buffer, &TREE_REAL_CST (r),
-                  sizeof (pp_buffer (pp)->digit_buffer), 0, 1);
+                  sizeof (pp_buffer (pp)->digit_buffer), 6, 1);
    pp_string (pp, pp_buffer(pp)->digit_buffer);
    if (TREE_TYPE (r) == float_type_node)
      pp_character (pp, 'f');