What's up with CXXFLAGS_FOR_BUILD?
I have been looking and looking until my eyes have started to cross. Here's my problem. The only way I have been able to affect an entire build of GCC, for example in order to do a "-ggdb -O0" build of the entire compiler and its libraries, has been to do something like this: mkdir build cd build CFLAGS="-ggdb -O0" CXXFLAGS="-ggdb - O0" ../configure ... However, one thing I want to be able to do when developing the COBOL front end is: CXXFLAGS="-ggdb -O0 -std=C++17" ../configure ... That results in a build failure because libcody gets upset when the standard isn't c++11 Okay. So, I tried setting CXXFLAGS_FOR_BUILD, which as far as I know is not supposed to affect libraries. Jumping ahead a bit, I tried this: CXXFLAGS_FOR_BUILD="-DDUBNER_HARMLESS" I then did a complete --disable-bootstrap build and saved the output of the make. The text DUBNER_HARMLESS did not appear anywhere in the output. I have determined that the environment variable CXXFLAGS_FOR_BUILD="-DDUBNER_HARMLESS" is definitely present at the point where gcc/cobol/.cc files are being compiled. But it's not finding its way into the command line for the compilation. This raises two, presumably related, questions. 1) What is CXXFLAGS_FOR_BUILD supposed to be doing? 2) How can I set compilation switches for gcc stuff (like the gcc/cobol front end) without affecting lib*** stuff? Thanks.
Re: smtgcc mid-year update
Krister Walfridsson via Gcc writes: > I have continued working on my translation validator, smtgcc [1]. Here > is an update of what I have done since the end-of-year update. > > > smtgcc-tv-backend > - > The main focus has been improving the smtgcc-tv-backend tool which > checks that the generated assembly is a refinement of the final GIMPLE > IR. > > Highlights: > * Implemented most AArch64 SVE instructions > * Implemented most RISC-V vector instructions > * Improved performance > > There are still some limitations in the ABI support. This is not too > problematic, as smtgcc reports "not implemented" instead of trying to > analyze, so it avoids false positives. But it does restrict the range > of code it can handle. > > The tool also still generates overly complicated SMT formulas for some > common instructions, which makes tests time out unnecessarily. > > > Add SMTGCC_ASM environment variable > --- > The smtgcc-tv-backend tool verifies that the generated assembly is a > refinement of the final GIMPLE IR. It is now possible to override the > file used for reading the assembly by setting the SMTGCC_ASM > environment variable. This is useful for testing the implementation of > smtgcc, but can also be used to verify hand-written assembly by > letting smtgcc-tv-backend compare the GIMPLE from the C function > against the provided assembly code instead of the compiler-generated > output. > > > Caching > --- > smtgcc can now cache SMT queries in a Redis database, and use the > cached result when an identical query is submitted. This speeds up > continuous testing of GCC a lot. > > > GCC testing > --- > I am continuing with weekly runs of the GCC test suite. The testing is > done with -fno-strict-aliasing and, for AArch64 and RISC-V, > -fno-section-anchors, as type-based aliasing and section anchors are > not yet supported by smtgcc. > > The tests are done on optimization levels: > * -O3 > * -O2 > * -Os > * -O1 > * -O0 > and for the following target flags (where I typically only run a > subset of targets each week): > * x86_64: > - > - -march=x86-64-v2 > - -march=x86-64-v3 > - -march=x86-64-v4 > - -m32 > * AArch64 > - > - -march=armv8.9-a > - -march=armv9.5-a > * RISC-V > - -march=rv64gcbv > - -march=rv64gcv > - -march=rv64gcb > - -march=rv64gc > - -march=rv32gcbv > - -march=rv32gcv > - -march=rv32gcb > - -march=rv32gc > > Please let me know if there are additional configurations you would > like me to include in the testing. > We sometimes get interesting bugs, especially with UBSAN (-fsanitize=undefined), with SAVE_EXPR. PR120471 is one example and PR120837 is another. These two are FE issues though, so may not really be applicable. It might be interesting to try -fhardened occasionally (which wraps up several options that distributions build with). I think anything that introduces instrumentation (so -fprofile-generate may be another candidate, or in a sense, -fnon-call-exceptions) could be interesting. sam
Re: libatomic vs. __atomic_test_and_set()
Hello,
it seems that the variants without a _1, _2, ... are explicitly provided
(libatomic_i.h):
/* And the generic sized versions. */
void libat_load (size_t, void *, void *, int) MAN(load);
void libat_store (size_t, void *, void *, int) MAN(store);
void libat_exchange (size_t, void *, void *, void *, int) MAN(exchange);
bool libat_compare_exchange (size_t, void *, void *, void *, int, int)
MAN(compare_exchange);
bool libat_is_lock_free (size_t, void *) MAN(is_lock_free);
I am not really sure why there is no alias to the _1 variant for the
DECLARE_ALL_SIZED(1);
operations. Does this patch make any sense?
diff --git a/libatomic/libatomic_i.h b/libatomic/libatomic_i.h
index e59dd412e17..afc356d257d 100644
--- a/libatomic/libatomic_i.h
+++ b/libatomic/libatomic_i.h
@@ -237,7 +237,8 @@ bool libat_is_lock_free (size_t, void *) MAN(is_lock_free);
#endif
#if IFUNC_ALT
-# define EXPORT_ALIAS(X) /* exported symbol in non-alternate file */
+# define EXPORT_ALIAS_2(X, Y) /* exported symbol in non-alternate file */
+# define EXPORT_ALIAS(X)
#elif defined(N) && IFUNC_NCOND(N)
# if IFUNC_NCOND(N) == 1
# define GEN_SELECTOR(X) \
@@ -278,18 +279,21 @@ bool libat_is_lock_free (size_t, void *)
MAN(is_lock_free);
# else
# error "Unsupported number of ifunc alternatives."
# endif
-# define EXPORT_ALIAS(X) \
+# define EXPORT_ALIAS_2(X, Y) \
GEN_SELECTOR(X) \
- typeof(C2(libat_,X)) C2(ifunc_,X) \
- ASMNAME(C2(__atomic_,X)) \
+ typeof(C2(libat_,X)) C2(ifunc_,Y) \
+ ASMNAME(C2(__atomic_,Y)) \
__attribute__((ifunc(S(C2(select_,X)
+# define EXPORT_ALIAS(X) EXPORT_ALIAS_2(X, X)
#elif defined(HAVE_ATTRIBUTE_ALIAS)
-# define EXPORT_ALIAS(X) \
- extern typeof(C2(libat_,X)) C2(export_,X) \
- ASMNAME(C2(__atomic_,X)) \
+# define EXPORT_ALIAS_2(X, Y) \
+ extern typeof(C2(libat_,X)) C2(export_,Y) \
+ ASMNAME(C2(__atomic_,Y)) \
__attribute__((alias(S(C2(libat_,X)
+# define EXPORT_ALIAS(X) EXPORT_ALIAS_2(X, X)
#else
-# define EXPORT_ALIAS(X) /* original symbol is exported */
+# define EXPORT_ALIAS_2(X, Y) /* original symbol is exported */
+# define EXPORT_ALIAS(X)
#endif
#endif /* LIBATOMIC_H */
diff --git a/libatomic/tas_n.c b/libatomic/tas_n.c
index 036a3d23307..fad9d00b280 100644
--- a/libatomic/tas_n.c
+++ b/libatomic/tas_n.c
@@ -114,4 +114,7 @@ SIZE(libat_test_and_set) (UTYPE *mptr, int smodel UNUSED)
#endif
EXPORT_ALIAS (SIZE(test_and_set));
+#if N == 1
+EXPORT_ALIAS_2 (SIZE(test_and_set), test_and_set);
+#endif
#undef LAT_TAS_N
- Am 2. Jul 2025 um 9:20 schrieb Sebastian Huber
sebastian.hu...@embedded-brains.de:
> Hello,
>
> for the RISC-V target, I would like to use the -march=rv64imc ISA variant.
> However, there is an issue with the libatomic for this target in the RTEMS
> configuration. For this test code:
>
> #include
>
> bool tas(atomic_flag *f)
> {
>return atomic_flag_test_and_set(f);
> }
>
> GCC 15 generates:
>
> riscv-rtems6-gcc -O2 -S -o - -march=rv64imc -mabi=lp64 test.c
>.file "test.c"
>.option nopic
>.attribute arch, "rv64i2p1_m2p0_c2p0_zmmul1p0_zca1p0"
>.attribute unaligned_access, 0
>.attribute stack_align, 16
>.text
>.align 1
>.globl tas
>.type tas, @function
> tas:
>li a1,5
>tail__atomic_test_and_set
>.size tas, .-tas
>.ident "GCC: 15.1.1 20250517"
>.section.note.GNU-stack,"",@progbits
>
> In the corresponding libatomic.a multilib, there are the following functions
> (omitting *_4, *_8, *_16 variants which exist for all *_1 variants):
>
> __atomic_add_fetch_1
> __atomic_and_fetch_1
> __atomic_compare_exchange
> __atomic_compare_exchange_1
> __atomic_exchange
> __atomic_exchange_1
> __atomic_feraiseexcept
> __atomic_fetch_add_1
> __atomic_fetch_and_1
> __atomic_fetch_nand_1
> __atomic_fetch_or_1
> __atomic_fetch_sub_1
> __atomic_fetch_xor_1
> __atomic_is_lock_free
> __atomic_load
> __atomic_load_1
> __atomic_nand_fetch_1
> __atomic_or_fetch_1
> __atomic_store
> __atomic_store_1
> __atomic_sub_fetch_1
> __atomic_test_and_set_1
> __atomic_xor_fetch_1
>
> Some operations have a variant without a _1, _2, _4, _8, and _16 postfix
> (example: __atomic_store). Others do not have such a variant, examples:
> __atomic_test_and_set_1, __atomic_add_fetch_1.
>
> I am a bit clueless what is going on here. Are the missing variants a
> libatomic
> configuration error? Is it a general configuration error or specific to RTEMS?
>
> --
gcc-12-20250702 is now available
Snapshot gcc-12-20250702 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20250702/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 14d40a2c5616e0a7225a95c801c0af78523b352e You'll find: gcc-12-20250702.tar.xz Complete GCC SHA256=3f6135bcdcce698164699cd11e871b83d93f3f21fe72fd056541180b9fc32f37 SHA1=baf7b51ea992cf40c7cf73045b39793753d115ff Diffs from 12-20250625 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
New AArch64 maintainers and reviewers appointed
I am pleased to announce that the GCC Steering Committee has appointed Tamar Christina as AArch64 maintainer. I am pleased to announce that the GCC Steering Committee has appointed Alex Coplan, Alice Carlotti, Andrew Pinski, and Wilco Dijkstra as AArch64 reviewers. Please join me in congratulating Tamar, Alex, Alice, Andrew, and Wilco on their new roles. All, please update your respective listings in the MAINTAINERS file. Happy hacking! David
libatomic vs. __atomic_test_and_set()
Hello,
for the RISC-V target, I would like to use the -march=rv64imc ISA variant.
However, there is an issue with the libatomic for this target in the RTEMS
configuration. For this test code:
#include
bool tas(atomic_flag *f)
{
return atomic_flag_test_and_set(f);
}
GCC 15 generates:
riscv-rtems6-gcc -O2 -S -o - -march=rv64imc -mabi=lp64 test.c
.file "test.c"
.option nopic
.attribute arch, "rv64i2p1_m2p0_c2p0_zmmul1p0_zca1p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
.align 1
.globl tas
.type tas, @function
tas:
li a1,5
tail__atomic_test_and_set
.size tas, .-tas
.ident "GCC: 15.1.1 20250517"
.section.note.GNU-stack,"",@progbits
In the corresponding libatomic.a multilib, there are the following functions
(omitting *_4, *_8, *_16 variants which exist for all *_1 variants):
__atomic_add_fetch_1
__atomic_and_fetch_1
__atomic_compare_exchange
__atomic_compare_exchange_1
__atomic_exchange
__atomic_exchange_1
__atomic_feraiseexcept
__atomic_fetch_add_1
__atomic_fetch_and_1
__atomic_fetch_nand_1
__atomic_fetch_or_1
__atomic_fetch_sub_1
__atomic_fetch_xor_1
__atomic_is_lock_free
__atomic_load
__atomic_load_1
__atomic_nand_fetch_1
__atomic_or_fetch_1
__atomic_store
__atomic_store_1
__atomic_sub_fetch_1
__atomic_test_and_set_1
__atomic_xor_fetch_1
Some operations have a variant without a _1, _2, _4, _8, and _16 postfix
(example: __atomic_store). Others do not have such a variant, examples:
__atomic_test_and_set_1, __atomic_add_fetch_1.
I am a bit clueless what is going on here. Are the missing variants a libatomic
configuration error? Is it a general configuration error or specific to RTEMS?
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: scan-*-dump-times across multiple functions considered harmful
On Tue, 2025-07-01 at 23:04 +0100, Joern Wolfgang Rennecke wrote:
> Quite often I see a test quickly written to test some new feature
> (bug
> fix, extension or optimization) that has a couple of functions to
> cover
> various aspects of the feature, checked all together with a single
> scan-tree-dump-times, scan-rtl-dump-times etc. check, using the
> expected
> value for the target of the test writer.
> Or worse, it's all packed into one giant function, with unpredictable
> interactions between the different pieces of code. I think we have
> less
> of those recently, but please don't interpret this post as a
> suggestion
> to fall back to this practice.
>
> Quite often it turns out that the feature applies only to some of the
> functions / sites on some targets. The first reaction is often to
> create multiple copies of the scan-*-dump-times stanza, with mutually
> exclusive conditions for each copy, which might look harmless when
> there
> are only two cases, but as more are added, it quickly turns into an
> unmaintainable mess of lots dejagnu directives with complicated.
>
> This can get even worse if different targets can get the compiler the
> pattern multiple times for the same piece of source, like for
> vectorization that is tried with different vectorization factors.
>
> I think we should discuss what is best practice to address these
> problems efficiently, and to preferably write new tests avoiding them
> in the first place.
>
> When each function has a single site per feature where success is
> given
> if the pattern appears at least once, a straightforward solution that
> has already been used a number of times is to split the test into
> multiple smaller tests. The main disadvantages of this approach are
> that a large set of small files can clutter the directory where they
> appear, making it less maintainable, and that the compiler is invoked
> more often, generally with the same set of include files read each
> time,
> thus making the test runs slower.
>
> Another approach would be to use source line numbers, where present
> and
> distinctive, to add to the scan pattern to make it specific to the
> site
> under concern. That should, for instance, work for vectorization
> scan-tree-dump-times tests. The disadvantage of that approach is
> that
> the tests become more brittle, as the line numbers would have to be
> adjusted whenever the line numbers of the source site change, like
> when
> new include files, dejagnu directives at the file start, or typedefs
> are
> needed.
Brainstorming some ideas on other possible approaches on making our
tests less brittle; for context I did some investigation back in 2018
about implementing "optimizations remarks" like clang does: diagnostics
about optimization decisions, so you could have a dg directive like
this on a particular line:
foo (); /* { dg-remark "inlined call to 'foo' into 'bar'" } */
which eventually became this series of patches:
[PATCH 00/10] RFC: Prototype of compiler-assisted performance analysis
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-05/msg01675.html
[PATCH] v3 of optinfo, remarks and optimization records
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-06/msg01267.html
[PATCH 0/2] v4: optinfo framework and remarks
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-07/msg00066.html
[PATCH 0/5] [RFC v2] Higher-level reporting of vectorization problems
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00446.html
where the "remark" idea eventually got dropped in favor of optimization
records (compressed json), which landed in GCC 9 as -fsave-
optimization-record.
Ideas for further approaches:
(a) we could revisit adding optimization remarks: perhaps the dump
subsystem could be extended so it also reports diagnostics, and we
could have DejaGnu directives that check for a remark relating to a
particular source line
(b) have a script that reads the compressed json and turns it into
something that's queryable from DejaGnu tests. This might be more
flexible in that it can potentially distinguish between different
copies of code (e.g. due to different inlinings sites), but might be
less easy to work with in terms of testsuite management.
Another idea: perhaps a new dump format for RTL that resembles
diagnostics, with line information, and then use per-line dg directives
on that so that e.g. you can test that at a particular line we do or
don't have some particular construct after a given RTL pass (e.g. that
the asm for a particular line does/doesn't match a regex).
Hope this is constructive
Dave
>
> Maybe we could get the best of both worlds if we add a new dump
> option?
> Say, if we make that option add the (for polymorphic languages like
> C++:
> mangled) name of the current function to each dumped line that is
> interesting to scan for. Or just every line, if that's simpler.
>
