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=50088
--- Comment #8 from Ilya Enkovich 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 and the mismatched load/store
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #9 from Ilya Enkovich 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.
That should work.
A bet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #13 from Ilya Enkovich 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 mode for shift count.
We
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50088
--- Comment #15 from Ilya Enkovich 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, shift count
> is CL regardl
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=50164
--- Comment #2 from Ilya Enkovich 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.
>
> Now I have code size 419 (g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich changed:
What|Removed |Added
Attachment #25083|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
--- Comment #8 from Ilya Enkovich 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 as the
first reproducer.
Reprodu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164
Ilya Enkovich changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50962
--- Comment #2 from Ilya Enkovich 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 changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353
--- Comment #7 from Ilya Enkovich ---
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 update_ssa only in case of missing V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
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 to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #8 from Ilya Enkovich ---
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 on that.
> When initializing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #11 from Ilya Enkovich ---
(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 != INVALID_REGNUM)
> 4396fixed_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
--- Comment #14 from Ilya Enkovich ---
(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 me to keep this
> bug open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #8 from Ilya Enkovich ---
Created attachment 34569
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34569&action=edit
patch to disable warnings for array references generated by cunroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #9 from Ilya Enkovich ---
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 starting index value range.
An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #12 from Ilya Enkovich ---
(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. Thus I disable them
only in c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #13 from Ilya Enkovich ---
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 and avoid warnings.
diff --git a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
--- Comment #5 from Ilya Enkovich ---
(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 because of the same
symptom.
: 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=65002
--- Comment #6 from Ilya Enkovich ---
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 attribute.
Probably just ignore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317
--- Comment #11 from Ilya Enkovich ---
(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. This test case
demonstrates per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65044
--- Comment #1 from Ilya Enkovich ---
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 of Pointer Bounds
Checker and Addre
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
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=65105
--- Comment #2 from Ilya Enkovich ---
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])
(plus:DI (reg:DI 0 ax [o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167
--- Comment #1 from Ilya Enkovich ---
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 registers are filled with values befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167
--- Comment #4 from Ilya Enkovich ---
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 for reproducer:
diff --git a/gcc/conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167
--- Comment #6 from Ilya Enkovich ---
(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, there will be no bnd regs when this
: 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
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=33825&action=edit
Reproducer
There is a segfault in ipa-icf pass.
>g++ test.cpp -O2 -c
test.cpp:40:1: internal comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766
--- Comment #2 from Ilya Enkovich ---
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 SRA we call convert_callers_for_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63766
--- Comment #5 from Ilya Enkovich ---
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=63992
--- Comment #1 from Ilya Enkovich ---
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 ---
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 ---
Created attachment 34052
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34052&action=edit
reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #2 from Ilya Enkovich ---
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
become better.
This particul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64056
Ilya Enkovich changed:
What|Removed |Added
CC||enkovich.gnu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #3 from Ilya Enkovich ---
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 into one of them and the differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #5 from Ilya Enkovich ---
Created attachment 34112
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34112&action=edit
-g0 problem reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #6 from Ilya Enkovich ---
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.o >1.dump
>objdump_pl -d 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #7 from Ilya Enkovich ---
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.
-g0 case:
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #8 from Ilya Enkovich ---
With both patches applied bootstrap is OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64075
--- Comment #4 from Ilya Enkovich ---
(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 streamers were not fixed
appro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994
--- Comment #3 from Ilya Enkovich ---
(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 -mmpx
> -fcheck-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994
--- Comment #5 from Ilya Enkovich ---
(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 to implement Pointer
Bounds Checke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64075
--- Comment #7 from Ilya Enkovich ---
(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 on it. It failed on functions
> __mulsc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63994
--- Comment #7 from Ilya Enkovich ---
(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
> interoperability with C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64055
--- Comment #6 from Ilya Enkovich ---
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-chkp.c
index 0fb78cc..84886da
ormal
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=34189&action=edit
Reproducer
There is a performance r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64183
--- Comment #2 from Ilya Enkovich ---
(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 operator in the attache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #17 from Ilya Enkovich ---
(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 understand the problem correctly th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #21 from Ilya Enkovich ---
(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 ("ix86_bnd_prefixed_insn_p (insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #22 from Ilya Enkovich ---
Created attachment 34195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34195&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
--- Comment #26 from Ilya Enkovich ---
(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 ADJUST_INSN_LENGTH. You could then keep
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
--- Comment #12 from Ilya Enkovich ---
For r218506 bootstrap with BOOT_CFLAGS="-O2 -g -fcheck-pointer-bounds -mmpx" on
x86_64-unknown-linux-gnu is OK.
-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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734
--- Comment #10 from Ilya Enkovich ---
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 does
it affect optimizations?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734
--- Comment #12 from Ilya Enkovich ---
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 and after the patch)
{
sum = (
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=33259&action=edit
Reproducer
I get ICE when try to compile tests with big am
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: unassig...@gcc.
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 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; count > 0; count--, addr++ )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50037
--- Comment #8 from Ilya Enkovich 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 += *addr;
No multiplication by
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 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 reproducer:
n1 = (n1 + 1) & 1
80 matches
Mail list logo
