On Tue, 30 Apr 2024, Martin Jambor wrote: > +<h3 id="gcc-targte-pragma">Pragma GCC Target now affects preprocessor > symbols</h4>
Note the id: should be "gcc-target-pragma", though I even suggest to simplify and say "target-pragma". > +The behavior of pragma GCC Target and specifically how it affects ISA Seconding Jakub's "And here as well, perhaps even <code>#pragma GCC target</code>." > +macros has changed in GCC 14. In GCC 13 and older, the <code>GCC > +target</code> pragma defined and undefined corresponding ISA macros in > +C when using integrated preprocessor during compilation but not when "...the integrated preprocessor..." > +preprocessor was invoked as a separate step or when using -save-temps. "...the preprocessor..." and <code>-save-temps</code>, or better "the <code>-save-temps</code> option". > +This can lead to different behavior, especially in C++. For example, > +functions the C++ snippet below will be (silently) compiled for an > +incorrect instruction set by GCC 14. "functions" above looks like it's extraneous and should be skipped? > + /* With GCC 14, __AVX2__ here will always be defined and pop_options > + never called. */ > + #if ! __AVX2__ > + #pragma GCC pop_options > + #endif Maybe a bit subtle, I would not say a #pragma is called; how about invoked or activated? > +<p> > +The fix in this case would be to remember > +whether <code>pop_options</code> needs to be performed in a new > +user-defined macro. "The fix in this case is to remember" (or "...remembering...") Gerald
