Compiling and running the following code on a CPU with BMI2 support
prints "BMI2 detected" as one would expect:
#include
int main(void)
{
if (__builtin_cpu_supports("bmi2"))
printf("BMI2 detected\n");
return 0;
}
However, "bmi2" is not documented in the list of arguments at
https://
On 11/6/18 1:35 PM, Martin Reinecke wrote:
> Compiling and running the following code on a CPU with BMI2 support
> prints "BMI2 detected" as one would expect:
>
> #include
>
> int main(void)
> {
> if (__builtin_cpu_supports("bmi2"))
> printf("BMI2 detected\n");
> return 0;
> }
>
> H
I was doing some benchmarking with SPEC 2017 fprate on aarch64
(Thunderx2) and I am getting some segfaults from GCC while compiling.
I am working with delta to try and cut down one of the test cases
but I was wondering if anyone else has seen this problem. The
three tests that segfault while comp
On November 6, 2018 5:45:52 PM GMT+01:00, Steve Ellcey
wrote:
>I was doing some benchmarking with SPEC 2017 fprate on aarch64
>(Thunderx2) and I am getting some segfaults from GCC while compiling.
This should be already fixed.
>I am working with delta to try and cut down one of the test cases
> I was doing some benchmarking with SPEC 2017 fprate on aarch64
> (Thunderx2) and I am getting some segfaults from GCC while compiling.
>
> I am working with delta to try and cut down one of the test cases
> but I was wondering if anyone else has seen this problem. The
> three tests that segfault
On Wed, 2018-11-07 at 00:16 +0700, Arseny Solokha wrote:
>
> This is probably PR87889, already fixed on trunk.
Yup, that was the problem. I have updated my sources and things are
building now. Thanks for the info.
Steve Ellcey
Greetings all,
I am wondering why this bug is only for the function reported:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66074
Seems there are lots of other functions in that file that could
use the exact same optimization, would it be better to rewrite
the file to use the void object pointer fo
Greetings all,
I am wondering why this bug is only for the function reported:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66074
Seems there are lots of other functions in that file that could
use the exact same optimization, would it be better to rewrite
the file to use the void object pointer fo
Hi,
I remember from awhile ago that there's some option (or there was...)
that gets GCC to print some register allocation information together
with the assembler output.
I am interested in obtaining the live registers per basic block. I think
the option I had in mind did that but I can't remember
Apologies, wrong mailing list. Should have sent this to gcc-help.
On 06/11/2018 21:35, Paulo Matos wrote:
> Hi,
>
> I remember from awhile ago that there's some option (or there was...)
> that gets GCC to print some register allocation information together
> with the assembler output.
>
> I am i
Hi Paulo,
On Tue, Nov 06, 2018 at 09:35:35PM +0100, Paulo Matos wrote:
> I remember from awhile ago that there's some option (or there was...)
> that gets GCC to print some register allocation information together
> with the assembler output.
>
> I am interested in obtaining the live registers pe
Hi,
Over the past couple of years, I have hand-assembled a new floating point
library for the ARM Cortex M0 architecture. I know the M0 is not generally
regarded as a number-crunching machine, but I felt it deserved at least some of
the attention that has previously been bestowed on the AVR a
On Tue, Nov 6, 2018, 10:32 PM Daniel Engel Hi,
>
> Over the past couple of years, I have hand-assembled a new floating point
> library for the ARM Cortex M0 architecture. I know the M0 is not generally
> regarded as a number-crunching machine, but I felt it deserved at least
> some of the attenti
On 07/11/2018 00:40, Segher Boessenkool wrote:
> Hi Paulo,
>
> -fdump-rtl-alignments[-all] is the last dump with all that information I
> think. This one also has all this info without -all it seems. With -all
> it shows it interleaving the RTL dump as well, which may or may not be
> handy fo
14 matches
Mail list logo
