Looking for specific pages from Muchnick's book

[Steven Bosscher]

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
university library, but that copy has been removed from the collection
and, apparently, it's been disposed off :-(

Could someone scan those pages and send them to me, please?

Thanks,

Gr.
Steven

Libiberty functions

[Paulo J. Matos]

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 but I would like
confirmation on this.

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

RE: Libiberty functions

[Dave Korn]

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 around?
> 
> I am almost sure it should be the other way around but I would like
> confirmation on this.

  Huh?  I don't quite get you here.  For example, xmalloc is a wrapper around
the system malloc; all it does is calls malloc and checks the result isn't
NULL.  So you don't need any xfree; just call the ordinary system free.  Same
goes for xstrdup; it's just a wrapper around the standard strdup
implementation that guarantees it won't fail; since strlen doesn't allocate
any memory and can't fail, there's no need for a xstrlen function.  In any
case, it's not a matter of include file ordering; you should have no need to
do anything other than just stick to the usual ordering, which is standard
library files first, application files last.

  There's libiberty documentation available online at DJ's homepage:
http://www.delorie.com/gnu/docs/gcc/libiberty.html

  (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-Information
for the full gory details)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Libiberty functions

[Diego Novillo]

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-Information
> for the full gory details)

That's not right.  GCC does not use GC memory everywhere, passes can
also heap-allocate and/or use obstacks.  You do have to be careful when
mixing heap-allocated with GC memory, but for pass-local memory
allocation schemes, heap and obstacks are perfectly fine.

Paulo, you may also want to use the XNEW/XCNEW wrapper macros.  They are
 handy shorthand wrappers around malloc.

Another convenient way of allocating a pool of memory is to use obstacks
(See libiberty/obstack.c).

Re: Looking for specific pages from Muchnick's book

[Steven Bosscher]

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 be a problem, back when I was a student), but the
shipping to Europe takes at least 9 days, and in my experience usually
more than a month. In order to move ahead with a plan I'm persuing, I
just want to read those pages asap, not many weeks from now ;-)

Gr.
Steven

RE: Looking for specific pages from Muchnick's book

[Dave Korn]

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 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.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Looking for specific pages from Muchnick's book

[Bob Rossi]

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 books
> collection because of its price. I used to have access to a copy in a
> university library, but that copy has been removed from the collection
> and, apparently, it's been disposed off :-(
> 
> Could someone scan those pages and send them to me, please?

Hi,

With a little hard work, you can make google show you the pages.
http://books.google.com/books?vid=ISBN1558603204&id=Pq7pHwG1_OkC&pg=PP1&lpg=PP1&ots=4VaZHsi8qT&dq=Advanced+Compiler+Design+and+Implementation&sig=w20IRwAK8s3z7gCUB1LSzmPqOf0#PRA1-PA202,M1

If you search for 'structural analysis', pages 202, 203, 204, 205, 210,
211, 212 and 214 come up. You only need to make it show you 5 more
pages.

Bob Rossi

Re: Looking for specific pages from Muchnick's book

[Robert Dewar]

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 so no one is confused, "fair 
use" does not mean "use that anyone would consider fair", it refers

specifically to the fair use section of the copyright act, which lays
out very specific criteria. So the question of "perfectly clear words 
and phrases" is not the issue. I suggest anyone interested actually

read the statute!


cheers,
  DaveK

Re: Libiberty functions

[Andrew Pinski]

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.

-- Pinski

Re: Looking for specific pages from Muchnick's book

[Steven Bosscher]

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
> english language.

It is of course way off topic, but just so no one is confused, "fair
use" does not mean "use that anyone would consider fair", it refers
specifically to the fair use section of the copyright act, which lays
out very specific criteria. So the question of "perfectly clear words
and phrases" is not the issue. I suggest anyone interested actually
read the statute!


In the mean time, I've received those pages.  I'll make sure to
ritually burn them when I finally receive the book.

To stray a bit further off topic, I'd actually much more enjoy the
book if I would not have to print out almost as many pages as the book
has to get all the errata. IMVHO very few books have a poorer
quality/price ratio than Muchnick, which is why I have never found it
worth it to buy it before. There should be a law that says you can
freely copy books with too many errata ;-)

