https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167
--- Comment #6 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Uroš Bizjak from comment #5)
(In reply to Ilya Enkovich from comment #4)
+ if (TARGET_MPX BND_REGNO_P (regno))
No need for TARGET_MPX check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167
--- Comment #1 from Ilya Enkovich enkovich.gnu at gmail dot com ---
For call arguments we usually store bounds passed in bounds tables and then
fill bounds passed in registers. But with -fschedule-insns we have order
changed and all hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167
--- Comment #4 from Ilya Enkovich enkovich.gnu at gmail dot com ---
ix86_function_arg_regno_p doesn't recognize bnd registers as args. Also
avoid_func_arg_motion doesn't work for BNDSTX because it is not a single set.
This patch works
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
In PIC code there are multiple cases when GOTOFF relocation is put into
register and then used in address expression instead of using relocation
directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65105
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com ---
For this test I see 'plus' and 'minus' ops have DI mode until RA and get GPR
pairs:
(insn 12 35 13 2 (parallel [
(set (reg:DI 0 ax [orig:98 D.1945 ] [98
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
XMM registers may be used for 64bit operations on 32bit target. It should make
code faster and free some GPRs.
Here is an example test where GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65044
--- Comment #1 from Ilya Enkovich enkovich.gnu at gmail dot com ---
ICE occurs due to NULL field attached to a constructor element used for
initialization of internal asan structure.
Overall I don't think we should allow simultaneous usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
--- Comment #11 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Vladimir Makarov from comment #10)
I guess it is easy to check by preventing pic pseudo generation.
i386 back-end doesn't support fixed PIC register any more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65002
--- Comment #6 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Is this actually an ICE on valid code? 'const' attribute seems incorrect here
similar to what we had in PR64353.
The problem comes from SSA inconsistency caused by the wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
--- Comment #5 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Jakub Jelinek from comment #4)
Does #c2 fix this, or is #c3 an unrelated bugreport that still needs fixing?
Problem is still seen after the fix. I put test here
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
After EBX was unfixed in i386 PIC target, we may see addresses of static
objects are loaded from GOT and placed to the stack for later usage. It allows
to reuse PIC register for other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #12 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Richard Biener from comment #10)
Ick - that will also paper over good warnings so I'd rather not do that.
I'm also worried about possible good warnings removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Created attachment 34569
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34569action=edit
patch to disable warnings for array references generated by cunroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #13 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Ranges have to be used for maxiter computations to have consistent analysis in
complete unroll and vrp. Following patch allows to refine maxiter estimation
using ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #9 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Nice solution for this problem would be to have a better estimation of maximum
loop iterations number. Currently array size and index step are used to get
the maximum ignoring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #14 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to David Malcolm from comment #13)
Ilya: I can't speak to the correctness of the above code or patch, but
r220044 fixes the original issue I ran into. Do you want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #11 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to David Malcolm from comment #10)
which led to investigating this code in ix86_conditional_register_usage:
4394 j = PIC_OFFSET_TABLE_REGNUM;
4395 if (j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com ---
different hooks(In reply to Jakub Jelinek from comment #5)
Can you explain it? Usually when this function is called,
pic_offset_table_rtx is NULL and your i386.h macro relies
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
This problem was actually found in 256.bzip2 benchmark codes compiled by GCC
5.0 on -O2. There is a small loop with bytes comparison which appeared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353
--- Comment #7 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Right, wrong const attribute causes no VUSE for calls to the function which
leads to # VUSE .MEM generated for added loads and requires SSA update.
We may actually call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #12 from Ilya Enkovich enkovich.gnu at gmail dot com ---
For r218506 bootstrap with BOOT_CFLAGS=-O2 -g -fcheck-pointer-bounds -mmpx on
x86_64-unknown-linux-gnu is OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #21 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Jeffrey A. Law from comment #20)
Ilya, it's the function call in this code I think:
(cond [(eq_attr length_nobnd !0)
(plus (symbol_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #22 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Created attachment 34195
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34195action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #26 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to rsand...@gcc.gnu.org from comment #25)
If all you want to do is add 1 byte to the length to account for a prefix
then it might be cleaner to use
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
Created attachment 34189
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34189action=edit
Reproducer
There is a performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64183
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Richard Biener from comment #1)
It works correctly for
int bits;
void
test ()
{
while (bits (unsigned int)25)
bits += 8;
}
Right. But shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #17 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Jorn Wolfgang Rennecke from comment #13)
AFAICS, the length attribute was broken in r217125
https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00133.html
If I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64055
--- Comment #6 from Ilya Enkovich enkovich.gnu at gmail dot com ---
TREE_INT_CST_LOW (maxval) assumes integer constant anyway. Therefore we may
use simpler check. It fixes gnat.dg/derived_aggregate.adb.
diff --git a/gcc/tree-chkp.c b/gcc/tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994
--- Comment #7 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to rguent...@suse.de from comment #6)
I see. I mainly wonder because of LTO which can combine TUs from C
and Ada and because for example both Fortran and Ada define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com ---
With both patches applied bootstrap is OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64075
--- Comment #4 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to H.J. Lu from comment #3)
It was caused by r217655.
The problem was introduced earlier when function_code field in
tree_function_decl was extended to 12 bits. LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994
--- Comment #3 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to rguent...@suse.de from comment #2)
TARGET_CFLAGS=-O2 -g -mmpx -fcheck-pointer-bounds TARGET_CXXFLAGS=-O2
-g -mmpx -fcheck-pointer-bounds BOOT_CFLAGS=-O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994
--- Comment #5 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to rguent...@suse.de from comment #4)
Any reason why non-C-family languages cannot use MPX?
Richard.
There is no fundamental restriction. If someone wants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64075
--- Comment #7 from Ilya Enkovich enkovich.gnu at gmail dot com ---
(In reply to Dmitry Gorbachev from comment #6)
The patch works, thanks! But the committed test is incorrect, because the
original, unpatched compiler, does not fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64056
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #3 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Patch removing duplicating bounds symbols is in review. With this patch
applied bootstrap goes till the end but there are lots of stage2 and stage3
comparison error. I looked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #5 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Created attachment 34112
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34112action=edit
-g0 problem reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #6 from Ilya Enkovich enkovich.gnu at gmail dot com ---
For attached -g0 problem reproducer:
gcc pr63995-2.c -c -O2 -mmpx -fcheck-pointer-bounds -g -o 1.o
gcc pr63995-2.c -c -O2 -mmpx -fcheck-pointer-bounds -g0 -o 2.o
objdump_pl -d 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #7 from Ilya Enkovich enkovich.gnu at gmail dot com ---
In chkpopt pass calls to bndmk are moved down to uses to decrease register
pressure. Debug info introduces new uses and therefore it affects a position
where bndmk calls appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63992
--- Comment #1 from Ilya Enkovich enkovich.gnu at gmail dot com ---
It is a part of already approved patch
(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02317.html) which waits for MPX
runtime to be approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994
--- Comment #1 from Ilya Enkovich enkovich.gnu at gmail dot com ---
What does bootstrap with -fcheck-pointer-bounds -mmpx mean? Any instruction
on how to reproduce?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #1 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Created attachment 34052
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34052action=edit
reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com ---
I had a successful bootstrap with instrumentation some time ago but it's not
performed regularly.
We are extending regression testing for instrumentation now and coverage should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766
--- Comment #5 from Ilya Enkovich enkovich.gnu at gmail dot com ---
I forgot to mention PR in a ChangeLog. Patch is in trunk:
https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00707.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Problem caused by the fact that now all function come to local optimizations in
SSA form. It affects inline parameters computation and therefore inlining
order.
During early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
Created attachment 33825
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33825action=edit
Reproducer
There is a segfault in ipa-icf pass.
g++ test.cpp -O2 -c
test.cpp:40:1: internal compiler error
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
I see ICE when try to compile a small test with -gcoff. Problem appears when
we have structure field and static variable with the same name. Here is a
reproducer:
typedef struct {
int *next
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
Created attachment 33259
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33259action=edit
Reproducer
I get ICE when try to compile tests with big amount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734
--- Comment #10 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Thanks for the fix!
Is there any reason for ABS_EXPR detection for not working on 64bit target for
the same test? The only difference should be the long long type size. How
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734
--- Comment #12 from Ilya Enkovich enkovich.gnu at gmail dot com ---
Before your last fix both 32bit and 64bit versions of .original look similar
except a condition. We have (a - b 0) for 64 bit and (a b) for 32bit.
64bit version (before
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
Recently a performance regression occurred in tests heavily using ABS
computation (observed on x86 and ARM targets). It is caused by missing
ABS_EXPR recognition which results in sub-optimal
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
Test gcc/testsuite/g++.dg/vect/pr60023.cc -fno-tree-dce fails with ICE if
executed with additional -fno-tree-dce flag.
As I can see the problem is in generated mask load which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57055
Bug #: 57055
Summary: Incorrect CFG after transactional memory passes
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50962
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-11-02
13:05:46 UTC ---
Created attachment 25689
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25689
Proposed patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50962
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
CC||enkovich.gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
Attachment #25083|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
--- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-30
10:50:44 UTC ---
I attached a fixed reproducer. It is closer to the original test and has higher
registers pressure then the previous version. It has the same problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich enkovich.gnu at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-25
09:31:29 UTC ---
(In reply to comment #1)
Yesterday I sent a patch
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01954.html which most probably
solved the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Bug #: 50164
Summary: [IRA, 4.7 Regression] Performance degradation due to
increased memory instructions count
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #13 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-17
09:07:20 UTC ---
(In reply to comment #12)
Created attachment 25025 [details]
A patch to use the same mode for shift count
This is an untested patch to use the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #15 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-17
14:16:27 UTC ---
(In reply to comment #14)
I think this problem is unique to x86 since some instructions have
different sizes in register operands. In this example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-16
06:55:34 UTC ---
(In reply to comment #4)
Well, yes, I think the proposal was to spill/load the full SImode instead
which would avoid both the partial dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #9 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-16
07:28:33 UTC ---
(In reply to comment #5)
It is for movqi. We can only safely replace mozbl with movl if
the source is 4byte aligned. It should a new backend option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50037
--- Comment #8 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-15
09:06:18 UTC ---
This patch did not work for me. Tried on following loop (-O2 -funroll-loops):
for ( count = ((*(hdrptr)) 0x7); count 0; count--, addr++ )
sum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
Bug #: 50088
Summary: movzbl is generated instead of movl
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-15
13:24:05 UTC ---
Actually we do not need any zero extensions here. Zero extended load appears
only after IRA if we have to spill/fill register.
Here is c code from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50037
Bug #: 50037
Summary: Unroll factor exceeds max trip count
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50037
--- Comment #2 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-10
15:33:22 UTC ---
I wouldn't blame vectorizer here. Following loop is unrolled with unroll factor
8 even if vectorizer is disabled:
for ( count = ((*(hdrptr)) 0x3) * 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49959
Summary: ABS pattern is not recognized
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo:
80 matches
Mail list logo
