mfentry and Darwin.
Hi Uros, It seems to me that (even if it was working “properly”, which it isn't) ‘-mfentry’ would break ABI on Darwin for both 32 and 64b - which require 16byte stack alignment at call sites. For Darwin, the dynamic loader enforces the requirement when it can and will abort a program that tries to make a DSO linkage with the stack in an incorrect alignment. We previously had a bug against profiling caused by exactly this issue (but when the mcount call was in the post-prologue position). Actually, I’m not sure why it’s not an issue for other 64b platforms that use the psABI (AFAIR, it’s only the 32b case that’s Darwin-specific). Anyway, my current plan is to disable mfentry (for Darwin) - the alternative might be some kind of “almost at the start of the function, but needing some stack alignment change”, I’m interested in if you know of any compelling use-cases that would make it worth finding some work-around instead of disabling. thanks Iain
-Wformat-diag: floating-point or floating point?
The GCC coding style says to use "floating-point" as an adjective rather than "floating point." After enhancing the -Wformat-diag checker to detect this I found a bunch of uses of the latter, such as in: gcc/c/c-decl.c:10944 gcc/c/c-parser.c:9423, 9446, 9450, etc. gcc/convert.c:418, 422 gcc/cp/call.c:5070 gcc/cp/cvt.c:886 Before I fix them all and adjust the tests, I want to make sure we really want to follow this rule. The C standard uses both interchangeably. With just one exception, the C++ standard uses the hyphenated form. Thanks Martin
Re: mfentry and Darwin.
On Tue, May 21, 2019 at 6:15 PM Iain Sandoe wrote: > > Hi Uros, > > It seems to me that (even if it was working “properly”, which it isn't) > ‘-mfentry’ would break ABI on Darwin for both 32 and 64b - which require > 16byte stack alignment at call sites. > > For Darwin, the dynamic loader enforces the requirement when it can and will > abort a program that tries to make a DSO linkage with the stack in an > incorrect alignment. We previously had a bug against profiling caused by > exactly this issue (but when the mcount call was in the post-prologue > position). > > Actually, I’m not sure why it’s not an issue for other 64b platforms that use > the psABI (AFAIR, it’s only the 32b case that’s Darwin-specific). The __fentry__ in glibc is written as a wrapper around the call to __mcount_internal, and is written in such a way that it compensates stack misalignment in a call to __mcount_internal. __fentry__ survives stack misalignment, since no xmm regs are saved to the stack in the function. > Anyway, my current plan is to disable mfentry (for Darwin) - the alternative > might be some kind of “almost at the start of the function, but needing some > stack alignment change”, > > I’m interested in if you know of any compelling use-cases that would make it > worth finding some work-around instead of disabling. Unfortunately, not from the top of my head... Uros.
Re: -Wformat-diag: floating-point or floating point?
On 5/21/19 11:47 AM, Martin Sebor wrote: > The GCC coding style says to use "floating-point" as an adjective > rather than "floating point." After enhancing the -Wformat-diag > checker to detect this I found a bunch of uses of the latter, such > as in: > > gcc/c/c-decl.c:10944 > gcc/c/c-parser.c:9423, 9446, 9450, etc. > gcc/convert.c:418, 422 > gcc/cp/call.c:5070 > gcc/cp/cvt.c:886 > > Before I fix them all and adjust the tests, I want to make sure > we really want to follow this rule. The C standard uses both > interchangeably. With just one exception, the C++ standard uses > the hyphenated form. The hyphenated form is correct English, so I certainly prefer it. :-) Bill > > Thanks > Martin >
Re: -Wformat-diag: floating-point or floating point?
On 5/21/19 2:18 PM, Bill Schmidt wrote:
On 5/21/19 11:47 AM, Martin Sebor wrote:
The GCC coding style says to use "floating-point" as an adjective
rather than "floating point." After enhancing the -Wformat-diag
checker to detect this I found a bunch of uses of the latter, such
as in:
gcc/c/c-decl.c:10944
gcc/c/c-parser.c:9423, 9446, 9450, etc.
gcc/convert.c:418, 422
gcc/cp/call.c:5070
gcc/cp/cvt.c:886
Before I fix them all and adjust the tests, I want to make sure
we really want to follow this rule. The C standard uses both
interchangeably. With just one exception, the C++ standard uses
the hyphenated form.
The hyphenated form is correct English, so I certainly prefer it. :-)
I agree and I'm changing the C/C++ FE diagnostics to match. I count
just 31 test that look for the unhyphenated form, and of those just
three under the gcc.target directory, so the fallout should be fairly
limited.
Thanks
Martin
PS As a heads up, below are the target-specific tests I found:
gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-5.c: return
(long long int) __builtin_vec_scalar_extract_sig (source); /* { dg-error
"requires ISA 3.0 IEEE 128-bit floating point" } */
gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-11.c: return
scalar_insert_exp (significand, exponent); /* { dg-error "requires ISA
3.0 IEEE 128-bit floating point" } */
gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-5.c: return
scalar_extract_exp (source); /* { dg-error "requires ISA 3.0 IEEE
128-bit floating point" } */
Determining maximum vector length supported by the CPU?
[Disclaimer: I sent this to gcc-help two weeks ago, but didn't get an answer. Maybe the topic is more suited for the main gcc list ... I really think the feature in question would be extremely useful to have, and easy to add!] Hi, I'm currently writing an FFT library which tries to make use of SIMD instructions and uses a lot of variables with __attribute__ ((vector_size (xyz)) The resulting source is nicely portable and architecture-independent - except for the one place where I need to determine the maximum hardware-supported vector length on the target CPU. This currently looks like #if defined(__AVX__) constexpr int veclen=32; #elif defined(__SSE2__) constexpr int veclen=16; [...] This approach requires me to add an #ifdef for many architectures, most of which I cannot really test on ... and new architectures will be unsupported by default. Hence my question: is there a way in gcc to determine the hardware vector length for the architecture the compiler is currently targeting? Some predefined macro like HARDWARE_VECTOR_LENGTH_IN_BYTES which is 32 for AVX, 16 for SSE2, and has proper values for Neon, VPX etc. etc. If this is not provided at the moment, would it bo possible to add this in the future? This could massively simplify writing and maintaining multi-platform SIMD code. Thanks, Martin
