[C++] [Coroutines] Does GCC want to support `-fno-coroutines`?
Hi, We're discussing to implement `-fno-coroutines` in clang so that we can disable the coroutine feature with C++ standard higher than 20. A full discussion can be found here: https://reviews.llvm.org/D156247. A major motivation for us to do this is to keep consistency with GCC. However, we don't find `-fno-coroutines` in https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/C_002b_002b-Dialect-Options.html#index-fcoroutines. Then we're not sure if GCC intends to support it. And we want to ask opinions from GCC developers for `-fno-coroutines`. Thanks, Chuanqi
Re: Naming flag for specifying the output file name for Binary Module Interface files
Hi Nathan,
> But how do they specify the mapping from module/header-unit name to CMI, so
> that
> imports work?
>
> Is this really a clang-specific mechanism, as it has no module mapper ATM
> (IIUC)?
Yes, clang doesn't have a module mapper. And I remember Iain said he want to
introduce these options in GCC.
Thanks,
Chuanqi
--
From:Nathan Sidwell
Send Time:2022年12月15日(星期四) 06:29
To:David Blaikie ; chuanqi.xcq
Cc:Iain Sandoe ; GCC Development ; Nathan
Sidwell ; Jonathan Wakely ;
ben.boeckel
Subject:Re: Naming flag for specifying the output file name for Binary Module
Interface files
I'm missing something from this discussion. IIUC the claim is that these 2 new
options -fmodule-output{,=NAME} are for build systems that want to specify the
module output file.
But how do they specify the mapping from module/header-unit name to CMI, so
that
imports work?
Is this really a clang-specific mechanism, as it has no module mapper ATM
(IIUC)?
nathan
--
Nathan Sidwell
Re: Naming flag for specifying the output file name for Binary Module Interface files
Hi David, > I think Nathan might've been asking not only about what currently happens, but what we think should happen? Yes. > Is that consistent with `-o`? (I assume so, but don't know - I guess there aren't many cases where `-o` is unused (maybe `-fsyntax-only`), so that behavior might be a bit less well specified) `-o` wouldn't emit a warning if it is not used. (with `-fsyntax-only` for example). Since we want to make the behavior of `-fmodule-output` to be consistent with `-o`. I've changed the behavior in https://reviews.llvm.org/D140001. > This seems surprising/possibly wrong to me - do we have precedent from other flags to draw from? I feel it makes sense since `-fmodule-output=` will provide more information than `-fmodule-output`. So it is naturally to me that `-fmodule-output=` has higher priority. For examples, I don't enumerate all the flags but I find the following cases in minutes: - `-fpack-struct=` has higher priority than `-fpack-struct`. - `-fsave-optimization-record=` has higher priority than `-fsave-optimization-record=`. - `-ftime-report=` has higher priority than `-ftime-report`. - `-ftime-trace=` has higher priority than `-ftime-trace`. So I think the bahavior should be correct. Thanks, Chuanqi -- From:David Blaikie Send Time:2022年12月13日(星期二) 23:56 To:chuanqi.xcq Cc:Iain Sandoe ; GCC Development ; Nathan Sidwell ; Jonathan Wakely ; ben.boeckel Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files I think Nathan might've been asking not only about what currently happens, but what we think should happen? On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq wrote: > > Hi Nathan, > > > 1) Are these flags silently ignored, if no module output is to be > > generated? Or is some kind of diagnostic generated? > > Currently, clang will generate the unused-command-line-argument warning for > this case: > > ``` > argument unused during compilation: '-fmodule-output' > [-Wunused-command-line-argument] > ``` Is that consistent with `-o`? (I assume so, but don't know - I guess there aren't many cases where `-o` is unused (maybe `-fsyntax-only`), so that behavior might be a bit less well specified) > > 2) what happens if you specify both -- do you get two outputs, a > > diagnostic, or > is one silently selected? > > If someone specify both `-fmodule-output` and `-fmodule-output=/path`, > the `-fmodule-output=/path` will be selected always no matter what the order > is. This seems surprising/possibly wrong to me - do we have precedent from other flags to draw from? > And if multiple `-fmodule-output=/path` are specified, the last one will be > selected. > > > 3) What is the behaviour if compilation fails? Does nothing happen to the > > file > indicated (potentially leaving an older version there), or does the equivalent > of 'rm -f $MODULE.pcm' happen? > > The module file will be deleted. The behavior is the same with `-o`. > > Thanks, > Chuanqi > > > -- > From:Nathan Sidwell > Send Time:2022年12月12日(星期一) 22:30 > To:Iain Sandoe ; GCC Development > Cc:Nathan Sidwell ; Jonathan Wakely > ; David Blaikie ; ben.boeckel > ; chuanqi.xcq > Subject:Re: Naming flag for specifying the output file name for Binary Module > Interface files > > On 12/9/22 12:33, Iain Sandoe wrote: > > Hello all. > > > >> On 9 Dec 2022, at 01:58, chuanqi.xcq wrote: > >> > >> It looks like `-fmodule-file` is better from the discussion. So let's take > >> it. Thanks for everyone here > > > > So FAOD (after this discussion) Chuanqi's current patchset implements the > > following in clang: > > > > -fmodule-output > > > > - this causes the BMI to be saved in the CWG with the basename of the > > source file and a suffix of .pcm. > > > > -fmodule-output= > > > > - this causes the BMI to be saved at the path specified. > > > > 1) Are these flags silently ignored, if no module output is to be generated? > Or > is some kind of diagnostic generated? > > 2) what happens if you specify both -- do you get two outputs, a diagnostic, > or > is one silently selected? > > 3) What is the behaviour if compilation fails? Does nothing happen to the file > indicated (potentially leaving an older version there), or does the equivalent > of 'rm -f $MODULE.pcm' happen? > > nathan > > -- > Nathan Sidwell > >
Re: Naming flag for specifying the output file name for Binary Module Interface files
Hi Nathan, > 1) Are these flags silently ignored, if no module output is to be generated? > Or is some kind of diagnostic generated? Currently, clang will generate the unused-command-line-argument warning for this case: ``` argument unused during compilation: '-fmodule-output' [-Wunused-command-line-argument] ``` > 2) what happens if you specify both -- do you get two outputs, a diagnostic, > or is one silently selected? If someone specify both `-fmodule-output` and `-fmodule-output=/path`, the `-fmodule-output=/path` will be selected always no matter what the order is. And if multiple `-fmodule-output=/path` are specified, the last one will be selected. > 3) What is the behaviour if compilation fails? Does nothing happen to the > file indicated (potentially leaving an older version there), or does the equivalent of 'rm -f $MODULE.pcm' happen? The module file will be deleted. The behavior is the same with `-o`. Thanks, Chuanqi -- From:Nathan Sidwell Send Time:2022年12月12日(星期一) 22:30 To:Iain Sandoe ; GCC Development Cc:Nathan Sidwell ; Jonathan Wakely ; David Blaikie ; ben.boeckel ; chuanqi.xcq Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files On 12/9/22 12:33, Iain Sandoe wrote: > Hello all. > >> On 9 Dec 2022, at 01:58, chuanqi.xcq wrote: >> >> It looks like `-fmodule-file` is better from the discussion. So let's take >> it. Thanks for everyone here > > So FAOD (after this discussion) Chuanqi's current patchset implements the > following in clang: > > -fmodule-output > > - this causes the BMI to be saved in the CWG with the basename of the source > file and a suffix of .pcm. > > -fmodule-output= > > - this causes the BMI to be saved at the path specified. > 1) Are these flags silently ignored, if no module output is to be generated? Or is some kind of diagnostic generated? 2) what happens if you specify both -- do you get two outputs, a diagnostic, or is one silently selected? 3) What is the behaviour if compilation fails? Does nothing happen to the file indicated (potentially leaving an older version there), or does the equivalent of 'rm -f $MODULE.pcm' happen? nathan -- Nathan Sidwell
Re: Naming flag for specifying the output file name for Binary Module Interface files
It looks like `-fmodule-file` is better from the discussion. So let's take it. Thanks for everyone here~ Thanks, Chuanqi -- From:Nathan Sidwell Send Time:2022年12月8日(星期四) 01:00 To:Iain Sandoe ; GCC Development Cc:Jonathan Wakely ; chuanqi.xcq ; David Blaikie ; ben.boeckel Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files On 12/7/22 11:58, Iain Sandoe wrote: > > >> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc wrote: >> >> On 12/7/22 11:18, Iain Sandoe wrote: >> >>> I think it is reasonable to include c++ in the spelling, since other >>> languages supported by >>> GCC (and clang in due course) have modules. >> >> I disagree (about the reasonableness part). Other languages have modules, >> true, but if they want to name the output file, why not have the same option >> spelling? >> >> I.e. why are we considering: >> >> $compiler -fc++-module-file=bob foo.cc >> $compiler -ffortran-module-file=bob foo.f77 >> >> The language is being selected implicitly by the file suffix (or explictly >> via -X$lang). There's no reason for some other option controlling an aspect >> of the compilation to rename the language. We don't do it for >> language-specific warning options, and similar. (i.e. no >> -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs >> -Wc-extra[*] > > Fair points. > > Unfortunately (in case it has not already been mentioned in this thread) > ‘-fmodule-file=‘ is already taken and it means an input, not an output. So, > whatever we choose it needs to be distinct from that. Yes, that's why I suggested -fmodule-output= nathan -- Nathan Sidwell
Re: Naming flag for specifying the output file name for Binary Module Interface files
Hi Nathan, > 1) 'save' -- does it *cause* the bmi to be saved, or is that actually > controlled by other options? (I suspect the latter) Yes, it causes the bmi to be saved. In fact, when we add `-save-temps` option in clang and we compile a module unit, we'll see the preprocessed output, the bmi, the LLVM IR and the assembly code. So the semantics of the option `-fsave-std-cxx-module-file=` is to save the bmi to the specified output. > 2) 'std' -- why is this there. There's only one C++ std, with different variants thereof being temporally selectable. Since in clang we have clang c++ modules extension. It is not std one. And we have objective C modules in clang too. So we said `std-cxx`. > 3) 'cxx' -- why not 'c++'? Let's not let this transliteration of + to x get into the options -- it hasn't in '-std=c++20' for example. `c++` should be good advice. > Might I suggest something more like '-fmodule-output='? That collates nicely > with other -fmodule-$FOO options, and the 'output' part is similar to the > mnemonic '-o' for the regular output file naming. My previous concern was there were tons of `-fmodule-*` options in clang, which are not standard c++ modules. So I was afraid the name `-fmodule-output` may be confusing. So I proposed `-fsave-std-cxx-module-file=`. But I didn't recognize we need to keep the option consistency between gcc and clang until Iain mentioned it. It is obviously redundant for gcc to keep the `-std-cxx` prefix in the name. Personally, I feel the clearity of the option name is more important than the length. Since I think such flags will be mainly used by build systems/build scripts so such flags wouldn't be typed frequently. But command line interface consistency is very important too. I know tools writer will hate to write tons of codes like: ``` if compiler == gcc ... elif compiler == clang ... ``` So I think the conclusion may be: (1) If gcc can tolerate the lengthy `-fsave-std-c++-module-file=` name, it would be best for clang. (2) If (1) is not acceptable and we love to keep the command line consistency, I think clang can use '-fmodule-output=' as long as we make it clear in the document. It will be confusing but it may be the cost clang need to pay for the extension (so I'll vote against strongly if someone want to add some other extensions) > (Incidentally, as clang treats the BMI as a step in the compilation pipeline, what do you do if you just want compilation to produce the BMI and no assembly artifact? Does '-o' name the BMI in that case?) In this case, we can use `--precompile` option in the command line. For example, we can compile HelloWorld in clang in the following command lines now: ``` $ clang++ -std=c++20 Hello.cppm --precompile -o Hello.pcm $ clang++ -std=c++20 -fprebuilt-module-path=. Hello.pcm -c -o Hello.o ``` If you are interested, you can take a look at: https://clang.llvm.org/docs/StandardCPlusPlusModules.html#quick-start Thanks, Chuanqi -- From:Nathan Sidwell Send Time:2022年12月7日(星期三) 08:35 To:David Blaikie ; gcc Mailing List ; Iain Sandoe ; chuanqi.xcq Subject:Re: Naming flag for specifying the output file name for Binary Module Interface files On 12/6/22 16:03, David Blaikie wrote: > Over in https://reviews.llvm.org/D137059 we're discussing the naming > of a clang flag - would be good to have it be consistent with GCC. > > The functionality is to name the BMI (.pcm in Clang's parlance) output > file when compiling a C++20 module. > > Current proposal is to use `-fsave-std-cxx-module-file=` which is > certainly precise, but maybe a bit verbose. Clang has some other flags > related to modules that skip the std/cxx parts, and are just > `-fmodule-*` or `-fmodules-*`, so there's some precedent for that too. > > Do GCC folks have any veto votes (is the currently proposed name > especially objectionable/wouldn't be acceptable in GCC) or preferences > (suggestions to add to the pool)? I think the suggested option name is problematic for a number of additional reasons: 1) 'save' -- does it *cause* the bmi to be saved, or is that actually controlled by other options? (I suspect the latter) 2) 'std' -- why is this there. There's only one C++ std, with different variants thereof being temporally selectable. 3) 'cxx' -- why not 'c++'? Let's not let this transliteration of + to x get into the options -- it hasn't in '-std=c++20' for example. Might I suggest something more like '-fmodule-output='? That collates nicely with other -fmodule-$FOO options, and the 'output' part is similar to the mnemonic '-o' for the regular output file naming. (Incidentally, as clang treats the BMI as a step in the compilation pipeline, what do you do if you just want compilation to produce the BMI and no assembly artifact? Does '-o' name the BMI in that case?) nathan -- Nathan Sidwell
