https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #26 from David Malcolm <dmalcolm at gcc dot gnu.org> --- (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...] > > > > > > Does the above support all your use-cases? > > > > OSH does not care too much about the names of SARIF files because all the > > important data are contained in the files inside. The ideal SARIF-based > > workflow for OSH would be: > > 1. create an empty directory for scan results > > 2. run the (instrumented) build a of C/C++ project > > 3. each invocation of gcc (that produces warnings) during the build creates > > a unique file with SARIF data in the pre-created directory with scan results > > 4. all the files created in the pre-created directory with scan results can > > be processed after the build > > > > Step 3. can be partially implemented in the compiler wrapper with > > flock/mktemp, which can invoke gcc with an absolute path of an already > > created empty file to write the SARIF data to. If we take this approach, > > OSH will not need any such substitutions in gcc. If a substitution was > > provided by gcc to construct a unique file name (such as %p and %n in > > valgrind), OSH would not need to implement this part in the compiler > > wrapper. > > Given that it seems like you can create a tempfile name for the sarif and > pass that to gcc easily from a script, I decided it would be simpler not to > implement any of the "substitution" ideas in GCC, but to let you specify the > .sarif filename, potentially with an absolute or relative path. > > 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 (currently they break > some targets, plus the Fortran, and Modula 2 frontends). I still hope to > get them ready for GCC 15 feature freeze. > > If you want to try them out, I've created a Copr build of gcc trunk with the > patches: > https://copr.fedorainfracloud.org/coprs/dmalcolm/gcc-latest/ > where the build > gcc-latest-15.0.0-4.20241006git4782662796ac.pr116613.v0.128.fc42.src.rpm > has the new feature. I've briefly tested them on my laptop, and: FWIW the packaging sources for that build are now here: https://github.com/davidmalcolm/pkg-gcc-latest/tree/pr116613 I'm locally testing an updated version of the patch, which also adds -fdiagnostics-set-output=, as described in comment #20. If that testing succeeds, then I'll update the copr build.