http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #40 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org
2012-04-16 15:32:28 UTC ---
Author: paolo
Date: Mon Apr 16 15:32:22 2012
New Revision: 186499
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186499
Log:
/cp
2012-04-16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #42 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-16
15:47:37 UTC ---
Awesome, thank you very very much, Paolo and Manu.
The example in comment 23 can now be added to
http://gcc.gnu.org/wiki/ClangDiagnosticsComparison ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Depends on||24985
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #31 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02
08:16:52 UTC ---
(In reply to comment #30)
(In reply to comment #26)
The caret is not a solution to this problem, because what Gabriel wants is
to
not reconstruct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #32 from Jason Merrill jason at gcc dot gnu.org 2012-04-02
15:57:16 UTC ---
(In reply to comment #31)
Well, that is reassuring. Then, will we still pretty-print expressions in
diagnostics once we have the caret?
No, there should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #33 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02
17:15:47 UTC ---
(In reply to comment #32)
(In reply to comment #31)
Well, that is reassuring. Then, will we still pretty-print expressions in
diagnostics once we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #34 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02
17:18:34 UTC ---
(In reply to comment #32)
Of course this may fail in some cases, like non-ANSI input, and not
preprocessing, but it will work in 99% of the cases. In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #35 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-02
17:19:15 UTC ---
(In reply to comment #34)
(In reply to comment #32)
Of course this may fail in some cases, like non-ANSI input, and not
preprocessing, but it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #36 from pinskia at gmail dot com pinskia at gmail dot com
2012-04-02 17:35:59 UTC ---
I know some of us use tee and that disables termainal detection code usually.
Or output to a file and then use tail -f. So please don't do that. It
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #37 from Jason Merrill jason at gcc dot gnu.org 2012-04-02
22:05:13 UTC ---
(In reply to comment #36)
I know some of us use tee and that disables termainal detection code usually.
Right, so then you don't get the caret by default.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #38 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-03
03:41:00 UTC ---
(In reply to comment #37)
Actually, it's not clear to me that the caret line would be likely to cause
trouble for IDEs in any case; they already have to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #26 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-01
11:24:14 UTC ---
(In reply to comment #24)
Personally, I don't believe Gaby is open to other solutions outside the
full-fledged caret diagnostics context, thus for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #27 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01
12:55:34 UTC ---
(In reply to comment #26)
because if you want nice diagnostics, why don't just use
Clang?
Because G++ gives much better diagnostics for template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #28 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-01
13:23:01 UTC ---
(In reply to comment #27)
(In reply to comment #26)
because if you want nice diagnostics, why don't just use
Clang?
Because G++ gives much better
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #30 from Jason Merrill jason at gcc dot gnu.org 2012-04-02
05:16:05 UTC ---
(In reply to comment #26)
The caret is not a solution to this problem, because what Gabriel wants is to
not reconstruct expressions ONLY when the caret is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-31
00:25:50 UTC ---
Is there a final verdict on this? Jonathan, Paolo, did you change your mind?
Or do you still think this should be fixed but you don't believe there is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #23 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-31
00:34:58 UTC ---
BTW, I think this example was mentioned some where already, but I cannot find
it now. From http://clang.llvm.org/diagnostics.html
manuel@gcc12:~$ cat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #24 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-31
02:03:02 UTC ---
Personally, I don't believe Gaby is open to other solutions outside the
full-fledged caret diagnostics context, thus for the time being at least I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #25 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-31
02:15:19 UTC ---
And, hey, I'm of course speaking only for myself, you are welcome to pursue a
compromise solution. For example, I don't know, if we could identify a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #20 from Ralph Loader suckfish at ihug dot co.nz 2012-03-23
07:54:51 UTC ---
Re comment 12 - as someone who regularly needs to understand gcc diagnostics, I
disagree completely.
Understanding a failure to look something up, the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|NEW
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-22
11:02:29 UTC ---
Please don't close this as a dup of the caret diagnostics PR.
I agree there's no consensus on what should be done, but printing of
reconstructed expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-22
11:17:36 UTC ---
Also, comment 2 shows another clear bug in the current diagnostics. It doesn't
matter whether you prefer carets or types or reconstructed expressions,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #15 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-22
11:37:17 UTC ---
(In reply to comment #13)
Please don't close this as a dup of the caret diagnostics PR.
I agree there's no consensus on what should be done, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-22
12:01:58 UTC ---
Right, we have the column numbers to indicate the position in the source
(not perfect, but enough to show which sub-expression the error refers to)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #17 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-22
12:59:30 UTC ---
(In reply to comment #16)
Right, we have the column numbers to indicate the position in the source
(not perfect, but enough to show which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #18 from Ralph Loader suckfish at ihug dot co.nz 2012-03-22
14:21:33 UTC ---
Flaws from the pretty-printing not listed in this bug (from 25362):
It takes the address of integer constants.
The pretty printing confuses '.' and '-'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-22
14:27:11 UTC ---
(In reply to comment #18)
But that is not correct: '' might be overloaded for the type in question...]
If the diagnostics were improved for all types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||suckfish at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #8 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-09-27 22:23:34 UTC ---
I agree that this would be an improvement, even without clang's selective
typedef unwrapping. But I have some doubts such a patch will be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Christopher Yeleighton giecrilj at stegny dot 2a.pl changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #2 from Christopher Yeleighton giecrilj at stegny dot 2a.pl
2011-09-21 20:06:42 UTC ---
== Code ==
struct X { int x; };
void trigger (X x []) { x [01] = 0; }
== Result (v4.6) ==
doit.cpp:2:34: error: no match for ‘operator=’ in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-21
20:16:24 UTC ---
Wow, that one is worthy of its own bug report, it's not just an unclear
diagnostic, it's completely bogus.
x[01] is *(x+1) or *((char*)x + 4) but what G++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-21
21:03:37 UTC ---
The common thing in my original example and comment 2 is that when printing no
match for a binary operator, the diagnostic machinery tries to reconstruct
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-21
23:30:34 UTC ---
Thanks, Manu. Most of the PRs mentioned on that page are FIXED, and I don't
see specific mention of outputting the types involved in the operation, just
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-09-21
23:56:25 UTC ---
(In reply to comment #6)
Thanks, Manu. Most of the PRs mentioned on that page are FIXED, and I don't
PR 35441 is still broken. In any case, most of the
42 matches
Mail list logo
