甜瓜 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
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,
, [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
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
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
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
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
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
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/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 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 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 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: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/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
>
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
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
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
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?
> 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
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
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
22 matches
Mail list logo
