[PATCH 7/7] jit,docs: remove :ref:`modindex`

gcc/jit/ChangeLog: * docs/index.rst: Remove reference to module index as we don't emit any. --- gcc/jit/docs/index.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/jit/docs/index.rst b/gcc/jit/docs/index.rst index 21c3140e238..0f575966303 100644 ---

Re: [PATCH 6/7] jit,docs: use :expr:`type *` for pointers to a type

On 7/26/22 00:41, David Malcolm wrote: > On Mon, 2022-07-25 at 14:39 +0200, Martin Liska wrote: >> gcc/jit/ChangeLog: >> >> * docs/cp/intro/tutorial02.rst: Use :expr:`type *` for >> pointers to a type >> * docs/cp/topics/asm.rst: Likewise. >> * docs/cp/topics/contexts.rst:

Re: [PATCH 2/7] jit,docs: replace c:type:`int_type` with :expr:`int_type`

On 7/26/22 00:37, David Malcolm wrote: > On Mon, 2022-07-25 at 11:03 +0200, Martin Liska wrote: >> Use expression that work fine for basic type. > > What's the motivation for this change? Surely the things being marked > up are types, rather than expressions? Problem is that one can't reference

Re: [PATCH 1/7] jit,docs: use enum directive for enumeral types

On 7/26/22 00:35, David Malcolm wrote: > On Mon, 2022-07-25 at 10:52 +0200, Martin Liska wrote: >> gcc/jit/ChangeLog: >> >> * docs/conf.py: Add needs_sphinx = '3.0' where c:type was >> added. > > Looking at the footer of https://gcc.gnu.org/onlinedocs/jit/index.html > I see we currently

Re: [PATCH 3/3] c++/106426: Treat u8 character literals as unsigned in char8_t modes.

