Liu Haibin <[EMAIL PROTECTED]> writes:
> Can someone help me explain that why there's an REG_DEP_OUTPUT (write
> after write dependence) between jump_insn 547 and insn 82?
>
> (insn 82 543 478 3 (set (mem/s:SI (reg/f:SI 6 r6 [224]) [4 W S4 A32])
> (reg:SI 2 r2 [95])) 8 {movsi_internal} (i
> Could you tell me what it means for 'test for excess errors'? I run
> make check-gcc RUNTESTFLAGS='dg.exp' on my machine, and got many
> failed tests for these errors on my porting gcc.
The dg.exp tests can instruct DejaGnu to look for specific
warnings/errors in diagnostics. The final test is
>2005-12-28 Leif Ekblad [EMAIL PROTECTED]
>
> * gcc/config.gcc: Added support for target RDOS
> * gcc/config/i386/rdos.h: Added rdos.h file for RDOS definitions
Patches should be sent to gcc-patches. Thanks.
Ben
Hi,
Can someone help me explain that why there's an REG_DEP_OUTPUT (write
after write dependence) between jump_insn 547 and insn 82?
(insn 82 543 478 3 (set (mem/s:SI (reg/f:SI 6 r6 [224]) [4 W S4 A32])
(reg:SI 2 r2 [95])) 8 {movsi_internal} (insn_list 81 (nil))
(expr_list:REG_DEAD (r
Hello,
I want to dump out all the c++ classes/structs and global data
structures defined in a given file scope or transaltion unit, as part
of the debug dumps in C-like syntax, from GIMPLE data structs. Is
there a TREE_VEC or BIND_EXPR_VARS that I can traverse through and get
all these ?
Thanks
> DJ Delorie wrote
> Revisiting an old thread...
>> > On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote:
>> > So... why is it illegal to put a constant into a single bit field?
>>
>> Probably because it was more efficient to use some other pattern
>> for some other target.
>
> That's a ba
On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> I'll have to give this some thought.
Heh, like many before you... Hope you can come up with an answer.
This is now bug 25654 in Bugzilla.
Gr.
Steven
On Jan 3, 2006, at 11:54 AM, Laurent GUERBY wrote:
To stop the annoying VM randomization you need to turn on
the old style VM layout in the kernel. Grrr.
I believe detailed instructions on the ways to disable VM
randomization
in the GCC wiki would be a welcomed addition by many GCC hackers
On Tue, 2006-01-03 at 16:41 -0500, Daniel Jacobowitz wrote:
> DESTDIR support (which we already have, and people use constantly)
> allows us to install a tree somewhere different than its configured
> --prefix. Relocatable toolchains (ditto) allow the toolchain to work
> when run from an address d
Snapshot gcc-3.4-20060103 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060103/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Ben --
The GCC SC has appointed you as a maintainer of libdecnumber.
Please add yourself to MAINTAINERS.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Revisiting an old thread...
> On Fri, Sep 02, 2005 at 09:40:20PM -0400, DJ Delorie wrote:
> > So... why is it illegal to put a constant into a single bit field?
>
> Probably because it was more efficient to use some other pattern
> for some other target.
That's a bad reason to put it in the MI
On Tue, Jan 03, 2006 at 10:39:06PM +0100, Laurent GUERBY wrote:
> On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote:
> > On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> > > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > > > Actually, looking more closely, t
On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote:
> On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > > Actually, looking more closely, the libiberty.a is the only one
> > > > installed
> > > > that way (from
On Fri, 30 Dec 2005, Jon Brisbin wrote:
> I'm trying to install the GCC 4.1 snapshot from Dec 23, 2005 on my
> FreeBSD box. I'm trying to try out gcj. The installation fails,
> complaining about not enough virtual memory. I just added another 2GB
> swap file on this box. I now have 1GB of physic
On Tue, 2006-01-03 at 15:54 -0500, Richard Kenner wrote:
> Quick poll: who does configure for some system dir when doing
> development?
>
> I do. Doesn't mean I have to keep doing it that way, of course, but that's
> not what you asked.
I assume linux (and GCC) distributors also do it
On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > Actually, looking more closely, the libiberty.a is the only one installed
> > > that way (from the gcc sources). All others (for example libstdc++.a)
> > > seem
> > > to
Quick poll: who does configure for some system dir when doing
development?
I do. Doesn't mean I have to keep doing it that way, of course, but that's
not what you asked.
On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > Actually, looking more closely, the libiberty.a is the only one installed
> > that way (from the gcc sources). All others (for example libstdc++.a) seem
> > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9).
> > Hmmm...
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
>
So, here's what appears to be happening.
1. A statement i
On Tue, 2006-01-03 at 12:42 -0700, Jeffrey A Law wrote:
> On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> > Hi Rainer, this is PR24994:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
> >
> > And is under investigation:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 17:15, Karel Gardas wrote:
I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The
failure happen during compilation of gcc and it looks like:
/tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/
Richard Earnshaw wrote:
Next, I suggest you add --with-cpu=xscale when configuring GCC. You can
then drop the -mcpu=xscale when compiling (this should also give you
better libraries for your system). However, beware that you libraries
will now only run on ARMv5 or later processors.
IMHO usi
On Tue, 2006-01-03 at 15:02 -0500, Diego Novillo wrote:
> On Tuesday 03 January 2006 14:57, Jeffrey A Law wrote:
>
> > No, this is not sufficient.
> >
> *shrug* that works for me without the legacy_va_layout setting.
>
> $ sysctl vm.legacy_va_layout
> vm.legacy_va_layout = 0
>
> (On 2.6.14-1.165
On Tuesday 03 January 2006 14:57, Jeffrey A Law wrote:
> No, this is not sufficient.
>
*shrug* that works for me without the legacy_va_layout setting.
$ sysctl vm.legacy_va_layout
vm.legacy_va_layout = 0
(On 2.6.14-1.1653_FC4smp)
On Tue, 2006-01-03 at 14:51 -0500, Diego Novillo wrote:
> On Tuesday 03 January 2006 14:47, Andrew Haley wrote:
>
> > Please, post instructions about how to turn on the old style VM layout
> > in the kernel. Sooner or later, many of us on this list will need to
> > know...
> >
> Adding this to /e
On Tuesday 03 January 2006 14:47, Andrew Haley wrote:
> Please, post instructions about how to turn on the old style VM layout
> in the kernel. Sooner or later, many of us on this list will need to
> know...
>
Adding this to /etc/sysctl.conf works for me:
# Do not randomize memory addresses
kern
Jeffrey A Law writes:
> On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> > Hi Rainer, this is PR24994:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
> >
> > And is under investigation:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
> Finally!
>
> Actually, looking more closely, the libiberty.a is the only one installed
> that way (from the gcc sources). All others (for example libstdc++.a) seem
> to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9).
> Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in?
Bingo. :-) http://gcc
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
Finally!
To stop the annoying VM randomization you need to tur
Quoting Eric Botcazou <[EMAIL PROTECTED]>:
I've noticed one inconsistency how libraries are installed. For shared
libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
64-bit version is installed in prefix/lib/sparcv9.
For static libraries (lib*.a archives), it is the other
> I've noticed one inconsistency how libraries are installed. For shared
> libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
> 64-bit version is installed in prefix/lib/sparcv9.
>
> For static libraries (lib*.a archives), it is the other way around. The
> 64-bit version is
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
Hmmm, I'm still having trouble disabling this (*&@#$ address
sp
On Tue, 2006-01-03 at 17:15, Karel Gardas wrote:
> I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The
> failure happen during compilation of gcc and it looks like:
>
> /tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/
> -nostdinc -B/tmp/arm-elf-build/
On Mon, 2 Jan 2006, Ian Lance Taylor wrote:
> When did the bogus split
> happen?
Sorry, I didn't answer this question and now the gdb session is
gone. Hopefully the answer isn't that important given RTH's
comment? I'd guess reorg.
brgds, H-P
On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> Hi Rainer, this is PR24994:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
>
> And is under investigation:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
Still under investigation. Very little happened over the last
In http://gcc.gnu.org/ml/gcc/2005-12/msg00642.html, Bernd Jendrissek wrote:
> Which leads me to the subject. Would it be a win to have a macro
> HARD_REGNO_MODE_OK_FOR_CLASS (REGNO, MODE, CLASS) which would be the
> authoritative test for this loop in find_reg()? On my port, and I
> imagine on m
On Tuesday 03 January 2006 12:17, [EMAIL PROTECTED] wrote:
> how to keep my branch updated with the mainline?
>
The easiest way is using svnmerge.py (included in SVN's contrib directory).
There's documentation in the GCC wiki: http://gcc.gnu.org/wiki/SvnBranch
All,
I've recently opened a new branch for treegion (tree-region) scheduling.
I'm new at this and was just wondering if someone could tell me how to
keep my branch updated with the mainline?
Thanks,
Chad Rosier
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:52, Karel Gardas wrote:
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:38, Karel Gardas wrote:
OK, if I understand you well, then I should not use -msoft-float for both:
compiling of eCos lib and then
I've just built gcc with sparc64 as build target (64-bit gcc binary that
generates 64-bit code by default, much like Linux amd64 does).
I've noticed one inconsistency how libraries are installed. For shared
libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
64-bit version i
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
First of all, you can't in general just copy in the old version of
t-arm-elf into a later version of GCC and expect it to work correctly.
Compare the gcc-4.0.x version against the sample one from the website
and then uncomment the relevant bits to suit
On Tue, 2006-01-03 at 15:52, Karel Gardas wrote:
> On Tue, 3 Jan 2006, Richard Earnshaw wrote:
>
> > On Tue, 2006-01-03 at 15:38, Karel Gardas wrote:
> >
> >> OK, if I understand you well, then I should not use -msoft-float for both:
> >> compiling of eCos lib and then for compiling my eCos-based
On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> ... the real
> solution is to transfer the information that the stack space sharing
> knows into some simple set form, and use *that directly* in alias.c, and
> check it *first*, so that if they have the same stack slot, we say there
On Mon, Jan 02, 2006 at 08:10:21PM -0800, Ian Lance Taylor wrote:
> And flow2 calls split_all_insns before the
> prologue and epilogue insns are threaded. When did the bogus split
> happen?
There are at least 3 post-reload split points.
r~
On Mon, Jan 02, 2006 at 10:35:40PM -0500, Hans-Peter Nilsson wrote:
> I was just bitten by the same behavior for define_split.
> Should the same go for define_splits ...
Um, sure.
> and maybe also as a guard test for combine?
That would be silly, since the note doesn't exist that early.
r~
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:38, Karel Gardas wrote:
OK, if I understand you well, then I should not use -msoft-float for both:
compiling of eCos lib and then for compiling my eCos-based app. The
problem is that this is not right way how to workaround th
On Tue, 2006-01-03 at 15:38, Karel Gardas wrote:
> OK, if I understand you well, then I should not use -msoft-float for both:
> compiling of eCos lib and then for compiling my eCos-based app. The
> problem is that this is not right way how to workaround this issue. I've
> checked that I'm not u
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Sat, 2005-12-31 at 20:26, Karel Gardas wrote:
/home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld:
ERROR:
/home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o)
uses hardware FP, wher
On Sat, 2005-12-31 at 20:26, Karel Gardas wrote:
> /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld:
>
> ERROR:
> /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o)
>
> uses hardware FP, whereas hello.xg2 uses software FP
On Mon, 2005-12-26 at 21:41, Ivan Petrov wrote:
> I have one question. So... have small sample programm.
>
> [code]
> int bar( int );
>
> int foo( int a, int b )
> {
>return bar( a + b );
> }
> [/code]
>
> If I compille it with out -thumb parameter, i have very clean code.
>
> add r0, r1
> Jim Blandy wrote:
> On 1/2/06, Paul Schlie wrote:
>> - at the most basic level, I feel like I've too often needlessly wasted
>> time debugging programs at one level of optimization, to only see a
>> different behavior needlessly expressed at a different level of
>> optimization (which I und
On Mon, 2 Jan 2006, Mark Mitchell wrote:
> Richard Guenther wrote:
> > g++ no longer parses
> >
> > ScalarCode >(CflFunctor(omrot, vis_f))(scratch,
> > I, cs, nue, v);
> >
> > correctly, but issues
> >
> > tramp3d-v4.cpp:53573: error: invalid declarator
> >
> > which can be fixed by putti
53 matches
Mail list logo
