https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115461
--- Comment #6 from Ilya Leoshkevich ---
Forgot to add: since the runtime is shared, this observation applies to both
GCC and LLVM.
$ gcc k.c -fsanitize=leak; ./a.out
0x5080
$ LSAN_OPTIONS=use_stacks=0 ./a.out
0x5080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115461
--- Comment #5 from Ilya Leoshkevich ---
The LLVM testsuite still passes.
Looking a bit deeper:
$ LSAN_OPTIONS=verbosity=1,log_pointers=1 ./a.out
[...]
0x5080
==1522380==LeakSanitizer: checking for leaks
[...]
==1522381==Scanning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115461
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #77 from Ilya Leoshkevich ---
Apparently fixing the message in GCC will produce maintenance overhead [1]. If
that's not very important to you, I'd rather leave this message as is.
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #76 from Ilya Leoshkevich ---
It's because the sanitizer runtime was copied from LLVM to GCC. I will post a
patch removing the unsupported MSan and DFSan from the error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404
--- Comment #4 from Ilya Leoshkevich ---
Thanks, cherry-picking
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a98d5130a6dcff2ed4db371e500550134777b8cf
helped both with the minimized testcase and the actual kernel bug. What you
describe there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404
--- Comment #2 from Ilya Leoshkevich ---
Created attachment 57745
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57745=edit
cc1 invocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114404
--- Comment #1 from Ilya Leoshkevich ---
Created attachment 57744
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57744=edit
preprocessed source
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
Reproducible with gcc commit 1b5510a59163.
I'm writing this up as a result of the following linux kernel discussion:
https://lore.kernel.org/bpf/c9923c1d-971d-4022-8dc8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284
--- Comment #6 from Ilya Leoshkevich ---
Created attachment 57014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57014=edit
patch v2
Thanks for the correction. I've noticed the function label and got tunnel
vision; .opd does indeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284
--- Comment #4 from Ilya Leoshkevich ---
Thanks, I can repro this on cfarm203 now. Apparently I missed
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 94fbf46f2b6..fd9bb807957 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113284
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113273
--- Comment #4 from Ilya Leoshkevich ---
I've pushed the fix. This can be closed as a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113251.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113273
--- Comment #3 from Ilya Leoshkevich ---
Thank you for the confirmation. I will push the fix as soon as my regtests
finish.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113273
--- Comment #1 from Ilya Leoshkevich ---
Hi, sorry about the regression. Could you please check if
https://inbox.sourceware.org/gcc-patches/20240108092434.554918-1-...@linux.ibm.com/
fixes that for you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99476
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113251
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
--- Comment #4 from Ilya Leoshkevich ---
Hi,
Nina fixed this in v8.0.0
(https://gitlab.com/qemu-project/qemu/-/commit/54fce97cfcaf5463ee5f325bc1f1d4adc2772f38).
The fix was backported to v7.2.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342
--- Comment #10 from Ilya Leoshkevich ---
This bug was fixed and backported to gcc-12:
commit 06254d97b8fa3a5d1c8b6b4e091d851700801385
Author: Ilya Leoshkevich
Date: Fri Jul 29 16:14:10 2022 +0200
PR106342 - IBM zSystems: Provide vsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
--- Comment #11 from Ilya Leoshkevich ---
I see. It would be good to update https://gcc.gnu.org/gcc-9/ then - e.g.
https://gcc.gnu.org/gcc-8/ says "This release series is no longer supported".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100853
--- Comment #1 from Ilya Leoshkevich ---
Created attachment 50903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50903=edit
repro
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
$ cat cp-tree-equal.cpp
typedef struct a *b;
template struct c
{ d({
b *e; __typeof (*({
__typeof *e f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100278
Ilya Leoshkevich changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
Minimized test:
$ cat test.c
a() {
register b asm("");
if (b)
b = 1;
for (; b;)
;
}
$ $HOME/gcc/build/di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #9 from Ilya Leoshkevich ---
Created attachment 50679
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50679=edit
regtesting this patch now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #8 from Ilya Leoshkevich ---
Yeah, inline asm seems to be problematic:
/home/iii/gcc/build/gcc/xgcc -B/home/iii/gcc/build/gcc/
/home/iii/gcc/gcc/testsuite/gcc.target/s390/vector/long-double-asm-hardreg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #5 from Ilya Leoshkevich ---
That would be an ideal solution, but I wonder how to implement it? Suppose we
find a way to convince expand to pick FPRX2mode for such a long double. What if
the following comes up?
register long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98738
--- Comment #1 from Ilya Leoshkevich ---
I realized I didn't post the command line I used to build task-detach-6.exe
(there are multiple variants of this test); here it is:
gcc/build/x86_64-pc-linux-gnu/libgomp/testsuite$
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
I'm currently on commit 2e43880dbd4c. Building task-detach-6.exe and running
it in a loop eventually leads to a hang (might take a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
Ilya Leoshkevich changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #10 from Ilya Leoshkevich ---
I've posted the combined fixincludes/tests/base/sys/types.h + genfixes patch
here: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561601.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #8 from Ilya Leoshkevich ---
Hm, can it be that fixincludes/tests/base/sys/types.h simply needs to be
updated?
For example, here is a similar commit:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #7 from Ilya Leoshkevich ---
Still a similar error:
sys/types.h /home/iii/gcc/fixincludes/tests/base/sys/types.h differ: byte 243,
line 12
*** sys/types.h 2020-12-09 15:57:57.575959676 +
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #5 from Ilya Leoshkevich ---
Oh, just in case: gcc121 is x86_64 CentOS Linux 7, not AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
--- Comment #4 from Ilya Leoshkevich ---
Unfortunately not, with this patch I get:
sys/types.h gcc/fixincludes/tests/base/sys/types.h differ: byte 243, line 12
*** sys/types.h 2020-12-09 15:46:15.843503181 +
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208
Ilya Leoshkevich changed:
What|Removed |Added
CC||nathan at acm dot org
--- Comment #1
: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
With the recent master (f1b6e17b3f75) make check fails (on gcc121 machine) as
follows:
sys/types.h gcc/regtest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113
--- Comment #6 from Ilya Leoshkevich ---
With the patch, vxe/popcount-1.c works on s390 again:
vpopctf:
.LFB2:
.cfi_startproc
vpopctf %v24,%v24
br %r14
Thanks!
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
s390's vxe/popcount-1.c began to fail after PR96789 fix.
The reason is that for the following source code
uv4si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866
--- Comment #3 from Ilya Leoshkevich ---
I believe it's already fixed by:
commit 253c415a1acba50711c82693426391743ac18040
Author: Vladimir N. Makarov
Date: Sun Nov 15 11:22:19 2020 -0500
Do not put reload insns in the last empty BB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866
--- Comment #2 from Ilya Leoshkevich ---
Never mind, I managed to reproduce it now:
ubuntu-focal-amd64$ git rev-parse --short HEAD
77f67db2a47
ubuntu-focal-amd64$ ../configure --target=s390x-linux-gnu --exec-prefix=/usr
--disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
The following (minimized from
gcc/testsuite/gcc.target/s390/zvector/autovec-double-signaling-eq.c) produces
an ICE on s390:
build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #17 from Ilya Leoshkevich ---
Created attachment 48917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48917=edit
aarch64 native build fix
Could you please try the attached patch? It fixed the issue for me, and
survived
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #16 from Ilya Leoshkevich ---
I finally managed to reproduce this by doing `./configure
--host=aarch64-none-linux-gnu` on gcc113. The problem is that `CXX_FOR_BUILD`
doesn't seem to be set correctly - normally it's `g++-4.8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #14 from Ilya Leoshkevich ---
gcc113 has 4.8.4, which is a bit newer. But in any case, according to
https://gcc.gnu.org/projects/cxx-status.html, gcc should support nullptr since
4.6.
Could you please post the failing compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #12 from Ilya Leoshkevich ---
I managed to bootstrap and regtest upstream commit 6e41c27bf549 on gcc113 farm
machine.
Two questions:
- What is your system compiler version? For GCC 11, C++11 compiler is required:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #11 from Ilya Leoshkevich ---
Sorry about that! I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #8 from Ilya Leoshkevich ---
Created attachment 48750
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48750=edit
proposed patch (tests are running)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #7 from Ilya Leoshkevich ---
Would it be OK then to replace last arguments of functions with
__attribute__((sentinel)) from NULLs to nullptrs? I can make a patch for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #5 from Ilya Leoshkevich ---
I'm sorry, I should not have written (uintptr_t)0 - I just used it as a synonym
for a "pointer-sized int". Would allowing 0L as a sentinel value be a
reasonable thing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #4 from Ilya Leoshkevich ---
Created attachment 48740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48740=edit
preprocessed output
In the preprocessed output I see that gcc's stddef.h is used, but most likely
`#define NULL
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
I'm trying to bootstrap gcc on gcc301 with --disable-multilib
--build=x86_64-alpine-linux-musl. The following error occu
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
gcc commit cf3a909cf455. Consider the following variation of pr65930-2.c:
$ cat pr65930-2b.c
#include "tree-vect.h"
int __attribute__((noipa))
bar (un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #29 from Ilya Leoshkevich ---
Created attachment 47463
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47463=edit
nop plugin
Hi Maxim,
Just to clear my conscience, could you please try the nop trick in your
setup? I normally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #27 from Ilya Leoshkevich ---
With
-DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -save-temps=obj -fopt-info-vec-optimized
-DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 -fgnu89-inline
on gcc113 I can see 2% slowdown:
r277511 (without this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #26 from Ilya Leoshkevich ---
Whoops, I accidentally used a script I normally use for big-endian
machines (s390 actually). But gcc113 is an APM X-Gene Mustang board.
I'll try again with your flags and see if I can reproduce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #24 from Ilya Leoshkevich ---
I got the following results on gcc113:
400.perlbench
Compiler flags: -DSPEC_CPU -DNDEBUG -DPERL_CORE -march=native -g -O3
-funroll-loops -fopt-info-vec-optimized -DSPEC_CPU -DNDEBUG -DPERL_CORE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #22 from Ilya Leoshkevich ---
Hello Maxim,
Sorry about that!
I don't think it's possible to simply move jump threading back, since
it's not correct to have it where it used to be. So I will build and
run the new and the old
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430
--- Comment #3 from Ilya Leoshkevich ---
Findings so far: when we forward an edge like this:
#0 redirect_edge_succ (e=0x76d73cc0, new_succ=0x76c2aa90) at
../.././gcc/cfg.c:368
#1 0x00a776ff in redirect_edge_succ_nodup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92430
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #15 from Ilya Leoshkevich ---
Created attachment 47059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47059=edit
proposed fix (without renaming the pass so far)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #14 from Ilya Leoshkevich ---
Created attachment 47058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47058=edit
temporary patch for finding out the number of threaded edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #12 from Ilya Leoshkevich ---
> Well, it apparently has found new jump threading opportunities after
> partition_blocks. Are such changes useful? Does it happen often?
It's still combine that was responsible for this particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92115
--- Comment #6 from Ilya Leoshkevich ---
> Am 16.10.2019 um 16:32 schrieb asolokha at gmx dot com
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92115
>
> --- Comment #4 from Arseny Solokha ---
> (In reply to Ilya Leoshkevich from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #10 from Ilya Leoshkevich ---
> Question is how to figure out which to do when.
I would always do the former before reload, and always the latter after
reload.
However, I have a concern regarding this approach: in more complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92115
--- Comment #3 from Ilya Leoshkevich ---
Thanks again, Jakub.
Arseny, how did you find this? Did you just run the regtest? I wonder why
didn't I see it during my test runs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #7 from Ilya Leoshkevich ---
How can we do this here?
When we make a decision to eliminate bb 5, all the "nearby" edges are
hot.
Having eliminated bb 5, we cannot avoid making bb 6 cold, since this
would violate CFG integrity: as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #5 from Ilya Leoshkevich ---
+1 regarding renaming, I just wanted to keep it simple here.
Landing pad issue aside, I'm beginning to wonder if we can have a jump
pass after reload at all? For example, if hotness of a basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #3 from Ilya Leoshkevich ---
Jump threading has converted this:
+-- 2/HOT +
| |
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91323
Ilya Leoshkevich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87206
--- Comment #1 from Ilya Leoshkevich ---
Gentle ping. Is there a way to make this work? I could look into implementing
this if someone points me in the right direction.
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
I'm implementing signaling comparisons on S/390 and I'm trying to figure out
whether or not LTGT is supposed to be signaling.
I've decided to check what Intel does, and ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89233
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902
--- Comment #7 from Ilya Leoshkevich ---
Apparently, for this specific case doing more of hard register copy
propagation is enough. I've just tried running pass_cprop_hardreg
before pass_thread_prologue_and_epilogue, and it helped.
So, would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87762
--- Comment #5 from Ilya Leoshkevich ---
Martin, I believe I fixed this one. Could you please give it another try?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902
--- Comment #5 from Ilya Leoshkevich ---
By the time shrink-wrapping is performed, which is after LRA
(pass_thread_prologue_and_epilogue, to be precise), aren't all spilling
decisions already made? Because if that's true, we have to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902
--- Comment #3 from Ilya Leoshkevich ---
Judging by the following comment in lra-coalesce.c, RA doesn't do this
intentionally:
Here we coalesce only spilled pseudos. Coalescing non-spilled
pseudos (with different hard regs) might result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902
--- Comment #1 from Ilya Leoshkevich ---
Bisect points to r265398: combine: Do not combine moves from hard
registers.
I wonder what would be the best place to fix this? I was thinking about
making shrink-wrapping try harder by not limiting the
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Target: s390x-linux-gnu
I've noticed that r265830 fails to shrink-wrap multiple early returns in
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87762
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747
--- Comment #2 from Ilya Leoshkevich ---
This is a little bit more complicated, because EQ_ATTR_ALT is valid only for
GENERATOR_FILEs. The regtest has just finished, so I will post the patch to
the mailing list now.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
Target: s390x-redhat-linux
SVN r265373 / git f9fd74d64e9:
$ f9fd74d64e9-install/bin/gcc -x c -O2 -c -
void b() {
int c = 1, d, e = 4096;
for (; c; c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417
--- Comment #6 from Ilya Leoshkevich ---
Candidate patch here:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01382.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417
--- Comment #5 from Ilya Leoshkevich ---
Ok, makes sense. I've just made a patch that adds the 5th, but it had to be
special-cased for GENERATOR_FILE, and thus doesn't look too nice. FORMAT[0] ==
'w' looks much cleaner.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417
--- Comment #3 from Ilya Leoshkevich ---
Valgrind has found an issue:
==12738== Invalid write of size 4
==12738==at 0x804CC48: attr_rtx_1 (genattrtab.c:518)
==12738==by 0x804CC48: attr_rtx(rtx_code, ...) (genattrtab.c:588)
==12738==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417
--- Comment #2 from Ilya Leoshkevich ---
Fails on i686-linux-gnu:
*** Error in `build/genattrtab': malloc(): memory corruption: 0x08e56da0 ***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xf755c38a]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87417
--- Comment #1 from Ilya Leoshkevich ---
Ouch! Somehow s2 got corrupted (the 2nd value can be either 0 or 1). I'm
looking at this now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309
--- Comment #7 from Ilya Leoshkevich ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309
--- Comment #4 from Ilya Leoshkevich ---
Do we also need to test m_test_pp_flags?
At least dump_context::emit_item does it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
$ cat test.cpp
void a() {}
$ g++ -c test.cpp -fopt-info-vec-optimized -O3
test.cpp:1:6: note: test.cpp:1:11: note
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
I tried to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080
--- Comment #12 from Ilya Leoshkevich ---
I've investigated foo3, foo4 and foo5, and came to the following
conclusions:
When foo3 is compiled with -march=z10 or later, cprop1 pass propagates
global's SYMBOL_REF value into UNSPECV_CAS. On
1 - 100 of 109 matches
Mail list logo