On 7/25/22 2:05 PM, Andrew Pinski wrote: On Mon, Jul 25, 2022 at 11:01 AM Tom Honermann via Gcc-patches wrote: This patch corrects handling of UTF-8 character literals in preprocessing directives so that they are treated as unsigned types in char8_t enabled C++ modes (C++17 with -fchar8_t or

Re: [PATCH 3/3 v2] preprocessor/106426: Treat u8 character literals as unsigned in char8_t modes.

This patch corrects handling of UTF-8 character literals in preprocessing directives so that they are treated as unsigned types in char8_t enabled C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously, UTF-8 character literals were always treated as having the same type as

[PATCH] x86: Enable __bf16 type for TARGET_SSE2 and above

Hi, The patch is enable __bf16 scalar type for target sse2 and above according to psABI(https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/35/diffs). The __bf16 type is a storage type like arm. OK for master? gcc/ChangeLog: * config/i386/i386-builtin-types.def (BFLOAT16): New

Re: [v2 PATCH] c++: ICE with erroneous template redeclaration [PR106311]

On 7/25/22 14:43, Marek Polacek wrote: On Fri, Jul 22, 2022 at 05:21:58PM -0400, Jason Merrill wrote: On 7/15/22 11:29, Marek Polacek wrote: Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens to be error_mark_node in this ill-formed test. I kept running into this while

[pushed] c++: aggregate prvalue as for range [PR106230]

Since my PR94041 work on temporary lifetime in aggregate initialization, we end up calling build_vec_init to initialize the reference-extended temporary for the artificial __for_range variable. And build_vec_init uses finish_for_stmt to implement its loop. That function assumes that if

Re: [PATCH] libgccjit.h: Make the macro definition for testing gcc_jit_context_new_bitcast correctly available.

On Sat, 2022-07-23 at 13:31 +0530, Vibhav Pant via Jit wrote: > 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

[PING][PATCH] c: Handle initializations of opaque types [PR106016] (need review of expr.cc hunk)

I'd like to ping the following patch. Segher has approved the test case change, so I just need a review for the expr.cc change. Peter Message-ID: <009c391d-3994-8755-0d22-9e80faf91...@linux.ibm.com> Date: Fri, 17 Jun 2022 23:50:35 -0500 To: GCC Patches Subject: [PATCH] c: Handle

Re: [PATCH 6/7] jit,docs: use :expr:`type *` for pointers to a type

On Mon, 2022-07-25 at 14:39 +0200, Martin Liska wrote: > gcc/jit/ChangeLog: > > * docs/cp/intro/tutorial02.rst: Use :expr:`type *` for > pointers to a type > * docs/cp/topics/asm.rst: Likewise. > * docs/cp/topics/contexts.rst: Likewise. > *

Re: [PATCH 5/7] jit,docs: use list-table instead of fixed table

On Mon, 2022-07-25 at 12:35 +0200, Martin Liska wrote: > Use rather list-table that is easible to maintainer and one > does not have to wrap lines. Moreover, it provides great > attribute :widths: that correctly works (tested for HTML and PDF). > > gcc/jit/ChangeLog: > > *

Re: [PATCH 4/7] jit,docs: compact function declarations

On Mon, 2022-07-25 at 11:51 +0200, Martin Liska wrote: > gcc/jit/ChangeLog: > > * docs/cp/topics/expressions.rst: Compact so that the > generated > output is also more compact. OK; thanks Dave

Re: [PATCH 3/7] jit,docs: various fixes

On Mon, 2022-07-25 at 11:15 +0200, Martin Liska wrote: > gcc/jit/ChangeLog: > > * docs/cp/intro/tutorial02.rst: Use proper reference. > * docs/cp/topics/contexts.rst: Likewise. > * docs/cp/topics/functions.rst: Put `class` directive before > a > function as it is

Re: [PATCH 2/7] jit,docs: replace c:type:`int_type` with :expr:`int_type`

On Mon, 2022-07-25 at 11:03 +0200, Martin Liska wrote: > Use expression that work fine for basic type. What's the motivation for this change? Surely the things being marked up are types, rather than expressions? Dave > > gcc/jit/ChangeLog: > > * docs/cp/topics/expressions.rst: Use

Re: [PATCH 1/7] jit,docs: use enum directive for enumeral types

On Mon, 2022-07-25 at 10:52 +0200, Martin Liska wrote: > gcc/jit/ChangeLog: > > * docs/conf.py: Add needs_sphinx = '3.0' where c:type was > added. Looking at the footer of https://gcc.gnu.org/onlinedocs/jit/index.html I see we currently only have sphinx 1.7.6 installed. Have you been

Re: [PATCH] match.pd: Add new division pattern [PR104992]

On Mon, Jul 25, 2022 at 1:59 PM Sam Feifer wrote: > > >> I suspect for eq and mult you might want to add :c to them even though >> in your testcase you don't need them, you might be able to get it via >> using different statements and looking at the forwprop gimple dump. >> Also, did you send the

Re: [PATCH] match.pd: Add new division pattern [PR104992]

> I suspect for eq and mult you might want to add :c to them even though > in your testcase you don't need them, you might be able to get it via > using different statements and looking at the forwprop gimple dump. > Also, did you send the wrong patch as it looks like the function call > to

[PATCH] Fortran: error recovery from calculation of storage size of a symbol [PR103504]

Dear all, we currently may ICE when array bounds of a dummy argument have a non-integer type, and the procedure with the bad declaration is referenced. The same applies to bad character length of dummies. We could simply punt in such a situation, as the causing error seems to be reliably

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

Hi Mikael, > > https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159 > > > > I disagree with the conclusion. Quoting Steve Lionel’s post: > > What you're missing is this: > > > > TARGET (optional)

[PATCH, V2] Do not enable -mblock-ops-vector-pair.

Do not enable -mblock-ops-vector-pair. Testing has shown that using the load vector pair and store vector pair instructions for block moves has some performance issues on power10. A patch on June 11th modified the code so that GCC would not set -mblock-ops-vector-pair by default if we are tuning

Re: [PATCH] match.pd: Add new division pattern [PR104992]

On Mon, Jul 25, 2022 at 12:37 PM Sam Feifer via Gcc-patches wrote: > > This patch fixes a missed optimization in match.pd. It takes the pattern, x / > y * y == x, and optimizes it to x % y == 0. This produces fewer instructions. > > There are also tests for the optimizations to be added to the

[PATCH] match.pd: Add new division pattern [PR104992]

This patch fixes a missed optimization in match.pd. It takes the pattern, x / y * y == x, and optimizes it to x % y == 0. This produces fewer instructions. There are also tests for the optimizations to be added to the test suite. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

Re: [RFA] Implement basic range operators to enable floating point VRP.

I forgot to mention. There's a regression in g++.dg/opt/pr94589-2.C, where an early optimization by evrp causes phiopt to no longer optimize a spaceship operator because it no longer sees the exact sequence of conditionals. I have included the analysis in the patch. Hopefully a phiopt expert can

[RFA] Implement basic range operators to enable floating point VRP.

Without further ado, here is the implementation for floating point range operators, plus the switch to enable all ranger clients to handle floats. These are bare bone implementations good enough for relation operators to work, while keeping the NAN bits up to date in the frange. There is also

[v2 PATCH] c++: ICE with erroneous template redeclaration [PR106311]

On Fri, Jul 22, 2022 at 05:21:58PM -0400, Jason Merrill wrote: > On 7/15/22 11:29, Marek Polacek wrote: > > Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens > > to be error_mark_node in this ill-formed test. I kept running into this > > while reducing code, so it'd be good

Re: New LinkedIn Message..

Dear sir, I've tried to contact you via LinkedIn but wasn't successful. Is there any number i can reach you? *Michael Kim|CIC Canada*

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

Le 25/07/2022 à 18:01, Harald Anlauf a écrit : Hi Mikael, all, a discussion in the Intel compiler forum suggests that the F2018 standard prohibits such use of the ASSOCIATED intrinsic.

[PATCH] Dispatch code for floating point range ops.

This modifies the range-op dispatch code to handle floats. Also provided are the stub routines for the floating point range-ops, as we need something to dispatch to ;-). I am not ecstatic about the dispatch code, but there's no getting around having to switch on the tree code and type in some

