--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-01-03 23:27 ---
// final version :)
void abort (void);
int main ()
{
int a;
volatile int *b = &a;
a = 1;
if (*b != 1)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1824
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-03
22:59 ---
the .t17.ssa dump:
f (i1243D.1466)
{
volatile intD.0 * i2D.1471;
intD.0 * i1D.1470;
intD.0 iD.1469[2];
intD.0 D.1475;
intD.0 D.1474;
intD.0 D.1473;
volatile intD.0 * D.1472;
# BL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-03
22:41 ---
Here is the most reduced testcase:
void abort (void);
int f(int i1243)
{
int i[2], *i1 = i;
i[0] = 1;
volatile int *i2 = i1;
i2[1] = 1;
i1243 = 0;
return i2[1]+i2[0];
}
int main(void)
{
if(
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-03
21:10 ---
(In reply to comment #30)
(In reply to comment #31)
> I'm not sure if it's the root cause yet, or just an interesting rat hole, but
> we do not create any virtual operands for the *addr = statement
> (or fo
--- Additional Comments From law at redhat dot com 2005-01-03 21:07 ---
I'm not sure if it's the root cause yet, or just an interesting rat hole, but
we do not create any virtual operands for the *addr = statement
(or for any statement with volatile operands).
--
http://gcc.gnu.org
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-01-03 20:46 ---
// even smaller testcase:
void abort (void);
void radix_tree_tag_clear (int *node)
{
int *path[2], **pathp = path, height;
volatile int *addr;
height = 1;
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-03
19:12 ---
Hmm, the following statements don't have VOPS:
D.1145_20->offset = offset_19;
D.1146_22 = pathp_1->slot;
D.1145_21->node = D.1147_23;
D.1148_26 = D.1145_25->node;
D.1145_25->slot = D.1154_32;
D.1
--- Additional Comments From arend dot bayer at web dot de 2005-01-03
13:55 ---
Sorry, should have been a bit more specific probably:
gcc version 4.0.0 20050103 (experimental) (i686-pc-linux-gnu)
Kernel is 2.6.10, and the oops is triggered for me by the EXT3 code.
--
Wha
--
What|Removed |Added
Severity|normal |critical
Priority|P2 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From arend dot bayer at web dot de 2005-01-03
13:41 ---
Happens on x86 too (symptom is an oops on boot in radix_tree_tag_clear).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From ak at muc dot de 2004-12-19 15:55 ---
Problem still happens with 4.0.0 20041219
--
What|Removed |Added
Status|WAITING
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18
12:03 ---
We have reason to believe this bug is now fixed, but it is kind of
hard to test... Can you please retry with CVS HEAD?
--
What|Removed |Added
--
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
15:14 ---
methinks the bug is in this code:
/* ??? This bit ought not be needed. For any element not present
in the initializer, we should simply set them to zero. Except
we'd need
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
15:16 ---
My last comment of course does not concern this bug, oops sorry :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From law at redhat dot com 2004-12-13 22:15 ---
FWIW, I've walked through all the actions of DOM1 and AFAICT every change it
makes is correct. I would have to strongly suspect that DOM1 is not the problem
here, but is instead changing things in such a way as to ex
--- Additional Comments From law at redhat dot com 2004-12-13 21:01 ---
(In reply to comment #15)
> Confirmed, this looks like a jump threading bug.
> Before we have:
> goto ();
>
> :;
> D.7815_42 = pathp_2->node;
> tag_43 = tag_27;
> idx_44 = idx_6;
> D.7819_45 = D.7815_42->t
--- Additional Comments From law at redhat dot com 2004-12-13 20:46 ---
I see no evidence that 18241 has the same root case as 18694.
--
What|Removed |Added
OtherBugsDepending
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2004-11-28 09:17 ---
Subject: Re: [4.0 Regression] linux kernel loop gets miscompiled
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-28
> 01:28 ---
> Confirmed, this lo
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-28
01:28 ---
Confirmed, this looks like a jump threading bug.
Before we have:
goto ();
:;
D.7815_42 = pathp_2->node;
tag_43 = tag_27;
idx_44 = idx_6;
D.7819_45 = D.7815_42->tags[tag_43][idx_44];
if (D.7819_
--- Additional Comments From ak at muc dot de 2004-11-28 01:21 ---
When I comment out the first pass_dominator in tree-optimize.c and compile
with -O1 it works too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From ak at muc dot de 2004-11-28 01:05 ---
-O1 -fno-tree-dominator-opts seems to avoid the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From ak at muc dot de 2004-11-28 00:17 ---
Tried -fno-tree-ch. Didn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27
23:07 ---
Can you try with -fno-tree-ch (or -Os)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From ak at muc dot de 2004-11-25 00:22 ---
Problem still happens as of HEAD 041125
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-16
17:54 ---
Does this still happen?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From ak at muc dot de 2004-11-01 03:08 ---
To clarify the previous comment means that the problem is likely in the
first loop in the function, not in the second
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18241
--- Additional Comments From ak at muc dot de 2004-11-01 03:07 ---
I must correct myself slightly - the kernel oops I see is not the second
loop, but in the check before:
ret = *pathp[0].slot; <--- references either NULL or a bogus pointer
if (ret == NULL)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-01 02:36
---
The corresponding asm for the loop:
with -fno-ivopts:
L11:
ld r11,8(r10)
srd r2,r4,r7
addi r0,r7,-6
rldicl r2,r2,0,58
rldicl r7,r0,0,32
ld r9,0(r11)
sl
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-01 02:34
---
Also for the first loop, we look we do much worse code with -fivopts at least on
powerpc64:
With -fno-ivopts:
offset = (int) (unsigned int) (index >> (int) shift) & 63;
pathp = pathp.109 + 24B;
pathp-
--- Additional Comments From giovannibajo at libero dot it 2004-11-01 02:29
---
(In reply to comment #3)
> Zdenek, two questions:
> - Aren't ivtmp.128 and ivtmp.124 duplicates?
Uhm, forget about this :)
> - Since ivtmp.128 behaves exactly like pathp, there is a way to at least
preser
--- Additional Comments From giovannibajo at libero dot it 2004-11-01 02:26
---
The final tree dump of the loop with -O1 -fno-ivopts looks like this:
:;
nr = pathp->offset;
node = pathp->node;
D.7834 = &node->tags;
addr.9 = (volatile long int *) ((long unsigned int *) D.7834 + D
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-31 04:41
---
Does -fno-ivopts produce a correct code?
--
What|Removed |Added
Keywords|
32 matches
Mail list logo