Gr.
Steven

Re: Libiberty functions

[Paulo J. Matos]

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 stdlib
but I understand now that I need stdlib anyway. :)

Thank you.

On 3/8/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:

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.

-- Pinski




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

MODIFY_EXPR lhs

[Paulo J. Matos]

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 type of the variable. Is it like that?

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Static Chain Argument in call_expr

[Paulo J. Matos]

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 Southampton, UK

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

[Kai Tietz]

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 until now 
in libc++, libiberty. There are ISO types defined for this case, as 
intptr_t  and uintptr_t. Is there something defined in the coding style ?

Regards,
 i.A. Kai Tietz

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

[DJ Delorie]

> 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

[Duncan Sands]

> 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 how child using a variable of parent, namely
the parameter n.  This gets lowered to something like:

struct frame { int n; };

int child (struct frame *static_chain, int m) { return m * static_chain->n; }

int parent (int n)
{
  struct frame FRAME;
  FRAME.n = n;
  return child (&FRAME, 2);
}

Ciao,

Duncan.

gcc gcov and --coverage on x86_64

[Matt Fago]

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?

Thanks,
Matt

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

[Kai Tietz]

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 (hashval_t) ((long)p >> 3);
+  return (hashval_t) ((intptr_t)p >> 3);
 }
 
 /* Returns non-zero if P1 and P2 are equal.  */
Index: pex-common.h
===
--- pex-common.h(revision 122691)
+++ pex-common.h(working copy)
@@ -108,7 +108,7 @@
  closed in the child process.  The function should handle the
  PEX_STDERR_TO_STDOUT flag.  Return >= 0 on success, or -1 on
  error and set *ERRMSG and *ERR.  */