Re: [PATCH 3/3] c++/106426: Treat u8 character literals as unsigned in char8_t modes.

On Mon, Jul 25, 2022 at 11:01 AM Tom Honermann via Gcc-patches wrote: > > This patch corrects handling of UTF-8 character literals in preprocessing > directives so that they are treated as unsigned types in char8_t enabled > C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t).

[PATCH 2/3] testsuite: Add tests for C2X N2653 char8_t and UTF-8 string literal changes

This change provides new tests for the core language and compiler dependent library changes adopted for C2X via WG14 N2653. gcc/testsuite/ChangeLog: * gcc.dg/atomic/c2x-stdatomic-lockfree-char8_t.c: New test. * gcc.dg/atomic/gnu2x-stdatomic-lockfree-char8_t.c: New test. *

[PATCH 1/3] C: Implement C2X N2653 char8_t and UTF-8 string literal changes

This patch implements the core language and compiler dependent library changes adopted for C2X via WG14 N2653. The changes include: - Change of type for UTF-8 string literals from array of const char to array of const char8_t (unsigned char). - A new atomic_char8_t typedef. - A new

[PATCH 3/3] c++/106426: Treat u8 character literals as unsigned in char8_t modes.

This patch corrects handling of UTF-8 character literals in preprocessing directives so that they are treated as unsigned types in char8_t enabled C++ modes (C++17 with -fchar8_t or C++20 without -fno-char8_t). Previously, UTF-8 character literals were always treated as having the same type as

[PATCH 0/3] Implement C2X N2653 (char8_t) and correct UTF-8 character literal type in preprocessor directives for C++

