https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=115970
Ever confirmed|0 |1
Last reconfirmed| |2024-08-27
Status|UNCONFIRMED |NEW
--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this bug; you make some very useful points.
I had thought that the .sarif filename was respecting the dumpfile options
(e.g. -dumpdir, see
https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpdir ) but it
turns out that it doesn't even handle that.
Bother.
I like the idea of using the output file name/path as the basis on which to
build the .sarif filename (e.g. outputdir/foo.o.sarif), but there may be
projects that are using the existing behavior, so we'd probably need some way
to ease transition.
Some other possibly-awkward cases: what about e.g. -S, or gcc invocations that
take multiple source files, and/or those that imply a.out as the output?
It may make sense to support both text *and* sarif output of diagnostics, to
avoid the "nothing on stderr" problem.
See also bug 115970 for another approach to capturing sarif from a build.
