Re: -fprofile-update=atomic vs. 32-bit architectures
On 05/12/2022 08:44, Richard Biener wrote:
On Mon, Dec 5, 2022 at 8:26 AM Sebastian Huber
wrote:
On 08/11/2022 11:25, Richard Biener wrote:
It would be great to have a code example for the construction of the "if
(f()) f();".
I think for the function above we need to emit __atomic_fetch_add_8,
not the emulated form because we cannot insert the required control
flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be
lowered after the instrumentation took place.
Would it help to change the
if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED)
== 0)
__atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
__ATOMIC_RELAXED);
into
unsigned int v = __atomic_add_fetch_4 ((unsigned int *) &val, 1,
__ATOMIC_RELAXED)
== 0)
v = (unsigned int)(v == 0);
__atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
__ATOMIC_RELAXED);
that's supposed to add 'v' instead of 1? Possibly use uint32_t here
(aka uint32_type_node).
to get rid of an inserted control flow?
That for sure wouldn't require any changes to how the profile
instrumentation works,
so yes it would be simpler.
Yes, this seems to work. After a bit of trial and error I ended up with
something in gimple_gen_edge_profiler() like this (endian support is
missing):
else if (flag_profile_update == PROFILE_UPDATE_SPLIT_ATOMIC)
{
tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
tree f = builtin_decl_explicit (BUILT_IN_ATOMIC_ADD_FETCH_4);
gcall *stmt1 = gimple_build_call (f, 3, addr, one,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
tree low = create_tmp_var (uint32_type_node);
gimple_call_set_lhs (stmt1, low);
tree is_zero = create_tmp_var (boolean_type_node);
gassign *stmt2 = gimple_build_assign (is_zero, EQ_EXPR, low,
build_zero_cst (uint32_type_node));
tree high_inc = create_tmp_var (uint32_type_node);
gassign *stmt3 = gimple_build_assign (high_inc, COND_EXPR, is_zero,
build_one_cst (uint32_type_node),
build_zero_cst (uint32_type_node));
tree addr_high = create_tmp_var (TREE_TYPE (addr));
gassign *stmt4 = gimple_build_assign (addr_high, addr);
gassign *stmt5 = gimple_build_assign (addr_high, POINTER_PLUS_EXPR,
addr_high,
build_int_cst (size_type_node, 4));
gcall *stmt6 = gimple_build_call (f, 3, addr_high, high_inc,
build_int_cst (integer_type_node,
MEMMODEL_RELAXED));
gsi_insert_on_edge (e, stmt1);
gsi_insert_on_edge (e, stmt2);
gsi_insert_on_edge (e, stmt3);
gsi_insert_on_edge (e, stmt4);
gsi_insert_on_edge (e, stmt5);
gsi_insert_on_edge (e, stmt6);
}
It can be probably simplified. The generated code:
.type f, @function
f:
lui a4,%hi(__gcov0.f)
li a3,1
addia4,a4,%lo(__gcov0.f)
amoadd.w a5,a3,0(a4)
lui a4,%hi(__gcov0.f+4)
addia5,a5,1
seqza5,a5
addia4,a4,%lo(__gcov0.f+4)
amoadd.w zero,a5,0(a4)
li a0,3
ret
looks good for this code:
int f(void)
{
return 3;
}
The loading of the high address could be probably optimized from
lui a4,%hi(__gcov0.f+4)
addia4,a4,%lo(__gcov0.f+4)
to
addia4,a4,4
I wasn't able to figure out how to do this.
--
embedded brains GmbH
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/
Separate warning/error thresholds for -Wfoo=
Greetings, David, community,
I'd like to get your input on how GCC command line interface should support
making a "tiered" warning like -Warray-bounds={1,2} an error for "tier 1"
where fewer false positives are expected, and a plain warning otherwise.
There was a recent thread mentioning the current limitation [1]:
> This also shows nicely why I don't like warnings with levels, what if I want
> -Werror=array-bounds=2 + -Warray-bounds=1?
Also in PR 48088 [2] there was a request to make it work for stack size usage:
> Stumbled on this bug today. I tried to use it in more intricate way:
>
> -Wframe-larger-than=4096 -Werror=frame-larger-than=32768
>
> which would only warn about any stack more than 4096+, but would fail on
> 32768+.
>
> Does it make sense to implement desired behaviour?
> I guess it's not many '>=number' style options in gcc.
A problem with implementing DWIM semantics like above for -Wfoo=k -Werror=foo=n
combination is that technically it changes its current meaning.
If we don't want to risk that, an alternative is to introduce a new option
for selecting error threshold for a tiered warning, for example:
-Warray-bounds=2 -Werror-level=array-bounds=1
Implementation-wise, we would need to extend common.opt language to annotate
which tier is more inclusive (generally smaller 'n' means fewer warnings, but
for -Wstack-usage and -Wstrict-aliasing it's the other way around).
Opinions? Does anybody envision problems with going the DWIM way?
Thanks.
Alexander
[1]
https://inbox.sourceware.org/gcc-patches/2552ab22-916f-d0fe-2c78-d482f6ad8...@lauterbach.com/
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48088#c5
Re: -fprofile-update=atomic vs. 32-bit architectures
On Tue, Dec 6, 2022 at 2:11 PM Sebastian Huber
wrote:
>
> On 05/12/2022 08:44, Richard Biener wrote:
> > On Mon, Dec 5, 2022 at 8:26 AM Sebastian Huber
> > wrote:
> >> On 08/11/2022 11:25, Richard Biener wrote:
> It would be great to have a code example for the construction of the "if
> (f()) f();".
> >>> I think for the function above we need to emit __atomic_fetch_add_8,
> >>> not the emulated form because we cannot insert the required control
> >>> flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be
> >>> lowered after the instrumentation took place.
> >> Would it help to change the
> >>
> >> if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED)
> >> == 0)
> >> __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
> >> __ATOMIC_RELAXED);
> >>
> >> into
> >>
> >> unsigned int v = __atomic_add_fetch_4 ((unsigned int *) &val, 1,
> >> __ATOMIC_RELAXED)
> >> == 0)
> >> v = (unsigned int)(v == 0);
> >> __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1,
> >> __ATOMIC_RELAXED);
> > that's supposed to add 'v' instead of 1? Possibly use uint32_t here
> > (aka uint32_type_node).
> >
> >> to get rid of an inserted control flow?
> > That for sure wouldn't require any changes to how the profile
> > instrumentation works,
> > so yes it would be simpler.
>
> Yes, this seems to work. After a bit of trial and error I ended up with
> something in gimple_gen_edge_profiler() like this (endian support is
> missing):
>
>else if (flag_profile_update == PROFILE_UPDATE_SPLIT_ATOMIC)
> {
>tree addr = tree_coverage_counter_addr (GCOV_COUNTER_ARCS, edgeno);
>tree f = builtin_decl_explicit (BUILT_IN_ATOMIC_ADD_FETCH_4);
>gcall *stmt1 = gimple_build_call (f, 3, addr, one,
> build_int_cst (integer_type_node,
> MEMMODEL_RELAXED));
>tree low = create_tmp_var (uint32_type_node);
>gimple_call_set_lhs (stmt1, low);
>tree is_zero = create_tmp_var (boolean_type_node);
>gassign *stmt2 = gimple_build_assign (is_zero, EQ_EXPR, low,
> build_zero_cst
> (uint32_type_node));
>tree high_inc = create_tmp_var (uint32_type_node);
>gassign *stmt3 = gimple_build_assign (high_inc, COND_EXPR, is_zero,
> build_one_cst (uint32_type_node),
> build_zero_cst
> (uint32_type_node));
>tree addr_high = create_tmp_var (TREE_TYPE (addr));
>gassign *stmt4 = gimple_build_assign (addr_high, addr);
>gassign *stmt5 = gimple_build_assign (addr_high, POINTER_PLUS_EXPR,
> addr_high,
> build_int_cst (size_type_node,
> 4));
>gcall *stmt6 = gimple_build_call (f, 3, addr_high, high_inc,
> build_int_cst (integer_type_node,
>MEMMODEL_RELAXED));
>gsi_insert_on_edge (e, stmt1);
>gsi_insert_on_edge (e, stmt2);
>gsi_insert_on_edge (e, stmt3);
>gsi_insert_on_edge (e, stmt4);
>gsi_insert_on_edge (e, stmt5);
>gsi_insert_on_edge (e, stmt6);
> }
>
> It can be probably simplified.
Likely. I'd use the gimple_build () API from gimple-fold.h which
builds the expression(s) to a gimple_seq creating necessary temporaries
on-the-fly and then insert that sequence on the edge.
But even the above should work.
The generated code:
>
> .type f, @function
> f:
> lui a4,%hi(__gcov0.f)
> li a3,1
> addia4,a4,%lo(__gcov0.f)
> amoadd.w a5,a3,0(a4)
> lui a4,%hi(__gcov0.f+4)
> addia5,a5,1
> seqza5,a5
> addia4,a4,%lo(__gcov0.f+4)
> amoadd.w zero,a5,0(a4)
> li a0,3
> ret
>
> looks good for this code:
>
> int f(void)
> {
>return 3;
> }
>
> The loading of the high address could be probably optimized from
>
> lui a4,%hi(__gcov0.f+4)
> addia4,a4,%lo(__gcov0.f+4)
>
> to
>
> addia4,a4,4
>
> I wasn't able to figure out how to do this.
I think that's something for the backend - we're not good
CSEing parts of an "invariant" address and the above might
be the form required when relocations are needed.
Richard.
>
> --
> embedded brains GmbH
> 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/
Spurious warning for zero-sized array parameters to a function
Hi!
In the following function, past_end is a pointer to one-past-the-end of the
array. Holding such a pointer is legal in C. I use it as a sentinel value that
helps (1) avoid overrunning the buffer, and (2) detect truncation. I mark it as
having a size of [0], which clearly states that it can't be dereferenced (and as
you can see, I don't).
/*
* This function copies an unterminated string into a string.
* - It never overruns the dest buffer.
* - It can be chained, to concatenate strings.
* - It detects truncation.
* - Truncation only needs to be tested once after all concatenations.
* - The name is self-documenting, compared to its alternative: strncat(3).
*/
char *
ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
{
bool trunc;
char *end;
ptrdiff_t len;
if (dst == past_end)
return past_end;
trunc = false;
len = strnlen(src, n);
if (len > past_end - dst - 1) {
len = past_end - dst - 1;
trunc = true;
}
end = mempcpy(dst, src, len);
*end = '\0';
return trunc ? past_end : end;
}
If I compile the code above, GCC considers the function definition to be fine.
However, at call site, it always warns:
#define nitems(arr) (sizeof((arr)) / sizeof((arr)[0]))
int
main(void)
{
char pre[4] = "pre.";
char *post = ".post";
char *src = "some-long-body.post";
char dest[100];
char *p, *past_end;
past_end = dest + nitems(dest);
p = dest;
p = ustr2stpe(p, pre, nitems(pre), past_end);
p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
p = ustr2stpe(p, "", 0, past_end);
if (p == past_end)
fprintf(stderr, "truncation\n");
puts(dest); // "pre.some-long-body"
}
$ cc -Wall -Wextra ustr2stpe.c
ustr2stpe.c: In function ‘main’:
ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
| ^~~~
ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
| ^~~
ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
45 | p = ustr2stpe(p, "", 0, past_end);
| ^
ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
| ^~~~
ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
| ^~~
ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
45 | p = ustr2stpe(p, "", 0, past_end);
| ^
ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
The warnings are invalid. While it's true that I'm referencing a pointer of
size 0, it's false that I'm "accessing 1 byte" in that region. I guess this is
all about the bogus design of 'static' in ISO C, where you can have an array
parameter of size 0, which is very useful in cases like this one
Re: Separate warning/error thresholds for -Wfoo=
On Tue, Dec 6, 2022 at 4:53 PM Alexander Monakov via Gcc
wrote:
>
> Greetings, David, community,
>
> I'd like to get your input on how GCC command line interface should support
> making a "tiered" warning like -Warray-bounds={1,2} an error for "tier 1"
> where fewer false positives are expected, and a plain warning otherwise.
>
> There was a recent thread mentioning the current limitation [1]:
>
> > This also shows nicely why I don't like warnings with levels, what if I want
> > -Werror=array-bounds=2 + -Warray-bounds=1?
>
> Also in PR 48088 [2] there was a request to make it work for stack size usage:
>
> > Stumbled on this bug today. I tried to use it in more intricate way:
> >
> > -Wframe-larger-than=4096 -Werror=frame-larger-than=32768
> >
> > which would only warn about any stack more than 4096+, but would fail on
> > 32768+.
> >
> > Does it make sense to implement desired behaviour?
> > I guess it's not many '>=number' style options in gcc.
>
> A problem with implementing DWIM semantics like above for -Wfoo=k
> -Werror=foo=n
> combination is that technically it changes its current meaning.
>
> If we don't want to risk that, an alternative is to introduce a new option
> for selecting error threshold for a tiered warning, for example:
>
> -Warray-bounds=2 -Werror-level=array-bounds=1
>
> Implementation-wise, we would need to extend common.opt language to annotate
> which tier is more inclusive (generally smaller 'n' means fewer warnings, but
> for -Wstack-usage and -Wstrict-aliasing it's the other way around).
Implementation-wise one could do a similar trick as we have for
global_options vs. global_options_set - add a global_options_error copy (ick!)
(and global_options_error_set!?) and have the logic that decides whether
a warning is an error pick that set. Of course it's the actual pass that looks
at flag_xyz which holds the magic number so that pass would need to be able
to see whether it needs to look at both numbers.
Btw, does '-Werror=array-bounds=2' imply that =1 kinds are diagnosed as
warning? Does it enable -Warray-bounds=2?
I think the DWIM behavior isn't all that clear and probably depends on the
actual option we want to make it work.
Richard.
>
> Opinions? Does anybody envision problems with going the DWIM way?
>
> Thanks.
> Alexander
>
> [1]
> https://inbox.sourceware.org/gcc-patches/2552ab22-916f-d0fe-2c78-d482f6ad8...@lauterbach.com/
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48088#c5
Re: Separate warning/error thresholds for -Wfoo=
On Tue, 6 Dec 2022, Richard Biener via Gcc wrote: > Implementation-wise one could do a similar trick as we have for > global_options vs. global_options_set - add a global_options_error copy (ick!) > (and global_options_error_set!?) and have the logic that decides whether > a warning is an error pick that set. Of course it's the actual pass that > looks > at flag_xyz which holds the magic number so that pass would need to be able > to see whether it needs to look at both numbers. I'm hoping to come up with a reasonably elegant way to implement this. > Btw, does '-Werror=array-bounds=2' imply that =1 kinds are diagnosed as > warning? No, =1 kinds are diagnosed as error as well. > Does it enable -Warray-bounds=2? Yes, -Werror=array-bounds=2 is simply decomposed into -Warray-bounds=2 -Werror=array-bounds= (since PR 48088 was fixed). > I think the DWIM behavior isn't all that clear and probably depends on the > actual option we want to make it work. Yeah, I guess there will be differences of opinion here, and I'm interested to reach community consensus. Let's say I'm mostly interested in supporting -Warray-bounds=2 -Werror=array-bounds=1 (errors for most certain OOB accesses, warnings otherwise). Alexander
Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition
On Mon, 5 Dec 2022, Gavin Ray via Gcc wrote:
> union [[may_alias]] broken2 {};
With [[]] syntax it's [[gnu::may_alias]], since it's not a standard
attribute.
--
Joseph S. Myers
jos...@codesourcery.com
Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition
Oh, D'oh! Thanks Joseph, apologies for the needless email on the list then.
One final question if I could -- does that mean that in order to support
"may-alias" with the bracket syntax on both Clang and GCC, it would require:
union [[gnu::may_alias]] [[clang::may_alias]] foo {};
On Tue, Dec 6, 2022 at 11:54 AM Joseph Myers
wrote:
> On Mon, 5 Dec 2022, Gavin Ray via Gcc wrote:
>
> > union [[may_alias]] broken2 {};
>
> With [[]] syntax it's [[gnu::may_alias]], since it's not a standard
> attribute.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>
Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition
On Tue, 6 Dec 2022, 18:36 Gavin Ray via Gcc, wrote:
> Oh, D'oh! Thanks Joseph, apologies for the needless email on the list then.
>
> One final question if I could -- does that mean that in order to support
> "may-alias" with the bracket syntax on both Clang and GCC, it would
> require:
>
> union [[gnu::may_alias]] [[clang::may_alias]] foo {};
>
Probably not. Clang accepts the gnu:: namespace for attributes that
originated with GCC.
Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition
Ah got it, didn't know that (handy, will save me duplicating a bunch of
attributes).
Thanks Jonathan!
On Tue, Dec 6, 2022 at 2:23 PM Jonathan Wakely
wrote:
>
>
> On Tue, 6 Dec 2022, 18:36 Gavin Ray via Gcc, wrote:
>
>> Oh, D'oh! Thanks Joseph, apologies for the needless email on the list
>> then.
>>
>> One final question if I could -- does that mean that in order to support
>> "may-alias" with the bracket syntax on both Clang and GCC, it would
>> require:
>>
>> union [[gnu::may_alias]] [[clang::may_alias]] foo {};
>>
>
>
>
> Probably not. Clang accepts the gnu:: namespace for attributes that
> originated with GCC.
>
>
>
Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition
On Tue, 6 Dec 2022 at 20:32, Gavin Ray wrote: > > Ah got it, didn't know that (handy, will save me duplicating a bunch of > attributes). > Thanks Jonathan! The Clang doc acually show all the forms that can be used for each attribute: https://clang.llvm.org/docs/AttributeReference.html#may-alias "GNU" means __attribute__((may_alias)) and the C++11 and C2x columns show that [[gnu::may_alias]] is the right way to use it. Clang-specific attributes use clang:: instead e.g. https://clang.llvm.org/docs/AttributeReference.html#preserve-all
D
Sent from my iPhone
Naming flag for specifying the output file name for Binary Module Interface files
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)?
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
Re: Naming flag for specifying the output file name for Binary Module Interface files
On Wed, 7 Dec 2022, 00:36 Nathan Sidwell via Gcc, wrote: > 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. > That's also much shorter and easier to remember than the five(!) words in the original suggestion.
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
GDC environment variable
Is there an environment variable like 'CC' or 'CXX', which specifies the name of the D compiler to use, which I might need to set when bootstrapping GCC? Thanks. -- Dave Blanchard
Re: GDC environment variable
I do see make using ‘GDC' while building gcc compiler, maybe try changing that ? - Ankur > On 07-Dec-2022, at 11:42 AM, Dave Blanchard wrote: > > Is there an environment variable like 'CC' or 'CXX', which specifies the name > of the D compiler to use, which I might need to set when bootstrapping GCC? > Thanks. > > -- > Dave Blanchard
