--- Comment #15 from hp at gcc dot gnu dot org 2010-09-04 03:08 ---
(In reply to comment #4)
> Good job picking up on that.
>
> There must be a better way of telling the compiler to generate lwr and lwl
> MIPS
> instructions without breaking strict aliasing rules...?
When requiring a
--- Comment #14 from yotambarnoy at gmail dot com 2010-09-02 20:47 ---
Getting back to the original question, I did some reading online and I can't
figure out why this breaks the strict aliasing rules.
Isn't void * some kind of special case? Shouldn't I be able to convert it to
whateve
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-02 09:07
---
(In reply to comment #11)
> (In reply to comment #10)
> > typedef my_unaligned_aliasing_uint32 uint32
> > __attribute__((aligned(1),may_alias));
> >
> > inline __attribute__((__always_inline__)) uint32 READ_UINT32
--- Comment #12 from yotambarnoy at gmail dot com 2010-09-01 18:35 ---
Right. Unfortunately
> typedef my_unaligned_aliasing_uint32 uint32
> __attribute__((aligned(1),may_alias));
>
> inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
> {
> return *(const my
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-09-01 18:25
---
(In reply to comment #10)
> typedef my_unaligned_aliasing_uint32 uint32
> __attribute__((aligned(1),may_alias));
>
> inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
> {
> return *(c
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-09-01 09:45
---
(In reply to comment #8)
> Unfortunately, a lib based solutions are difficult for me to implement. The
> reason is that the current PSP SDK uses newlib. I can probably change my
> personal toolchain with some work,
--- Comment #9 from pinskia at gmail dot com 2010-09-01 06:17 ---
Subject: Re: Bad optimization in -O3 sometimes
I am not talking about a library solution at all. I am talking about a
solution inside the compiler. Gcc will optimize memcpy; how much for
MIPS is a good question. Try
I am not talking about a library solution at all. I am talking about a
solution inside the compiler. Gcc will optimize memcpy; how much for
MIPS is a good question. Try it out and see. Oh if you are using
scei's gcc you really should be reporting issues to them.
On Aug 31, 2010, at 10:03 PM
--- Comment #8 from yotambarnoy at gmail dot com 2010-09-01 05:03 ---
Unfortunately, a lib based solutions are difficult for me to implement. The
reason is that the current PSP SDK uses newlib. I can probably change my
personal toolchain with some work, but then it's a custom modificatio
--- Comment #7 from pinskia at gmail dot com 2010-09-01 04:41 ---
Subject: Re: Bad optimization in -O3 sometimes
On Aug 31, 2010, at 9:32 PM, "yotambarnoy at gmail dot com"
wrote:
>
>
> --- Comment #6 from yotambarnoy at gmail dot com 2010-09-01
> 04:32 ---
> I recently
On Aug 31, 2010, at 9:32 PM, "yotambarnoy at gmail dot com" > wrote:
--- Comment #6 from yotambarnoy at gmail dot com 2010-09-01
04:32 ---
I recently implemented a custom memcpy for ScummVM. I didn't notice
the
standard memcpy using lwl and lwr. In any case, how would memcpy do
--- Comment #6 from yotambarnoy at gmail dot com 2010-09-01 04:32 ---
I recently implemented a custom memcpy for ScummVM. I didn't notice the
standard memcpy using lwl and lwr. In any case, how would memcpy do it any
better? Unless you're referring to the new memcpy inlining in newer ver
--- Comment #5 from pinskia at gmail dot com 2010-08-31 19:09 ---
Subject: Re: Bad optimization in -O3 sometimes
On Aug 31, 2010, at 8:24 AM, "yotambarnoy at gmail dot com"
wrote:
>
>
> --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31
> 15:24 ---
> Good job pi
On Aug 31, 2010, at 8:24 AM, "yotambarnoy at gmail dot com" > wrote:
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31
15:24 ---
Good job picking up on that.
There must be a better way of telling the compiler to generate lwr
and lwl MIPS
instructions without breaki
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 ---
Good job picking up on that.
There must be a better way of telling the compiler to generate lwr and lwl MIPS
instructions without breaking strict aliasing rules...?
Thanks a bunch!
--
yotambarnoy at gmail dot co
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-31 14:17 ---
inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr)
{
struct Unaligned32 { uint32 val; } __attribute__ ((__packed__));
return ((const Unaligned32 *)ptr)->val;
}
and similar look like
--- Comment #2 from yotambarnoy at gmail dot com 2010-08-31 11:53 ---
Created an attachment (id=21603)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21603&action=view)
header.h, used by logic.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
--- Comment #1 from yotambarnoy at gmail dot com 2010-08-31 11:52 ---
Created an attachment (id=21602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21602&action=view)
Logic.ii, where gcc makes the mistake
LogicUp() is the critical function
--
http://gcc.gnu.org/bugzilla/show
18 matches
Mail list logo
