-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kirill.yukhin at intel dot com
Hello,
While building Linux using recent GCC trunk I've got ICE:
CC kernel/locking/spinlock.o
kernel/locking/spinlock.c: In function ‘_raw_read_unlock_bh’:
kernel/locking/spinlock.c:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617
--- Comment #16 from Yukhin Kirill ---
(In reply to Dominique d'Humieres from comment #15)
> 19:02:01.0 +0100
> +++ gcc/testsuite/gcc.target/i386/avx512f-gather-5.c 2014-04-03
> 15:17:05.0 +0200
> @@ -1,5 +1,6 @@
> /* { dg-do com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59617
--- Comment #11 from Yukhin Kirill ---
Maybe simply do:
#ifdef __restrict
#undef __restrict
In some common header (say, avx512f-check.h)?
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kirill.yukhin at intel dot com
Hello,
This case is not vectorized:
$ cat f2.f
subroutine foo(a,x,y,n)
implicit none
integer n,i
real*8 y(n),x(n),a
do i=1,n
a=a+x(i)*y(i)+x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #11 from Yukhin Kirill ---
(In reply to Yukhin Kirill from comment #9)
> (In reply to Jakub Jelinek from comment #6)
> > Prerelease samples shouldn't count, people using those just can avoid using
> > -march=haswell and use -march=ivyb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59952
--- Comment #9 from Yukhin Kirill ---
(In reply to Jakub Jelinek from comment #6)
> Prerelease samples shouldn't count, people using those just can avoid using
> -march=haswell and use -march=ivybridge -mavx2 or similar instead. Can
> anyone from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808
--- Comment #11 from Yukhin Kirill ---
(In reply to Uroš Bizjak from comment #10)
> (In reply to Uroš Bizjak from comment #9)
>
> > This is not a good ChangeLog entry. You should say somethin along
> >
> > * gcc.target/i386/sse-14.c: Update con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808
--- Comment #5 from Yukhin Kirill ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > Kirill, please update also sse-13.c with new builtins.
>
> And sse-12.c with new options.
Sure, I think this is obvio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808
--- Comment #4 from Yukhin Kirill ---
(In reply to Uroš Bizjak from comment #2)
> Kirill, please update also sse-13.c with new builtins.
Fix is posted as part of:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00761.html
I may strip it into separat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59797
--- Comment #1 from Yukhin Kirill ---
Sorry, didn't get the problem.
According to output you provided - GCC warns ABI changes
Here is analogue for AVX2:
$ cat 2.c
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59754
--- Comment #6 from Yukhin Kirill ---
(In reply to Jeffrey A. Law from comment #3)
> Kirill, can you verify that Jakub's patch restores proper behaviour for your
> tests? It'd be greatly appreciated.
Hello,
I've checked recent trunk with Jakub's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59754
--- Comment #1 from Yukhin Kirill ---
> made bunch of AVX-512F tests failing (at runtime):
FAIL: gcc.target/i386/avx512f-vpmovsxdq-2.c execution test
FAIL: gcc.target/i386/avx512f-vpmovsxwd-2.c execution test
FAIL: gcc.target/i386/avx512f-vpmovzxd
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kirill.yukhin at intel dot com
Hello,
It seems that this revision:
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@206418
138bc75d-0d04-0410-961f-82ee72b054a4
made bunch of AVX
IRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kirill.yukhin at intel dot com
Created attachment 31529
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31529&action=edit
Reproducer
Hello, I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #5 from Yukhin Kirill ---
I see. So, it seems like a limitation to passing vectors as arguments in 32-bit
mode. We may implement something similar to `vzerroupper' autogeneration or
simply close the bug as `user misunderstanding.'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #3 from Yukhin Kirill ---
(In reply to Uroš Bizjak from comment #1)
> There is no testcase attached, but you need to *manually* insert _mm_empty
> (== emms) to switch from MMX to x87 state.
>
> The compiler does not automatically inse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #2 from Yukhin Kirill ---
Created attachment 31389
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31389&action=edit
Testcase
ponent: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kirill.yukhin at intel dot com
Hello,
Attached test reproduces the error:
$ gcc -m32 -mmmx 1.c
$ ./a.out
Aborted (core dumped)
Disassembly of the foo is:
foo32x2_be:
.LFB0:
pushl %ebp# 22*p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52731
--- Comment #1 from Yukhin Kirill ---
Reproduced on recent trunk.
It seems that we have in ia64.c:
int
ia64_st_address_bypass_p (rtx producer, rtx consumer)
{
rtx dest, reg, mem;
gcc_assert (producer && consumer);
dest = ia64_single_set (p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58421
Yukhin Kirill changed:
What|Removed |Added
CC||kirill.yukhin at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #4 from Yukhin Kirill ---
> Could some one check if the generated code is now correct ?
Patch works both on attached AVX2 testcase and on root AVX-512 issue, thanks.
I think it should be submitted to gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #1 from Yukhin Kirill ---
Actually, this case come while debugging Spec2000's perl workload on AVX-512
changes (with bigger tripcount).
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kirill.yukhin at intel dot com
Created attachment 30635
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30635&action=edit
Reproducer
Hello attached test produces ICE, when compiled as
$ gcc -S -O3 1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56741
Bug #: 56741
Summary: Why not to perform 128-bit vector iteration when
vectorizing loop by 256-bit
Classification: Unclassified
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54564
--- Comment #3 from Yukhin Kirill 2012-09-13
11:57:35 UTC ---
Fails also occur on real HW.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54156
Bug #: 54156
Summary: New fail on AVX target: gcc.dg/vect/pr53773.c. 190010
vs revision 189996
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53877
--- Comment #3 from Yukhin Kirill 2012-07-20
08:58:17 UTC ---
Done.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
--- Comment #2 from Yukhin Kirill 2012-05-22
08:22:12 UTC ---
(In reply to comment #1)
> Please provide a testcase to show the problem.
I have no idea, which kind of test it should be.
These is just MS-ICC-GCC incompatibility issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
Yukhin Kirill changed:
What|Removed |Added
CC||areg.melikadamyan at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53435
--- Comment #2 from Yukhin Kirill 2012-05-21
12:17:41 UTC ---
(In reply to comment #0)
>
> gcc.c-torture/execute/vshuf-v* and gcc.dg/torture/pr45720.c fail.
>
This occurs on AVX2-capable HW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399
--- Comment #11 from Yukhin Kirill 2012-05-21
11:02:07 UTC ---
>
> Please test the attached patch. The patch checks CCCmode for TARGET_BMI in ffs
> patterns.
Hi Uros, seems your patch fixes the problem, here is piece of asm from
testcase:
...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399
--- Comment #6 from Yukhin Kirill 2012-05-20
15:54:38 UTC ---
>
> Can you please isolate failing test?
Sure, it is attached.
It works when compiled this way:
/export/home/kyukhin/gcc/build/build-x86_64-linux/gcc/xgcc
-B/export/home/kyukhin/gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399
--- Comment #5 from Yukhin Kirill 2012-05-20
15:54:08 UTC ---
>
> Can you please isolate failing test?
Sure, it is attached.
It works when compiled this way:
/export/home/kyukhin/gcc/build/build-x86_64-linux/gcc/xgcc
-B/export/home/kyukhin/gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399
--- Comment #4 from Yukhin Kirill 2012-05-20
15:53:30 UTC ---
Created attachment 27449
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27449
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399
--- Comment #1 from Yukhin Kirill 2012-05-18
13:58:22 UTC ---
(In reply to comment #0)
> It also seems to fail gcc.c-torture/execute/builtin-bitops-1.c
It fails on BMI-capable CPU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53399
Bug #: 53399
Summary: "*ffs" pattern generates wrong code with BMI enabled
(for corner cases)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #2 from Yukhin Kirill 2012-05-09
16:53:12 UTC ---
(In reply to comment #1)
> Testcase?
It is trivial, so posting right here:
#include
unsigned a;
int
rtm_xtest (void)
{
if (_xtest ())
a = 1;
}
./build-x86_64-linux/gcc/xgcc -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
Bug #: 53291
Summary: Code generated for xtest is wrong
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53194
--- Comment #4 from Yukhin Kirill 2012-05-03
07:02:50 UTC ---
(In reply to comment #3)
> Created attachment 27299 [details]
> Proposed solution
Attached patch cures failing tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53194
--- Comment #3 from Yukhin Kirill 2012-05-03
07:01:37 UTC ---
Created attachment 27299
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27299
Proposed solution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53201
--- Comment #2 from Yukhin Kirill 2012-05-03
05:15:47 UTC ---
Tobias, bootstrap (-march=native) is passing with your fix.
If nobody objects, I'll commit it as obvious fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53201
Yukhin Kirill changed:
What|Removed |Added
CC||kirill.yukhin at intel dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53194
--- Comment #2 from Yukhin Kirill 2012-05-02
19:20:59 UTC ---
The problem is here:
+
+ sprintf (hle_macro, "__ATOMIC_HLE_ACQUIRE=%d", IX86_HLE_ACQUIRE);
+ def_or_undef (parse_in, hle_macro);
+
+ sprintf (hle_macro, "__ATOMIC_HLE_RELEASE=%d", I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53192
Bug #: 53192
Summary: Incorrect arguments to AVX2's gather intrinsics
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
--- Comment #3 from Yukhin Kirill 2012-04-17
17:00:34 UTC ---
(In reply to comment #2)
> Uh...
>
> Index: config/i386/sync.md
> ===
> --- config/i386/sync.md (revision 186501)
> +++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
--- Comment #1 from Yukhin Kirill 2012-04-17
16:23:26 UTC ---
Instead, of single `locked` instruction, it generates:.L2:
movl%eax, %ecx
orl $1, %ecx
lock cmpxchgl %ecx, (%edx)
Similar variant for AND operation:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53020
Bug #: 53020
Summary: __atomic_fetch_or doesn't generate `1 insn` variant
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932
--- Comment #4 from Yukhin Kirill 2012-04-12
13:51:26 UTC ---
Created attachment 27140
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27140
Updated patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932
--- Comment #5 from Yukhin Kirill 2012-04-12
13:52:26 UTC ---
(In reply to comment #2)
> Created attachment 27133 [details]
> Proposed patch
>
> Kirill, can you please test proposed patch on AVX2 target?
Uros, I've slightly updated your patch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52932
Yukhin Kirill changed:
What|Removed |Added
CC||kirill.yukhin at intel dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50823
Yukhin Kirill changed:
What|Removed |Added
CC||kirill.yukhin at intel dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766
--- Comment #6 from Yukhin Kirill 2011-10-19
13:09:30 UTC ---
Thread on gcc-patches ML:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01719.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766
--- Comment #5 from Yukhin Kirill 2011-10-19
09:48:51 UTC ---
(In reply to comment #4)
> (In reply to comment #2)
> > Hi,
> > this is obviously a bug (introduced by me).
> > Memory operand in GCC notation must occur at first place.
>
> Please no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766
--- Comment #3 from Yukhin Kirill 2011-10-19
09:38:22 UTC ---
Created attachment 25553
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25553
Patch
I am testing it by now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50766
--- Comment #2 from Yukhin Kirill 2011-10-19
09:37:17 UTC ---
Hi,
this is obviously a bug (introduced by me).
Memory operand in GCC notation must occur at first place.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #6 from Yukhin Kirill 2011-10-05
15:43:54 UTC ---
This was caused by
gcc.gnu.org/svn/gcc/trunk@179553
Previous one bootstraps ok:
gcc.gnu.org/svn/gcc/trunk@179549
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
--- Comment #1 from Yukhin Kirill 2011-10-05
14:36:19 UTC ---
Revision 179538 is ok.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50621
Bug #: 50621
Summary: [4.7 Regression] Bootstrap failure
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543
--- Comment #7 from Yukhin Kirill 2011-09-28
19:42:52 UTC ---
Anybody but me and Evgeny can confirm that?
I've tried really general path of build it and got fail to compare different
stages...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543
--- Comment #5 from Yukhin Kirill 2011-09-28
07:30:46 UTC ---
(In reply to comment #4)
> I have no problem with
>
> /export/gnu/import/git/gcc-release/configure --enable-clocale=gnu
> --with-system-zlib --with-demangler-in-ld --enable-languages=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543
--- Comment #2 from Yukhin Kirill 2011-09-27
16:17:15 UTC ---
(In reply to comment #1)
> what do you mean latest 4.6.0? the 4.6.0 release, or the latest sources on
> the
> 4.6 branch? (which will become 4.6.2)
Latest sources. Sorry for misunde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543
Bug #: 50543
Summary: Bootstrap fails to build for latest 4.6.0
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480
--- Comment #4 from Yukhin Kirill 2011-09-27
08:31:35 UTC ---
(In reply to comment #3)
> For 32bit only it seems. Supposedly a cost model issue, the register pressure
> will be higher and we have only half the number of SSE regs.
Richard, what'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480
--- Comment #2 from Yukhin Kirill 2011-09-22
10:33:06 UTC ---
Here is optset details:
base=-static -O2 -ffast-math ("-m32 -msse2 -mfpmath=sse" if 32 bit mode)
peak=-static -O3 -funroll-loops -ffast-math ("-m32 -msse2 -mfpmath=sse" if 32
bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480
--- Comment #1 from Yukhin Kirill 2011-09-22
10:00:34 UTC ---
Checkin URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177368
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50480
Bug #: 50480
Summary: 10% performance regression on Spec2006 410.bwaves
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50185
--- Comment #4 from Yukhin Kirill 2011-08-26
12:04:59 UTC ---
(In reply to comment #3)
> I don't think using -dp and matching insn names is a good approach, any time
> you macroize the insns or rename you'll need to adjust the tests.
> You can tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50185
Yukhin Kirill changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50155
--- Comment #1 from Yukhin Kirill 2011-08-22
18:52:40 UTC ---
Hi,
thanks, for investigation.
Here is a patch:
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01808.html
K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
--- Comment #1 from Yukhin Kirill 2011-08-17
13:41:58 UTC ---
Created attachment 25033
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25033
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107
Bug #: 50107
Summary: [IRA, i386] allocates regiters in very non-optimal way
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50074
--- Comment #8 from Yukhin Kirill 2011-08-16
08:48:21 UTC ---
Hi,
I agree, this is a performance regression. Fix to tail-call optimization made
it very conservative. By using some additional tweaks, we may relax it.
However, my fix cured a stabil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964
--- Comment #1 from Yukhin Kirill 2011-08-03
14:28:55 UTC ---
Started from here
http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00051.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49964
Summary: Bootstrap failed with AVX turned on
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49547
Yukhin Kirill changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49547
Yukhin Kirill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49547
--- Comment #2 from Yukhin Kirill 2011-07-27
05:04:04 UTC ---
Patch prepared.
Discussion is here:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02266.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #22 from Yukhin Kirill 2011-07-06
11:57:21 UTC ---
(In reply to comment #21)
> On Wed, 6 Jul 2011, kirill.yukhin at intel dot com wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
> >
> > ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #20 from Yukhin Kirill 2011-07-06
11:50:51 UTC ---
With patch attached both tescase and 447.dealII passing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #19 from Yukhin Kirill 2011-07-06
11:49:34 UTC ---
Created attachment 24701
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24701
Patch to make tailcall check more conservative
Attached patch adds another check for clobbered stac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #16 from Yukhin Kirill 2011-07-06
10:35:03 UTC ---
Yes.
This is because expander prepares arguments like this:
...
(insn 6 5 7 2 (parallel [
(set (reg:SI 64)
(plus:SI (reg/f:SI 53 virtual-incoming-args)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #14 from Yukhin Kirill 2011-07-06
10:25:01 UTC ---
Created attachment 24700
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24700
Reduced testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #13 from Yukhin Kirill 2011-07-06
08:47:20 UTC ---
I agree, that there is no problem with GIMPLE. As I mentioned we may just
forbid tailcall opt for non-MEMREFS, but I suspect it will lead to significant
perf. degradation.
BTW, I am
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49639
Summary: [4.7 Regression] 447.dealII in SPEC CPU 2006 runtime
fail
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #9 from Yukhin Kirill 2011-06-30
15:37:04 UTC ---
One more point for FE guys.
Function definition have no difference between 4 args. Here it is
include/base/thread_management.h:
template
static inline void do_call (P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #8 from Yukhin Kirill 2011-06-30
15:26:36 UTC ---
If someone really need a quick fix, it may be done like this:
gcc/expor.s:
static bool
mem_overlaps_already_clobbered_arg_p (rtx addr, unsigned HOST_WIDE_INT size)
{
HOST_WI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #7 from Yukhin Kirill 2011-06-30
15:22:58 UTC ---
Expanding arguments in different ways occurs because corresponding GIMPLE
statements are of different types.
For 'good' case we have expression of type
COMPONENT_REF
While for 'bad'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #6 from Yukhin Kirill 2011-06-30
15:11:41 UTC ---
I've looked into tail-call opt. Seems we need not call it at all if we have
new/old stack addresses for parameters overlap. BTW, I think it is to
conservative, anyway...
We have call t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #5 from Yukhin Kirill 2011-06-29
12:24:25 UTC ---
Problem here is that GCC incorrectly stores arguments to stack in case of
tail-call opt.
Here is snippet
movl40(%esp), %eax
movl%eax, 28(%esp)
movl3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #4 from Yukhin Kirill 2011-06-29
05:06:04 UTC ---
I've dived into the problem yesterday.
Seems the problem is connected with tail call optimization.
The refined difference is below. Assembler is extracted from step-14.cc
Tail call op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49547
Summary: LZCNT should be enabled only if ABM or LZCNT bits are
set
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49465
--- Comment #4 from Yukhin Kirill 2011-06-22
04:23:34 UTC ---
(In reply to comment #3)
> Fix looking good. Doing a cpu2k6 int test right now.
Jeffrey, could you please share your patch?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49002
--- Comment #2 from Yukhin Kirill 2011-05-18
08:24:10 UTC ---
Created attachment 24278
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24278
The patch
Hi,
Here is fix for the bug. I made bootrstrap and make check on 4.6
BTW, it also have to
93 matches
Mail list logo
