* [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
[not found] <bug-45704-4@http.gcc.gnu.org/bugzilla/>
@ 2010-09-27 18:12 ` anemo at mba dot ocn.ne.jp
2010-09-27 18:14 ` rguenther at suse dot de
` (5 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: anemo at mba dot ocn.ne.jp @ 2010-09-27 18:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #5 from Atsushi Nemoto <anemo at mba dot ocn.ne.jp> 2010-09-27 15:48:32 UTC ---
Here is a similar test case with "packed" attribute, which still produces bad
result.
Four load-byte instructions are generated instead of one load-word.
struct st {
int ptr;
} __attribute__ ((packed));
int foo(struct st *st)
{
int v = *(volatile int *)&st->ptr;
return v & 0xff;
}
gcc 4.4.4 works fine (same result with the first test case)
gcc 4.6.0 20100927 (or 4.5.2 20100927) generates:
lbu $2,0($4)
lbu $3,1($4)
andi $2,$2,0x00ff
lbu $3,2($4)
lbu $3,3($4)
j $31
nop
I do not know this should be another PR or not.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
[not found] <bug-45704-4@http.gcc.gnu.org/bugzilla/>
2010-09-27 18:12 ` [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int anemo at mba dot ocn.ne.jp
@ 2010-09-27 18:14 ` rguenther at suse dot de
2010-09-28 18:31 ` anemo at mba dot ocn.ne.jp
` (4 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2010-09-27 18:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> 2010-09-27 15:54:06 UTC ---
On Mon, 27 Sep 2010, anemo at mba dot ocn.ne.jp wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
>
> --- Comment #5 from Atsushi Nemoto <anemo at mba dot ocn.ne.jp> 2010-09-27 15:48:32 UTC ---
> Here is a similar test case with "packed" attribute, which still produces bad
> result.
> Four load-byte instructions are generated instead of one load-word.
>
> struct st {
> int ptr;
> } __attribute__ ((packed));
>
> int foo(struct st *st)
> {
> int v = *(volatile int *)&st->ptr;
> return v & 0xff;
> }
>
> gcc 4.4.4 works fine (same result with the first test case)
>
> gcc 4.6.0 20100927 (or 4.5.2 20100927) generates:
> lbu $2,0($4)
> lbu $3,1($4)
> andi $2,$2,0x00ff
> lbu $3,2($4)
> lbu $3,3($4)
> j $31
> nop
>
> I do not know this should be another PR or not.
It should be as this is likely a problem with unaligned access
support. I think you can't generally expect unaligned volatile
accesses to work (on ia64 for example they certainly wouldn't).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
[not found] <bug-45704-4@http.gcc.gnu.org/bugzilla/>
2010-09-27 18:12 ` [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int anemo at mba dot ocn.ne.jp
2010-09-27 18:14 ` rguenther at suse dot de
@ 2010-09-28 18:31 ` anemo at mba dot ocn.ne.jp
2010-09-30 18:47 ` anemo at mba dot ocn.ne.jp
` (3 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: anemo at mba dot ocn.ne.jp @ 2010-09-28 18:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #7 from Atsushi Nemoto <anemo at mba dot ocn.ne.jp> 2010-09-28 15:34:59 UTC ---
(In reply to comment #6)
> It should be as this is likely a problem with unaligned access
> support. I think you can't generally expect unaligned volatile
> accesses to work (on ia64 for example they certainly wouldn't).
OK, filed as PR 45819.
ARM linux kernel depends on this unaligned volatile access.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
[not found] <bug-45704-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2010-09-28 18:31 ` anemo at mba dot ocn.ne.jp
@ 2010-09-30 18:47 ` anemo at mba dot ocn.ne.jp
2010-09-30 18:51 ` rguenther at suse dot de
` (2 subsequent siblings)
6 siblings, 0 replies; 11+ messages in thread
From: anemo at mba dot ocn.ne.jp @ 2010-09-30 18:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #8 from Atsushi Nemoto <anemo at mba dot ocn.ne.jp> 2010-09-30 13:59:34 UTC ---
(In reply to comment #0)
> The PR 42956 bugzilla shows same fix was applied to both 4.5.0 and 4.4.4,
> but they behave differently on this test case.
>
> Comparing patches for 4.4 branch and 4.5, I see the latter contains two more
> changes for gimplify.c:
> A STRIP_NOP line and lines starting with "/* *(foo *)&complexfoo => __real__
> complexfoo */" comment.
In the first place, why PR 42956 fixes are different for 4.4 and 4.5?
The commit logs are same, but actual changes for gimplify.c were differ.
Is that "two more changes" are not bugfix but improvement?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
[not found] <bug-45704-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2010-09-30 18:47 ` anemo at mba dot ocn.ne.jp
@ 2010-09-30 18:51 ` rguenther at suse dot de
2010-10-01 12:48 ` anemo at mba dot ocn.ne.jp
2011-02-03 18:28 ` tschwinge at gcc dot gnu.org
6 siblings, 0 replies; 11+ messages in thread
From: rguenther at suse dot de @ 2010-09-30 18:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2010-09-30 14:14:13 UTC ---
On Thu, 30 Sep 2010, anemo at mba dot ocn.ne.jp wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
>
> --- Comment #8 from Atsushi Nemoto <anemo at mba dot ocn.ne.jp> 2010-09-30 13:59:34 UTC ---
> (In reply to comment #0)
> > The PR 42956 bugzilla shows same fix was applied to both 4.5.0 and 4.4.4,
> > but they behave differently on this test case.
> >
> > Comparing patches for 4.4 branch and 4.5, I see the latter contains two more
> > changes for gimplify.c:
> > A STRIP_NOP line and lines starting with "/* *(foo *)&complexfoo => __real__
> > complexfoo */" comment.
>
> In the first place, why PR 42956 fixes are different for 4.4 and 4.5?
> The commit logs are same, but actual changes for gimplify.c were differ.
>
> Is that "two more changes" are not bugfix but improvement?
Yes.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
[not found] <bug-45704-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2010-09-30 18:51 ` rguenther at suse dot de
@ 2010-10-01 12:48 ` anemo at mba dot ocn.ne.jp
2011-02-03 18:28 ` tschwinge at gcc dot gnu.org
6 siblings, 0 replies; 11+ messages in thread
From: anemo at mba dot ocn.ne.jp @ 2010-10-01 12:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
--- Comment #10 from Atsushi Nemoto <anemo at mba dot ocn.ne.jp> 2010-10-01 12:48:47 UTC ---
(In reply to comment #9)
> > Is that "two more changes" are not bugfix but improvement?
>
> Yes.
I see, thank you for clarification.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int
[not found] <bug-45704-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2010-10-01 12:48 ` anemo at mba dot ocn.ne.jp
@ 2011-02-03 18:28 ` tschwinge at gcc dot gnu.org
6 siblings, 0 replies; 11+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2011-02-03 18:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |domen at cba dot si
--- Comment #11 from Thomas Schwinge <tschwinge at gcc dot gnu.org> 2011-02-03 18:27:10 UTC ---
*** Bug 46762 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 11+ messages in thread