Hello,
I experienced an ICE for no-scevccp-outer-16.c in our port. It seems not in
other ports so I couldn't file a bug report.
Baiscally, the problem appears after the following transformations in
expand_compound_operation (combine.c).
Enter expand_compound_operation
x:
(zero_extend:SI (su
Dear Sir/Madam,
We would like to raise an HTTP GCC mirror on our dedicated server in
Canada and I would be very grateful if you provided me with
instructions.
Thank you.
Best wishes,
James Miller
> It seems to me that both the gen_lowpart and simplify_shift_const do the
> wrong things in handling vector type. (zero_extend:SI (subreg:HI (V4HI)) is
> not equal to (subreg:SI (V4HI)), is it? simplify_shift_const produces
> (ashift:V4HI (V4HI..) (16), which is not right either.
The combine pas
The file config/mt-gnu currently defines CXXFLAGS_FOR_TARGET =
$(CXXFLAGS) -D_GNU_SOURCE. To me, it seems that it should be +=
-D_GNU_SOURCE (like most of the other frags). Otherwise, I cannot
override the CXXFLAGS without overriding CXXFLAGS_FOR_TARGET. Or am I
missing something?
On 03/25/2010 12:31 PM, Eric Botcazou wrote:
The combine pass had been written at least a decade before vector modes were
introduced so it essentially doesn't expect them, i.e. some transformations
simply don't make sense for vector modes. You need to analyze the one you're
seeing (e.g. where do
Hi Richard
(* I am weak in English, so pleas forgive my English mistake.)
Thank you for your reply, and I'm sorry to be late a reply.
> On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike wrote:
>> [ summary ]
>> compiling is failed when more than two source file are
>>specified with both
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
}
else
{
...
}
where REG is a pseudo register and r0 is a physical register. I have
lo
On 03/25/2010 04:03 PM, Jie Zhang wrote:
> I just found that the current RTL code hoisting cannot optimize
>
> REG = ...
> if (cond)
> {
> r0 = REG;
>
> }
> else
> {
> r0 = REG;
> ...
> }
>
> to
>
>
> REG = ...
> r0 = REG;
> if (cond)
> {
>
> }
> else
>
On Thu, Mar 25, 2010 at 4:14 PM, Bernd Schmidt wrote:
> On 03/25/2010 04:03 PM, Jie Zhang wrote:
>> I just found that the current RTL code hoisting cannot optimize
>>
>> REG = ...
>> if (cond)
>> {
>> r0 = REG;
>>
>> }
>> else
>> {
>> r0 = REG;
>> ...
>> }
>>
>> to
>>
On 03/25/10 09:14, Bernd Schmidt wrote:
On 03/25/2010 04:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
On Thu, Mar 25, 2010 at 4:03 PM, Jie Zhang wrote:
> I just found that the current RTL code hoisting cannot optimize
>
> REG = ...
> if (cond)
> {
> r0 = REG;
>
> }
> else
> {
> r0 = REG;
> ...
> }
>
> to
>
>
> REG = ...
> r0 = REG;
> if (cond)
> {
>
> }
> else
> {
>
On Thu, Mar 25, 2010 at 11:33:17PM +0900, Tadashi Koike wrote:
> Hi Richard
> (* I am weak in English, so pleas forgive my English mistake.)
>
> Thank you for your reply, and I'm sorry to be late a reply.
>
> > On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike wrote:
> >> [ summary ]
> >> c
On 03/25/2010 11:22 PM, Jeff Law wrote:
On 03/25/10 09:14, Bernd Schmidt wrote:
On 03/25/2010 04:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
}
el
On 03/25/2010 11:24 PM, Steven Bosscher wrote:
On Thu, Mar 25, 2010 at 4:03 PM, Jie Zhang wrote:
I just found that the current RTL code hoisting cannot optimize
REG = ...
if (cond)
{
r0 = REG;
}
else
{
r0 = REG;
...
}
to
REG = ...
r0 = REG;
if (cond)
{
...
On 03/25/10 10:19, Jie Zhang wrote:
On 03/25/2010 11:22 PM, Jeff Law wrote:
I never bothered to implement hoisting which touched hard regs -- I
never thought the cost/benefit analysis made much sense. It's quite a
bit more work to implement and code motion of hard regs is much more
restricted t
Doug Semler writes:
> The file config/mt-gnu currently defines CXXFLAGS_FOR_TARGET =
> $(CXXFLAGS) -D_GNU_SOURCE. To me, it seems that it should be +=
> -D_GNU_SOURCE (like most of the other frags). Otherwise, I cannot
> override the CXXFLAGS without overriding CXXFLAGS_FOR_TARGET. Or am I
> m
Hi,
I wanted to let you know that I found the issue.
The arguments to the script that drove the simulator
had changed. Once I saw the command line that
invoked the simulator, it was trivial to fix.
Thanks for the pointer. Easy problem that was hard
to find.
--joel
On 03/23/2010 04:10 PM, Jan
Thank you very much!!! :D
--- Mer 24/3/10, Ian Lance Taylor ha scritto:
> Da: Ian Lance Taylor
> Oggetto: Re: Problem with ADDR_EXPR array offset
> A: "Massimo Nazaria"
> Cc: gcc@gcc.gnu.org
> Data: Mercoledì 24 marzo 2010, 23:59
> Massimo Nazaria
> writes:
>
> > I'm working on a pass and I
Snapshot gcc-4.5-20100325 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100325/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
, [AC_MSG_RESULT([yes])], [AC_MSG_RESULT([no]); clooglibs= ; clooginc= ])
I noticed that this test only returns...
checking for version 0.15.9 (or later revision) of CLooG... no
for...
../gcc-4.5-20100325/configure --prefix=/sw --prefix=/sw/lib/gcc4.5
--mandir=/sw/share/man --infodir=/sw/shar
Howdy,
I find a problem when upgraded g++ from 4.4.1 to 4.4.2. Original g++
generates code with "System V ABI", but new g++ generates code with
"Linux ABI". I don't know what difference between them, but the output
.so file from g++ 4.4.2 cannot be used in g++ 4.4.1.
To describe my problem clear,
甜瓜 writes:
> I find a problem when upgraded g++ from 4.4.1 to 4.4.2. Original g++
> generates code with "System V ABI", but new g++ generates code with
> "Linux ABI". I don't know what difference between them, but the output
> .so file from g++ 4.4.2 cannot be used in g++ 4.4.1.
>
> To describe m
22 matches
Mail list logo
