Looking for specific pages from Muchnick's book

Hi, I found this old patch (http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers to pages 202-214 of Muchnick's "Advanced Compiler Design and Implementation" book. That book still is not in my own compiler books collection because of its price. I used to have access to a copy in a

Libiberty functions

Hello all, when using functions from libiberty, I'm for example using xstrdup and xmalloc but free is not defined as free or xfree afail nor strlen so how should I include things? Before system.h and then standard libs or the other way around? I am almost sure it should be the other way around b

RE: Libiberty functions

On 08 March 2007 11:46, Paulo J. Matos wrote: > Hello all, > > when using functions from libiberty, I'm for example using xstrdup and > xmalloc but free is not defined as free or xfree afail nor strlen so > how should I include things? Before system.h and then standard libs or > the other way aro

Re: Libiberty functions

Dave Korn wrote on 03/08/07 07:30: > (Also, bear in mind that if you want your new pass to work correctly with > pre-compiled headers, you really ought to be using Gcc's garbage-collected > memory management facilities. See > http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Infor

Re: Looking for specific pages from Muchnick's book

On 3/8/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: Could someone scan those pages and send them to me, please? I received some private mails from people that are concerned about copyright issues and all that. I should have said I've actually ordered the book from Amazon (the price used to b

RE: Looking for specific pages from Muchnick's book

On 08 March 2007 12:59, Steven Bosscher wrote: > On 3/8/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: >> Could someone scan those pages and send them to me, please? > > I received some private mails from people that are concerned about > copyright issues and all that. A few pages for personal

Re: Looking for specific pages from Muchnick's book

On Thu, Mar 08, 2007 at 10:05:11AM +0100, Steven Bosscher wrote: > Hi, > > I found this old patch > (http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers > to pages 202-214 of Muchnick's "Advanced Compiler Design and > Implementation" book. That book still is not in my own compiler

Re: Looking for specific pages from Muchnick's book

Dave Korn wrote: A few pages for personal study? That's fair use by any meaningful definition, no matter how much the RIAA/MPAA/similar-copyright-nazis would like to redefine the meanings of perfectly clear words and phrases in the english language. It is of course way off topic, but just s

Re: Libiberty functions

On 3/8/07, Diego Novillo <[EMAIL PROTECTED]> wrote: Another convenient way of allocating a pool of memory is to use obstacks (See libiberty/obstack.c). Though alloc-pool might be a better idea than obstack, see alloc-pool.[ch]. As alloc-pool contains checking code while obstack does not. -- P

Re: Looking for specific pages from Muchnick's book

On 3/8/07, Robert Dewar <[EMAIL PROTECTED]> wrote: Dave Korn wrote: > A few pages for personal study? That's fair use by any meaningful > definition, no matter how much the RIAA/MPAA/similar-copyright-nazis would > like to redefine the meanings of perfectly clear words and phrases in the > en

Re: Libiberty functions

Thank you all for the excellent suggestions, I'll be looking into all of your references this afternoon. Regarding my initial question, I understand I don't need free. My real problem was if I needed to include standard libraries after including system.h or if system.h would provide me free from s

MODIFY_EXPR lhs

Hello, Why is it that a left hand side of a modify_expr usually had void_type while other times it has integer, real or something else _type? One pattern I'm detecting is that when the lhs is a user variable it has void type, but when the lhs if a gcc generated variable, the modify expr has the t

Static Chain Argument in call_expr

Hello, in tree.def, in DEFTREECODE for call_expr, it says operand 2 is the static chain argument, or NULL. Can someone tell me or reference me to what static chain argument is? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of

What does coding-style tells about integer types for pointers ?

Hi, while porting gcc to the new target x86_64-pc-mingw32 I noticed, that on many places the long type is wrongly used as equivalent for pointers. This leads for this MS compatible target to some problems, because the long is just 4 bytes long and the pointer 8 bytes. I found this problems unti

Re: What does coding-style tells about integer types for pointers ?

> I found this problems until now in libc++, libiberty. Could you be more specific about the libiberty ones?

Re: Static Chain Argument in call_expr

> in tree.def, in DEFTREECODE for call_expr, it says operand 2 is the > static chain argument, or NULL. Can someone tell me or reference me to > what static chain argument is? It's for nested functions, eg int parent (int n) { int child (int m) { return m * n; } return child (2); } Notice h

gcc gcov and --coverage on x86_64

Having searched in bugzilla and asked on gcc-help to no avail ... gcc --coverage appears to be broken on x86_64 in gcc 4.1.1 on FC6 (works fine with Trunk). I'm almost certain that this is a known issue, but cannot find a reference in Bugzilla. Could someone please give me a pointer to the bug?

Re: What does coding-style tells about integer types for pointers ?

In libiberty the following points I found the following points. Index: hashtab.c === --- hashtab.c (revision 122691) +++ hashtab.c (working copy) @@ -196,7 +196,7 @@ static hashval_t hash_pointer (const PTR p) { - return (hash

Re: What does coding-style tells about integer types for pointers ?

> In libiberty I found the following points. Do any of these cause real failures?

Re: Static Chain Argument in call_expr

On 3/8/07, Duncan Sands <[EMAIL PROTECTED]> wrote: > in tree.def, in DEFTREECODE for call_expr, it says operand 2 is the > static chain argument, or NULL. Can someone tell me or reference me to > what static chain argument is? It's for nested functions, eg int parent (int n) { int child (int

What does coding-style tells about integer types for pointers ?

Yes, it does. The pointer cast to a long and the cast of a long to a pointer e.g. in pex-win32 leads under x86_64 to an serious pointer-truncation. Windows x86 may have pointers exceeding the 2^31 range. For linux on x86_64 it would fit, because the long has the sizeof a pointer, but this isn't

What does coding-style tells about integer types for pointers ?

Yes, for the hashtab.c it is more a cosmetic issue. But for pex-win32.c is not. See method pex_win32_wait, there the pid is getting casted to the type HANDLE, which is in fact declared as a void pointer. Regards, i.A. Kai Tietz DJ Delorie <[EMAIL PROTECTED]> 08.03.2007 17:46 To [EMAIL PR

Re: What does coding-style tells about integer types for pointers ?

On Thu, 8 Mar 2007, Kai Tietz wrote: > while porting gcc to the new target x86_64-pc-mingw32 I noticed, that on > many places the long type is wrongly used as equivalent for pointers. This > leads for this MS compatible target to some problems, because the long is > just 4 bytes long and the po

Re: What does coding-style tells about integer types for pointers ?

Kai Tietz <[EMAIL PROTECTED]> writes: > while porting gcc to the new target x86_64-pc-mingw32 I noticed, that on > many places the long type is wrongly used as equivalent for pointers. This > leads for this MS compatible target to some problems, because the long is > just 4 bytes long and the p

Re: What does coding-style tells about integer types for pointers ?

In gcc the file emutls.c assumes that a long has sizeof void * in function emutls_destroy. Regards, i.A. Kai Tietz Kai Tietz - Software engineering OneVision Software Entwicklungs GmbH & Co KG Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany Phon

Strange Behavior

Greetings, While writing a generic C++ algoririthm for base64 encoding, I came across some very strange behavior. If you take the following program (admittedly verbose for debugging purposes) and test it on some data, say the logo image from www.google.com, you may notice (depending on your plat

Re: What does coding-style tells about integer types for pointers ?

As I know, the types are declared in config/stdint.m4, which is part of gcc, isn't it ? Regards, i.A. Kai Tietz Kai Tietz - Software engineering OneVision Software Entwicklungs GmbH & Co KG Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany Phone:

Re: Static Chain Argument in call_expr

"Paulo J. Matos" <[EMAIL PROTECTED]> writes: > Ah, nice, didn't know that was possible in C. Is that new in C99 or > it's a GCC extension? Nested functions are a gcc extension. Ian

Re: What does coding-style tells about integer types for pointers ?

On Thu, 8 Mar 2007, Kai Tietz wrote: > As I know, the types are declared in config/stdint.m4, which is part of > gcc, isn't it ? There are many different things "part of GCC" can mean. Different parts of GCC may wish to know these types for the build system, for the host system or for the targ

Re: Strange Behavior

"Eric Lemings" <[EMAIL PROTECTED]> writes: > If anyone can shed some light on the strange behavior in the C++ > program, This is not the appropriate forum, which is about development of GCC, for such questions. Please use [EMAIL PROTECTED] or a general programming forum instead. Andreas. -- A

Re: What does coding-style tells about integer types for pointers ?

On Thu, Mar 08, 2007 at 06:06:57PM +0100, Kai Tietz wrote: > In gcc the file emutls.c assumes that a long has sizeof void * in function > emutls_destroy. Not really. It assumes you can store the size of the array in min(sizeof(long), sizeof(void*)) bytes. r~

Re: RFC: vectorizer cost model

> > > "Linthicum, Tony" <[EMAIL PROTECTED]> writes: ... > > > * What is the best way to access target level cost information? > > > > I'm sure you know that the loop code does this by generating RTL and > > asking for the cost of it (computation_cost in tree-ssa-loop-ivopts.c). > > Which should

Updating libtool in GCC and srctree

Now that autoconf has been updated to 2.59, I would like to update the libtool that GCC and the binutils/gdb/etc use. Unfortunately, I am not having much luck coming up with a patch and figuring out what all needs to be reconfigured. Here is what I have tried so far. In the libtool documentatio

Re: Updating libtool in GCC and srctree

Steve Ellcey <[EMAIL PROTECTED]> writes: > I downloaded the 2.1a snapshot of libtool and found Are you sure you want to use the (rather oldish) 2.1a snapshot? I think you'll better off using the latest stable release which is 1.5.22. > ltmain.sh in libltdl/config/ltmain.sh, I copied that to the

Re: Updating libtool in GCC and srctree

> > I downloaded the 2.1a snapshot of libtool and found > > Are you sure you want to use the (rather oldish) 2.1a snapshot? I think > you'll better off using the latest stable release which is 1.5.22. I thought that 2.1a was a snapshot of ToT. I have some recollection of someone saying we would

Re: Updating libtool in GCC and srctree

On Fri, 9 Mar 2007, Andreas Schwab wrote: > Steve Ellcey <[EMAIL PROTECTED]> writes: > > > I downloaded the 2.1a snapshot of libtool and found > > Are you sure you want to use the (rather oldish) 2.1a snapshot? I think > you'll better off using the latest stable release which is 1.5.22. We sho

Re: Updating libtool in GCC and srctree

Steve Ellcey <[EMAIL PROTECTED]> writes: >> > I downloaded the 2.1a snapshot of libtool and found >> >> Are you sure you want to use the (rather oldish) 2.1a snapshot? I think >> you'll better off using the latest stable release which is 1.5.22. > > I thought that 2.1a was a snapshot of ToT. So

Re: gcc gcov and --coverage on x86_64

> gcc --coverage appears to be broken on x86_64 in gcc 4.1.1 on FC6 > (works fine with Trunk). I'm almost certain that this is a known > issue, but cannot find a reference in Bugzilla. I implemented that option, so can probably help you. Contact me in private mail and we'll try and troubleshoot i

Re: Updating libtool in GCC and srctree

On Mar 8, 2007, Steve Ellcey <[EMAIL PROTECTED]> wrote: >> You'll still need libtool.m4. > Are you sure? Yep. You can do away without a manually-managed libtool.m4 if you use aclocal and you trust it will always bring in the right version of libtool.m4 (i.e., in the one that is compatible with

Re: Looking for specific pages from Muchnick's book

Steven Bosscher wrote: Hi, I found this old patch (http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers to pages 202-214 of Muchnick's "Advanced Compiler Design and Implementation" book. That book still is not in my own compiler books collection because of its price. Since yo

Re: Updating libtool in GCC and srctree

On Thursday 08 March 2007, Steve Ellcey wrote: > > You'll still need libtool.m4. > > Are you sure? According to > we > shouldn't need libtool.m4 in our package. i'm pretty sure those guidelines are for people making their final redis