This patch series provides an implementation and tests for the WG14 N2653 paper as adopted for C2X. Additionally, a fix is included for the C++ preprocessor to treat UTF-8 character literals in preprocessor directives as an unsigned type in char8_t enabled modes (in C++17 and earlier with

RE: [PATCH] analyzer: fix coding style in sm-fd.cc

Thanks for this. I’ll keep this in mind for future patches. Immad. Sent from Mail for Windows 10 From: Martin Liška Sent: 25 July 2022 12:14 PM To: gcc-patches@gcc.gnu.org Cc:

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

Hi Mikael, all, a discussion in the Intel compiler forum suggests that the F2018 standard prohibits such use of the ASSOCIATED intrinsic. https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159 As a

Re: [PATCH] analyzer: fix coding style in sm-fd.cc

On Mon, 2022-07-25 at 08:44 +0200, Martin Liška wrote: > Hi. > > First, thanks Mir for your contribution. The following patch > addresses > coding style issues I let you know in: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003#c3 > > Most notably, I converted Windows endlines to Unix

Re: [PATCH] analyzer: convert tests with dos2unix

On Mon, 2022-07-25 at 08:45 +0200, Martin Liška wrote: > Ready for master? Yes, thanks. Dave > Thanks, > Martin > > gcc/testsuite/ChangeLog: > > * gcc.dg/analyzer/fd-2.c: Convert Windows endlines to Unix > style. > * gcc.dg/analyzer/fd-3.c: Likewise. > *

[COMMITTED] [PR middle-end/106432] Gracefully handle unsupported type in range_on_edge

A cleaner approach to fix this PR has been suggested by Andrew, which is to just return false on range_on_edge for unsupported range types. Tested on x86-64 Linux. gcc/ChangeLog: * gimple-range.cc (gimple_ranger::range_on_edge): Return false when the result range type is

Re: [PATCH] tree-optimization/106379 - add missing ~(a ^ b) folding for _Bool

On Mon, 25 Jul 2022, H.J. Lu wrote: > On Fri, Jul 22, 2022 at 11:10 PM Richard Biener via Gcc-patches > wrote: > > > > > > > > > Am 22.07.2022 um 22:17 schrieb H.J. Lu via Gcc-patches > > > : > > > > > > On Thu, Jul 21, 2022 at 4:24 AM Richard Biener via Gcc-patches > > > wrote: > > >> > > >>

Re: [PATCH] tree-optimization/106379 - add missing ~(a ^ b) folding for _Bool

On Fri, Jul 22, 2022 at 11:10 PM Richard Biener via Gcc-patches wrote: > > > > > Am 22.07.2022 um 22:17 schrieb H.J. Lu via Gcc-patches > > : > > > > On Thu, Jul 21, 2022 at 4:24 AM Richard Biener via Gcc-patches > > wrote: > >> > >> The following makes sure to fold ~(a ^ b) to a == b for

[PATCH] contrib: use sphinx-build from a venv

Hi. As you likely know, I'm still working on transition of the current docs to Sphinx. But for now, I've sent a modernizing patches for the current libgccjit documentation and I will need a more recent version of Sphinx. Can please a maintainer install the package from pip? Something like:

Re: [PATCH] OpenMP, libgomp: Environment variable syntax extension.

Hi Jakub, I'm not sure we can rely on execv on all targets that do support libgomp. Any reason why you actually need this, rather than using dg-set-target-env-var directive(s) and perhaps return 0; if getenv doesn't return the expected values? Interesting topic. After some (internal)

[PATCH V4] rs6000: Optimize cmp on rotated 16bits constant

Hi, When checking eq/neq with a constant which has only 16bits, it can be optimized to check the rotated data. By this, the constant building is optimized. As the example in PR103743: For "in == 0x8000LL", this patch generates: rotldi %r3,%r3,16 cmpldi %cr0,%r3,32768

[pushed] c++: -Woverloaded-virtual false positive [PR87729]

My attempt to shortcut unnecessary checking after finding a match was also wrong for multiple inheritance, so let's give up on it. Tested x86_64-pc-linux-gnu, applying to trunk. PR c++/87729 gcc/cp/ChangeLog: * class.cc (warn_hidden): Remove shortcut. gcc/testsuite/ChangeLog:

[PATCH 5/7] jit,docs: use list-table instead of fixed table

Use rather list-table that is easible to maintainer and one does not have to wrap lines. Moreover, it provides great attribute :widths: that correctly works (tested for HTML and PDF). gcc/jit/ChangeLog: * docs/cp/intro/tutorial04.rst: Use list-table. * docs/intro/tutorial04.rst:

[PATCH 3/7] jit,docs: various fixes

gcc/jit/ChangeLog: * docs/cp/intro/tutorial02.rst: Use proper reference. * docs/cp/topics/contexts.rst: Likewise. * docs/cp/topics/functions.rst: Put `class` directive before a function as it is not allowed declaring a class in a fn. *

[PATCH 4/7] jit,docs: compact function declarations

gcc/jit/ChangeLog: * docs/cp/topics/expressions.rst: Compact so that the generated output is also more compact. --- gcc/jit/docs/cp/topics/expressions.rst | 42 +- 1 file changed, 14 insertions(+), 28 deletions(-) diff --git

[PATCH 1/7] jit,docs: use enum directive for enumeral types

gcc/jit/ChangeLog: * docs/conf.py: Add needs_sphinx = '3.0' where c:type was added. * docs/index.rst: Remove note about it. * docs/topics/compilation.rst: Use enum directive and reference. * docs/topics/contexts.rst: Likewise. * docs/topics/expressions.rst:

[PATCH 2/7] jit, docs: replace c:type:`int_type` with :expr:`int_type`

Use expression that work fine for basic type. gcc/jit/ChangeLog: * docs/cp/topics/expressions.rst: Use :expr: for basic types. * docs/topics/compilation.rst: Likewise. * docs/topics/expressions.rst: Likewise. * docs/topics/function-pointers.rst: Likewise. ---

[PATCH 6/7] jit,docs: use :expr:`type *` for pointers to a type

gcc/jit/ChangeLog: * docs/cp/intro/tutorial02.rst: Use :expr:`type *` for pointers to a type * docs/cp/topics/asm.rst: Likewise. * docs/cp/topics/contexts.rst: Likewise. * docs/cp/topics/expressions.rst: Likewise. * docs/cp/topics/functions.rst: Likewise.

[PATCH 0/7] jit,docs: remove warnings and modernize the docs

The patch set modernizes the documentation and removes most of the reported Sphinx warnings. Ready for master? Thanks, Martin Martin Liska (7): jit,docs: use enum directive for enumeral types jit,docs: replace c:type:`int_type` with :expr:`int_type` jit,docs: various fixes jit,docs:

[PATCH] middle-end/106414 - fix mistake in ~(x ^ y) -> x == y pattern

When compares are integer typed the inversion with ~ isn't properly preserved by the equality comparison even when converting the result properly. The following fixes this by restricting the input precisions accordingly. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress. PR

Re: [PATCH] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]

