Hi:
Yeah. You are right. Here is another RTL unrecognized. It happened
after reload.
(insn 749 156 147 22 (set (reg:HI 5 R5)
(subreg:HI (mem/c:SI (plus:SI (reg/f:SI 15 R15)
(const_int 108 [0x6c])) [19 d0+0 S4 A32]) 0)) -1 (nil))
I traced the lots of functions like: r
here are some information from the libgcc2.c.176r.greg. (BTY: the
error happened when cc1 build the libgcc2.c)
Reloads for insn # 147
Reload 0: reload_out (SI) = (reg/v:SI 99 [ __d0 ])
GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/v:SI 99 [ __d0 ])
reload
On Tue, Sep 29, 2009 at 2:39 PM, Richard Guenther
wrote:
> On Tue, Sep 29, 2009 at 2:22 PM, Joseph S. Myers
> wrote:
>> On Tue, 29 Sep 2009, Richard Guenther wrote:
>>
>>> The summary is as follows, extra errors compared to a run
>>> without the merge patch applied:
>>>
>>> i586:
>>>
>>> FAIL: gc
On Wed, 30 Sep 2009, Gerald Pfeifer wrote:
> On Tue, 29 Sep 2009, Dave Korn wrote:
> > We have ~48 hours left for stage 1 and I can't be confident of getting
> > it reviewed in the remaining time, so I'd like to make a special
> > request: can you, as RM, please say that this is OK in principle
On Tue, Sep 29, 2009 at 8:23 PM, David Edelsohn wrote:
> On Thu, Aug 20, 2009 at 4:48 AM, Richard Guenther
> wrote:
>
>> Can't we use graphite to re-roll loops? That is, compress the
>> polyhedron by introducing a new parameter? But maybe I am
>> not good at guessing what your initial bloat iss
Hi,
Thanks for your guys advice. Now the gcc is built succeed first
time(without headers).
Now I have to keep going for newlib.
Thanks very much.
On Wed, 30 Sep 2009, Richard Guenther wrote:
> New failures for head-i586
> FAIL: 26_numerics/headers/cmath/fabs_inline.cc (test for excess errors)
This is a failure of a non-LTO test, so a regression.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, Sep 30, 2009 at 2:35 PM, Joseph S. Myers
wrote:
> On Wed, 30 Sep 2009, Richard Guenther wrote:
>
>> New failures for head-i586
>
>> FAIL: 26_numerics/headers/cmath/fabs_inline.cc (test for excess errors)
>
> This is a failure of a non-LTO test, so a regression.
You are right. It doesn't
daniel tian wrote:
> here are some information from the libgcc2.c.176r.greg. (BTY: the
> error happened when cc1 build the libgcc2.c)
>
> Reloads for insn # 147
> Reload 0: reload_out (SI) = (reg/v:SI 99 [ __d0 ])
> GENERAL_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
> reload_out_reg: (reg/v:S
On Wed, Sep 30, 2009 at 10:49:40AM +0200, Richard Guenther wrote:
> >
> > Now, submitting a one liner as your first atte...@a new pass today
> > and then claiming the rest are just fixes, would be a stretch :-), but
> > for a patch like yours it does not seem unreasonable.
>
> Just to followup on
On 09/29/2009 09:46 PM, Mohamed Shafi wrote:
bool strict = reload_completed ? true : false;
What happens if you set "strict = false" here?
That's what ARM does.
r~
What is the best way to go from this:
Makefile:
C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o \
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \
C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS)
OBJS-common = \
^Iinsn-attrtab.o \
^Iinsn-
On Wed, Sep 30, 2009 at 10:41:26AM +0200, Richard Guenther wrote:
> I think the vmx testcases fail on me because I don't have a
> POWER7 machine to test on. But it would be nice if ppc
> people would look at this. Mike?
I or the others in my group should look at the failures. Note, VMX is the
a
On 09/30/2009 08:00 AM, Paul Edwards wrote:
What is the best way to go from this:
Makefile:
The easy way to convert a Makefile to a shell script is "make -n". That
will print out all of the commands that make would run. From there it's
a Mere Matter of Programming to have perl (or whatever
Hi All,
We are trying to get the .dfa output file, showing details about the
automaton constructed for - instruction scheduling, using pipeline hazard
detector. However we are unable to do so.
We tried
(a.)uncommenting - (automata_option "v") - in ia64.md file
(b.)adding v_flag = 1 in gen_automa
Diego Novillo writes:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
>
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
I've run
On Wed, Sep 30, 2009 at 13:36, Rainer Orth
wrote:
>> $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto
>> $ mkdir bld && cd bld
>> $ ../lto/configure --enable-lto && make
>
> Why just a make and no make bootstrap?
It's not necessary, but I wanted to make sure that you force LTO. If
not, configur
Diego Novillo writes:
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
The branch on mipsisa64-elf looks good (no regressions with languages
c,c++,objc):
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02717.html
baseline:
http://gcc.gnu.org/ml/gcc-
On Wed, Sep 30, 2009 at 7:36 PM, Rainer Orth
wrote:
> Diego Novillo writes:
>
>> In preparation for the final merge into mainline. I need to test
>> the branch on various platforms. Richi is currently testing on
>> i586, ppc, ppc64, ia64, s390, s390x.
>>
>> If anyone has free cycles I would app
Hello!
Could you please clarify whether or not g++ takes into an account
explicitly specified inline qualifier for the class member function
implemented in the class body?
I know that according to C++ standard such a function shall be
qualified as inline no matter whether "inline" qualifier speci
On Wed, Sep 30, 2009 at 12:39 PM, Alexander Shabanov
wrote:
> I mean whether the code
>
> class A
> {
> inline void foo() { ... }
> };
>
> is absolutely equal to
>
> class A
> {
> void foo() { ... }
> };
>
> in *any* circumstances or not?
They are the same unless you do -fno-default-inline and
On Wed, 30 Sep 2009, Richard Guenther wrote:
On Wed, Sep 30, 2009 at 7:36 PM, Rainer Orth
wrote:
+FAIL: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o link
+UNRESOLVED: gcc.dg/lto/20090729 c_lto_20090729_0.o-c_lto_20090729_1.o execute
-w
output is:
ld: warning: symbol `i' has diff
What is the best way to go from this:
Makefile:
The easy way to convert a Makefile to a shell script is "make -n". That
will print out all of the commands that make would run. From there it's a
Mere Matter of Programming to have perl (or whatever) edit that down into
your JCL scripts.
Hi
Hello GNU webmasters,
I hope this is the right place to report what appears to be a problem at
rt.gnu.org, I couldn't find an explicit contact address for it.
We just got two posts on the GCC mailing list with the subject line
"[gnu.org #263454] Take home $204,000.00 this month":
http:/
Hello GNU webmasters,
I hope this is the right place to report what appears to be a problem at
rt.gnu.org, I couldn't find an explicit contact address for it.
We just got two posts on the GCC mailing list with the subject line
"[gnu.org #263454] Take home $204,000.00 this month":
http:/
Diego Novillo wrote:
> In preparation for the final merge into mainline. I need to test
> the branch on various platforms. Richi is currently testing on
> i586, ppc, ppc64, ia64, s390, s390x.
>
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
>
> $ svn c
On Wed, Sep 30, 2009 at 06:48:02PM -0400, Dave Korn via RT wrote:
>
> Hello GNU webmasters,
>
> I hope this is the right place to report what appears to be a problem at
> rt.gnu.org, I couldn't find an explicit contact address for it.
>
> We just got two posts on the GCC mailing list wit
Daniel Jacobowitz wrote:
> On Wed, Sep 30, 2009 at 06:48:02PM -0400, Dave Korn via RT wrote:
>> Hello GNU webmasters,
>>
>> I hope this is the right place to report what appears to be a problem at
>> rt.gnu.org, I couldn't find an explicit contact address for it.
>>
>> We just got two posts
Status
==
The trunk is in Stage 3. Stage 3 will end on Nov 30th after which
the trunk will be open for regression and documentation fixes only.
Stage 3 is for general bugfixing, what is considered a bugfix is
up to the maintainers. At the discretion of the maintainers patches
that were fini
On Wed, Sep 30, 2009 at 6:23 PM, Richard Guenther wrote:
>
> Status
> ==
>
> The trunk is in Stage 3.
some of us are living in a timezone where it is still September 30, 2009. :-/
-- Gaby
On Wed, 30 Sep 2009, Gabriel Dos Reis wrote:
> On Wed, Sep 30, 2009 at 6:23 PM, Richard Guenther wrote:
> >
> > Status
> > ==
> >
> > The trunk is in Stage 3.
>
> some of us are living in a timezone where it is still September 30, 2009. :-/
Sorry ;) I expect the news will take some time to
"Paul Edwards" writes:
> 2. If the normal way to do things is to parse the make -n output
> with perl etc, that's fine, I'll do it that way. I was just wondering
> if the proper way was to incorporate the logic into a Makefile
> rule and get that rule repeatedly executed rather than just
> havin
On Wed, 30 Sep 2009, Ian Lance Taylor wrote:
> "Paul Edwards" writes:
>
> > 2. If the normal way to do things is to parse the make -n output
> > with perl etc, that's fine, I'll do it that way. I was just wondering
> > if the proper way was to incorporate the logic into a Makefile
> > rule and
Hi Richard,
I have several patches that I've emailed to gcc-patches (some a few
days ago, some a bit longer). They are still pending code review.
Will this still be able to make it into gcc 4.5? The list of patches
is as follows:
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01170.html
http://gc
Hi everyone,
I'm using g++.old-deja/g++.brendan/new3.C as a testcase to investigate a
problem with dllimport at the moment, and noticed something a bit unusual:
Here is the CIE data from new3.C as compiled with gcc-4.3.4
> .section.eh_frame,"w"
> Lframe1:
> .long L
I ran LTO for spu-elf.
Most of the gcc.dg/lto.exp fail because -shared is not support as
there are no shared library support for SPU yet.
In fact there is an error running the lto.exp testsuite from dejagnu:
+ERROR: tcl error sourcing
/home/apinski/src/lto/gcc/gcc/testsuite/gcc.dg/lto/lto.exp.
+ERR
On Wed, Sep 30, 2009 at 9:58 PM, Andrew Pinski wrote:
> One failure without LTO which looks like it was introduced in just
> recently (between revision 152285 and 152343):
> FAIL: g++.dg/eh/crossjump1.C (test for excess errors)
>
> I almost want to say
> 2009-09-30 Diego Novillo
> 2009-09-30 D
Yeah. My target do have instructions support load/store HImode. And
the problem is fix. I just don't understand why. Here is the
information I gotta: http://gcc.gnu.org/ml/gcc/2005-01/msg00788.html.
I defined a predicate function rice_memory_operand which calls the
function memory operand directly
38 matches
Mail list logo
