> On Oct 30, 2024, at 10:48, David Malcolm <dmalc...@redhat.com> wrote:
>
> On Wed, 2024-10-30 at 14:34 +0000, Sam James wrote:
>> Qing Zhao <qing.z...@oracle.com> writes:
>>
>>> Control this with a new option -fdiagnostics-details.
>>>
>>> [...]
>>
>> The patch doesn't apply for me on very latest trunk -- I think
>> David's
>> recent diag refactoring means it needs a slight rebase. Could you
>> send
>> that?
>
> If it's broken, it was probably by:
>
> r15-4610 ("Use unique_ptr in more places in pretty_printer/diagnostics
> [PR116613]")
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=bf43fe6aa966eaf397ea3b8ebd6408d3d124e285
Yes, due to the following change in the above commit:
diff --git a/gcc/toplev.cc b/gcc/toplev.cc
index
62034c32b4aff32cdf2cb051bf9d0803b4730b3f..a12a2e1afba15ba16f6ade624cde3e60907ba5d2
100644 (file)
--- a/gcc/toplev.cc
+++ b/gcc/toplev.cc
@@ -42,6 +42,7 @@ along with GCC; see the file COPYING3. If not see
#include "cgraph.h"
#include "coverage.h"
#include "diagnostic.h"
+#include "pretty-print-urlifier.h"
#include "varasm.h"
#include "tree-inline.h"
#include "realmpfr.h" /* For GMP/MPFR/MPC versions, in print_version. */
>
> and/or
>
> r15-4617 ("analyzer: avoid implicit use of global_dc's pretty_printer
> [PR116613]")
> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666390.html
>
> which both made small changes to the internal interface for creating
> events in a diagnostic path, and possibly by:
>
> r15-4760 ("diagnostics: support multiple output formats simultaneously
> [PR116613]")
> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666807.html
>
> which made big changes to diagnostic_context internally.
Just rebased the patch against the latest trunk today.
Redo the bootstrap and regression test now.
>
> Sorry about this; let me know if you want help debugging/fixing things.
I have a question on the changes to the “warning_at”: (there are a lot of such
changes for -Warray-bounds and -Wstringop-**)
- warned = warning_at (location, OPT_Warray_bounds_,
+ {
+ rich_location *richloc
+ = build_rich_location_with_diagnostic_path (location, stmt);
+ warned = warning_at (richloc, OPT_Warray_bounds_,
The above is the current change.
My concern with this change is:
even when -fdiagnostics_details is NOT on, the rich_location is created.
How much is the additional overhead when using “rich_location *” other than
“location_t” as the 1st argument of warning_at?
Should I control the creation of “rich_location" with the flag
“flag_diagnostics_details” (Similar as I control the creation of “move_history”
data structure with the flag “flag_diagnostics_details”?
If so, how should I do it? Do you have a suggestion on a clean and simply
coding here (Sorry for the stupid question on this)
Thanks a lot for the help.
Qing
> Dave
>