Le 21/07/2022 à 22:12, Harald Anlauf via Fortran a écrit : Dear all, the rank check for ASSOCIATED (POINTER, TARGET) did not allow all rank combinations that were allowed in pointer assignment for newer versions of the Fortran standard (F2008+). Fix the logic. So, if I understand correctly

Re: [PATCH 9/12 V2] arm: Make libgcc bti compatible

On 22/07/2022 16:09, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: On 21/07/2022 10:17, Andrea Corallo via Gcc-patches wrote: Richard Earnshaw writes: On 28/04/2022 10:48, Andrea Corallo via Gcc-patches wrote: This change add bti instructions at the beginning of arm

Re: [PATCH V1] HIGH part of symbol ref is invalid for constant pool

Hi Jeff, on 2022/7/19 22:30, Jiufu Guo wrote: > Hi, > > In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html, > test case was not added. After more check, a testcase is added for it. > Good to see that you constructed one actual test case, nice! :) > The high part of the

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

Rainer Orth writes: >> I think this just leaves: >> >>> * While this lets the build finish on all of i386-pc-solaris2.11, >>> sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of >>> testsuite failures, all of the same kind: >>> >>> Undefined first

PING: [PATCH] libsanitizer: don't enable for MIPS Linux without GNU libc [PR 106136]

