| Message ID | 4E92E968.4020107@oracle.com |
|---|---|
| State | New |
| Headers | show |
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?
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.
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. >
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.
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.
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.
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.
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.
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');