--- Comment #27 from rguenth at gcc dot gnu dot org 2010-01-18 11:12
---
Testing a patch to do minimal surgery to restore previous behavior (thus, fix
this regression but not the fundamental frontend / middle-end problem).
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-01-18 11:24
---
Btw, get_pointer_alignment should get passed an access type to put it into
context. For alignment of say INDIRECT_REFs it would be the pointed-to type
but for function arguments in general it needs to be 'char'
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-01-18 11:43
---
(In reply to comment #28)
Btw, get_pointer_alignment should get passed an access type to put it into
context. For alignment of say INDIRECT_REFs it would be the pointed-to type
but for function arguments in
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-01-18 12:59
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-01-18 13:00
---
Subject: Bug 39954
Author: rguenth
Date: Mon Jan 18 12:59:50 2010
New Revision: 156008
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156008
Log:
2010-01-18 Richard Guenther rguent...@suse.de
PR
--- Comment #26 from matz at gcc dot gnu dot org 2009-06-18 11:26 ---
Hmm, yeah, I should probably clean up my hack and formally submit it. But
I had hoped to get some advise from the frontend guys, because I was surprised
that the patch actually worked.
--
--- Comment #25 from sje at cup dot hp dot com 2009-06-17 20:37 ---
Micheal, are you still working on this bug? It looks like you had a patch for
it that you were testing but I don't see anything after that and the test is
still failing.
--
sje at cup dot hp dot com changed:
--- Comment #24 from danglin at gcc dot gnu dot org 2009-05-10 18:40
---
I see this on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-06 09:48 ---
Mark, I'm certainly willing to help fixing this, but it's not a new
regression. Before my change TER _sometimes_ worked around the pre-existing
problem, but it's trivial to construct a case exposing it also before
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-05-06 11:08
---
For optimization purposes differently aligned type variants should be treated
as a variant type, thus liked in the TYPE_NEXT_VARIANT chain (probably also
required to get correct behavior when assigning alias
--- Comment #16 from matz at gcc dot gnu dot org 2009-05-06 11:20 ---
Joseph: I'd need some advise where best starting to fix this. I see some
options, when we want to deal with such construct:
struct S { T member __attribute__((packed)); };
... struct S s; ... s-member ...
(1) make
--- Comment #17 from rguenther at suse dot de 2009-05-06 11:45 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:
--- Comment #16 from matz at gcc dot gnu dot org
--- Comment #18 from matz at gcc dot gnu dot org 2009-05-06 11:57 ---
The structure in this testcase is not packed. One member is. Or are you
talking about some different case?
Let's suppose you are and you mean something like this:
struct S {T1 m1; T2 m2; ...}
--- Comment #19 from matz at gcc dot gnu dot org 2009-05-06 20:39 ---
Something like this implements option 1. It's probably hopelessly inefficient
(always generating a new type for each packed field), and wrong, and generally
just a bad idea, but it does fix the testcase, execute.exp
--- Comment #20 from rguenther at suse dot de 2009-05-06 21:02 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:
--- Comment #19 from matz at gcc dot gnu dot org
--- Comment #21 from matz at suse dot de 2009-05-06 21:39 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, rguenther at suse dot de wrote:
+ tree ret;
+ if (TYPE_PACKED (t))
+return t;
Walking
--- Comment #22 from rguenther at suse dot de 2009-05-06 21:55 ---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 6 May 2009, matz at suse dot de wrote:
--- Comment #21 from matz at suse dot de 2009-05-06 21:39 ---
--- Comment #23 from matz at gcc dot gnu dot org 2009-05-06 21:56 ---
No regressions on x86_64-linux. I'm baffled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #12 from mmitchel at gcc dot gnu dot org 2009-05-05 15:48
---
Yes, we've been discussing the interaction between attributes and the type
system for at least a decade. :-) In type-theoretic terms, the address of a
packed int has type pointer-to-packed-int, not
--- Comment #13 from hjl dot tools at gmail dot com 2009-05-05 15:59
---
(In reply to comment #12)
Michael, unfortunately, if it was your change that introduced this regression,
you are responsible for solving the problem. The Right Answer, as you
suggest,
is to include the
--- Comment #10 from joseph at codesourcery dot com 2009-04-29 11:33
---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 29 Apr 2009, matz at gcc dot gnu dot org wrote:
The user should have the possibility to announce the
--- Comment #11 from matz at gcc dot gnu dot org 2009-04-29 11:38 ---
Thanks for the clarification. So there indeed is only one issue, that the
temporary has an aligned type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-28 23:43 ---
Revision 146817:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-28 23:48 ---
(In reply to comment #3)
Indeed. We likely fold the memcpy, but that should better preserve the
known alignment.
What known alignment?
The alignment of the type is known to be the same alignment as long inside a
--- Comment #6 from matz at gcc dot gnu dot org 2009-04-29 00:17 ---
Andrew is right. There is no known alignment (or misalignment) as far
as the gimple code is concerned, only the natural alignment:
send_probe (struct outdata * outdata, struct timeval * tp)
{
struct timeval *
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-29 00:33 ---
(In reply to comment #6)
Andrew is right. There is no known alignment (or misalignment) as far
as the gimple code is concerned, only the natural alignment:
send_probe (struct outdata * outdata, struct timeval
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 00:42 ---
This code:
---
void *memcpy(void *dest, const void *src, __SIZE_TYPE__ n);
struct timeval {
long tv_sec;
};
typedef struct timeval packed __attribute__((aligned(1)));
struct outdata {
long align;
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-04-29 00:43 ---
(In reply to comment #7)
How does gimple handle
typedef int foo __attribute__ ((aligned(1)));
The C/C++ front-end ignores the aligned here but does not mention that to you.
That is a different issue though,
28 matches
Mail list logo
