* Mike Stump:
> On Oct 24, 2005, at 5:52 PM, Vincent Lefevre wrote:
>> But then, copy-paste would no longer always work since spaces are
>> sometimes added at the end of some lines (depending on the terminal
>> and the context).
>
> Please name such systems. We can then know to not use them, and
Successfully built and installed GCC 4.0.2 on i686-pc-linux-gnu Debian
Testing/Unstable
# config.guess
i686-pc-linux-gnu
# gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-threads --with-cpu=i686
Thread model: posix
gcc version
On 10/25/05, Mike Stump <[EMAIL PROTECTED]> wrote:
> >
> > First off, several fields are marked "skip", though the
> > documents seem to strongly discourage this. For example,
> > see ssa_use_operand_t in tree.h.
>
> Was this a question? :-) Skipping is anti-social and decreases the
> flexibility
> Please name such systems. We can then know to not use them, and can
> document in the manual they are broken if we wish.
IIRC the Windows cut-n-paste cuts a rectangle, not as-printed.
Also, beware of the \r\n line endings, where \r is considered
"whitespace" if it's not auto-converted.
On Oct 24, 2005, at 5:52 PM, Vincent Lefevre wrote:
But then, copy-paste would no longer always work since spaces are
sometimes added at the end of some lines (depending on the terminal
and the context).
Please name such systems. We can then know to not use them, and can
document in the manu
On Tue, Oct 25, 2005 at 02:52:31AM +0200, Vincent Lefevre wrote:
> On 2005-10-25 07:52:36 +0900, Neil Booth wrote:
> > Howard Hinnant wrote:-
> > > I've been reviewing the age-old issue of interpreting
> > > * as the end-of-line indicator as is the current
> > > practice with gcc.
> >
> > FWIW
On 2005-10-25 07:52:36 +0900, Neil Booth wrote:
> Howard Hinnant wrote:-
> > I've been reviewing the age-old issue of interpreting
> > * as the end-of-line indicator as is the current
> > practice with gcc.
>
> FWIW I support abandoning this behaviour too.
But then, copy-paste would no longer
Hi,
I need to do the following. I want to at run time run a data
correction pass on some of my integer arrays. As the data needs
correctioin often, it needs to be done just before the use of such an
array.
I am trying to do this in gcc by inserting a function
(convert(int *))
Christophe LYON wrote:
I have been look at the Dwarf2 frame info generated by GCC, and how it
works.
From what I can see, only the register saves are recorded, and not the
restores. Why?
The frame info is primarily used for C++ EH stack unwinding. Since you
can't throw a C++ exception in an
Janis Johnson <[EMAIL PROTECTED]> writes:
> The end of http://gcc.gnu.org/onlinedocs/gccint/Top-Level.html#Top-Level
> has a link to a separate manual that is supposed to explain how the
> top level build works, including building target libraries. Here's the
> corresponding text in sourcebuild.t
On Tue, Oct 25, 2005 at 07:52:36AM +0900, Neil Booth wrote:
> Howard Hinnant wrote:-
>
> > I've been reviewing the age-old issue of interpreting
> > * as the end-of-line indicator as is the current
> > practice with gcc.
>
> FWIW I support abandoning this behaviour too.
It would probably be
Howard Hinnant wrote:-
> I've been reviewing the age-old issue of interpreting
> * as the end-of-line indicator as is the current
> practice with gcc.
FWIW I support abandoning this behaviour too.
Neil.
I've been reviewing the age-old issue of interpreting
* as the end-of-line indicator as is the current
practice with gcc. For those not familiar with this issue, gcc takes
advantage of C99's 5.1.1.2p1b1 "implementation-defined manner" to
convert multibyte end-of-line indicators to newline
The end of http://gcc.gnu.org/onlinedocs/gccint/Top-Level.html#Top-Level
has a link to a separate manual that is supposed to explain how the
top level build works, including building target libraries. Here's the
corresponding text in sourcebuild.texi:
The build system in the top level directory
I have a question about GCC's handling of the condition codes (specifically
the CF, ZF, NF, OF, PF bits in bits in EFLAGS) on the i386 that will
hopefully be trivial to anyone familiar with the implementation of the i386
target. My impression is that GCC generally treats the i386 condition code
> Yes. Instead of a direct call, load the fptr for _mcount and do an
> indirect call. That'll avoid the dynamic linker. You can conditionalize
> this on cfun->static_chain_decl to avoid the extra work when nested
> functions aren't involved.
Ah! yes, of course, writing the stub by hand. This c
Giovanni Bajo wrote:
Hello,
I have rehauled http://gcc.gnu.org/wiki/SvnHelp.
I had a look earlier today and liked a lot! Thanks!
Paolo.
Hello,
I have rehauled http://gcc.gnu.org/wiki/SvnHelp. I'm almost done with it
(should be ready tomorrow), but only a few things are missing now. I believe
I have integrated all the issues raised during the past week in the mailing
list. Also, I have added new information (especially for branch
m
On Oct 24, 2005, at 9:14 AM, Ranjit Mathew wrote:
I have a few queries on GGC, the GCC garbage collector,
and usage of GTY markers in GCC sources. I would be grateful
if someone could take some time out to answer these.
First off, several fields are marked "skip", though the
documents seem to
On Monday 24 October 2005 11:41, David Edelsohn wrote:
> Diego and Daniel, please update your listings in the MAINTAINERS file.
>
Done. Thanks.
Tyler Anderson <[EMAIL PROTECTED]> writes:
> I've gotten much further. I've added the new register
> type to just about everywhere I can think of.
>
> Then I was getting a cannot find a spill register
> error.
Could be any number of things. It's not trivial to do what you are
trying to do. You
On Mon, Oct 24, 2005 at 05:37:06PM +0200, Eric Botcazou wrote:
> Would that be fixable purely on the compiler side without too much kludgery?
Yes. Instead of a direct call, load the fptr for _mcount and do an
indirect call. That'll avoid the dynamic linker. You can conditionalize
this on cfun->
On Mon, Oct 24, 2005 at 06:27:55PM +0200, Christophe LYON wrote:
>
> Hi all,
>
> I have been look at the Dwarf2 frame info generated by GCC, and how it
> works.
> From what I can see, only the register saves are recorded, and not the
> restores. Why?
IIUC, because (A) it's much harder, and (B)
Hi all,
I have been look at the Dwarf2 frame info generated by GCC, and how it
works.
From what I can see, only the register saves are recorded, and not the
restores. Why?
I guess it may loose GDB if one sets a breakpoint inside a function
epilogue, right?
I am currently working on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have a few queries on GGC, the GCC garbage collector,
and usage of GTY markers in GCC sources. I would be grateful
if someone could take some time out to answer these.
First off, several fields are marked "skip", though the
documents seem to
On Thu, 20 Oct 2005, Richard Guenther wrote:
> If it is at all possible we should probably try to keep read-only CVS
> working (and up-to-date) for HEAD and release-branches.
That would be great. It would allow me to continue my nightly bootstraps
on some guest account without interruption.
On
I am pleased to announce that the GCC Steering Committee has
appointed Diego Novillo and Daniel Berlin as alias analysis maintainers --
both Tree-SSA and RTL middle-end.
Please join me in congratulating Diego and Daniel on their new
role. Diego and Daniel, please update your listi
Hi,
As the title may hint at, the combination doesn't work because:
1. the static chain register is r15 and
2. mcount is called from the prologue and
3. r15 is correctly preserved in glibc/sysdeps/ia64/_mcount.S but
4. r15 is clobbered in the PLT:
5.3.6 Procedure Linkage Table
2.
I've gotten much further. I've added the new register
type to just about everywhere I can think of.
Then I was getting a cannot find a spill register
error.
Any thoughts?
Tyler
--- Ian Lance Taylor wrote:
> Tyler Anderson <[EMAIL PROTECTED]> writes:
>
> > I've already added the new type to i
> The cases you have to look at are the ones with move-if-change. You
> have to make sure that if the file does not change, none of the
> dependencies are considered to have changed.
>
> For example in
>
> multilib.h: s-mlib; @true
> s-mlib: $(srcdir)/genmultilib Makefile
> ...
> $(SHE
On Mon, 2005-10-24 at 04:50 +, shreyas krishnan wrote:
> Hi ,
> I am overwhelmed with the jargon and world of alias analysis and
> different kinds of it. I was wondering if some one can help me with
> this simple question. Is deciding if a pointer is pointing to what
> segment (heap/othe
shreyas krishnan wrote:
Hi ,
I am overwhelmed with the jargon and world of alias analysis and
different kinds of it. I was wondering if some one can help me with
this simple question. Is deciding if a pointer is pointing to what
segment (heap/otherwise) a simpler problem than exactly decid
32 matches
Mail list logo
