Hi!
On 2025-03-03T17:30:06+0100, I wrote:
> On 2002-04-17T21:37:50-0400, Phil Edwards <p...@jaj.com> wrote:
>> If the user decides to build the library with extra compiler options
>> via --enable-cxx-flags, the testsuite should (by default) use those same
>> options when running.
>
> Hmm, are we sure that's what we actually want?
>
>> Verified by passing strange things via --enable
>> and watching their effects on the testsuite.
>
>> --- testsuite_flags.in 7 Jan 2002 00:07:27 -0000 1.11
>> +++ testsuite_flags.in 18 Apr 2002 01:34:43 -0000
>> @@ -49,7 +49,7 @@ case ${query} in
>> ;;
>> --cxxflags)
>> CXXFLAGS=' -g @SECTION_FLAGS@ @SECTION_LDFLAGS@
>> - -fmessage-length=0
>> + -fmessage-length=0 @EXTRA_CXX_FLAGS@
>> -DDEBUG_ASSERT -DLOCALEDIR="@glibcpp_localedir@" '
>> echo ${CXXFLAGS}
>> ;;
>
> This got installed in Subversion r52450
> (Git commit 822ca943a31961fd7339de6fbe6593118ec7f231).
>
> To me at least, this comes unexpected: per my reading of (the current)
> 'libstdc++-v3/acinclude.m4:GLIBCXX_ENABLE_CXX_FLAGS', I'd have thought
> these flags apply only to the build of libstdc++ itself, but apparently
> "flags to pass to the compiler while building" or
> "extra compiler flags for building" also includes use by
> 'make check-target-libstdc++-v3'?
>
> I'm OK to leave this as-is, if only for hysterical raisins, but would
> then proposa a patch to document this behavior?
>
>
> Alas, there's an additional issue: with Subversion r42272
> (Git commit 28e8acb68f8a427552bc9f2d4cae12a1ac477855) -- so, already
> in place when the change above got installed -- we'd gotten:
>
> * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Set flags
> appropriately for remote testing and testing installed files without
> a build dir.
>
> - [...]
> - set cxxflags [exec sh ${blddir}/testsuite_flags --cxxflags]
> - [...]
> + if [is_remote host] {
> + [...]
> + set cxxflags "-ggdb3 -DDEBUG_ASSERT"
> + [...]
> + } else {
> + # If we find a testsuite_flags file, we're testing in the build
> dir.
> + set flags_file "${blddir}/testsuite_flags"
> + if { [file exists $flags_file] } {
> + [...]
> + set cxxflags [exec sh $flags_file --cxxflags]
> + [...]
> + } else {
> + [...]
> + set cxxflags "-ggdb3 -DDEBUG_ASSERT"
> + [...]
> + }
> + }
>
> (Nowadays: 'libstdc++-v3/testsuite/lib/libstdc++.exp:libstdc++_init',
> similarly.)
>
> That means, any 'EXTRA_CXX_FLAGS' specified by '--enable-cxx-flags=[...]'
> are *not* considered for remote host testing -- which in turn appears to
> be in conflict with the original intent, quoted at the beginning of this
> email? Hmm...
>
>
> I think we should clarify the intended cases where 'EXTRA_CXX_FLAGS' (as
> specified by '--enable-cxx-flags=[...]') apply, and then make that apply
> in a uniform way? I think I'd be in favor of removing them from
> 'testsuite_flags --cxxflags' -- but can't quite tell which use cases
> that'd break...
I still maintain my position that 'testsuite_flags' should not be about
passing compiler flags (as opposed to all kinds of search paths, where
it's appropriate).
However, 'libstdc++-v3/doc/xml/manual/test.xml' also "You can run the
tests with different options by adding them to the output of the
'--cxxflags' option of that script, or [...]", so there's more precedence
of doing it this way.
And, 'testsuite_flags -cxxflags' actually isn't only about
'EXTRA_CXX_FLAGS' but also '-fmessage-length=0 -fno-show-column', and
'@SECTION_FLAGS@' ('-ffunction-sections -fdata-sections'), and other
random ones, like '-fcf-protection', '-mshstk'.
All this doesn't work for the '[is_remote host]' case, as far as I can
tell, but resolving that shall not be my problem of today. ;-)
And, considering that for GCN/nvptx libstdc++ I also need a way to inject
compiler flags into 'make check-target-libstdc++-v3', and these happen to
overlap with those needed for the libstdc++ build, so the current
'EXTRA_CXX_FLAGS' actually fits that model. ;-)
And for flags that only apply to libstdc++ compilation but not apply to
'make check-target-libstdc++-v3', I may use 'OPTIMIZE_CXXFLAGS'.
Sounds like a plan, I guess? (So, effectively no code changes, but I'll
still propose updates to the documentation.)
Grüße
Thomas
