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
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
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
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 or
: 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 of the
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"
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) is
: 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 to
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 +
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 b/gcc/multipl
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");
: 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
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 target
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 w
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:
.LFB
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, %eax
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 th
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 h
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
d
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=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 th
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, using
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=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 a
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
```
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96069
--- Comment #2 from Yichao Yu ---
Why should this feature be c only?
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 'preprocesso
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 #8 from Yichao Yu ---
OK, done. It would be nice to mention it on
https://gcc.gnu.org/contribute.html#patches
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=96539
--- Comment #4 from Yichao Yu ---
Wow that was fast... thx.
: 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=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.
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
++
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
real
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.
: 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 vectorca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
Yichao Yu changed:
What|Removed |Added
CC||yyc1992 at gmail dot com
--- Comment #23
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).
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
: 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
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
va
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
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: ---
Test code, Compiled for arm/aarch64 with -O1/-O2/-O3/-Os/-Ofast
```
#include
void f4(float32x4x2_t *p, const float *p1
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: ---
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 #3 from Yichao Yu ---
Done pr89614
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 #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 reference
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=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=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
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 A
: 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
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.
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=69550
Yichao Yu changed:
What|Removed |Added
CC||yyc1992 at gmail dot com
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458
Yichao Yu changed:
What|Removed |Added
CC||yyc1992 at gmail dot com
--- Comment #1
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
`std::atomic<__int128>::store` on aarch64 is not lock free and generates a
function call `__atomic_store_16`. However, required atomic instructions
(`stlxp`) exi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70814
--- Comment #2 from Yichao Yu ---
As an update, it seems that the llvm trunk recently switched to using
`__atomic_*` function call for int128 on all platforms (that I can test
anyway). I'm not sure how that decision is made or if there's any comm
: 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
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?
: 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=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
```
%
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 -fvariable-exp
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
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=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 incont
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 #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=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=77728
--- Comment #6 from Yichao Yu ---
Anything new here?
: 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=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...).
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 opt
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.
: 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.
(This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83110
--- Comment #2 from Yichao Yu ---
What might be invalid about the source?
: 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
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).
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
successf
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
successf
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..
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://githu
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 now
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://gist.github.com/yuyichao/6c24d4a4bc374425906138359a44479c/raw/f5e
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 code
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 #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=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 #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 compl
y: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
The following code compiles on clang++ but not on g++ 4.9.0.
```
struct A {
template
inline int
a()
{
return 0;
}
template
inline auto
b() -> de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61400
--- Comment #1 from Yichao Yu ---
Additional info.
It seems that G++ only raise this error when all of the following are met:
1. Both of the functions (the one that uses suffix return type and the one used
in the argument of decltype) must be no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61400
--- Comment #2 from Yichao Yu ---
Sorry I have just noticed that I forgot to include the error message...
```
gcc.cpp: In function 'int main()':
gcc.cpp:20:12: error: no matching function for call to 'A::b()'
a.b<2>();
^
gcc.cpp
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Target Milestone: ---
The following code gives a warning about control flow reaching the end of
function without returning a value even though the function will always reach
the `return 1;` statement and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68336
--- Comment #1 from Yichao Yu ---
Ref clang bug report https://llvm.org/bugs/show_bug.cgi?id=25521
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yyc1992 at gmail dot com
Created attachment 34903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34903&action=edit
PKGBUILD used to compile the cross compiling version of gcc
Duplicate of the problem repo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65255
--- Comment #1 from Yichao Yu ---
Created attachment 34904
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34904&action=edit
Source and output programs
1 - 100 of 123 matches
Mail list logo
