https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687
--- Comment #4 from David Malcolm ---
In particular, consider e.g. the cases of SARIF and json output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687
--- Comment #5 from David Malcolm ---
Created attachment 58523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58523&action=edit
WIP patch to try to print all notes for an error with -Wfatal-errors
Am attaching an experimental patch for thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687
David Malcolm changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97687
--- Comment #7 from David Malcolm ---
(In reply to David Malcolm from comment #5)
> scope of the auto_diagnostic_context.
^^^
auto_diagnostic_group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115680
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115724
--- Comment #4 from David Malcolm ---
The analyzer *does* try to handle error() and error_at_line() from GNU's
non-standard ; see:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/analyzer/kf.cc;h=4213b89ac9fb4ff11994cf2c35f15a281be3b024;hb=HEAD#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115724
--- Comment #5 from David Malcolm ---
glib'c bits/error.h has:
/* If we know the function will never return make sure the compiler
realizes that, too. */
__extern_always_inline void
error (int __status, int __errnum, const char *__format, .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115724
--- Comment #6 from David Malcolm ---
Posted to mailing lists:
https://gcc.gnu.org/pipermail/gcc/2024-July/244257.html
https://sourceware.org/pipermail/libc-alpha/2024-July/157942.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115724
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115735
--- Comment #3 from David Malcolm ---
The analyzer's list of functions known to be signal unsafe was introduced in
r10-5959-g4804c5fe965eef and has only gained "exit" since then, in
r11-577-g2221fb6f668a7e.
Is there a wider list of such functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115736
--- Comment #2 from David Malcolm ---
Indeed.
Is "puts" safe or unsafe to call from a signal handler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115735
--- Comment #8 from David Malcolm ---
Not only are we not treating "syslog" as unsafe, we're also failing to handle
sigaction as a way of setting a signal handler. I'm taking a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115735
--- Comment #9 from David Malcolm ---
(In reply to Sam James from comment #4)
> Hi David, I started hacking up a list based on the man pages I had from
> `man-pages` & removing the POSIX list of safe functions, but it's kind of
> gross. It's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115735
--- Comment #11 from David Malcolm ---
FWIW I just noticed that your reproducer is wrong (I think) whilst trying to
implement sigaction: if you're going to use sa_sigaction for the function
pointer (rather than sa_handler), you have to set the S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115724
--- Comment #9 from David Malcolm ---
Fixed by the above patch for trunk for gcc 15.
Handling of "error" was added in r11-7333-g5ee4ba031dd9fc to fix PR
analyzer/99196 so keeping this open to track backporting to earlier branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115784
--- Comment #1 from David Malcolm ---
Thanks for filing this bug report.
The analyzer reports -Wanalyzer-infinite-loop on the example code you posted;
trunk on Compiler Explorer: https://godbolt.org/z/WzPEc3hxh
But it is indeed an infinite loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115784
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84889
--- Comment #25 from David Malcolm ---
(In reply to David Malcolm from comment #0)
[...snip...]
> We might want to revisit our current colorization choices.
Done, in https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657201.html
Screenshots
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3358r0.html#msvc
describes a feature of Visual Studio 2022 version 17.8. which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115970
--- Comment #2 from David Malcolm ---
One difference here is that VS code is sending the diagnostics one at a time as
JSON-RPC messages containing SARIF "result" objects as they occur, whereas
currently we write all our SARIF output at once on e
: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider e.g.:
struct A *extref = something;
...
for (int i = 0; i < n; i++)
{
struct A intref = *ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107941
David Malcolm changed:
What|Removed |Added
Keywords||SARIF
--- Comment #5 from David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79423
--- Comment #7 from David Malcolm ---
We've had -fdiagnostics-format=json since GCC 9, and
-fdiagnostics-format=sarif-{file,stderr} support since GCC 13, IIRC. Arguably
an IDE should be using the latter instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107941
David Malcolm changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117109
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #22 from David Malcolm ---
(In reply to David Malcolm from comment #18)
[...snip...]
>
> I have work-in-progress patches that implement this as a new
> -fdiagnostics-add-output=
> option, but they're not yet ready to push upstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117152
--- Comment #4 from David Malcolm ---
It's happening here:
(gdb) bt
#0 0x00f95395 in dump_function_name (pp=0x4d00c40
, t=, flags=148)
at ../../src/gcc/cp/error.cc:2139
#1 0x00f94109 in dump_function_decl (pp=0x4d00c40
, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #23 from David Malcolm ---
(In reply to David Malcolm from comment #21)
[...snip...]
>
> FWIW SARIF has a distinction between a "result" and a "notification" where
> the former refer to the software under test, and the latter to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
David Malcolm changed:
What|Removed |Added
Summary|[15 regression] Segfault in |[15 regression] Segfault in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #18 from David Malcolm ---
(In reply to Kamil Dudka from comment #16)
> (In reply to David Malcolm from comment #15)
> > (In reply to Kamil Dudka from comment #14)
[...snip...]
>
> > Does the above support all your use-cases?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116977
--- Comment #3 from David Malcolm ---
(In reply to Thomas Schwinge from comment #1)
> David, re (a) and (c), do we teach directly the Analyzer about specific
> functions (like 'acc_malloc', 'acc_free' if '-fopenacc' is enabled), or do
> we add G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116977
--- Comment #2 from David Malcolm ---
Thanks for looking at this, and for filing the bug.
There are two ways of tracking state in the analyzer:
(a) using state machines, like in sm-malloc.cc, which let program_state
instances track per-svalue
: SARIF
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Running cc1/cc1plus/etc directly like this ICEs:
$ ./cc1 -fdiagnostics-format=sarif-file
cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116970
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116978
David Malcolm changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116978
--- Comment #4 from David Malcolm ---
Note that if you're invoking cc1 or another compiler directly, rather than via
the "gcc" or "xgcc" driver, add
-dumpbase foo
or similar before -fdiagnostics-format=sarif-file, so that it will write to
foo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116602
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116978
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #4 from David Malcolm ---
(In reply to Jakub Jelinek from comment #2)
> Sure, it is trunk only, introduced in r15-4375.
> Would be nice if it could be handled similarly to apply_ctor_val_to_range by
> creating just a single record fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
--- Comment #3 from David Malcolm ---
I see:
(gdb) pt ctor
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea664348 precision:8 min max
pointer_to_this >
BLK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117262
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #20 from David Malcolm ---
Created attachment 59344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59344&action=edit
Generated HTML documentation
(In reply to Kamil Dudka from comment #19)
> Thank you for working on this! I r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #21 from David Malcolm ---
(In reply to David Malcolm from comment #20)
> (In reply to Kamil Dudka from comment #19)
[...snip...]
> > Is there a better way to tell gcc to write all diagnostic messages only to
> > the specified SARIF
||2024-10-14
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
--- Comment #1 from David Malcolm ---
Sorry about this; working on a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #31 from David Malcolm ---
(In reply to Kamil Dudka from comment #27)
> Sounds good, looking forward to try out a new COPR build!
I've update the COPR to use the latest version of my patches:
https://copr.fedorainfracloud.org/copr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||2024-11-05
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from David Malcolm ---
Seems to happen at exit if there's a buffered diagnostic in error_buffer, due
to its g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117442
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117361
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117373
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
Bug 116613 depends on bug 105916, which changed state.
Bug 105916 Summary: gfortran -fdiagnostics-format=json/sarif* output contains
buffered errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105916
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105916
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Seen on cfarm120:
Within the jit testsuite, test-functions.c and test-tls.c are both failing this
assertion on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275
--- Comment #1 from David Malcolm ---
The particular assertion was added in r14-5930-gf31a019d1161ec aka
f31a019d1161ec78846473da743aedf49cca8c27, so the test failures presumably
affect gcc 14 and trunk. There may be other dormant issues on old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275
--- Comment #4 from David Malcolm ---
Looks like this might have introduced some noise into "make selftest-valgrind":
==2462086== 160 (56 direct, 104 indirect) bytes in 1 blocks are definitely lost
in loss record 248 of 352
==2462086==at 0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275
--- Comment #3 from David Malcolm ---
Should be fixed on trunk for gcc 15 by the above patch.
Keeping open to track backporting to the active release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #26 from David Malcolm ---
(In reply to David Malcolm from comment #18)
> (In reply to Kamil Dudka from comment #16)
> > (In reply to David Malcolm from comment #15)
> > > (In reply to Kamil Dudka from comment #14)
>
> [...snip...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117503
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117503
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117361
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253
David Malcolm changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253
--- Comment #4 from David Malcolm ---
Created attachment 59580
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59580&action=edit
Screenshot of textual output, showing colorization
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
I made this typo in C++:
class layout_printer
{
void print_newline ();
};
void
layout_pirnter::print_newline ()
{
}
and noticed that we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #15 from David Malcolm ---
Ouch, sorry about this. The -3 patch looks reasonable to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #4 from David Malcolm ---
(In reply to Jonathan Wakely from comment #3)
> If we add [[nodiscard]] to the constructors of the standard exception types
> then we get a warning with no compiler changes needed:
...in Compiler Explorer a
n: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
See
https://gitlab.com/antto/pimp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #2 from David Malcolm ---
A simple example:
#include
int divide(int num, int denom) {
if (denom == 0)
std::invalid_argument ("division by zero"); // forgot "throw"
return num / denom;
}
which compiles with -Wall wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116866
--- Comment #5 from David Malcolm ---
(In reply to Jonathan Wakely from comment #3)
> If we add [[nodiscard]] to the constructors of the standard exception types
> then we get a warning with no compiler changes needed:
Is it possible to do this
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Currently we can emit diagnostics as:
* text to stderr
* SARIF to stderr or to a file
* "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #13 from David Malcolm ---
I'm experimenting with a new
-fdiagnostics-add-output=
with this rough grammar:
:
":" key_value_pairs
: "text"
: "sarif"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #15 from David Malcolm ---
(In reply to Kamil Dudka from comment #14)
> I think that the above described interface looks reasonable. A few
> questions:
Thanks for the feedback.
> 1. Will `file=` work with absolute paths?
Yes. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116301
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2024-10-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116301
--- Comment #3 from David Malcolm ---
Also, perhaps sarif-output.exp could have a loop to run all tests
per-sarif-version, rather than just for 2.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #33 from David Malcolm ---
(In reply to Kamil Dudka from comment #32)
> Thanks for the update! I confirm that the man page is readable now and that
> the use of -fdiagnostics-set-output= eliminated the duplicated output
> without th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63388
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117629
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
||dmalcolm at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #2 from David Malcolm ---
Looks like this was fixed by Jakub with r14-10091-g4338ac149e270e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117629
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90160
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90160
--- Comment #6 from David Malcolm ---
(In reply to Roland Illig from comment #2)
> From gcn.c:
>
> error ("unknown specifier %s in amdgpu_hsa_kernel attribute", str);
(In reply to Roland Illig from comment #3)
> From gcn.c, one more:
>
> e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80760
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
||2024-11-27
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from David Malcolm ---
Created attachment 59732
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59732&
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
It seems useful to have a way to set an environment variable that makes gcc
capture SARIF for all invocations.
e.g. if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552
Bug 104552 depends on bug 104896, which changed state.
Bug 104896 Summary: Messages use %<%s%> instead of the idiomatic %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104896
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117815
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #1)
> Created attachment 59732 [details]
> Candidate patch
>
> Patch seems to work, but not yet bootstrapped, and doesn't have automated
> test coverage.
Successfull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104896
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87850
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82892
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253
--- Comment #7 from David Malcolm ---
Created attachment 59611
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59611&action=edit
Screenshot of textual output with followup patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253
--- Comment #6 from David Malcolm ---
Followup patches:
* [PATCH 1/2] c++: print z candidate count and number them
* https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669035.html
* [PATCH 2/2] diagnostics: suppress "note: " prefix in ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96032
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96032
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96032
--- Comment #10 from David Malcolm ---
(In reply to Kamil Dudka from comment #8)
> Where can one get the sarif-replay tool? It does not seem to be included in
> gcc-latest.
Sorry, I haven't updated the copr build; I'll look at doing that today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117677
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117662
--- Comment #4 from David Malcolm ---
Note that LTO with -fanalyzer isn't in good shape yet, sorry. It works on toy
examples, and I have some basic test coverage in the testsuite, but there are
likely to be algorithmic explosions when trying it
||dmalcolm at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2024-11-26
Summary|Custom diagnostics for |Custom diagnostics for
|unsatisified standard |unsatisfied standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84918
--- Comment #8 from David Malcolm ---
(In reply to David Malcolm from comment #0)
[...]
>
> Checking on godbolt.org:
>
> #include
> void test ()
> {
> std::cout >> 42;
> }
>
> we currently spew dozens of lines of diagnostics.
For referen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106285
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106256
--- Comment #2 from David Malcolm ---
For reference, trunk with -std=c++20:
https://godbolt.org/z/3q6b9dc6a
(output as per comment #0).
With my patches for PR other/116253, and with
-fdiagnostics-set-output=text:experimental-nesting=yes -std
3301 - 3400 of 3524 matches
Mail list logo