-  long (*exec_child) (struct pex_obj *, int /* flags */,
+  intptr_t (*exec_child) (struct pex_obj *, int /* flags */,
   const char */* executable */, char * const * /* 
argv */,
   char * const * /* env */,
   int /* in */, int /* out */, int /* errdes */,
@@ -120,7 +120,7 @@
  and time in *TIME (if it is not null).  CHILD is from fork.  DONE
  is 1 if this is called via pex_free.  ERRMSG and ERR are as in
  fork.  Return 0 on success, -1 on error.  */
-  int (*wait) (struct pex_obj *, long /* child */, int * /* status */,
+  int (*wait) (struct pex_obj *, intptr_t /* child */, int * /* status 
*/,
struct pex_time * /* time */, int /* done */,
const char ** /* errmsg */, int * /* err */);
   /* Create a pipe (only called if PEX_USE_PIPES is set) storing two
Index: pex-win32.c
===
--- pex-win32.c (revision 122691)
+++ pex-win32.c (working copy)
@@ -79,12 +79,12 @@
 
 static int pex_win32_open_read (struct pex_obj *, const char *, int);
 static int pex_win32_open_write (struct pex_obj *, const char *, int);
-static long pex_win32_exec_child (struct pex_obj *, int, const char *,
+static intptr_t pex_win32_exec_child (struct pex_obj *, int, const char 
*,
  char * const *, char * const *,
   int, int, int, int,
  const char **, int *);
 static int pex_win32_close (struct pex_obj *, int);
-static int pex_win32_wait (struct pex_obj *, long, int *,
+static int pex_win32_wait (struct pex_obj *, intptr_t, int *,
   struct pex_time *, int, const char **, int *);
 static int pex_win32_pipe (struct pex_obj *, int *, int);
 static FILE *pex_win32_fdopenr (struct pex_obj *, int, int);
@@ -522,7 +522,7 @@
   return c1 - c2;
 }
 
-static long
+static intptr_t
 win32_spawn (const char *executable,
 BOOL search,
 char *const *argv,
@@ -606,7 +606,7 @@
   if (env_block)
 free (env_block);
 
-  return (long) pi->hProcess;
+  return (intptr_t) pi->hProcess;
 
  error:
   if (env_block)
@@ -616,17 +616,17 @@
   if (full_executable)
 free (full_executable);
 
-  return -1;
+  return (intptr_t) -1;
 }
 
-static long
+static intptr_t
 spawn_script (const char *executable, char *const *argv,
   char* const *env,
  DWORD dwCreationFlags,
  LPSTARTUPINFO si,
  LPPROCESS_INFORMATION pi)
 {
-  int pid = -1;
+  intptr_t pid = -1;
   int save_errno = errno;
   int fd = _open (executable, _O_RDONLY);
 
@@ -696,7 +696,7 @@
 
 /* Execute a child.  */
 
-static long
+static intptr_t
 pex_win32_exec_child (struct pex_obj *obj ATTRIBUTE_UNUSED, int flags,
  const char *executable, char * const * argv,
   char* const* env,
@@ -705,7 +705,7 @@
  const char **errmsg,
  int *err)
 {
-  long pid;
+  intptr_t pid;
   HANDLE stdin_handle;
   HANDLE stdout_handle;
   HANDLE stderr_handle;
@@ -808,7 +808,7 @@
macros.  Note that WIFSIGNALED will never be true under CRTDLL. */
 
 static int
-pex_win32_wait (struct pex_obj *obj ATTRIBUTE_UNUSED, long pid,
+pex_win32_wait (struct pex_obj *obj ATTRIBUTE_UNUSED, intptr_t pid,
int *status, struct pex_time *time, int done 
ATTRIBUTE_UNUSED,
const char **errmsg, int *err)
 {

Regards,
 i.A. Kai Tietz


  Kai Tietz - Software engineering
  OneVision Software Entwicklungs GmbH & Co KG
  Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
  Phone: +49-941-78004-0
  FAX:   +49-941-78004-489
  WWW:   http://www.OneVision.com



DJ Delorie <[EMAIL PROTECTED]> 
08.03.2007 17:04

To
[EMAIL PROTECTED]
cc
gcc@gcc.gnu.org
Subject
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: What does coding-style tells about integer types for pointers ?

[DJ Delorie]

> In libiberty I found the following points.

Do any of these cause real failures?

Re: Static Chain Argument in call_expr

[Paulo J. Matos]

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 m) { return m * n; }

  return child (2);
}

Notice how child using a variable of parent, namely
the parameter n.  This gets lowered to something like:

struct frame { int n; };

int child (struct frame *static_chain, int m) { return m * static_chain->n; }

int parent (int n)
{
  struct frame FRAME;
  FRAME.n = n;
  return child (&FRAME, 2);
}



Ah, nice, didn't know that was possible in C. Is that new in C99 or
it's a GCC extension?

Cheers,

Paulo Matos


Ciao,

Duncan.




--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

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

[Kai Tietz]

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 so for mingw ;(

Regards,
 i.A. Kai Tietz


  Kai Tietz - Software engineering
  OneVision Software Entwicklungs GmbH & Co KG
  Dr.-Leo-Ritter-Str. 9, 93049 Regensburg, Germany
  Phone: +49-941-78004-0
  FAX:   +49-941-78004-489
  WWW:   http://www.OneVision.com



DJ Delorie <[EMAIL PROTECTED]> 
08.03.2007 17:30

To
[EMAIL PROTECTED]
cc
gcc@gcc.gnu.org
Subject
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?

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

[Kai Tietz]

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 PROTECTED]
cc

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







But... hash values aren't pointers, so we should never be converting
them back to pointers.  Nor are PIDs.

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

[Joseph S. Myers]

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 pointer 8 bytes. I found this problems until now 
> in libc++, libiberty. There are ISO types defined for this case, as 
> intptr_t  and uintptr_t. Is there something defined in the coding style ?

GCC does not know about the target's intptr_t and uintptr_t; you'd need 
new target macros for that.  (They could default to the same as ptrdiff_t 
and size_t.)

GCC does not know about such types for the host either, but already has 
autoconf support (config/stdint*) for creating a local stdint.h where the 
host lacks one.  You'll need to make sure that autoconf support is used in 
any host directory where you wish to use intptr_t / uintptr_t.

Testcases in the GCC testsuite should generally use __SIZE_TYPE__ and 
__PTRDIFF_TYPE__ for such cases.

Target libraries such as libstdc++ can probably use size_t and ptrdiff_t 
reasonably safely for this.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

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

[Ian Lance Taylor]

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 pointer 8 bytes. I found this problems until now 
> in libc++, libiberty. There are ISO types defined for this case, as 
> intptr_t  and uintptr_t. Is there something defined in the coding style ?

Code in gcc which assumes that sizeof (long) == sizeof (void *) is
broken.  Tell us where that code is, and we will try to fix it.

Ian

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

[Kai Tietz]

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
  Phone: +49-941-78004-0
  FAX:   +49-941-78004-489
  WWW:   http://www.OneVision.com



Ian Lance Taylor <[EMAIL PROTECTED]> 
08.03.2007 18:02

To
Kai Tietz <[EMAIL PROTECTED]>
cc
gcc@gcc.gnu.org
Subject
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 pointer 8 bytes. I found this problems until 
now 
> in libc++, libiberty. There are ISO types defined for this case, as 
> intptr_t  and uintptr_t. Is there something defined in the coding style 
?

Code in gcc which assumes that sizeof (long) == sizeof (void *) is
broken.  Tell us where that code is, and we will try to fix it.

Ian

Strange Behavior

[Eric Lemings]

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 platform) that
the
byte at offset 0230 (octal) is either read in with an incorrect value or
is
skipped entirely.

template < class InputItor, class OutputItor >
OutputItor
encode (InputItor first, InputItor last,
OutputItor out) {

  static const char s [] =
  "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
  "abcdefghijklmnopqrstuvwxyz"
  "0123456789+/";

  while (first != last) {
unsigned char uc0 = *first++;
int i0 = (uc0>>2) & 0x3f;
char c0 = s [i0];
*out++ = c0;

unsigned char uc1 = (first == last? 0: *first++);
int i1 = ((uc0<<4) + (uc1>>4)) & 0x3f;
char c1 = s [i1];
*out++ = c1;

bool eof = (first == last);
unsigned char uc2 = (eof? 0: *first++);
int i2 = ((uc1<<2) + (uc2>>6)) & 0x3f;
char c2 = (eof? '=': s [i2]);
*out++ = c2;

int i3 = uc2 & 0x3f;
char c3 = (first == last? '=': s [i3]);
*out++ = c3;
  }

  return out;
}

#include 
#include 
#include 
#include 
#include 
using namespace std;

extern int
main () {
  ifstream in ("logo.gif", ios_base::binary);

  istream_iterator< char > first (in);
  istream_iterator< char > last;
  string s;
  encode (first, last, back_inserter (s));

  cout << s;

  return 0;
}

You can boil the while loop down to it's basic read operations and still
see the same results.

  while (first != last) {
unsigned char uc0 = *first++;
unsigned char uc1 = (first == last? 0: *first++);
unsigned char uc2 = (first == last? 0: *first++);
}

Just for sake of sanity, I wrote a quick version of the algorithm in C.
Naturally, this program behaves as it should.

#include 
#include 

extern int
main (int argc, char* argv []) {

  FILE* in = fopen ("logo.gif", "rb");
  if (in == NULL) {
perror (argv[0]);
exit (EXIT_FAILURE);
  }

  const char s [] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"abcdefghijklmnopqrstuvwxyz"
"0123456789+/";

  while (!feof (in)) {
unsigned char uc0 = fgetc (in);
int i0 = (uc0>>2) & 0x3f;
char c0 = s [i0];
putc (c0, stdout);

unsigned char uc1 = (feof (in)? 0: fgetc (in));
int i1 = ((uc0<<4) + (uc1>>4)) & 0x3f;
char c1 = s [i1];
putc (c1, stdout);

int eof = feof (in);
unsigned char uc2 = (eof? 0: fgetc (in));
int i2 = ((uc1<<2) + (uc2>>6)) & 0x3f;
char c2 = (eof? '=': s [i2]);
putc (c2, stdout);

int i3 = uc2 & 0x3f;
char c3 = (feof (in)? '=': s [i3]);
putc (c3, stdout);
  }

  fclose (in);

  return 0;
}

If anyone can shed some light on the strange behavior in the C++
program,
I would appreciate it very much.

Thanks,
Eric.

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

[Kai Tietz]

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: +49-941-78004-0
  FAX:   +49-941-78004-489
  WWW:   http://www.OneVision.com



"Joseph S. Myers" <[EMAIL PROTECTED]> 
08.03.2007 18:00

To
Kai Tietz <[EMAIL PROTECTED]>
cc
gcc@gcc.gnu.org
Subject
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 pointer 8 bytes. I found this problems until 
now 
> in libc++, libiberty. There are ISO types defined for this case, as 
> intptr_t  and uintptr_t. Is there something defined in the coding style 
?

GCC does not know about the target's intptr_t and uintptr_t; you'd need 
new target macros for that.  (They could default to the same as ptrdiff_t 
and size_t.)

GCC does not know about such types for the host either, but already has 
autoconf support (config/stdint*) for creating a local stdint.h where the 
host lacks one.  You'll need to make sure that autoconf support is used in 

any host directory where you wish to use intptr_t / uintptr_t.

Testcases in the GCC testsuite should generally use __SIZE_TYPE__ and 
__PTRDIFF_TYPE__ for such cases.

Target libraries such as libstdc++ can probably use size_t and ptrdiff_t 
reasonably safely for this.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Static Chain Argument in call_expr

[Ian Lance Taylor]

"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 ?

[Joseph S. Myers]

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 target system, and all three may differ.  
Sometimes they may only care about the width of the types, other times 
about the exact type (that is, about whether it's "int" or "long" where 
they have the same size, which affects C++ name mangling).

For the build and host you can use that autoconf support from 
config/stdint.m4.  It's less safe to do so for the target because such 
support may get the wrong choice between types of the same size.  Of 
course, for many places for the target you may not care about which type 
of a given size is chosen; but if these types ever appear in C++ ABIs, 
then you need to care.  For purely internal use not appearing in ABIs, 
size_t and ptrdiff_t should work.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Strange Behavior

[Andreas Schwab]

"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.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Richard Henderson]

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

[Ayal Zaks]

> > > "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 be removed (I have some patches for that, but I somehow
> forgot on them because of other issues).
>
> Zdenek
...
> > > ... determine the minimum trip count needed for the vector loop to be
> > > profitable.

So, if we know the actual trip count to be more than this minimum trip
count (mtc), we'll abandon the effort to vectorize. And if we don't know
the actual trip count, we can ask at runtime if it is larger than mtc. We
already ask at runtime if the actual trip count is larger than the
vectorization factor, if we don't know the actual trip count at compile
time. In such (predominant?) cases the vectorized loop gets versioned,
keeping its original scalar version and introducing another, vector
version, with this runtime guard choosing between the two. (This is also
used to check if potentially aliased pointers overlap, or to check
alignment constraints.) If we version the loop, we can update the threshold
of this guard at a later stage, when the cost of each version becomes more
apparent (RTL).

So if we don't want to generate RTL just for the sake of computing its
cost, we can wait until it is eventually generated (and optimized) and plug
its cost back where we need it.

One disadvantage is that we're not saving compile-time (and probably
produce worse code) if the mtc turns out to be greater than a known trip
count, or greater than any conceivable trip count. There are ways to try
and cope with this disadvantage, and there are additional disadvantages...

BTW, we had a simple cost model for the modulo scheduler, which turned out
to be overly conservative (fourth in-progress item on
http://gcc.gnu.org/wiki/SwingModuloScheduling).

Ayal.

Updating libtool in GCC and srctree

[Steve Ellcey]

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 documentation it says
that to include libtool in your package you need to add config.guess,
config.sub, install-sh, and ltmain.sh to your package.  We already have
the install-sh that is in the latest libtool and our config.guess and
config.sub look to be newer than the ones in libtool so that just leaves
ltmain.sh.  I downloaded the 2.1a snapshot of libtool and found
ltmain.sh in libltdl/config/ltmain.sh, I copied that to the top level of
the src tree and then removed libtool.m4, ltconfig, ltcf-c.sh,
ltcf-cxx.sh, and ltcf-gcj.sh.

I was able to run autoconf on the top-level of the source tree with no
errors but when I did a configure/make I got the following error while
make was in the bfd subdirectory:

make[3]: Entering directory `/proj/opensrc/sje/svn.libtool/build-ia64-hp-hpux11.
23-trunk/obj_src/bfd'
make[3]: LIBTOOL@: Command not found
make[3]: *** [archive.lo] Error 127

So I went into bfd and tried to run autoconf there but I get the errors:

$ /proj/opensrc/be/ia64-hp-hpux11.23/bin/autoconf
configure.in:13: error: possibly undefined macro: AM_PROG_LIBTOOL
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.in:20: error: possibly undefined macro: AM_DISABLE_SHARED

I tried changing the macros to AC_* but that didn't help, should I just 
use m4_pattern_allow or am I missing a bigger picture here?

Steve Ellcey
[EMAIL PROTECTED]

Re: Updating libtool in GCC and srctree

[Andreas Schwab]

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 top level of
> the src tree and then removed libtool.m4,

You'll still need libtool.m4.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Updating libtool in GCC and srctree

[Steve Ellcey]

> > 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 want to use ToT libtool as opposed to the latest
released one.

> > ltmain.sh in libltdl/config/ltmain.sh, I copied that to the top level of
> > the src tree and then removed libtool.m4,
> 
> You'll still need libtool.m4.

Are you sure?  According to
 we
shouldn't need libtool.m4 in our package.

Steve Ellcey
[EMAIL PROTECTED]

Re: Updating libtool in GCC and srctree

[Joseph S. Myers]

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 should use current CVS HEAD libtool.  We definitely can't use 1.5 
releases without *a lot* of auditing of local changes: we've allowed local 
changes into GCC's libtool on the basis that there are equivalents in CVS 
HEAD (this is the policy in codingconventions.html), to use 1.5 while 
avoiding regressions would require auditing every local change since 
libtool 1.5 branched to see if it's in 1.5.22.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Updating libtool in GCC and srctree

[Andreas Schwab]

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.

Sorry, I was confused.  You are right.

>> > ltmain.sh in libltdl/config/ltmain.sh, I copied that to the top level of
>> > the src tree and then removed libtool.m4,
>> 
>> You'll still need libtool.m4.
>
> Are you sure?  According to
>  we
> shouldn't need libtool.m4 in our package.

You still need the macros when you regenerate configure.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc gcov and --coverage on x86_64

[Ben Elliston]

> 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 it.  If necessary, you can
then file a bug report.

Ben

Re: Updating libtool in GCC and srctree

[Alexandre Oliva]

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 the ltmain.sh in
your tree).

Personally, I prefer to manage both libtool.m4 and ltmain.sh by hand,
because then I can make sure they are in sync.

So, yes, don't remove it, replace it with the version from the same
CVS tree.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: Looking for specific pages from Muchnick's book

[jimmy]

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 you've mentioned it, could you also suggest a few books worth 
buying (for the benefit of the not-so-compiler-savvy-but-want-to-be :). 
I think it would be very much appreciated!



thnx,
-jb
--
mathematician, n.:
Some one who believes imaginary things appear right before your 
i's.

Re: Updating libtool in GCC and srctree

[Mike Frysinger]

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 
redistributable source tarball ... since you shouldnt be regenerating 
autotools with that package, you shouldnt include the libtool.m4

in the sourceware case, regenerating the files happens often so the .m4 should 
be included to match the ltmain.sh ... very weird things can happen if the 
libtool code that makes it into configure (via the .m4/aclocal) is a 
different version from the ltmain.sh ... i like the one where shared 
libraries are generated but they lack the '.so' suffix :)
-mike


pgpoWYHqkZCcc.pgp
Description: PGP signature