https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106340
Yichao Yu changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106324
--- Comment #3 from Yichao Yu ---
Actually I just realized that the not instruction used the .d version as
requested, the vector instruction didn’t….. I got it reversed in the original
post……
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106340
--- Comment #1 from Yichao Yu ---
Also note that this is for code I've tweaked to match what the finally code as
much as possible. For a complete implementation of this, I expect the loop
transformation done for normal loop should move the
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
I'm experimenting with manually writing VLA loops and trying to match the
assembly code I expect/from autovectorizer. One of the main area I
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
If a known-all-false predicate is used on an SVE intrinsic, the result should
be fully no-op, undefined, zeroing and no actual instruction (other than
potentially returning
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106326 .
According to the Arm C Language Extension for SVE, when
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The following code should generate a predicate-free fadd instruction since all
the predicates are true.
```
svfloat64_t
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The following code has two use of `svptrue_b64()`s and none of the instructions
using them should be clearning it so only one
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
If a comparison involving a template parameter is always true or false, it
should not raise a warning if it could take other
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The following code
```
__attribute__((target("avx2")))
void fill_avx2(double *__restrict__ data, int n, double value)
{
for (int i = 0; i &
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The following code used to work on gcc 9.3 but stops working with 10.2 with an
error
```
a.c: In function ‘test_aa64_vec_2’:
a.c:19:24: error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96629
--- Comment #3 from Yichao Yu ---
Just curious, is it some particular structure that is upsetting it or did it
simply hit some depth limit.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Reduced test code:
```
int mem(char *data);
int cond(void);
void f(char *data, unsigned idx, unsigned inc)
{
char *d2;
int c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539
--- Comment #4 from Yichao Yu ---
Wow that was fast... thx.
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Test C code,
```
struct A {
int a;
int b;
int c;
int d;
int e;
int f;
void *p1;
void *p2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069
--- Comment #8 from Yichao Yu ---
OK, done. It would be nice to mention it on
https://gcc.gnu.org/contribute.html#patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069
--- Comment #6 from Yichao Yu ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549411.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549413.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069
--- Comment #4 from Yichao Yu ---
> Apparently it is.
Yes, but my question is about why should this be "WONTFIX". This feature
(reproducible build) is certainly as useful in fortran as it is in C family.
> Let move the component to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069
--- Comment #2 from Yichao Yu ---
Why should this feature be c only?
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Compiling the following code `a.f`
```
subroutine f(name)
implicit none
character*(*) name
print *,name
return
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775
--- Comment #4 from Yichao Yu ---
> Hey. My opinion is similar to Richi's. If you really want a highly optimized
> library, you should rather use a dlopen mechanism with pre-built set of
> options.
Well, a few things,
1. That sounds like an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95777
--- Comment #3 from Yichao Yu ---
And for backward compatibility maybe
`target_clones("(sse4.1,arch=core2),default")` would work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95777
--- Comment #2 from Yichao Yu ---
I only tested this with `target_clones` and it seems that I misread the
document for `target`. So this is only an issue with `target_clones` attribute.
`target` support this just fine.
So to be more clear,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95775
--- Comment #2 from Yichao Yu ---
> But it will blow up code-size considerably.
> So without some major work I don't think simply slapping target_clones on
> each function is going to fly in practice.
I mean, it'll blow up not much more than
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
If two functions with the same target attribute calls each other, GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #8 from Yichao Yu ---
And the reason I reported this as a mis-optimization rather than something
completely unsupported is that the following code.
```
#include
// #define disable_opt __attribute__((flatten))
#define disable_opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #7 from Yichao Yu ---
> Your testcase has nested function multi-versioning. I don't think it works
at all. I opened PR 95793.
I'm sorry but what is nested function multi-versioning? and what's the
difference between the test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #5 from Yichao Yu ---
It’s wrong when running on a target that has avx512f. The unoptimuzed version
will call the correct foo but the unoptimized case won’t.
As I said, this is an issue when the total targets are different between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #3 from Yichao Yu ---
And the assembly showing the correct dispatch is
.file "a.c"
.text
.p2align 4
.type _ZL3fooPKcj, @function
_ZL3fooPKcj:
.LFB0:
.cfi_startproc
movl$1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95790
--- Comment #2 from Yichao Yu ---
The C++ code attached above produces the following incorrect code with `g++ -O2
-S`
.file "a.c"
.text
.p2align 4
.globl _Z3barv
.type _Z3barv, @function
_Z3barv:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778
--- Comment #4 from Yichao Yu ---
Yeah, after digging further the two issue are indeed the same. I initially
didn't think they are since I didn't realize PR95786 (that the visibility
attribute is simply ignored completely...) and thought static
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The indirection elimination code currently only check for match of the target
for the specific version but doesn't check if all the targets
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
I realize this issue when debugging PR95778 and PR95780 (ref
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548631.html)
It seems that the indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778
--- Comment #2 from Yichao Yu ---
Also, the original code example had an error, the code that works properly was
```
static __attribute__((noinline,target_clones("default,avx2"))) int f2(int *p)
{
asm volatile ("" :: "r"(p) : "memory");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778
--- Comment #1 from Yichao Yu ---
Ah, I think this might be the fix for both this issue and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95780 . I'll test more and will
try to submit it later.
```
diff --git a/gcc/multiple_target.c
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Code,
```
static int 2(int *p, int k)
{
int res = 0;
if (k > 0)
res += 2(p, k - 1);
return *p +
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Again using the code in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778. If
the static function `f2` is changed
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Using the code in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95778 the full
assembly generated (the version with both noinline
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Compiling
```
static __attribute__((noinline,target_clones("default,avx2"))) int f2(int *p)
{
asm volatile ("" :: "r"
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Currently it seems that (document and own tests) only a single option is
allowed for each version
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Currently, if a function is not not visible outside the final library (static,
or internal
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Would it make sense to add a command line argument that is roughly equivalent
to to adding `target_clones` to all functions?
In terms of usefulness, I believe it will be a very
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This is basically the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732 except now it only happens
with LTO enabled.
It seems
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling the following code with `gcc -c` leads to a segfault in the compiler
targetclone pass
++
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
I get the following warning when running gdb/rr.
```
/usr/lib/../share/gcc-9.2.0/python/libstdcxx/v6/xmethods.py:731: SyntaxWarning:
list indices must be integers or slices, not str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #29 from Yichao Yu ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412#c25
GCC is fully capable of aligning the stack. It just seems that different part
of it disagrees on what the current stack alignment is and whether a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826
--- Comment #2 from Yichao Yu ---
Also, I just upgraded the compiler on this computer from 7.x to 9.1.0. The
issue appeared before the upgrade as well but I didn't investigate until the
upgrade finished.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826
--- Comment #1 from Yichao Yu ---
Oh, forgot to mention that the first assembly was generated with -O3 and adding
`.weak f` to the generated file fixes the issue as well.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The following code does not link correctly with all optimization levels on
windows with the mingw-w64-x86_64-g++ compiler.
```
#include
extern "C" void f() __a
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The code below comes from a template expansion (when certain cache feature is
disabled) and all the operation on the `buff` member are no-op.
```
#include
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582
--- Comment #6 from Yichao Yu ---
For the vfloat test case, isn't the optimum code just
```
addps %xmm2, %xmm0
addps %xmm3, %xmm1
retq
```
It's not making full use of the vector but I assume not having to spill is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606
--- Comment #1 from Yichao Yu ---
Compiled a GCC 9 snapshot for pr89607 and the issue is still present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607
--- Comment #8 from Yichao Yu ---
I see. I don't imagine this to cause a major local speed up though I assume it
should at least not be slower? That's also why I mentioned that this should at
least be done for `-Os`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607
--- Comment #6 from Yichao Yu ---
> For aarch64, there was talk about adding stp for q registers.
What do you mean? I was initially unsure about it too but I assume it already
exist since clang (and now GCC 9) emits it and the arm arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607
--- Comment #5 from Yichao Yu ---
I just compiled the 9-20190303 snapshot and this is indeed seems to be fixed.
Should this be closed now or after GCC 9 is released?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607
--- Comment #3 from Yichao Yu ---
Done pr89614
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Separated from pr89607 as requested. Test code and result compiled with any
non-zero optimization levels,
```
#include
void f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89607
--- Comment #2 from Yichao Yu ---
Sure. I'll do that.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Test code, Compiled for arm/aarch64 with -O1/-O2/-O3/-Os/-Ofast
```
#include
void f4(float32x4x2_t *p, const float *p1
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Code to reproduce,
```
#include
#ifdef __aarch64__
float64x2x2_t f(const double *p1, const double *p2)
{
float64x2x2_t v = vld2q_f64(p1);
return
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
For 256bit and 512bit vector return values, Clang and MSVC always returns them
in the corresponding registers even without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89581
--- Comment #1 from Yichao Yu ---
The problem is still there when compiled with -O2
```
f:
pushq %rbp
vmovq (%r8), %xmm1
movq%rcx, %rax
vmovq 8(%r8), %xmm0
vaddsd (%rdx), %xmm1, %xmm1
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
When testing the code for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89581 on
linux, I noticed that the code seems suboptimum
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
On windows, when compiling the following code with ` gcc -mavx2 a.c -o - -S -O3
-g0 -fno-asynchronous-unwind-tables -fomit-frame-pointer -Wall -Wextra`
```
typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #24 from Yichao Yu ---
Oh, and the test case above was compiled with -O3 (and -g -Wall -Wextra).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Yichao Yu changed:
What|Removed |Added
CC||yyc1992 at gmail dot com
--- Comment #23
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
I'm very surprised that I didn't find an issue for this so sorry if this is
discussed/rejected somewhere else.
It appears that both MSVC and clang supports a vectorcall calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #20 from Yichao Yu ---
Just want to mention that the lack of a way to locally change the arch settings
without lying to the compiler is exactly why I reported this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83110
--- Comment #2 from Yichao Yu ---
What might be invalid about the source?
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
This is very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
although that one is marked as fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #7 from Yichao Yu ---
It would be great if `+crc` can work if it's not ambiguous. Requiring
`arch=armv8-a+crc` works for me too, and it'll just require more preprocessor
checks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #3 from Yichao Yu ---
> ARMv8-a is the only architecture variant where the CRC extension is optional
Not really. There's also armv8-r and armv8-m. Also, I believe code compiled for
armv7-a can run on armv8-a hardware and can also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82641
--- Comment #1 from Yichao Yu ---
I've found a workaround in
https://sourceware.org/ml/binutils/2017-04/msg00171.html but it's extremely
ugly (albeit also very clever...).
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The assembler complains about the target not supporting CRC32 instructions for
certain (generic) targets on ARM and AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732
--- Comment #9 from Yichao Yu ---
Thanks for the fix!
Does it fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78366 at the same
time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732
--- Comment #6 from Yichao Yu ---
Good to know. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80732
--- Comment #4 from Yichao Yu ---
`double (*pf1)(double, double, double) = dlsym(hdl, "f1.ifunc");`
Wouldn't it be better if GCC generates local functions `f1.default`, `f1.fma`
as implementation and `f1` to replace `f1.ifunc`? It's quite
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Compiling the code below to a executable with `gcc -Wall -Wextra -O3 -fPIC -ldl
-rdynamic`. On a haswell+ system, the output is
```
1:
0, 4.93038e-32, 0
2:
4.93038e-32, 4.93038e-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
--- Comment #48 from Yichao Yu ---
Thanks for fixing this. I didn't follow all the comments since I'm not familiar
with the C++ ABI so just to make sure I understand what's happening is it that
the bug is caused by a inconsistency in C++ ABI for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
--- Comment #6 from Yichao Yu ---
Anything new here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
--- Comment #5 from Yichao Yu ---
Ping again? Anything new or I can help with here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
--- Comment #12 from Yichao Yu ---
Since the LLVM miscompilation isn't fixed, is there any way to check the alias
assumptions more programmatically? (I can see that the TrailingObject might
easily introduce something like this but given the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
--- Comment #4 from Yichao Yu ---
Ping. Anything I can help with debugging this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
--- Comment #11 from Yichao Yu ---
The case pointed out is fixed in https://reviews.llvm.org/rL284336 although as
expected that doesn't fix the error. Still not sure whose bug is this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
--- Comment #10 from Yichao Yu ---
That does look like an violation (this particular one should be hidden behind
shared library boundary in the reduced case though). Reported to LLVM at
https://llvm.org/bugs/show_bug.cgi?id=30711 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
--- Comment #8 from Yichao Yu ---
> Can you try with -fno-strict-aliasing ?
That seems to fix it for both the original case (LLVM) and the reduced case
(the linked tarball). Is there a way to figure out the problematic (either bug
in LLVM's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
--- Comment #6 from Yichao Yu ---
I've compiled a gcc at 951db45 using the same configuration as archlinux arm
PKGBUILD and I can reproduce the problem using the `code/` in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
--- Comment #5 from Yichao Yu ---
Compiling current llvm trunk (r284322) still shows the same error. The script I
used to compile LLVM is here
https://github.com/yuyichao/arch-pkg/blob/master/pkg/all/llvm-svn/PKGBUILD.
Compiling gcc 951db45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996
--- Comment #3 from Yichao Yu ---
> What exact version of LLVM are you trying to compile? Revision of the LLVM
> sources including revision of clang, etc.
I was compiling the trunk version. The version I started reducing from was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77997
--- Comment #2 from Yichao Yu ---
. Sorry the first submission gave me a time out so I did again..
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
I'm seeing a miscompilation of LLVM's tablegen on AArch64 by gcc 6.2.1 when LTO
is enabled. I've tried very hard to reduce it but unfortunately it wasn't very
successful this time
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
I'm seeing a miscompilation of LLVM's tablegen on AArch64 by gcc 6.2.1 when LTO
is enabled. I've tried very hard to reduce it but unfortunately it wasn't very
successful this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
--- Comment #2 from Yichao Yu ---
I should add that turning on lto works around the issue both in the simple code
attached and for the original issue I was having in julia (i.e. compiling llvm
with LTO makes the issue go away).
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Code to reproduce is at
https://gist.github.com/yuyichao/a66edb9d05d18755fb7587b12e021a8a. The two cpp
files are
```c++
#include
#include
typedef std::vector<std::p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #4 from Yichao Yu ---
Thanks for the explanation. I didn't realize that the load is the problem. Just
curious (since I somehow can't find documentation about it), would `ldaxp`
provide the right semantics without the corresponding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
--- Comment #7 from Yichao Yu ---
If I add `-fvariable-expansion-in-unroller` (omg this options is like half the
command line ;-p ...), the performance matches the clang one after the clang
3.8 regression.
```
% gcc -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71414
--- Comment #4 from Yichao Yu ---
The C code is in the gist linked `a` is a cacheline aligned pointer and `n` is
1024 so `a` should even fits in L1d, which is 32kB on both processors I
benchmarked.
More precise timing (ns per loop)
6700K
```
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
Ref https://llvm.org/bugs/show_bug.cgi?id=28002
C source code.
```c
__attribute__((noinline)) float sum32(float *a, size_t n)
{
/* a = (float*)__builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71056
--- Comment #4 from Yichao Yu ---
(Sorry I'm not sure how to understand that cross link). Is the fix merged?
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The following code generate a NEON instruction not available error when
compiling with `gcc -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -O3 -o
/dev/null -c a.c` on ARM
1 - 100 of 117 matches
Mail list logo
