Re: A problem of weak & weakref function attribute
On Fri, Dec 9, 2022 at 7:17 PM 刘畅 via Gcc wrote:
>
> Hi all,
>
> I met a problem when I was testing the weak attribute and the weakref
> attribute of GCC. I've read the documentation and in the 6.33.1 Common
> Function Attributes - weakref part I found:
>
> Without a target given as an argument to weakref or to alias,
> weakref is equivalent to weak (in that case the declaration may be
> extern).
>
> To verify this statement, I wrote the following two C programs:
>
> a.c
> #include
>
> void func(void) __attribute__((weak));
>
> int main() {
> if (func)
> printf("1\n");
> else
> printf("0\n");
>
> return 0;
> }
>
> b.c
> #include
>
> extern void func(void) __attribute__((weakref));
>
> int main() {
> if (func)
> printf("1\n");
> else
> printf("0\n");
>
> return 0;
> }
>
> The only difference is a.c uses __attribute__((weak)) while b.c uses
> __attribute__((weakref)). According to the statement I referred above,
> I expect the two programs have the smae behavior. However, after I
> compiled the two programs with:
>
> $ gcc a.c -o a.out; gcc b.c -o b.out
>
> I got a warning:
>
> b.c:3:13: warning: ‘weakref’ attribute should be accompanied with an
> ‘alias’ attribute [-Wattributes]
> 3 | extern void func(void) __attribute__((weakref));
> |
>
> then I found they have different output:
>
> $ ./a.out; ./b.out
> 0
> 1
>
> Then I disassembled the main function of a.out and b.out, and found
> the func symbol didn't even appear in the assemble code of b.c (I
> recompiled the 2 programs with -g option):
>
> assemble code of a.c:
> 5 int main() {
>0x1149 <+0>: f3 0f 1e fa endbr64
>0x114d <+4>: 55 push %rbp
>0x114e <+5>: 48 89 e5mov%rsp,%rbp
>
> 6 if (func)
>0x1151 <+8>: 48 8b 05 90 2e 00 00mov
> 0x2e90(%rip),%rax# 0x3fe8
>0x1158 <+15>:48 85 c0test %rax,%rax
>0x115b <+18>:74 0e je 0x116b
>
> 7 printf("1\n");
>0x115d <+20>:48 8d 3d a0 0e 00 00lea
> 0xea0(%rip),%rdi# 0x2004
>0x1164 <+27>:e8 e7 fe ff ff callq 0x1050
>0x1169 <+32>:eb 0c jmp0x1177
>
> 8 else
> 9 printf("0\n");
>0x116b <+34>:48 8d 3d 94 0e 00 00lea
> 0xe94(%rip),%rdi# 0x2006
>0x1172 <+41>:e8 d9 fe ff ff callq 0x1050
>
> 10
> 11 return 0;
>0x1177 <+46>:b8 00 00 00 00 mov$0x0,%eax
>
> 12 }
>0x117c <+51>:5d pop%rbp
>0x117d <+52>:c3 retq
>
> assemble code of b.c:
> 5 int main() {
>0x1149 <+0>: f3 0f 1e fa endbr64
>0x114d <+4>: 55 push %rbp
>0x114e <+5>: 48 89 e5mov%rsp,%rbp
>
> 6 if (func)
> 7 printf("1\n");
>0x1151 <+8>: 48 8d 3d ac 0e 00 00lea
> 0xeac(%rip),%rdi# 0x2004
>0x1158 <+15>:e8 f3 fe ff ff callq 0x1050
>
> 8 else
> 9 printf("0\n");
> 10
> 11 return 0;
>0x115d <+20>:b8 00 00 00 00 mov$0x0,%eax
>
> 12 }
>0x1162 <+25>:5d pop%rbp
>0x1163 <+26>:c3 retq
>
> In my test, the weak attribute and the weakref attribute without a
> target given as an argument to weakref or to alias have different
> behavior, which is different from the documentation. I don't know if
> it's because I misunderstood the documentation. I would be appreciate
> if anyone can help me :)
No it is a bug, at least the documentation no longer matches the implementation.
I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042 and even
pointed out the (old) revision which changed the behavior to no longer
match the documentation.
Thanks,
Andrew
>
> Best regards,
>
> Chang Liu
A problem of weak & weakref function attribute
Hi all,
I met a problem when I was testing the weak attribute and the weakref
attribute of GCC. I've read the documentation and in the 6.33.1 Common
Function Attributes - weakref part I found:
Without a target given as an argument to weakref or to alias,
weakref is equivalent to weak (in that case the declaration may be
extern).
To verify this statement, I wrote the following two C programs:
a.c
#include
void func(void) __attribute__((weak));
int main() {
if (func)
printf("1\n");
else
printf("0\n");
return 0;
}
b.c
#include
extern void func(void) __attribute__((weakref));
int main() {
if (func)
printf("1\n");
else
printf("0\n");
return 0;
}
The only difference is a.c uses __attribute__((weak)) while b.c uses
__attribute__((weakref)). According to the statement I referred above,
I expect the two programs have the smae behavior. However, after I
compiled the two programs with:
$ gcc a.c -o a.out; gcc b.c -o b.out
I got a warning:
b.c:3:13: warning: ‘weakref’ attribute should be accompanied with an
‘alias’ attribute [-Wattributes]
3 | extern void func(void) __attribute__((weakref));
|
then I found they have different output:
$ ./a.out; ./b.out
0
1
Then I disassembled the main function of a.out and b.out, and found
the func symbol didn't even appear in the assemble code of b.c (I
recompiled the 2 programs with -g option):
assemble code of a.c:
5 int main() {
0x1149 <+0>: f3 0f 1e fa endbr64
0x114d <+4>: 55 push %rbp
0x114e <+5>: 48 89 e5mov%rsp,%rbp
6 if (func)
0x1151 <+8>: 48 8b 05 90 2e 00 00mov
0x2e90(%rip),%rax# 0x3fe8
0x1158 <+15>:48 85 c0test %rax,%rax
0x115b <+18>:74 0e je 0x116b
7 printf("1\n");
0x115d <+20>:48 8d 3d a0 0e 00 00lea
0xea0(%rip),%rdi# 0x2004
0x1164 <+27>:e8 e7 fe ff ff callq 0x1050
0x1169 <+32>:eb 0c jmp0x1177
8 else
9 printf("0\n");
0x116b <+34>:48 8d 3d 94 0e 00 00lea
0xe94(%rip),%rdi# 0x2006
0x1172 <+41>:e8 d9 fe ff ff callq 0x1050
10
11 return 0;
0x1177 <+46>:b8 00 00 00 00 mov$0x0,%eax
12 }
0x117c <+51>:5d pop%rbp
0x117d <+52>:c3 retq
assemble code of b.c:
5 int main() {
0x1149 <+0>: f3 0f 1e fa endbr64
0x114d <+4>: 55 push %rbp
0x114e <+5>: 48 89 e5mov%rsp,%rbp
6 if (func)
7 printf("1\n");
0x1151 <+8>: 48 8d 3d ac 0e 00 00lea
0xeac(%rip),%rdi# 0x2004
0x1158 <+15>:e8 f3 fe ff ff callq 0x1050
8 else
9 printf("0\n");
10
11 return 0;
0x115d <+20>:b8 00 00 00 00 mov$0x0,%eax
12 }
0x1162 <+25>:5d pop%rbp
0x1163 <+26>:c3 retq
In my test, the weak attribute and the weakref attribute without a
target given as an argument to weakref or to alias have different
behavior, which is different from the documentation. I don't know if
it's because I misunderstood the documentation. I would be appreciate
if anyone can help me :)
Best regards,
Chang Liu
Re: The method of determining the specific assignment of gcc optimization options
Thank you for your response. Jonathan Wakely 于2022年12月9日周五 22:40写道： > This question belongs on the gcc-help mailing list, not here. > > On Fri, 9 Dec 2022 at 12:01, hongjie wu via Gcc wrote: > > > > Dear Sir or Madam， > > I want to know how to obtain optimal level of the value of the > > What do you mean by optimal? > > They have pros and cons. > > > specific compiler options, for example - fexcess - precision = [fast | > > standard] [default], including the default represent？Or how to determine? > > gcc -Q --help=optim > > > I am looking forward to your favorable replay. >
gcc-11-20221209 is now available
Snapshot gcc-11-20221209 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20221209/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 5d3bf022a7bf7dba2f376fb328c5c60cfd21eb91 You'll find: gcc-11-20221209.tar.xz Complete GCC SHA256=8b46e1371ebf8f6eed980af1c1af19ed23502cb38bb98dae3ba7613124f2f8b1 SHA1=962cabe4364831445b18ca55254420f0693dd6cc Diffs from 11-20221202 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
On 2022-12-09 14:23, Georg-Johann Lay wrote:
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
I am sorry, I feel your frustration. I was not aware of this PR.
Unfortunately, the PR was marked as P4 and I have too many open PRs and
should prioritize them.
I've just started to work on this issue. It is hard for me to say when
it will be fixed. I'll give an update on the next week.
Simple test cases are, for example
#define PORT (*((unsigned char volatile*) 0x24))
unsigned short var16;
void func (void)
{
if (2048000ul * var16 > 120ul)
PORT |= 1;
}
When I compile it with
$ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
the code size increases from 36 bytes (v8) to 88 bytes (v13).
Apart from that, register pressure is much higher because a frame
pointer is set up for no reason, and the values go through stack slots
for no reason.
Even test cases which don't require any code like
long func2 (void)
{
long var32;
__asm ("; some code %0" : "=r" (var32));
return var32;
}
increase in register pressure (x2), stack usage (from 0 to 6 bytes)
and code size from 2 bytes (v8) to 34 bytes (v13).
Some projects like QMK "solved" the problem by declaring GCC > v8 to
be "incompatible" with their project, see
https://github.com/qmk/qmk_firmware/issues/6719
In own projects I observed the problem, too, and the only solution is
to use v8 or older. Options like -fcaller-saves or -fira-algorithm=
have no effect.
To configure, I used --target=avr --disable-nls --with-dwarf2
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared,
so nothing special.
The problem is present in v9, v10, v11, v12 and master (future v13),
so sitting around for quite a while, so maybe it's not fixed because
RA maintainers are not aware of the problem.
Re: Spurious warning for zero-sized array parameters to a function
On 12/9/22 21:19, Alejandro Colomar wrote:
Hi Martin,
On 12/9/22 21:04, mse...@gmail.com wrote:
Most of these warnings are designed to find simple mistakes in common use
cases so "tricky," unusual, or otherwise unexpected code is likely to lead to
surprises. This warning expects that in calls to a function, every parameter
declared using the array syntax (which is expected to have a nonzero bound) is
passed a dereferenceable pointer as an argument. It considers neither the
definition of the function to see if it does in fact dereference the argument,
nor this unlikely (and strictly invalid) use case.
Hi Martin,
Is it really invalid? AFAIK, ISO C doesn't specify anything for array syntax in
function parameters othen than that they are equivalent to a pointer. The only
exception is when using 'static', which requires a minimum of 0.
Oops, typo there. I wanted to say that 'static' requires a minimum of 1.
So, [0], by
not using 'static', is conforming code, I believe. Or does the restriction to
0-sized arrays also apply to function parameters? What if you pass a size of 0
through a variable? I don't think it's undefined behavior to do so.
Could you please quote the standard about being "strictly invalid"?
Cheers,
Alex
The warning should not be issued if the parameter is declared as an ordinary
pointer
I confirm; it doesn't warn.
so I would suggest to use that instead. It's possible that declaring the
array parameter with attribute access none might also suppress the warning,
but there is no utility in using a zero-length array in this context. The
intended purpose of the zero-length array GCC extension is as trailing members
of structs in legacy (pre-C99 code) that cannot use flexible array members.
Using them anywhere else is likely to be surprising, both to tools and to
readers, so the attribute on a pointer parameter would be preferable.
Heh, then the following function will blow brains :P
char *
stpecpy(char *dst, const char *restrict src, char past_end[0])
{
char *p;
if (dst == past_end)
return past_end;
p = memccpy(dst, src, '\0', past_end - dst);
if (p != NULL)
return p - 1;
/* truncation detected */
past_end[-1] = '\0';
return past_end;
}
which similar to strscpy(9), but allows chaining.
In this case, I can't even use the access attribute. I _need_ to use the
'past_end' pointer to access the array (or perform unnecessary pointer
arithmetic that would hurt readability: 'p = &dst[past_end - dst];').
For the curious, a variant that behaves like strlcpy(3), can be implemented as:
inline char *
stpecpyx(char *dst, const char *restrict src, char past_end[0])
{
if (src[strlen(src)] != '\0')
raise(SIGSEGV);
return stpecpy(dst, src, past_end);
}
Cheers,
Alex
--
Re: Spurious warning for zero-sized array parameters to a function
Hi Martin,
On 12/9/22 21:04, mse...@gmail.com wrote:
Most of these warnings are designed to find simple mistakes in common use cases so
"tricky," unusual, or otherwise unexpected code is likely to lead to surprises.
This warning expects that in calls to a function, every parameter declared using the
array syntax (which is expected to have a nonzero bound) is passed a dereferenceable
pointer as an argument. It considers neither the definition of the function to see if it
does in fact dereference the argument, nor this unlikely (and strictly invalid) use case.
Hi Martin,
Is it really invalid? AFAIK, ISO C doesn't specify anything for array syntax in
function parameters othen than that they are equivalent to a pointer. The only
exception is when using 'static', which requires a minimum of 0. So, [0], by
not using 'static', is conforming code, I believe. Or does the restriction to
0-sized arrays also apply to function parameters? What if you pass a size of 0
through a variable? I don't think it's undefined behavior to do so.
Could you please quote the standard about being "strictly invalid"?
Cheers,
Alex
The warning should not be issued if the parameter is declared as an ordinary
pointer
I confirm; it doesn't warn.
so I would suggest to use that instead. It's possible that declaring the array
parameter with attribute access none might also suppress the warning, but there
is no utility in using a zero-length array in this context. The intended
purpose of the zero-length array GCC extension is as trailing members of
structs in legacy (pre-C99 code) that cannot use flexible array members. Using
them anywhere else is likely to be surprising, both to tools and to readers, so
the attribute on a pointer parameter would be preferable.
Heh, then the following function will blow brains :P
char *
stpecpy(char *dst, const char *restrict src, char past_end[0])
{
char *p;
if (dst == past_end)
return past_end;
p = memccpy(dst, src, '\0', past_end - dst);
if (p != NULL)
return p - 1;
/* truncation detected */
past_end[-1] = '\0';
return past_end;
}
which similar to strscpy(9), but allows chaining.
In this case, I can't even use the access attribute. I _need_ to use the
'past_end' pointer to access the array (or perform unnecessary pointer
arithmetic that would hurt readability: 'p = &dst[past_end - dst];').
For the curious, a variant that behaves like strlcpy(3), can be implemented as:
inline char *
stpecpyx(char *dst, const char *restrict src, char past_end[0])
{
if (src[strlen(src)] != '\0')
raise(SIGSEGV);
return stpecpy(dst, src, past_end);
}
Cheers,
Alex
--
Re: Spurious warning for zero-sized array parameters to a function
> On Dec 6, 2022, at 9:22 AM, Alejandro Colomar via Gcc wrote:
>
> 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
[IRA] Code bloat due to register spills in v9, v10, v11, v12 and master
There is the following code size regression, filed as
https://gcc.gnu.org/PR90706
Simple test cases are, for example
#define PORT (*((unsigned char volatile*) 0x24))
unsigned short var16;
void func (void)
{
if (2048000ul * var16 > 120ul)
PORT |= 1;
}
When I compile it with
$ avr-gcc -Os bloat1.c -c && avr-size bloat1.o
the code size increases from 36 bytes (v8) to 88 bytes (v13).
Apart from that, register pressure is much higher because a frame
pointer is set up for no reason, and the values go through stack slots
for no reason.
Even test cases which don't require any code like
long func2 (void)
{
long var32;
__asm ("; some code %0" : "=r" (var32));
return var32;
}
increase in register pressure (x2), stack usage (from 0 to 6 bytes) and
code size from 2 bytes (v8) to 34 bytes (v13).
Some projects like QMK "solved" the problem by declaring GCC > v8 to be
"incompatible" with their project, see
https://github.com/qmk/qmk_firmware/issues/6719
In own projects I observed the problem, too, and the only solution is to
use v8 or older. Options like -fcaller-saves or -fira-algorithm= have
no effect.
To configure, I used --target=avr --disable-nls --with-dwarf2
--enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-shared,
so nothing special.
The problem is present in v9, v10, v11, v12 and master (future v13), so
sitting around for quite a while, so maybe it's not fixed because RA
maintainers are not aware of the problem.
Thanks for any help,
Johann
Re: Naming flag for specifying the output file name for Binary Module Interface files
Thanks Iain for the summary/thanks everyone for the discussion! On Fri, Dec 9, 2022 at 9:33 AM 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. > > === > > These facilities support build systems that do not use the P1184 interface to > map between module names and paths. > > cheers > Iain > > > > > 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
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. === These facilities support build systems that do not use the P1184 interface to map between module names and paths. cheers Iain > > 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: Spurious warning for zero-sized array parameters to a function
Hi Richard,
On 12/7/22 09:17, Richard Biener wrote:
[...]
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.
It looks like we run into pass_waccess::maybe_check_access_sizes doing
if (sizidx == -1)
{
/* If only the pointer attribute operand was specified and
not size, set SIZE to the greater of MINSIZE or size of
one element of the pointed to type to detect smaller
objects (null pointers are diagnosed in this case only
if the pointer is also declared with attribute nonnull. */
if (access.second.minsize
&& access.second.minsize != HOST_WIDE_INT_M1U)
access_nelts = build_int_cstu (sizetype, access.second.minsize);
else if (VOID_TYPE_P (argtype) && access.second.mode == access_none)
/* Treat access mode none on a void* argument as expecting
as little as zero bytes. */
access_nelts = size_zero_node;
else
access_nelts = size_one_node;
and use size_one_node as fallback - it either doesn't consider [0] "valid" or
for some reason chooses to interpret it as "unknown". Can you file a bugreport
please?
Sure; will do!
Cheers,
Alex
Martin?
Richard.
--
Missing optimization: mempcpy(3) vs memcpy(3)
Hi!
I expect mempcpy(3) to be at least as fast as memcpy(3), since it performs the
same operations, with the exception that mempcpy(3) returns something useful (as
opposed to memcpy(3), which could perfectly return void), and in fact something
more likely to be in cache, if the copy is performed upwards.
The following two files are alternative implementations of a function, each one
written in terms of one of memcpy(3) and mempcpy(3):
$ cat usts2stp1.c
#include
struct ustr_s {
size_t len;
char*ustr;
};
char *
usts2stp(char *restrict dst, const struct ustr_s *restrict src)
{
memcpy(dst, src->ustr, src->len);
dst[src->len] = '\0';
return dst + src->len;
}
$ cat usts2stp3.c
#define _GNU_SOURCE
#include
struct ustr_s {
size_t len;
char*ustr;
};
char *
usts2stp(char *restrict dst, const struct ustr_s *restrict src)
{
char *end;
end = mempcpy(dst, src->ustr, src->len);
*end = '\0';
return end;
}
I expect the compiler to be knowledgeable enough to call whatever is fastest,
whatever it is, but be consistent in both cases. However, here are the results:
$ cc -Wall -Wextra -O3 -S usts2stp*.c
$ diff -u usts2stp[13].s
--- usts2stp1.s 2022-12-09 18:06:11.708367061 +0100
+++ usts2stp3.s 2022-12-09 18:06:11.740366451 +0100
@@ -1,4 +1,4 @@
- .file "usts2stp1.c"
+ .file "usts2stp3.c"
.text
.p2align 4
.globl usts2stp
@@ -6,16 +6,13 @@
usts2stp:
.LFB0:
.cfi_startproc
- pushq %rbx
+ subq$8, %rsp
.cfi_def_cfa_offset 16
- .cfi_offset 3, -16
- movq(%rsi), %rbx
+ movq(%rsi), %rdx
movq8(%rsi), %rsi
- movq%rbx, %rdx
- callmemcpy@PLT
- leaq(%rax,%rbx), %rax
+ callmempcpy@PLT
movb$0, (%rax)
- popq%rbx
+ addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
The code with memcpy(3) seems to be worse (assuming both calls to be
equivalent). Shouldn't GCC produce the same code for both implementations?
Cheers,
Alex
--
Re: The method of determining the specific assignment of gcc optimization options
This question belongs on the gcc-help mailing list, not here. On Fri, 9 Dec 2022 at 12:01, hongjie wu via Gcc wrote: > > Dear Sir or Madam， > I want to know how to obtain optimal level of the value of the What do you mean by optimal? They have pros and cons. > specific compiler options, for example - fexcess - precision = [fast | > standard] [default], including the default represent？Or how to determine? gcc -Q --help=optim > I am looking forward to your favorable replay.
The method of determining the specific assignment of gcc optimization options
Dear Sir or Madam， I want to know how to obtain optimal level of the value of the specific compiler options, for example - fexcess - precision = [fast | standard] [default], including the default represent？Or how to determine? I am looking forward to your favorable replay.
Support
Dear team, I am working in the compiler domain. Can you please provide the source application where the mis-compilation errors occurred which has been detected by the GCC compiler. This support is very helpful for my PHD work. - P Rajshekhar Rao Thanks and Regards
