Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
(see handle_pragma_diagnostic_early) for the C++ frontend and, as such,
require that the target diagnostic option be enabled for the preprocessor
(see c_option_is_from_cpp_diagnostics). This change modifies the
-Wc++20-compat
This change addresses the following issue raised on the libc-alpha mailing list:
https://sourceware.org/pipermail/libc-alpha/2022-July/140825.html
Glibc 2.36 adds a char8_t typedef in C++ modes that do not enable the char8_t
builtin type (C++17 and earlier by default; subject to _GNU_SOURCE and u
On Sat, 2022-07-23 at 22:08 +0530, Immad Mir wrote:
> This patch adds get_meaning_for_state_change vfunc to
> fd_diagnostic in sm-fd.cc which could be used by SARIF output.
>
> Lightly tested in x86_64 Linux.
>
> gcc/analyzer/ChangeLog:
> PR analyzer/106286
> * sm-fd.cc:
>
This patch adds get_meaning_for_state_change vfunc to
fd_diagnostic in sm-fd.cc which could be used by SARIF output.
Lightly tested in x86_64 Linux.
gcc/analyzer/ChangeLog:
PR analyzer/106286
* sm-fd.cc:
(fd_diagnostic::get_meaning_for_state_change): New.
Signed-off-by: I
This patch is a one line correction/clarification to GCC's current
RTL documentation that explains a USE of a MEM is permissible.
PR rtl-optimization/99930 is an interesting example on x86_64 where
the backend generates better code when a USE is a (const) MEM than
when it is a REG. In fact the ba
Hi Uros,
This is the next iteration of the zero_extendditi2 patch last reviewed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596204.html
[1] The sse.md changes were split out, reviewed, approved and committed.
[2] The *concat splitters have been moved post-reload matching wha
The macro definition for LIBGCCJIT_HAVE_gcc-jit_context_new_bitcast
was earlier located in the documentation comment for
gcc_jit_context_new_bitcast, making it unavailable to code that
consumed libgccjit.h. This patch moves the definition out of the
comment, making it effective.
Thanks,
Vibhav
--
This patch resolves PR target/106303 (and the related PRs 106347,
106404, 106407) which are ICEs caused by my improvements to x86_64's
128-bit TImode to V1TImode Scalar to Vector (STV) pass. My apologies
for the breakage. The issue is that data flow analysis is used to
partition usage of each TI