Gentle ping :). On Thu, 2022-06-30 at 12:22 +0800, Xi Ruoyao wrote: > In libsanitizer code, the size of some GNU libc data structure > (notably, > struct stat) is hard coded.  These sizes may trigger a static assert > buidling against another libc. > > Just make non-GNU libc targets UNSUPPORTED

Re: [PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

LGTM. Requiring permission to push. > +const unsigned struct_kernel_stat_sz = > +    SANITIZER_ANDROID > +    ? FIRST_32_SECOND_64(104, 128) > +    : FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216); These values matches sizeof(struct stat) on gcc230, so should be correct:

[PATCH] docs: remove recently added trailing whitespaces

Pushed as obvious. Martin gcc/ChangeLog: * doc/extend.texi: Remove trailing whitespaces. * doc/invoke.texi: Likewise. --- gcc/doc/extend.texi | 12 ++-- gcc/doc/invoke.texi | 10 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git

[PATCH] libsanitizer: Cherry-pick 2bfb0fcb51510f22723c8cdfefe from upstream

2bfb0fcb51510f22723c8cdfefe [Sanitizer][MIPS] Fix stat struct size for the O32 ABI. Signed-off-by: Dimitrije Milosevic . --- .../sanitizer_common/sanitizer_platform_limits_posix.h | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git

[COMMITTED] frange class to represent floating point ranges

This implements a basic frange class to represent floating point ranges. Although it is meant to be a base for further development, it is enough to handle relations and propagate NAN and other properties. For ranger clients to become floating point aware, we still need the range-op entries,

[PATCH] analyzer: convert tests with dos2unix

Ready for master? Thanks, Martin gcc/testsuite/ChangeLog: * gcc.dg/analyzer/fd-2.c: Convert Windows endlines to Unix style. * gcc.dg/analyzer/fd-3.c: Likewise. * gcc.dg/analyzer/fd-4.c: Likewise. * gcc.dg/analyzer/fd-5.c: Likewise. *

[PATCH] analyzer: fix coding style in sm-fd.cc

Hi. First, thanks Mir for your contribution. The following patch addresses coding style issues I let you know in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003#c3 Most notably, I converted Windows endlines to Unix style, replace 8 spaces with tabs and removed trailing whitespaces. Please

[PATCH v2] rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

Hi, As the failure of test case gcc.target/powerpc/pr92398.p9-.c in PR106345 shows, some test sources for some powerpc effective targets use empty translation unit wrongly. The test sources could go with options like "-ansi -pedantic-errors", then those effective target checkings will fail

Re: [PATCH] rs6000/test: Update some cases with -mdejagnu-tune

Hi Peter and Segher, on 2022/7/23 03:28, Peter Bergner wrote: > On 7/22/22 1:53 PM, Peter Bergner wrote: >> So I think the way the code above *should* work is: >> 1) Any -mdejagnu-cpu= usage should filter out all -mcpu= and -mtune= >> options. >> 2) Any -mdejagnu-tune= usage should filter

Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

Hi Sebastian, > On 25 Jul 2022, at 06:59, Sebastian Huber > wrote: > On 22/07/2022 16:02, Jose E. Marchesi wrote: >> I find "subtarget" confusing in this context. >> If it is about rtems.h, linux.h or sol2.h, wouldn't this be better >> called OS_CC1_SPEC or similar? These files specify

Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

Hallo Jose, On 22/07/2022 16:02, Jose E. Marchesi wrote: I find "subtarget" confusing in this context. If it is about rtems.h, linux.h or sol2.h, wouldn't this be better called OS_CC1_SPEC or similar? These files specify configurations that apply to a set of targets, not to a subset of a