Hi everybody,
Im interested whether there is gcc support (at the RTL
level) after unrolling which allows to disambiguate
memory accesses present in RTL constructs (specially
among memory accesses generated due to unrolling) for
machines that do not support indexed addressing modes.
I am aware of
Alexandre Oliva <[EMAIL PROTECTED]> writes:
| On Jan 26, 2006, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| > I don't see anything in the ISO C standard that implies that.
|
| > This
|
| > x.v1 = 384;
| > x.v2 = 94.08;
| > int v = x.v2;
| > x.v1 = v;
|
| > is valid fragment
On Jan 26, 2006, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> I don't see anything in the ISO C standard that implies that.
> This
> x.v1 = 384;
> x.v2 = 94.08;
> int v = x.v2;
> x.v1 = v;
> is valid fragment.
But can you see anything in it that makes it undefined?
Failing t
Michael Veksler <[EMAIL PROTECTED]> writes:
| So, is union is a very useful feature in ISO C, without
| gcc's extension? It seems that the only legal use of union
| is to use the same type through the whole life of the object.
|
| Here is the rationale:
|
| Quoting Richard Guenther <[EMAIL PROTE
So, is union is a very useful feature in ISO C, without
gcc's extension? It seems that the only legal use of union
is to use the same type through the whole life of the object.
Here is the rationale:
Quoting Richard Guenther <[EMAIL PROTECTED]>:
> On 1/25/06, Alexandre Oliva <[EMAIL PROTECTED]> w
On Jan 26, 2006, Richard Guenther <[EMAIL PROTECTED]> wrote:
>> So it is perfectly valid, but if GCC reorders the read from *ip past
>> the store to *dp, it turns the valid program into one that misbehaves.
> *ip = 15; ii = *ip; *dp = 1.5; dd = *dp;
> Here^^^
> you are accessi
On 1/25/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Jan 22, 2006, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > On 1/22/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> >> I don't think it is any different. GCC's exception for unions only
> >> applies if the object is accessed using th
On Jan 22, 2006, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 1/22/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> I don't think it is any different. GCC's exception for unions only
>> applies if the object is accessed using the union type. So they are
>> indeed equivalent. The scary thin
* Richard Guenther <[EMAIL PROTECTED]> [060122 14:23]:
> [...] The correct solution for converting
> a float to an integer (bit-representation) as in the expample is to use
> two different memory locations and memcpy (which avoids aliasing
> issues by means of using the special rules for access thr
Ian Lance Taylor wrote:
> Yeah, I think I'm going to step back from trying to argue what is and
> is not valid. To cut to the chase, I think the best approach for this
> particular problem is to wholly avoid having union types share the
> same stack slot.
RTH agrees with you.
Upon reading the th
Richard Sandiford <[EMAIL PROTECTED]> writes:
> I was just trying to point out that Ian's claim that the original code
> was valid doesn't reflect what GCC implements.
Yeah, I think I'm going to step back from trying to argue what is and
is not valid. To cut to the chase, I think the best approa
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Sun, 22 Jan 2006, Richard Sandiford wrote:
>
>> I'm going to regret this, but... I don't follow. How is Kai's testcase
>> different from:
>>
>> int ii;
>> double dd;
>> void foo (int *ip, double *dp)
>> {
>> *ip = 15;
>> ii = *ip;
>> *dp =
On Sun, 22 Jan 2006, Richard Guenther wrote:
> ISO C says that the following violates aliasing rules:
>
> int foo(float f)
> {
> union { int i; float f; } u;
> i.f = f;
> return i.i;
> }
>
> because the memory at u is accessed as two different effective types.
> Using a union doesn't chang
On Sun, 22 Jan 2006, Richard Sandiford wrote:
> I'm going to regret this, but... I don't follow. How is Kai's testcase
> different from:
>
> int ii;
> double dd;
> void foo (int *ip, double *dp)
> {
> *ip = 15;
> ii = *ip;
> *dp = 1.5;
> dd = *dp;
> }
>
> void test (void)
> {
> union
On 1/22/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> I don't think it is any different. GCC's exception for unions only
> applies if the object is accessed using the union type. So they are
> indeed equivalent. The scary thing is that I don't think they
> actually violate the ISO C strict a
On Jan 22, 2006, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor writes:
>> [EMAIL PROTECTED] (Kai Henningsen) writes:
>>> void test(void) { union { int i; double d; } u;
>>> int *ip; double *dp; int ii; double dd;
>>> ip = &u.i; *ip = 15; ii = *ip; dp = &u.d; *dp = 1.5; dd =
Ian Lance Taylor writes:
> [EMAIL PROTECTED] (Kai Henningsen) writes:
>> void test(void)
>> {
>> union { int i; double d; } u;
>> int *ip;
>> double *dp;
>> int ii;
>> double dd;
>>
>> ip = &u.i;
>> *ip = 15;
>> ii = *ip;
>>
ian@airs.com (Ian Lance Taylor) wrote on 21.01.06 in <[EMAIL PROTECTED]>:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
> > I think he's saying that _this_ one might generate invalid code:
> >
> > void test(void)
> > {
> > union { int i; double d; } u;
> > int *ip;
> > dou
"Dave Korn" <[EMAIL PROTECTED]> writes:
> I think he's saying that _this_ one might generate invalid code:
>
> void test(void)
> {
> union { int i; double d; } u;
> int *ip;
> double *dp;
> int ii;
> double dd;
>
> dp = &u.d;
> ip = &u.i;
[EMAIL PROTECTED] (Kai Henningsen) writes:
> ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in <[EMAIL PROTECTED]>:
>
> > When dealing with unions, you can take pointers to different fields in
> > the unions. If the fields have different types, these pointers can
> > have non-conflicting ali
Kai Henningsen wrote:
> ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in
> <[EMAIL PROTECTED]>:
>
>> When dealing with unions, you can take pointers to different fields in
>> the unions. If the fields have different types, these pointers can
>> have non-conflicting alias sets. Therefore wi
ian@airs.com (Ian Lance Taylor) wrote on 20.01.06 in <[EMAIL PROTECTED]>:
> When dealing with unions, you can take pointers to different fields in
> the unions. If the fields have different types, these pointers can
> have non-conflicting alias sets. Therefore within a single union the
> same m
On Sat, 2006-01-21 at 15:33 +0100, Jan Hubicka wrote:
> > One way to avoid this restriction would be to extend RTL alias
> > analysis to not be strictly type based. In particular, we could
> > extend it to know that a particular stack slot has a range of alias
> > sets. A
> One way to avoid this restriction would be to extend RTL alias
> analysis to not be strictly type based. In particular, we could
> extend it to know that a particular stack slot has a range of alias
> sets. And we would then have to know whether a particular pointer
> could po
Steven Bosscher <[EMAIL PROTECTED]> writes:
> The proposed work-around is to avoid confusing RTL alias analysis by
> simply not presenting it with situations where two references to the
> same memory can have different alias sets.
To recapitulate.
RTL alias analysis assumes that
Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
>
>>I guess a secondary question is: is the workaround sufficiently useful
>>in many of the problematic cases and sufficiently non-harmful in other
>>cases as to merit inclusion, given that we don't have a be
On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
> I guess a secondary question is: is the workaround sufficiently useful
> in many of the problematic cases and sufficiently non-harmful in other
> cases as to merit inclusion, given that we don't have a better solution?
I replied with
Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
>
>>FWIW, I don't believe this is a "fix", but rather a solid work-around
>>for the problem. I'm still trusting rth's superior compiler brain and
>>GCC knowledge to ultimately be ingredients in a real fix
On 1/20/06, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> > FWIW, I don't believe this is a "fix", but rather a solid work-around
> > for the problem. I'm still trusting rth's superior compiler brain and
> > GCC knowledge to ultim
On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> FWIW, I don't believe this is a "fix", but rather a solid work-around
> for the problem. I'm still trusting rth's superior compiler brain and
> GCC knowledge to ultimately be ingredients in a real fix ;-)
I don't think it's quite
quot;=r" (c):"0" (c));
sum += *c;
}
{
struct B { union setconflict u; } a;
int *c;
c = a.u.b;
asm ("": "=r" (c):"0" (c));
*c = 1; // This store is moved before the first "sum += *c;"
asm ("": "=r"
Richard Guenther wrote:
>>patch needs a paragraph-long comment explaining what the problem is and
>>how this approach solves it.
>
> Ok, I'll try to come up with an explanation.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Friday 20 January 2006 18:34, Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> > Richard Guenther wrote:
> > > A patch was also posted based on ideas in the audit trail. It's third
> > > incarnation at
> > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
>
>>Richard Guenther wrote:
>>
>>>A patch was also posted based on ideas in the audit trail. It's third
>>>incarnation at
>>>http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
>>>would need a review.
>>
>>This pat
On 1/20/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > A patch was also posted based on ideas in the audit trail. It's third
> > incarnation at
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> > would need a review.
>
> This patch uses "type_i == type_j"
On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> Richard Guenther wrote:
> > A patch was also posted based on ideas in the audit trail. It's third
> > incarnation at
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> > would need a review.
>
> This patch uses "type_i == type_j" w
Richard Guenther wrote:
> A patch was also posted based on ideas in the audit trail. It's third
> incarnation at
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> would need a review.
This patch uses "type_i == type_j" which is usually a mistake; are we
sure we don't need the usual typ
On 1/20/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> > On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> > > ... the real
> > > solution is to transfer the information that the stack space sharing
> > > knows into some
On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> > ... the real
> > solution is to transfer the information that the stack space sharing
> > knows into some simple set form, and use *that directly* in alias.c, and
> > chec
On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> I'll have to give this some thought.
Heh, like many before you... Hope you can come up with an answer.
This is now bug 25654 in Bugzilla.
Gr.
Steven
On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> ... the real
> solution is to transfer the information that the stack space sharing
> knows into some simple set form, and use *that directly* in alias.c, and
> check it *first*, so that if they have the same stack slot, we say there
On Sun, 2006-01-01 at 10:22 -0800, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > Hi rth,
> >
> > The stack space sharing you added to cfgexpand.c breaks RTL alias
> > analysis.
> >
> > For example, the attached test case breaks for pentiumpro at -O2.
> Steven Bosscher wrote:
> > Hi rth,
> >
> > The stack space sharing you added to cfgexpand.c breaks RTL alias
> > analysis.
> >
> > For example, the attached test case breaks for pentiumpro at -O2.
> > The problem apparently is that the second stor
Steven Bosscher wrote:
> Hi rth,
>
> The stack space sharing you added to cfgexpand.c breaks RTL alias
> analysis.
>
> For example, the attached test case breaks for pentiumpro at -O2.
> The problem apparently is that the second store to c is moved up
> before before
Hi rth,
The stack space sharing you added to cfgexpand.c breaks RTL alias
analysis.
For example, the attached test case breaks for pentiumpro at -O2.
The problem apparently is that the second store to c is moved up
before before the load.
This looks like a serious problem to me...
Many thanks
45 matches
Mail list logo
