Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On Tue, 6 Jun 2023, 01:07 Dave Blanchard, wrote: > On Tue, 6 Jun 2023 01:59:42 +0200 > Gabriel Ravier wrote: > > > [nothing of value] > > If this guy's threads are such a terrible waste of your time, how about > employing your email client's filters to ignore his posts (and mine too) > and fuck off? > > Now YOU'RE wasting everyone's time, as your type is so skilled at doing, > refocusing an important discussion to generic whining about "muh feelings", > instead of the real issue at hand here: GCC's optimizer is TERRIBLE! > Why are you still here then? Other compilers are available. > > I for one appreciate this guy's posts, as this issue might have never been > called to my attention otherwise; certainly not if this were relegated to > the dusty corner of some bug list somewhere. I've now reverted to a much > older version of GCC which will hopefully waste much fewer of my old > computer's CPU cycles, while also (provably) not constantly breaking my > system with all the added warnings and errors every release. > Great, so there's no reason for you to follow the development of current gcc. Toddle off somewhere else.
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On 06/06/2023 02:09, Dave Blanchard wrote: If this guy's threads are such a terrible waste of your time, how about employing your email client's filters to ignore his posts (and mine too) and fuck off? You apparently appreciate Stefan's posts, but burst a blood vessel when reading anyone else's. And Stefan has shown a total disregard for what anyone else writes. Rather than everyone else having to killfile the pair of you, why don't you do everyone a favour and have your little rants with each other directly, and not on this list? If either of you are remotely interested in improving gcc's optimisation, there are two things you must do: 1. Stop wasting the developers' time and driving them up the wall, so that they have more time to work on improving the tools. 2. Make the suggestions and requests for improvements through the proper channels - polite, factual and detailed bug reports. This is not rocket science - it's basic human decency, and should not be difficult to understand. David
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
It's alright Gabriel, pay this intellectually challenged individual no mind. It's clear that, unlike Stefan, who at the very least knows how to disassemble native code and understands what the instruction sequences mean (even though the way he goes about it is flat out wrong), this retard doesn't know how the fuck compiler code emission works in the slightest. I'd be surprised if our friend Dave here (from "killthe.net", VERY professional Dave!) even knows what registers or the stack are. Hell Dave, forget about something as advanced as a compiler for native chip architectures, do you even know the basic design principles of a fucking Interpreter? Should be easy for a "Big Dog" like you, shouldn't it? Hell, I'll make it easy for you, you can ignore ultra low level Interpreters like the one within the JVM (because there is no fucking way in hell someone like you with IQ comparable to room temperature can ever grasp how such a complex system works), how would a basic Interpreter even function? How does simple interpreter dispatch work, hm? How does cpython (or PyPy) or even one as simple as the Matz Ruby Interpreter operate? Can you answer that Dave? Or have you deluded your braindead self into thinking that you're one of the "Big Dogs" (Your own words) and are now punching way above your league? Are you going to answer with the "Hurr durr they work by translating source code to machine code on the fly" that outdated and flat out wrong as shit text in computer science textbooks say? Pffft Sorry for my outburst, to the rest of this list. I can no longer stay silent and watch these little shits bully people who are too kind to fire back with the same kind of venom in their words. They may be polite enough to refrain from doing so, Dave, but rest assured, I am far from as kind as they are when dealing with assholes. I'm all for constructive criticism to help improve a product as a whole, but if any of Stefan's (or god forbid, David's) mails are "constructive", then Donald Trump is the second fucking incarnation of Jesus Christ himself returning to earth for the second coming
Moving analyzer tests to c-c++-common
Hi David, Sorry I didn't answer you earlier, I was busy concluding my term. Finally finished yesterday, I now have 100% of my time for GCC. I build yesterday the analyzer with -fanalyzer enabled. Globally there are not many coherent warnings, and a common issue are the thesis-long warnings. Below are the headers of these warnings, the first two were emitted dozen of times across the build. I'll look into these two particularly as it would clean up a lot of noise easily enough. ../../gcc/gcc/wide-int.h:1338:30: warning: use of uninitialized value ‘‘result_decl’ not supported by dump_expr’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] ../../gcc/gcc/analyzer/bounds-checking.cc:658:44: warning: use of uninitialized value ‘’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] ../../gcc/gcc/make-unique.h:41:30: warning: use of possibly-NULL ‘operator new(120)’ where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] I'm also adding new tests for c++. Specifically I'm writing tests for the operators [placement] new and delete, as a number of false-positives occurred repeatedly when building the analyzer. I'm also reediting some of the c tests but with their c++ counterparts, such as using the standard libraries containers and see how the analyzer behaves. Should I put them under c-c++-common or c++ ? With a new analyzer folder and analyzer.exp I guess. For the warnings diving too deep into the standard library, I considered adding a flag to the analyzer to control the maximum depth of the warnings. Have a nice day, Benjamin.
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote: > Sorry for my outburst, to the rest of this list. I can no longer stay > silent and watch these little shits bully people who are too kind to > fire back with the same kind of venom in their words. Many of us have had Dave in our killfiles for a long time already. I recommend you (and everyone else) do the same. You won't miss out on any information of any use to anyone: he apparently just enjoys making other people angry. I'm quite serious: it's so not worth the mental energy to even read his messages, much less to reply to him. Arguing with "people who are wrong on the internet" can be cathartic but this is not arguing, it's just stabbing yourself in the eye with a pencil. Don't play.
Passing the complex args in the GPR's
Hi all , For the test case https://godbolt.org/z/vjs1vfs5W ,we see the mismatch in the ABI b/w gcc and clang . Do we have any supporting documents that second the GCC behaviour over CLANG ? EABI states like In the Power Architecture 64-Bit ELF V2 ABI Specification document (v1.1 from 16 July 2015) Page 53: Map complex floating-point and complex integer types as if the argument was specified as separate real and imaginary parts. and in this case the double complexes are broken down with double real and double img and expected to pass in FPR not the GPR. Thank you ~Umesh
Re: Passing the complex args in the GPR's
On Tue, Jun 6, 2023 at 7:50 AM Umesh Kalappa via Libc-alpha wrote: > > Hi all , > > For the test case https://godbolt.org/z/vjs1vfs5W ,we see the mismatch > in the ABI b/w gcc and clang . > > Do we have any supporting documents that second the GCC behaviour over CLANG ? > > EABI states like > > In the Power Architecture 64-Bit ELF V2 ABI Specification document > (v1.1 from 16 July 2015) You are looking at the wrong ABI document. That is for the 64bit ABI. The 32bit ABI document is located at: http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf Plus the 32bit ABI document does not document Complex argument passing as it was written in 1995 and never updated. https://www.nxp.com/docs/en/reference-manual/E500ABIUG.pdf does not document it either. Thanks, Andrew Pinski > > Page 53: > > Map complex floating-point and complex integer types as if the > argument was specified as separate real > and imaginary parts. > > and in this case the double complexes are broken down with double real > and double img and expected to pass in FPR not the GPR. > > > > Thank you > ~Umesh
Re: Passing the complex args in the GPR's
Hi Adnrew, Thank you for the quick response and for PPC64 too ,we do have mismatches in ABI b/w complex operations like https://godbolt.org/z/bjsYovx4c . Any reason why GCC chose to use GPR 's here ? ~Umesh On Tue, Jun 6, 2023 at 8:28 PM Andrew Pinski wrote: > > On Tue, Jun 6, 2023 at 7:50 AM Umesh Kalappa via Libc-alpha > wrote: > > > > Hi all , > > > > For the test case https://godbolt.org/z/vjs1vfs5W ,we see the mismatch > > in the ABI b/w gcc and clang . > > > > Do we have any supporting documents that second the GCC behaviour over > > CLANG ? > > > > EABI states like > > > > In the Power Architecture 64-Bit ELF V2 ABI Specification document > > (v1.1 from 16 July 2015) > > You are looking at the wrong ABI document. > That is for the 64bit ABI. > The 32bit ABI document is located at: > http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf > > Plus the 32bit ABI document does not document Complex argument passing > as it was written in 1995 and never updated. > > https://www.nxp.com/docs/en/reference-manual/E500ABIUG.pdf does not > document it either. > > Thanks, > Andrew Pinski > > > > > Page 53: > > > > Map complex floating-point and complex integer types as if the > > argument was specified as separate real > > and imaginary parts. > > > > and in this case the double complexes are broken down with double real > > and double img and expected to pass in FPR not the GPR. > > > > > > > > Thank you > > ~Umesh
Re: Passing the complex args in the GPR's
On Tue, Jun 6, 2023 at 8:05 AM Umesh Kalappa wrote: > > Hi Adnrew, > Thank you for the quick response and for PPC64 too ,we do have > mismatches in ABI b/w complex operations like > https://godbolt.org/z/bjsYovx4c . > > Any reason why GCC chose to use GPR 's here ? Yes because it was set before 2003. There could not be an ABI break. r0-50273-gded9bf77e35ce9a2246 fixed GCC for the AIX ABI though. > > ~Umesh > > On Tue, Jun 6, 2023 at 8:28 PM Andrew Pinski wrote: > > > > On Tue, Jun 6, 2023 at 7:50 AM Umesh Kalappa via Libc-alpha > > wrote: > > > > > > Hi all , > > > > > > For the test case https://godbolt.org/z/vjs1vfs5W ,we see the mismatch > > > in the ABI b/w gcc and clang . > > > > > > Do we have any supporting documents that second the GCC behaviour over > > > CLANG ? > > > > > > EABI states like > > > > > > In the Power Architecture 64-Bit ELF V2 ABI Specification document > > > (v1.1 from 16 July 2015) > > > > You are looking at the wrong ABI document. > > That is for the 64bit ABI. > > The 32bit ABI document is located at: > > http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf > > > > Plus the 32bit ABI document does not document Complex argument passing > > as it was written in 1995 and never updated. > > > > https://www.nxp.com/docs/en/reference-manual/E500ABIUG.pdf does not > > document it either. > > > > Thanks, > > Andrew Pinski > > > > > > > > Page 53: > > > > > > Map complex floating-point and complex integer types as if the > > > argument was specified as separate real > > > and imaginary parts. > > > > > > and in this case the double complexes are broken down with double real > > > and double img and expected to pass in FPR not the GPR. > > > > > > > > > > > > Thank you > > > ~Umesh
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On 06/06/2023 14:53, Paul Smith wrote: On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote: Sorry for my outburst, to the rest of this list. I can no longer stay silent and watch these little shits bully people who are too kind to fire back with the same kind of venom in their words. Many of us have had Dave in our killfiles for a long time already. I recommend you (and everyone else) do the same. You won't miss out on any information of any use to anyone: he apparently just enjoys making other people angry. I'm quite serious: it's so not worth the mental energy to even read his messages, much less to reply to him. Arguing with "people who are wrong on the internet" can be cathartic but this is not arguing, it's just stabbing yourself in the eye with a pencil. Don't play. If a poster is causing enough aggravation that a large number of people have killfiled him, is there a process for banning him from the list? That is surely a better solution than having many people individually killfiling him? I would assume those with the power to blacklist addresses from the mailing list do not do so lightly, and that there is a procedure for it. David
Re: Passing the complex args in the GPR's
Hi! On Tue, Jun 06, 2023 at 08:35:22PM +0530, Umesh Kalappa wrote: > Hi Adnrew, > Thank you for the quick response and for PPC64 too ,we do have > mismatches in ABI b/w complex operations like > https://godbolt.org/z/bjsYovx4c . > > Any reason why GCC chose to use GPR 's here ? What did you expect, what happened instead? Why did you expect that, and why then is it an error what did happen? You used -O0. As long as the code works, all is fine. But unoptimised code frequently is hard to read, please use -O2 instead? As Andrew says, why did you use -m32 for GCC but -m64 for LLVM? It is hard to compare those at all! 32-bit PowerPC Linux ABI (based on 32-bit PowerPC ELF ABI from 1995, BE version) vs. 64-bit ELFv2 ABI from 2015 (LE version). Segher
Re: Passing the complex args in the GPR's
Hi Segher , >>What did you expect, what happened instead? For example the complex args are passed in GPR's for cexp in the case GCC and Clang uses caller memory . for reference : https://godbolt.org/z/MfMz3cTe7 We have cross tools like some of libraries built using the GCC and some use Clang . We approached Clang developers on this behaviour (Why stack , not the FPR's registers like PPC64) and they are not going to change this behaviour, and asked us to refer back to GCC ,hence this email thread. Question is : Why does GCC choose to use GPR's here and have any reference to support this decision ? Thank you ~Umesh On Tue, Jun 6, 2023 at 10:16 PM Segher Boessenkool wrote: > > Hi! > > On Tue, Jun 06, 2023 at 08:35:22PM +0530, Umesh Kalappa wrote: > > Hi Adnrew, > > Thank you for the quick response and for PPC64 too ,we do have > > mismatches in ABI b/w complex operations like > > https://godbolt.org/z/bjsYovx4c . > > > > Any reason why GCC chose to use GPR 's here ? > > What did you expect, what happened instead? Why did you expect that, > and why then is it an error what did happen? > > You used -O0. As long as the code works, all is fine. But unoptimised > code frequently is hard to read, please use -O2 instead? > > As Andrew says, why did you use -m32 for GCC but -m64 for LLVM? It is > hard to compare those at all! 32-bit PowerPC Linux ABI (based on 32-bit > PowerPC ELF ABI from 1995, BE version) vs. 64-bit ELFv2 ABI from 2015 > (LE version). > > > Segher
Re: Passing the complex args in the GPR's
On Tue, 6 Jun 2023, Andrew Pinski via Gcc wrote: > You are looking at the wrong ABI document. > That is for the 64bit ABI. > The 32bit ABI document is located at: > http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf > > Plus the 32bit ABI document does not document Complex argument passing > as it was written in 1995 and never updated. For the 32-bit ABI see https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf (sources at https://github.com/ryanarn/powerabi - power.org has long since disappeared). -- Joseph S. Myers jos...@codesourcery.com
Re: Passing the complex args in the GPR's
On Tue, Jun 6, 2023 at 1:08 PM Umesh Kalappa via Gcc wrote: > Hi Segher , > > >>What did you expect, what happened instead? > For example the complex args are passed in GPR's for cexp in the case > GCC and Clang uses caller memory . > > for reference : https://godbolt.org/z/MfMz3cTe7 > > We have cross tools like some of libraries built using the GCC and > some use Clang . > > We approached Clang developers on this behaviour (Why stack , not the > FPR's registers like PPC64) and they are not going to change this > behaviour, and asked us to refer back to GCC ,hence this email thread. > > Question is : Why does GCC choose to use GPR's here and have any > reference to support this decision ? > The use of GPRs to pass complex floating point arguments was an early implementation mistake -- the parameter passing code missed the enumeration of a type. The behavior cannot be changed and corrected without breaking the ABI. I don't know what you mean by "support this decision". It was not intentionally chosen through careful performance analysis or type system design as the preferred method to pass complex floating point values. The initial implementation was wrong and not discovered until it was too late. The reference to support this is that one cannot break the ABI without causing chaos in the ecosystem. Thanks, David > > Thank you > ~Umesh > > > > On Tue, Jun 6, 2023 at 10:16 PM Segher Boessenkool > wrote: > > > > Hi! > > > > On Tue, Jun 06, 2023 at 08:35:22PM +0530, Umesh Kalappa wrote: > > > Hi Adnrew, > > > Thank you for the quick response and for PPC64 too ,we do have > > > mismatches in ABI b/w complex operations like > > > https://godbolt.org/z/bjsYovx4c . > > > > > > Any reason why GCC chose to use GPR 's here ? > > > > What did you expect, what happened instead? Why did you expect that, > > and why then is it an error what did happen? > > > > You used -O0. As long as the code works, all is fine. But unoptimised > > code frequently is hard to read, please use -O2 instead? > > > > As Andrew says, why did you use -m32 for GCC but -m64 for LLVM? It is > > hard to compare those at all! 32-bit PowerPC Linux ABI (based on 32-bit > > PowerPC ELF ABI from 1995, BE version) vs. 64-bit ELFv2 ABI from 2015 > > (LE version). > > > > > > Segher >
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
On Tue, Jun 6, 2023 at 11:38 AM David Brown via Gcc wrote: > On 06/06/2023 14:53, Paul Smith wrote: > > On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote: > >> Sorry for my outburst, to the rest of this list. I can no longer stay > >> silent and watch these little shits bully people who are too kind to > >> fire back with the same kind of venom in their words. > > > > Many of us have had Dave in our killfiles for a long time already. I > > recommend you (and everyone else) do the same. You won't miss out on > > any information of any use to anyone: he apparently just enjoys making > > other people angry. > > > > I'm quite serious: it's so not worth the mental energy to even read his > > messages, much less to reply to him. Arguing with "people who are > > wrong on the internet" can be cathartic but this is not arguing, it's > > just stabbing yourself in the eye with a pencil. Don't play. > > > > If a poster is causing enough aggravation that a large number of people > have killfiled him, is there a process for banning him from the list? > That is surely a better solution than having many people individually > killfiling him? I would assume those with the power to blacklist > addresses from the mailing list do not do so lightly, and that there is > a procedure for it. > The GNU Toolchain leadership has blacklisted people in the past, but we have used the power sparingly. The behavior of the individual attracts attention, albeit negative, while not effectively accomplishing what he purports to desire. The recommended solution is to ignore the poster instead of trying to encourage him to communicate more effectively. Thanks, David
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
David Edelsohn writes: > The GNU Toolchain leadership has blacklisted people in the past, but we > have used the power sparingly. > > The behavior of the individual attracts attention, albeit negative, while > not effectively accomplishing what he purports to desire. The recommended > solution is to ignore the poster instead of trying to encourage him to > communicate more effectively. IMO, the sparing usage of this power on what are clearly purely abusive participants can only drive away users and contributors. It seems reasonable to establish a process for dealing with incidents like this (and appeals, of course), especially given their frecency. -- Arsen Arsenović signature.asc Description: PGP signature
Support in the GCC(/C++) test suites for '-fno-exceptions'
Hi!
This issue comes up in context of me working on C++ support for GCN and
nvptx target. Those targets shall default to '-fno-exceptions' -- or,
"in other words", '-fexceptions' is not supported. (Details omitted
here.)
It did seem clear to me that with such a configuration it'll be hard to
get clean test results. Then I found code in
'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
# If exceptions are disabled, mark tests expecting exceptions to be enabled
# as unsupported.
if { ![check_effective_target_exceptions_enabled] } {
if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled" $text] {
return "::unsupported::exception handling disabled"
}
..., which, in a way, sounds as if the test suite generally is meant to
produce useful results for '-fno-exceptions', nice surprise!
Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
..., I find that indeed this does work for a lot of test cases, where we
then get (random example):
PASS: g++.dg/coroutines/pr99710.C (test for errors, line 23)
-PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
+UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling disabled
..., due to:
[...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
+[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
disabled, use '-fexceptions' to enable
[...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are not
permitted in handlers
compiler exited with status 1
But, we're nowhere near clean test results: PASS -> FAIL as well as
XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
precluding other diagnostics seems to be one major issue.
Is there interest in me producing the obvious (?) changes to those test
cases, such that compiler g++ as well as target library libstdc++ test
results are reasonably clean? (If you think that's all "wasted effort",
then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
that appear in combination with
'UNSUPPORTED: [...]: exception handling disabled'.)
For a start, the libstdc++ test suite needs
'UNSUPPORTED: [...]: exception handling disabled' enabled/ported. (I'll
do that.) Otherwise, a number of test cases need DejaGnu directives
conditionalized on 'target exceptions_enabled'. (Or,
'error: exception handling disabled' made a "really late" diagnostic, so
that it doesn't preclude other diagnostics? I'll have a look. Well,
maybe something like: in fact do not default to '-fno-exceptions', but
instead emit 'error: exception handling disabled' only if in a "really
late" pass we run into exceptions-related constructs that we cannot
support. That'd also avoid PASS -> UNSUPPORTED "regressions" when
exception handling in fact gets optimized away, for example. I like that
idea, conceptually -- but is it feasible to implement..?)
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Re: Support in the GCC(/C++) test suites for '-fno-exceptions'
On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
wrote:
> Hi!
>
> This issue comes up in context of me working on C++ support for GCN and
> nvptx target. Those targets shall default to '-fno-exceptions' -- or,
> "in other words", '-fexceptions' is not supported. (Details omitted
> here.)
>
> It did seem clear to me that with such a configuration it'll be hard to
> get clean test results. Then I found code in
> 'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-prune':
>
> # If exceptions are disabled, mark tests expecting exceptions to be
> enabled
> # as unsupported.
> if { ![check_effective_target_exceptions_enabled] } {
> if [regexp "(^|\n)\[^\n\]*: error: exception handling disabled"
> $text] {
> return "::unsupported::exception handling disabled"
> }
>
> ..., which, in a way, sounds as if the test suite generally is meant to
> produce useful results for '-fno-exceptions', nice surprise!
>
> Running x86_64-pc-linux-gnu (not yet GCN, nvptx) 'make check' with:
>
> RUNTESTFLAGS='--target_board=unix/-fno-exceptions\{,-m32\}'
>
> ..., I find that indeed this does work for a lot of test cases, where we
> then get (random example):
>
> PASS: g++.dg/coroutines/pr99710.C (test for errors, line 23)
> -PASS: g++.dg/coroutines/pr99710.C (test for excess errors)
> +UNSUPPORTED: g++.dg/coroutines/pr99710.C: exception handling disabled
>
> ..., due to:
>
> [...]/g++.dg/coroutines/pr99710.C: In function 'task my_coro()':
> +[...]/g++.dg/coroutines/pr99710.C:18:10: error: exception handling
> disabled, use '-fexceptions' to enable
> [...]/g++.dg/coroutines/pr99710.C:23:7: error: await expressions are
> not permitted in handlers
> compiler exited with status 1
>
> But, we're nowhere near clean test results: PASS -> FAIL as well as
> XFAIL -> XPASS regressions, due to 'error: exception handling disabled'
> precluding other diagnostics seems to be one major issue.
>
> Is there interest in me producing the obvious (?) changes to those test
> cases, such that compiler g++ as well as target library libstdc++ test
> results are reasonably clean? (If you think that's all "wasted effort",
> then I suppose I'll just locally ignore any FAILs/XPASSes/UNRESOLVEDs
> that appear in combination with
> 'UNSUPPORTED: [...]: exception handling disabled'.)
>
I would welcome that for libstdc++. I do sometimes run the libstdc++ tests
with "unusual" options, like -fno-exceptions and -fno-rtti (e.g. today I've
been fixing FAILs that only happen with -fexcess-precision=standard). I
just manually ignore the tests that fail for -fno-exceptions, but it would
be great if they were automatically skipped as UNSUPPORTED.
We already have a handful of tests that use #if __cpp_exceptions to make
those parts conditional on exception support. We also have exactly one test
that is currently UNSUPPORTED when -fno-exceptions is used:
testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:// {
dg-skip-if "" { *-*-* } { "-fno-exceptions" } }
That could be changed to use an effective target keyword instead.
To add an effective-target to the libstdc++ testsuite would be as simple as:
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1421,6 +1421,14 @@ proc check_effective_target_tzdb { } {
}]
}
+# Return 1 if exception handling is enabled.
+proc check_effective_target_exceptions_enabled { } {
+return [check_v3_target_prop_cached et_eh {
+ set cond "defined __cpp_exceptions"
+ return [v3_check_preprocessor_condition eh $cond]
+}]
+}
+
set additional_prunes ""
if { [info exists env(GCC_RUNTEST_PARALLELIZE_DIR)] \
However, you probably want to add it to the main testsuite instead, which
would be a little more involved (the v3_check_preprocessor_condition proc
is specific to libstdc++).
> For a start, the libstdc++ test suite needs
> 'UNSUPPORTED: [...]: exception handling disabled' enabled/ported. (I'll
> do that.) Otherwise, a number of test cases need DejaGnu directives
> conditionalized on 'target exceptions_enabled'. (Or,
> 'error: exception handling disabled' made a "really late" diagnostic, so
> that it doesn't preclude other diagnostics? I'll have a look. Well,
> maybe something like: in fact do not default to '-fno-exceptions', but
> instead emit 'error: exception handling disabled' only if in a "really
> late" pass we run into exceptions-related constructs that we cannot
> support. That'd also avoid PASS -> UNSUPPORTED "regressions" when
> exception handling in fact gets optimized away, for example. I like that
> idea, conceptually -- but is it feasible to implement..?)
>
IMHO just defining an effective target keyword and then using that in test
selectors seems simpler, and doesn't require changes to the compiler, just
the tests.
[PATCH v6 0/4] P1689R5 support
Hi, This patch series adds initial support for ISO C++'s [P1689R5][], a format for describing C++ module requirements and provisions based on the source code. This is required because compiling C++ with modules is not embarrassingly parallel and need to be ordered to ensure that `import some_module;` can be satisfied in time by making sure that any TU with `export import some_module;` is compiled first. [P1689R5]: https://isocpp.org/files/papers/P1689R5.html I've also added patches to include imported module CMI files and the module mapper file as dependencies of the compilation. I briefly looked into adding dependencies on response files as well, but that appeared to need some code contortions to have a `class mkdeps` available before parsing the command line or to keep the information around until one was made. I'd like feedback on the approach taken here with respect to the user-visible flags. I'll also note that header units are not supported at this time because the current `-E` behavior with respect to `import ;` is to search for an appropriate `.gcm` file which is not something such a "scan" can support. A new mode will likely need to be created (e.g., replacing `-E` with `-fc++-module-scanning` or something) where headers are looked up "normally" and processed only as much as scanning requires. FWIW, Clang as taken an alternate approach with its `clang-scan-deps` tool rather than using the compiler directly. Thanks, --Ben --- v5 -> v6: - rebase onto `master` (585c660f041 (reload1: Change return type of predicate function from int to bool, 2023-06-06)) - fix crash related to reporting imported CMI files as dependencies - rework utf-8 validity to patch the new `cpp_valid_utf8_p` function instead of the core utf-8 decoding routine to reject invalid codepoints (preserves higher-level error detection of invalid utf-8) - harmonize of `fdeps` spelling in flags, variables, comments, etc. - rename `-fdeps-output=` to `-fdeps-target=` v4 -> v5: - add dependency tracking for imported modules to `-MF` - add dependency tracking for static module mapper files given to `-fmodule-mapper=` v3 -> v4: - add missing spaces between function names and arguments v2 -> v3: - changelog entries moved to commit messages - documentation updated/added in the UTF-8 routine editing v1 -> v2: - removal of the `deps_write(extra)` parameter to option-checking where ndeeded - default parameter of `cpp_finish(fdeps_stream = NULL)` - unification of libcpp UTF-8 validity functions from v1 - test cases for flag parsing states (depflags-*) and p1689 output (p1689-*) Ben Boeckel (4): libcpp: reject codepoints above 0x10 p1689r5: initial support c++modules: report imported CMI files as dependencies c++modules: report module mapper files as a dependency gcc/c-family/c-opts.cc| 40 +++- gcc/c-family/c.opt| 12 + gcc/cp/mapper-client.cc | 4 + gcc/cp/mapper-client.h| 1 + gcc/cp/module.cc | 24 +- gcc/doc/invoke.texi | 15 ++ gcc/testsuite/g++.dg/modules/depflags-f-MD.C | 2 + gcc/testsuite/g++.dg/modules/depflags-f.C | 1 + gcc/testsuite/g++.dg/modules/depflags-fi.C| 3 + gcc/testsuite/g++.dg/modules/depflags-fj-MD.C | 3 + gcc/testsuite/g++.dg/modules/depflags-fj.C| 4 + .../g++.dg/modules/depflags-fjo-MD.C | 4 + gcc/testsuite/g++.dg/modules/depflags-fjo.C | 5 + gcc/testsuite/g++.dg/modules/depflags-fo-MD.C | 3 + gcc/testsuite/g++.dg/modules/depflags-fo.C| 4 + gcc/testsuite/g++.dg/modules/depflags-j-MD.C | 2 + gcc/testsuite/g++.dg/modules/depflags-j.C | 3 + gcc/testsuite/g++.dg/modules/depflags-jo-MD.C | 3 + gcc/testsuite/g++.dg/modules/depflags-jo.C| 4 + gcc/testsuite/g++.dg/modules/depflags-o-MD.C | 2 + gcc/testsuite/g++.dg/modules/depflags-o.C | 3 + gcc/testsuite/g++.dg/modules/modules.exp | 1 + gcc/testsuite/g++.dg/modules/p1689-1.C| 18 ++ gcc/testsuite/g++.dg/modules/p1689-1.exp.json | 27 +++ gcc/testsuite/g++.dg/modules/p1689-2.C| 16 ++ gcc/testsuite/g++.dg/modules/p1689-2.exp.json | 16 ++ gcc/testsuite/g++.dg/modules/p1689-3.C| 14 ++ gcc/testsuite/g++.dg/modules/p1689-3.exp.json | 16 ++ gcc/testsuite/g++.dg/modules/p1689-4.C| 14 ++ gcc/testsuite/g++.dg/modules/p1689-4.exp.json | 14 ++ gcc/testsuite/g++.dg/modules/p1689-5.C| 14 ++ gcc/testsuite/g++.dg/modules/p1689-5.exp.json | 14 ++ gcc/testsuite/g++.dg/modules/test-p1689.py| 222 ++ gcc/testsuite/lib/modules.exp | 71 ++ libcpp/charset.cc | 7 + libcpp/include/cpplib.h | 12 +- libcpp/include/mkdeps.h | 17 +- libcpp/init.cc| 13 +- libcpp/mkdeps.cc | 149 +++
[PATCH v6 3/4] c++modules: report imported CMI files as dependencies
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
Signed-off-by: Ben Boeckel
---
gcc/cp/module.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index c80f139eb82..e88ce0a1818 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -18966,6 +18966,9 @@ module_state::do_import (cpp_reader *reader, bool
outermost)
dump () && dump ("CMI is %s", file);
if (note_module_cmi_yes || inform_cmi_p)
inform (loc, "reading CMI %qs", file);
+ /* Add the CMI file to the dependency tracking. */
+ if (cpp_get_deps (reader))
+ deps_add_dep (cpp_get_deps (reader), file);
fd = open (file, O_RDONLY | O_CLOEXEC | O_BINARY);
e = errno;
}
--
2.40.1
[PATCH v6 1/4] libcpp: reject codepoints above 0x10FFFF
Unicode does not support such values because they are unrepresentable in UTF-16. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10. UTF-16 does not support such codepoints and therefore all Unicode rejects such values. Signed-off-by: Ben Boeckel --- libcpp/charset.cc | 7 +++ 1 file changed, 7 insertions(+) diff --git a/libcpp/charset.cc b/libcpp/charset.cc index d7f323b2cd5..3b34d804cf1 100644 --- a/libcpp/charset.cc +++ b/libcpp/charset.cc @@ -1886,6 +1886,13 @@ cpp_valid_utf8_p (const char *buffer, size_t num_bytes) int err = one_utf8_to_cppchar (&iter, &bytesleft, &cp); if (err) return false; + + /* Additionally, Unicode declares that all codepoints above 0010 are +invalid because they cannot be represented in UTF-16. + +Reject such values.*/ + if (cp >= 0x10) + return false; } /* No problems encountered. */ return true; -- 2.40.1
[PATCH v6 2/4] p1689r5: initial support
This patch implements support for [P1689R5][] to communicate to a build system the C++20 module dependencies to build systems so that they may build `.gcm` files in the proper order. Support is communicated through the following three new flags: - `-fdeps-format=` specifies the format for the output. Currently named `p1689r5`. - `-fdeps-file=` specifies the path to the file to write the format to. - `-fdeps-target=` specifies the `.o` that will be written for the TU that is scanned. This is required so that the build system can correlate the dependency output with the actual compilation that will occur. CMake supports this format as of 17 Jun 2022 (to be part of 3.25.0) using an experimental feature selection (to allow for future usage evolution without committing to how it works today). While it remains experimental, docs may be found in CMake's documentation for experimental features. Future work may include using this format for Fortran module dependencies as well, however this is still pending work. [P1689R5]: https://isocpp.org/files/papers/P1689R5.html [cmake-experimental]: https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/dev/experimental.rst TODO: - header-unit information fields Header units (including the standard library headers) are 100% unsupported right now because the `-E` mechanism wants to import their BMIs. A new mode (i.e., something more workable than existing `-E` behavior) that mocks up header units as if they were imported purely from their path and content would be required. - non-utf8 paths The current standard says that paths that are not unambiguously represented using UTF-8 are not supported (because these cases are rare and the extra complication is not worth it at this time). Future versions of the format might have ways of encoding non-UTF-8 paths. For now, this patch just doesn't support non-UTF-8 paths (ignoring the "unambiguously represetable in UTF-8" case). - figure out why junk gets placed at the end of the file Sometimes it seems like the file gets a lot of `NUL` bytes appended to it. It happens rarely and seems to be the result of some `ftruncate`-style call which results in extra padding in the contents. Noting it here as an observation at least. libcpp/ * include/cpplib.h: Add cpp_deps_format enum. (cpp_options): Add format field (cpp_finish): Add dependency stream parameter. * include/mkdeps.h (deps_add_module_target): Add new preprocessor parameter used for C++ module tracking. * init.cc (cpp_finish): Add new preprocessor parameter used for C++ module tracking. * mkdeps.cc (mkdeps): Implement P1689R5 output. gcc/ * doc/invoke.texi: Document -fdeps-format=, -fdeps-file=, and -fdeps-target= flags. gcc/c-family/ * c-opts.cc (c_common_handle_option): Add fdeps_file variable and -fdeps-format=, -fdeps-file=, and -fdeps-target= parsing. * c.opt: Add -fdeps-format=, -fdeps-file=, and -fdeps-target= flags. gcc/cp/ * module.cc (preprocessed_module): Pass whether the module is exported to dependency tracking. gcc/testsuite/ * g++.dg/modules/depflags-f-MD.C: New test. * g++.dg/modules/depflags-f.C: New test. * g++.dg/modules/depflags-fi.C: New test. * g++.dg/modules/depflags-fj-MD.C: New test. * g++.dg/modules/depflags-fj.C: New test. * g++.dg/modules/depflags-fjo-MD.C: New test. * g++.dg/modules/depflags-fjo.C: New test. * g++.dg/modules/depflags-fo-MD.C: New test. * g++.dg/modules/depflags-fo.C: New test. * g++.dg/modules/depflags-j-MD.C: New test. * g++.dg/modules/depflags-j.C: New test. * g++.dg/modules/depflags-jo-MD.C: New test. * g++.dg/modules/depflags-jo.C: New test. * g++.dg/modules/depflags-o-MD.C: New test. * g++.dg/modules/depflags-o.C: New test. * g++.dg/modules/p1689-1.C: New test. * g++.dg/modules/p1689-1.exp.json: New test expectation. * g++.dg/modules/p1689-2.C: New test. * g++.dg/modules/p1689-2.exp.json: New test expectation. * g++.dg/modules/p1689-3.C: New test. * g++.dg/modules/p1689-3.exp.json: New test expectation. * g++.dg/modules/p1689-4.C: New test. * g++.dg/modules/p1689-4.exp.json: New test expectation. * g++.dg/modules/p1689-5.C: New test. * g++.dg/modules/p1689-5.exp.json: New test expectation. * g++.dg/modules/modules.exp: Load new P1689 library routines. * g++.dg/modules/test-p1689.py: New tool for validating P1689 output. * lib/modules.exp: Support for validating P1689 outputs. Signed-off-by: Ben Boeckel --- gcc/c-family/c-opts.cc| 40 +++- gcc/c-family/c.opt| 12 + gcc/cp/module.cc | 3 +- gcc/doc/invoke.texi | 15 ++ gcc/testsuite/g++.dg/mod
[PATCH v6 4/4] c++modules: report module mapper files as a dependency
It affects the build, and if used as a static file, can reliably be
tracked using the `-MF` mechanism.
gcc/cp/:
* mapper-client.cc, mapper-client.h (open_module_client): Accept
dependency tracking and track module mapper files as
dependencies.
* module.cc (make_mapper, get_mapper): Pass the dependency
tracking class down.
Signed-off-by: Ben Boeckel
---
gcc/cp/mapper-client.cc | 4
gcc/cp/mapper-client.h | 1 +
gcc/cp/module.cc| 18 +-
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/gcc/cp/mapper-client.cc b/gcc/cp/mapper-client.cc
index 39e80df2d25..0ce5679d659 100644
--- a/gcc/cp/mapper-client.cc
+++ b/gcc/cp/mapper-client.cc
@@ -34,6 +34,7 @@ along with GCC; see the file COPYING3. If not see
#include "diagnostic-core.h"
#include "mapper-client.h"
#include "intl.h"
+#include "mkdeps.h"
#include "../../c++tools/resolver.h"
@@ -132,6 +133,7 @@ spawn_mapper_program (char const **errmsg, std::string
&name,
module_client *
module_client::open_module_client (location_t loc, const char *o,
+ class mkdeps *deps,
void (*set_repo) (const char *),
char const *full_program_name)
{
@@ -285,6 +287,8 @@ module_client::open_module_client (location_t loc, const
char *o,
errmsg = "opening";
else
{
+ /* Add the mapper file to the dependency tracking. */
+ deps_add_dep (deps, name.c_str ());
if (int l = r->read_tuple_file (fd, ident, false))
{
if (l > 0)
diff --git a/gcc/cp/mapper-client.h b/gcc/cp/mapper-client.h
index b32723ce296..a3b0b8adc51 100644
--- a/gcc/cp/mapper-client.h
+++ b/gcc/cp/mapper-client.h
@@ -55,6 +55,7 @@ public:
public:
static module_client *open_module_client (location_t loc, const char *option,
+ class mkdeps *,
void (*set_repo) (const char *),
char const *);
static void close_module_client (location_t loc, module_client *);
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index e88ce0a1818..9dbb53d2aaf 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -3969,12 +3969,12 @@ static GTY(()) vec
*partial_specializations;
/* Our module mapper (created lazily). */
module_client *mapper;
-static module_client *make_mapper (location_t loc);
-inline module_client *get_mapper (location_t loc)
+static module_client *make_mapper (location_t loc, class mkdeps *deps);
+inline module_client *get_mapper (location_t loc, class mkdeps *deps)
{
auto *res = mapper;
if (!res)
-res = make_mapper (loc);
+res = make_mapper (loc, deps);
return res;
}
@@ -14031,7 +14031,7 @@ get_module (const char *ptr)
/* Create a new mapper connecting to OPTION. */
module_client *
-make_mapper (location_t loc)
+make_mapper (location_t loc, class mkdeps *deps)
{
timevar_start (TV_MODULE_MAPPER);
const char *option = module_mapper_name;
@@ -14039,7 +14039,7 @@ make_mapper (location_t loc)
option = getenv ("CXX_MODULE_MAPPER");
mapper = module_client::open_module_client
-(loc, option, &set_cmi_repo,
+(loc, option, deps, &set_cmi_repo,
(save_decoded_options[0].opt_index == OPT_SPECIAL_program_name)
&& save_decoded_options[0].arg != progname
? save_decoded_options[0].arg : nullptr);
@@ -19504,7 +19504,7 @@ maybe_translate_include (cpp_reader *reader, line_maps
*lmaps, location_t loc,
dump.push (NULL);
dump () && dump ("Checking include translation '%s'", path);
- auto *mapper = get_mapper (cpp_main_loc (reader));
+ auto *mapper = get_mapper (cpp_main_loc (reader), cpp_get_deps (reader));
size_t len = strlen (path);
path = canonicalize_header_name (NULL, loc, true, path, len);
@@ -19620,7 +19620,7 @@ module_begin_main_file (cpp_reader *reader, line_maps
*lmaps,
static void
name_pending_imports (cpp_reader *reader)
{
- auto *mapper = get_mapper (cpp_main_loc (reader));
+ auto *mapper = get_mapper (cpp_main_loc (reader), cpp_get_deps (reader));
if (!vec_safe_length (pending_imports))
/* Not doing anything. */
@@ -20090,7 +20090,7 @@ init_modules (cpp_reader *reader)
if (!flag_module_lazy)
/* Get the mapper now, if we're not being lazy. */
-get_mapper (cpp_main_loc (reader));
+get_mapper (cpp_main_loc (reader), cpp_get_deps (reader));
if (!flag_preprocess_only)
{
@@ -20300,7 +20300,7 @@ late_finish_module (cpp_reader *reader,
module_processing_cookie *cookie,
if (!errorcount)
{
- auto *mapper = get_mapper (cpp_main_loc (reader));
+ auto *mapper = get_mapper (cpp_main_loc (reader), cpp_get_deps (reader));
mapper->ModuleCompiled (state->get_flatname ());
}
else if (cookie->cmi_name)
--
2.40.1
