GCC 8, ppc64-le and problems with -fstack-protector-strong
Hi Everyone, We are tracking an issue on ppc64-le and GCC 8. We can duplicate it on GCC112 when using /opt/cfarm/gcc8-r257824 compiler. Also see https://github.com/weidai11/cryptopp/issues/588. We have the issue isolated, but its not really reduced yet. When '-O2 -fstack-protector-strong' is used during a compile then we have some failed self tests. When '-O3 -fstack-protector-strong' is used during a compile then everything is OK. (It is not backwards; -O3 is OK, and -O2 is bad). The source code is clean under the sanitizers on the platform. The problem does not occur under GCC 4.8.5 (default compiler) and GCC 7 (installed at /opt/cfarm/gcc-latest). The source file that is causing the problems under Power8 is https://github.com/weidai11/cryptopp/blob/master/rijndael-simd.cpp#L536 . Its an awful file and nearly everything is inlined. I've tried looking at the disassemblies but I don't have the knowledge to spot the trouble. I'm not sure how to troubleshoot things further. Suggestions on the next step would be very helpful. Thanks in advance.
CPP documentation minor typo
__VA_OPT__ was documented after 7.3.0 and the eprintf example for it ends with two backslashes instead of one: https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html Regards, Bogdan
sign-compare warning for short and char
I wonder why -Wsign-compare only warns when there is no int promotion?
No warning for this, where the result is “surprisingly” false because of int
promotion:
signed char i = (signed char) -3;
unsigned char j = (unsigned char) -3;
printf("i=%x j=%x i==j=%d\n", i, j, i==j);
gcc -Wsign-compare ~/test.c -o /tmp/glop && /tmp/glop
i=fffd j=fd i==j=0
But a warning for this where the result is true (which I believe represents a
lower risk than the above case):
signed int i = (signed int) -3;
unsigned int j = (unsigned int) -3;
printf("i=%x j=%x i==j=%d\n", i, j, i==j);
% gcc -Wsign-compare ~/test.c -o /tmp/glop && /tmp/glop
i=fffd j=fd i==j=0
/home/ddd/test.c:7:42: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
printf("i=%x j=%x i==j=%d\n", i, j, i==j);
^~
i=fffd j=fffd i==j=1
I did not find a rationale in the documentation, nor a good alternative flag
that would focus on comparisons with promotion.
Tested with several semi-old variants of GCC, e.g. 4.8.5, and more recent ones
e.g. 7.2.1, with consistent results.
gcc --version
gcc (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
Thanks,
Christophe
Re: sign-compare warning for short and char
This question belongs on the gcc-help list really. On 20 February 2018 at 14:44, Christophe de Dinechin wrote: > I wonder why -Wsign-compare only warns when there is no int promotion? I suspect the correct-but-not-helpful answer is that after integer promotion the operands have the same type, and so there's no comparison between signed and unsigned types. But the compiler could make the warning apply *before* doing integer promotion, to diagnose this case.
Re: sign-compare warning for short and char
> On 20 Feb 2018, at 16:15, Jonathan Wakely wrote: > > This question belongs on the gcc-help list really. I posted here because I saw it as a possible diagnostic bug / limitation. Do such things go to gcc-help? Or is it that you thought I was asking for the correct option? > On 20 February 2018 at 14:44, Christophe de Dinechin > wrote: >> I wonder why -Wsign-compare only warns when there is no int promotion? > > I suspect the correct-but-not-helpful answer is that after integer > promotion the operands have the same type, and so there's no > comparison between signed and unsigned types. That’s an implementation explanation, not a rationale, right? > But the compiler could make the warning apply *before* doing integer > promotion, to diagnose this case. That is what I am thinking, but I was wondering if there was not some rationale making this a bad idea.
Re: sign-compare warning for short and char
On 20 February 2018 at 15:43, Christophe de Dinechin wrote: > I posted here because I saw it as a possible diagnostic bug / limitation. Do > such things go to gcc-help? Or is it that you thought I was asking for the > correct option? Bug reports and enhancement requests go to bugzilla not here, and questions about using GCC (including warnings and "why doesn't this work?" stuff) belongs on gcc-help. Although arguably this question is somewhere halfway between gcc@ and gcc-help@
