fdump-ast-original and strg:

fdump-ast-original and strg:

[Guillaume]

Hello,

I'm student and I'm trying to build a tool which use the ASG given by g++
using the option -fdump-ast-original. Actually I build a basic parser
which reads the file file.c.original and stores the ASG in memory in a
hash table where the key is the number of a node. I also build a visitor
which visits the ASG in memory and extracts a CFG for some analysis.

The problem is the following. If you have something like:

-- part of a C code --

fprintf(stderr, "error strg: toto");

--

The asg given by gcc gives the following line:

@247    string_cst       type: @268    strg: error strg: toto  lngt: 5

So, I add a very basic modification inside GCC (in c-dump.c) and now, it
produces this line:

@247    string_cst       type: @268    strg: "error strg: toto"  lngt: 5

It is easier to parse. So, I'd like to know if it can be added to official
gcc futur release. It's only one line and for me it will be easier because
people won't need to recompile the gcc compiler if they want to use my
tool (ok for now I'm the only one who use it but it can change...).

Thank you
Sorry for my english

---
Guillaume Thouvenin
GASTA: Gcc Abstract Syntax Tree
http://gasta.sf.net

Re: fdump-ast-original and strg:

[Joe Buck]

Guillaume Thouvenin writes:
...
> The problem is the following. If you have something like:
> 
> -- part of a C code --
> 
> fprintf(stderr, "error strg: toto");
> 
> --
> 
> The asg given by gcc gives the following line:
> 
> @247    string_cst       type: @268    strg: error strg: toto  lngt: 5
> 
> So, I add a very basic modification inside GCC (in c-dump.c) and now, it
> produces this line:
> 
> @247    string_cst       type: @268    strg: "error strg: toto"  lngt: 5
> 
> It is easier to parse. So, I'd like to know if it can be added to official
> gcc futur release. It's only one line and for me it will be easier because
> people won't need to recompile the gcc compiler if they want to use my
> tool (ok for now I'm the only one who use it but it can change...).

This seems reasonable, but does your patch do the whole job?  What happens
if the string contains newlines, control characters, or '"'?  It would
seem reasonable to make the output match the input (that is, output \",
\n, etc).

Re: fdump-ast-original and strg:

[Guillaume]

On Thu, 29 Nov 2001, Joe Buck wrote:

> Guillaume Thouvenin writes:
> ...
> > The problem is the following. If you have something like:
> >
> > -- part of a C code --
> >
> > fprintf(stderr, "error strg: toto");
> >
> > --
> >
> > The asg given by gcc gives the following line:
> >
> > @247    string_cst       type: @268    strg: error strg: toto  lngt: 5
> >
> > So, I add a very basic modification inside GCC (in c-dump.c) and now, it
> > produces this line:
> >
> > @247    string_cst       type: @268    strg: "error strg: toto"  lngt: 5
> >
> This seems reasonable, but does your patch do the whole job?  What happens
> if the string contains newlines, control characters, or '"'?  It would
> seem reasonable to make the output match the input (that is, output \",
> \n, etc).

No it doesn't do the whole job. If you have something like :

 fprintf (stderr, "Hello\nit's a \"test\"\n");

It will produce :

@54     string_cst       type: @67     strg: "Hello
it's a "test"
"  lngt: 21

So, the good output should be

@54     string_cst       type: @67     strg: "Hello\nit's a \"test\"\n"
        lngt: 21


Actually, strings with newlines, control characters and '"' are treated by
my parser. The only modification that I done in GCC is in file c-dump.c:

line 649:
---
648: case STRING_CST:
649:      fprintf (di->stream, "strg: \"%-7s\" ", TREE_STRING_POINTER (t));
                                      ^^    ^^
650:      dump_int (di, "lngt", TREE_STRING_LENGTH (t));
651:      break;

So, I can try to path GCC to make output match the input?

Guillaume

Re: fdump-ast-original and strg:

[Florian Krohm]

I'm afraid, things are even a bit more complex.
Consider a string containing two characters, the first
of which contains the bit pattern 00001010. The second
character is '2'. If you want to recover the original
representation for that string you will have to use a 
string concatenation e.g. "\12" "2" or "\x6" "2". 
Note that you cannot write "\122" as that would specify
only a single character.
You could call this a pathological example, but I think
you want to come up with an algorithm that can handle
the general case.

Florian

On Friday 30 November 2001 12:54, Guillaume wrote:
> On Thu, 29 Nov 2001, Joe Buck wrote:
> > Guillaume Thouvenin writes:
> > ...
> >
> > > The problem is the following. If you have something like:
> > >
> > > -- part of a C code --
> > >
> > > fprintf(stderr, "error strg: toto");
> > >
> > > --
> > >
> > > The asg given by gcc gives the following line:
> > >
> > > @247    string_cst       type: @268    strg: error strg: toto  lngt: 5
> > >
> > > So, I add a very basic modification inside GCC (in c-dump.c) and now,
> > > it produces this line:
> > >
> > > @247    string_cst       type: @268    strg: "error strg: toto"  lngt:
> > > 5
> >
> > This seems reasonable, but does your patch do the whole job?  What
> > happens if the string contains newlines, control characters, or '"'?  It
> > would seem reasonable to make the output match the input (that is, output
> > \", \n, etc).
>
> No it doesn't do the whole job. If you have something like :
>
>  fprintf (stderr, "Hello\nit's a \"test\"\n");
>
> It will produce :
>
> @54     string_cst       type: @67     strg: "Hello
> it's a "test"
> "  lngt: 21
>
> So, the good output should be
>
> @54     string_cst       type: @67     strg: "Hello\nit's a \"test\"\n"
>         lngt: 21
>
>
> Actually, strings with newlines, control characters and '"' are treated by
> my parser. The only modification that I done in GCC is in file c-dump.c:
>
> line 649:
> ---
> 648: case STRING_CST:
> 649:      fprintf (di->stream, "strg: \"%-7s\" ", TREE_STRING_POINTER (t));
>                                       ^^    ^^
> 650:      dump_int (di, "lngt", TREE_STRING_LENGTH (t));
> 651:      break;
>
> So, I can try to path GCC to make output match the input?
>
> Guillaume

Re: fdump-ast-original and strg:

[Joe Buck]

[ fixing the dump format to be able to read back strings ]

The correct solution, in my opinion, is to produce a valid C string
literal.  This can always be done, for any input, and furthermore
there should already be routines in the compiler that you can use
(though I can't be more specific off the top of my head).  Don't try
to invent a new format.

Re: fdump-ast-original and strg:

[Joe Buck]

[ fixing the dump format to be able to read back strings ]

The correct solution, in my opinion, is to produce a valid C string
literal.  This can always be done, for any input, and furthermore
there should already be routines in the compiler that you can use
(though I can't be more specific off the top of my head).  Don't try
to invent a new format.

Re: fdump-ast-original and strg:

[Dale Johannesen]

On Friday, November 30, 2001, at 10:12 AM, Florian Krohm wrote:

> I'm afraid, things are even a bit more complex.
> Consider a string containing two characters, the first
> of which contains the bit pattern 00001010. The second
> character is '2'. If you want to recover the original
> representation for that string you will have to use a
> string concatenation e.g. "\12" "2" or "\x6" "2".
> Note that you cannot write "\122" as that would specify
> only a single character.

"\0122" works.

TImode ?inhibited? in main 3.1 branch

[davide.rossetti]

hi folks,
sure I'm missing something, but I'm wondering why gcc/gcc/c-common.c has
this kind of conditionals:

#if HOST_BITS_PER_WIDE_INT >= 64
  if (mode == TYPE_MODE (intTI_type_node))
    return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
#endif

it ends up being excluded in my build on PIII, so that I can't use

typedef int __m128 __attribute__ ((mode (TI)));
...
  register __v4sf a,b,c;
  register __v4si d;
  __m128 e,f,g;
...
  g = __builtin_ia32_andps((__m128)d,(__m128)a);
...

bacause bitwise SSE stuff is marked with TImode args:

(define_insn "*sse_andti3_sf_1"
  [(set (subreg:TI (match_operand:SF 0 "register_operand" "=x") 0)
        (and:TI (subreg:TI (match_operand:SF 1 "register_operand" "%0") 0)
		(subreg:TI (match_operand:SF 2 "register_operand" "x")
0)))]
  "TARGET_SSE"
  "andps\t{%2, %0|%0, %2}"
  [(set_attr "type" "sse")])


so the point is, PIII is somewhat exceptional in having this 128 bit
stuff even being 32bit, but ... as it is, SSE support seems (very
cautious :) partly unusable..

ciao

-- 
______/ Rossetti Davide   INFN - Roma I - APE group \______________
 pho +390649914412     web: http://apegate.roma1.infn.it/~rossetti
 fax +390649914423   email: davide.rossetti@roma1.infn.it

TImode ?inhibited? in main 3.1 branch

[davide.rossetti]

hi folks,
sure I'm missing something, but I'm wondering why gcc/gcc/c-common.c has
this kind of conditionals:

#if HOST_BITS_PER_WIDE_INT >= 64
  if (mode == TYPE_MODE (intTI_type_node))
    return unsignedp ? unsigned_intTI_type_node : intTI_type_node;
#endif

it ends up being excluded in my build on PIII, so that I can't use

typedef int __m128 __attribute__ ((mode (TI)));
...
  register __v4sf a,b,c;
  register __v4si d;
  __m128 e,f,g;
...
  g = __builtin_ia32_andps((__m128)d,(__m128)a);
...

bacause bitwise SSE stuff is marked with TImode args:

(define_insn "*sse_andti3_sf_1"
  [(set (subreg:TI (match_operand:SF 0 "register_operand" "=x") 0)
        (and:TI (subreg:TI (match_operand:SF 1 "register_operand" "%0") 0)
		(subreg:TI (match_operand:SF 2 "register_operand" "x")
0)))]
  "TARGET_SSE"
  "andps\t{%2, %0|%0, %2}"
  [(set_attr "type" "sse")])


so the point is, PIII is somewhat exceptional in having this 128 bit
stuff even being 32bit, but ... as it is, SSE support seems (very
cautious :) partly unusable..

ciao

-- 
______/ Rossetti Davide   INFN - Roma I - APE group \______________
 pho +390649914412     web: http://apegate.roma1.infn.it/~rossetti
 fax +390649914423   email: davide.rossetti@roma1.infn.it

Re: fdump-ast-original and strg:

[Tim Hollebeek]

> On Friday, November 30, 2001, at 10:12 AM, Florian Krohm wrote:
> 
> > I'm afraid, things are even a bit more complex.
> > Consider a string containing two characters, the first
> > of which contains the bit pattern 00001010. The second
> > character is '2'. If you want to recover the original
> > representation for that string you will have to use a
> > string concatenation e.g. "\12" "2" or "\x6" "2".
> > Note that you cannot write "\122" as that would specify
> > only a single character.
> 
> "\0122" works.

I believe you can also use "\12\2".

Re: fdump-ast-original and strg:

[Dale Johannesen]

On Friday, November 30, 2001, at 03:07 PM, Tim Hollebeek wrote:

>
>> On Friday, November 30, 2001, at 10:12 AM, Florian Krohm wrote:
>>
>>> I'm afraid, things are even a bit more complex.
>>> Consider a string containing two characters, the first
>>> of which contains the bit pattern 00001010. The second
>>> character is '2'. If you want to recover the original
>>> representation for that string you will have to use a
>>> string concatenation e.g. "\12" "2" or "\x6" "2".
>>> Note that you cannot write "\122" as that would specify
>>> only a single character.
>>
>> "\0122" works.
>
> I believe you can also use "\12\2".

No, that specifies a second character with bit pattern 00000010,
which is not '2'.

Re: fdump-ast-original and strg:

[Dale Johannesen]

On Friday, November 30, 2001, at 03:07 PM, Tim Hollebeek wrote:

>
>> On Friday, November 30, 2001, at 10:12 AM, Florian Krohm wrote:
>>
>>> I'm afraid, things are even a bit more complex.
>>> Consider a string containing two characters, the first
>>> of which contains the bit pattern 00001010. The second
>>> character is '2'. If you want to recover the original
>>> representation for that string you will have to use a
>>> string concatenation e.g. "\12" "2" or "\x6" "2".
>>> Note that you cannot write "\122" as that would specify
>>> only a single character.
>>
>> "\0122" works.
>
> I believe you can also use "\12\2".

No, that specifies a second character with bit pattern 00000010,
which is not '2'.

Re: fdump-ast-original and strg:

[Tim Hollebeek]

> On Friday, November 30, 2001, at 10:12 AM, Florian Krohm wrote:
> 
> > I'm afraid, things are even a bit more complex.
> > Consider a string containing two characters, the first
> > of which contains the bit pattern 00001010. The second
> > character is '2'. If you want to recover the original
> > representation for that string you will have to use a
> > string concatenation e.g. "\12" "2" or "\x6" "2".
> > Note that you cannot write "\122" as that would specify
> > only a single character.
> 
> "\0122" works.

I believe you can also use "\12\2".

Re: fdump-ast-original and strg:

[Dale Johannesen]

On Friday, November 30, 2001, at 10:12 AM, Florian Krohm wrote:

> I'm afraid, things are even a bit more complex.
> Consider a string containing two characters, the first
> of which contains the bit pattern 00001010. The second
> character is '2'. If you want to recover the original
> representation for that string you will have to use a
> string concatenation e.g. "\12" "2" or "\x6" "2".
> Note that you cannot write "\122" as that would specify
> only a single character.

"\0122" works.

Re: fdump-ast-original and strg:

[Zack Weinberg]

On Fri, Nov 30, 2001 at 01:12:07PM -0500, Florian Krohm wrote:
> I'm afraid, things are even a bit more complex.
> Consider a string containing two characters, the first
> of which contains the bit pattern 00001010. The second
> character is '2'. If you want to recover the original
> representation for that string you will have to use a 
> string concatenation e.g. "\12" "2" or "\x6" "2". 

I think you meant "\xa" "2".

> Note that you cannot write "\122" as that would specify
> only a single character.
> You could call this a pathological example, but I think
> you want to come up with an algorithm that can handle
> the general case.

"\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)

We already have code to emit strings safely, into the assembly output;
you could just use that.

zw

Re: fdump-ast-original and strg:

[Florian Krohm]

>
> "\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)
>
Yup, you're right. So if you use octal notation to represent a 
non-printable character and always use 3 octal digits following
the '\' you have something that should work in all cases.

> We already have code to emit strings safely, into the assembly output;
> you could just use that.
>
Even better!

Florian

Re: fdump-ast-original and strg:

[Joe Buck]

> > "\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)
> >
> Yup, you're right. So if you use octal notation to represent a 
> non-printable character and always use 3 octal digits following
> the '\' you have something that should work in all cases.
> 
> > We already have code to emit strings safely, into the assembly output;
> > you could just use that.
> >
> Even better!

Not just "even better", IMHO.  While I'm not the one that will make
a decision about whether a patch is acceptable, I think that any patch
that includes a complete new conversion function should be rejected,
if the option of simply calling an existing string-emitting function
exists.

Re: fdump-ast-original and strg:

[Richard Henderson]

On Fri, Nov 30, 2001 at 11:01:52AM -0800, Joe Buck wrote:
> if the option of simply calling an existing string-emitting function
> exists.

Unfortunately there is no such function.  That stuff is 
replicated 99 times in various header files.


r~

Re: fdump-ast-original and strg:

[Zack Weinberg]

On Fri, Nov 30, 2001 at 03:26:12PM -0800, Richard Henderson wrote:
> On Fri, Nov 30, 2001 at 11:01:52AM -0800, Joe Buck wrote:
> > if the option of simply calling an existing string-emitting function
> > exists.
> 
> Unfortunately there is no such function.  That stuff is 
> replicated 99 times in various header files.

Dare I ask why?

zw

Re: fdump-ast-original and strg:

[Richard Henderson]

On Fri, Nov 30, 2001 at 03:37:43PM -0800, Zack Weinberg wrote:
> > Unfortunately there is no such function.  That stuff is 
> > replicated 99 times in various header files.
> 
> Dare I ask why?

Historic acretion.


r~

Re: fdump-ast-original and strg:

[Richard Henderson]

On Fri, Nov 30, 2001 at 03:37:43PM -0800, Zack Weinberg wrote:
> > Unfortunately there is no such function.  That stuff is 
> > replicated 99 times in various header files.
> 
> Dare I ask why?

Historic acretion.


r~

Re: fdump-ast-original and strg:

[Zack Weinberg]

On Fri, Nov 30, 2001 at 03:26:12PM -0800, Richard Henderson wrote:
> On Fri, Nov 30, 2001 at 11:01:52AM -0800, Joe Buck wrote:
> > if the option of simply calling an existing string-emitting function
> > exists.
> 
> Unfortunately there is no such function.  That stuff is 
> replicated 99 times in various header files.

Dare I ask why?

zw

Re: fdump-ast-original and strg:

[Richard Henderson]

On Fri, Nov 30, 2001 at 11:01:52AM -0800, Joe Buck wrote:
> if the option of simply calling an existing string-emitting function
> exists.

Unfortunately there is no such function.  That stuff is 
replicated 99 times in various header files.


r~

Re: fdump-ast-original and strg:

[Joe Buck]

> > "\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)
> >
> Yup, you're right. So if you use octal notation to represent a 
> non-printable character and always use 3 octal digits following
> the '\' you have something that should work in all cases.
> 
> > We already have code to emit strings safely, into the assembly output;
> > you could just use that.
> >
> Even better!

Not just "even better", IMHO.  While I'm not the one that will make
a decision about whether a patch is acceptable, I think that any patch
that includes a complete new conversion function should be rejected,
if the option of simply calling an existing string-emitting function
exists.

Re: fdump-ast-original and strg:

[Florian Krohm]

>
> "\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)
>
Yup, you're right. So if you use octal notation to represent a 
non-printable character and always use 3 octal digits following
the '\' you have something that should work in all cases.

> We already have code to emit strings safely, into the assembly output;
> you could just use that.
>
Even better!

Florian

Re: fdump-ast-original and strg:

[Guillaume]

On Fri, 30 Nov 2001, Zack Weinberg wrote:

> > Note that you cannot write "\122" as that would specify
> > only a single character.
> > You could call this a pathological example, but I think
> > you want to come up with an algorithm that can handle
> > the general case.
>
> "\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)

Yes it will produce "\n2"

>
> We already have code to emit strings safely, into the assembly output;
> you could just use that.

I will look to your code tonight. I put what I've done at the end of the
mail and I will modify it if I can find code to emit strings safely.

The function dump_string_cst() produced the following output:

@51     string_cst       type: @58     strg: "Hello\nit's a \t\"test\"\n" lngt: 22


for the following input:

  fprintf (stderr, "Hello\nit's a \t\"test\"\n");

Thanks to all of you for your help
Guillaume

-----------
diff -urN gcc-3.0.2-20011014/gcc/c-dump.c
gcc-3.0.2-20011014-mod/gcc/c-dump.c
--- gcc-3.0.2-20011014/gcc/c-dump.c     Tue Jun  5 03:46:58 2001
+++ gcc-3.0.2-20011014-mod/gcc/c-dump.c Fri Nov 30 16:25:48 2001
@@ -214,6 +214,49 @@
     di->column += 14;
 }

+void
+dump_string_cst (di, string)
+     dump_info_p di;
+     const char *string;
+{
+  int index;
+
+  fprintf (di->stream, "strg: \"");
+  for (index = 0; string[index] != '\0' ; index++)
+    {
+    switch (string[index])
+      {
+      case '\a':
+        fprintf (di->stream, "%c%c", '\\', 'a');
+       break;
+      case '\b':
+        fprintf (di->stream, "%c%c", '\\', 'b');
+       break;
+      case '\t':
+        fprintf (di->stream, "%c%c", '\\', 't');
+       break;
+      case '\n':
+        fprintf (di->stream, "%c%c", '\\', 'n');
+       break;
+      case '\v':
+        fprintf (di->stream, "%c%c", '\\', 'v');
+       break;
+      case '\f':
+        fprintf (di->stream, "%c%c", '\\', 'f');
+       break;
+      case '\r':
+        fprintf (di->stream, "%c%c", '\\', 'r');
+       break;
+      case '\"':
+        fprintf (di->stream, "%c%c", '\\', '\"');
+       break;
+      default :
+        fprintf (di->stream, "%c", string[index]);
+      }
+    }
+  fprintf (di->stream, "\"");
+}
+
 /* Dump the string field S.  */

 static void
@@ -646,7 +689,7 @@
       break;

     case STRING_CST:
-      fprintf (di->stream, "strg: %-7s ", TREE_STRING_POINTER (t));
+      dump_string_cst (di, TREE_STRING_POINTER(t));
       dump_int (di, "lngt", TREE_STRING_LENGTH (t));
       break;

diff -urN gcc-3.0.2-20011014/gcc/c-dump.h
gcc-3.0.2-20011014-mod/gcc/c-dump.h
--- gcc-3.0.2-20011014/gcc/c-dump.h     Tue Jun  5 03:46:58 2001
+++ gcc-3.0.2-20011014-mod/gcc/c-dump.h Fri Nov 30 16:23:12 2001
@@ -80,6 +80,8 @@
   PARAMS ((dump_info_p, const char *, int));
 extern void dump_string
   PARAMS ((dump_info_p, const char *));
+extern void dump_string_cst
+  PARAMS ((dump_info_p, const char *));
 extern void dump_stmt
   PARAMS ((dump_info_p, tree));
 extern void dump_next_stmt

--------------------

Re: fdump-ast-original and strg:

[Guillaume]

On Fri, 30 Nov 2001, Zack Weinberg wrote:

> > Note that you cannot write "\122" as that would specify
> > only a single character.
> > You could call this a pathological example, but I think
> > you want to come up with an algorithm that can handle
> > the general case.
>
> "\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)

Yes it will produce "\n2"

>
> We already have code to emit strings safely, into the assembly output;
> you could just use that.

I will look to your code tonight. I put what I've done at the end of the
mail and I will modify it if I can find code to emit strings safely.

The function dump_string_cst() produced the following output:

@51     string_cst       type: @58     strg: "Hello\nit's a \t\"test\"\n" lngt: 22


for the following input:

  fprintf (stderr, "Hello\nit's a \t\"test\"\n");

Thanks to all of you for your help
Guillaume

-----------
diff -urN gcc-3.0.2-20011014/gcc/c-dump.c
gcc-3.0.2-20011014-mod/gcc/c-dump.c
--- gcc-3.0.2-20011014/gcc/c-dump.c     Tue Jun  5 03:46:58 2001
+++ gcc-3.0.2-20011014-mod/gcc/c-dump.c Fri Nov 30 16:25:48 2001
@@ -214,6 +214,49 @@
     di->column += 14;
 }

+void
+dump_string_cst (di, string)
+     dump_info_p di;
+     const char *string;
+{
+  int index;
+
+  fprintf (di->stream, "strg: \"");
+  for (index = 0; string[index] != '\0' ; index++)
+    {
+    switch (string[index])
+      {
+      case '\a':
+        fprintf (di->stream, "%c%c", '\\', 'a');
+       break;
+      case '\b':
+        fprintf (di->stream, "%c%c", '\\', 'b');
+       break;
+      case '\t':
+        fprintf (di->stream, "%c%c", '\\', 't');
+       break;
+      case '\n':
+        fprintf (di->stream, "%c%c", '\\', 'n');
+       break;
+      case '\v':
+        fprintf (di->stream, "%c%c", '\\', 'v');
+       break;
+      case '\f':
+        fprintf (di->stream, "%c%c", '\\', 'f');
+       break;
+      case '\r':
+        fprintf (di->stream, "%c%c", '\\', 'r');
+       break;
+      case '\"':
+        fprintf (di->stream, "%c%c", '\\', '\"');
+       break;
+      default :
+        fprintf (di->stream, "%c", string[index]);
+      }
+    }
+  fprintf (di->stream, "\"");
+}
+
 /* Dump the string field S.  */

 static void
@@ -646,7 +689,7 @@
       break;

     case STRING_CST:
-      fprintf (di->stream, "strg: %-7s ", TREE_STRING_POINTER (t));
+      dump_string_cst (di, TREE_STRING_POINTER(t));
       dump_int (di, "lngt", TREE_STRING_LENGTH (t));
       break;

diff -urN gcc-3.0.2-20011014/gcc/c-dump.h
gcc-3.0.2-20011014-mod/gcc/c-dump.h
--- gcc-3.0.2-20011014/gcc/c-dump.h     Tue Jun  5 03:46:58 2001
+++ gcc-3.0.2-20011014-mod/gcc/c-dump.h Fri Nov 30 16:23:12 2001
@@ -80,6 +80,8 @@
   PARAMS ((dump_info_p, const char *, int));
 extern void dump_string
   PARAMS ((dump_info_p, const char *));
+extern void dump_string_cst
+  PARAMS ((dump_info_p, const char *));
 extern void dump_stmt
   PARAMS ((dump_info_p, tree));
 extern void dump_next_stmt

--------------------

Re: fdump-ast-original and strg:

[Zack Weinberg]

On Fri, Nov 30, 2001 at 01:12:07PM -0500, Florian Krohm wrote:
> I'm afraid, things are even a bit more complex.
> Consider a string containing two characters, the first
> of which contains the bit pattern 00001010. The second
> character is '2'. If you want to recover the original
> representation for that string you will have to use a 
> string concatenation e.g. "\12" "2" or "\x6" "2". 

I think you meant "\xa" "2".

> Note that you cannot write "\122" as that would specify
> only a single character.
> You could call this a pathological example, but I think
> you want to come up with an algorithm that can handle
> the general case.

"\0122" will work fine.  (Or, in this case, "\n2" assuming ASCII.)

We already have code to emit strings safely, into the assembly output;
you could just use that.

zw

Re: fdump-ast-original and strg:

[Florian Krohm]

I'm afraid, things are even a bit more complex.
Consider a string containing two characters, the first
of which contains the bit pattern 00001010. The second
character is '2'. If you want to recover the original
representation for that string you will have to use a 
string concatenation e.g. "\12" "2" or "\x6" "2". 
Note that you cannot write "\122" as that would specify
only a single character.
You could call this a pathological example, but I think
you want to come up with an algorithm that can handle
the general case.

Florian

On Friday 30 November 2001 12:54, Guillaume wrote:
> On Thu, 29 Nov 2001, Joe Buck wrote:
> > Guillaume Thouvenin writes:
> > ...
> >
> > > The problem is the following. If you have something like:
> > >
> > > -- part of a C code --
> > >
> > > fprintf(stderr, "error strg: toto");
> > >
> > > --
> > >
> > > The asg given by gcc gives the following line:
> > >
> > > @247    string_cst       type: @268    strg: error strg: toto  lngt: 5
> > >
> > > So, I add a very basic modification inside GCC (in c-dump.c) and now,
> > > it produces this line:
> > >
> > > @247    string_cst       type: @268    strg: "error strg: toto"  lngt:
> > > 5
> >
> > This seems reasonable, but does your patch do the whole job?  What
> > happens if the string contains newlines, control characters, or '"'?  It
> > would seem reasonable to make the output match the input (that is, output
> > \", \n, etc).
>
> No it doesn't do the whole job. If you have something like :
>
>  fprintf (stderr, "Hello\nit's a \"test\"\n");
>
> It will produce :
>
> @54     string_cst       type: @67     strg: "Hello
> it's a "test"
> "  lngt: 21
>
> So, the good output should be
>
> @54     string_cst       type: @67     strg: "Hello\nit's a \"test\"\n"
>         lngt: 21
>
>
> Actually, strings with newlines, control characters and '"' are treated by
> my parser. The only modification that I done in GCC is in file c-dump.c:
>
> line 649:
> ---
> 648: case STRING_CST:
> 649:      fprintf (di->stream, "strg: \"%-7s\" ", TREE_STRING_POINTER (t));
>                                       ^^    ^^
> 650:      dump_int (di, "lngt", TREE_STRING_LENGTH (t));
> 651:      break;
>
> So, I can try to path GCC to make output match the input?
>
> Guillaume

Re: fdump-ast-original and strg:

[Guillaume]

On Thu, 29 Nov 2001, Joe Buck wrote:

> Guillaume Thouvenin writes:
> ...
> > The problem is the following. If you have something like:
> >
> > -- part of a C code --
> >
> > fprintf(stderr, "error strg: toto");
> >
> > --
> >
> > The asg given by gcc gives the following line:
> >
> > @247    string_cst       type: @268    strg: error strg: toto  lngt: 5
> >
> > So, I add a very basic modification inside GCC (in c-dump.c) and now, it
> > produces this line:
> >
> > @247    string_cst       type: @268    strg: "error strg: toto"  lngt: 5
> >
> This seems reasonable, but does your patch do the whole job?  What happens
> if the string contains newlines, control characters, or '"'?  It would
> seem reasonable to make the output match the input (that is, output \",
> \n, etc).

No it doesn't do the whole job. If you have something like :

 fprintf (stderr, "Hello\nit's a \"test\"\n");

It will produce :

@54     string_cst       type: @67     strg: "Hello
it's a "test"
"  lngt: 21

So, the good output should be

@54     string_cst       type: @67     strg: "Hello\nit's a \"test\"\n"
        lngt: 21


Actually, strings with newlines, control characters and '"' are treated by
my parser. The only modification that I done in GCC is in file c-dump.c:

line 649:
---
648: case STRING_CST:
649:      fprintf (di->stream, "strg: \"%-7s\" ", TREE_STRING_POINTER (t));
                                      ^^    ^^
650:      dump_int (di, "lngt", TREE_STRING_LENGTH (t));
651:      break;

So, I can try to path GCC to make output match the input?

Guillaume

Re: fdump-ast-original and strg:

[Joe Buck]

Guillaume Thouvenin writes:
...
> The problem is the following. If you have something like:
> 
> -- part of a C code --
> 
> fprintf(stderr, "error strg: toto");
> 
> --
> 
> The asg given by gcc gives the following line:
> 
> @247    string_cst       type: @268    strg: error strg: toto  lngt: 5
> 
> So, I add a very basic modification inside GCC (in c-dump.c) and now, it
> produces this line:
> 
> @247    string_cst       type: @268    strg: "error strg: toto"  lngt: 5
> 
> It is easier to parse. So, I'd like to know if it can be added to official
> gcc futur release. It's only one line and for me it will be easier because
> people won't need to recompile the gcc compiler if they want to use my
> tool (ok for now I'm the only one who use it but it can change...).

This seems reasonable, but does your patch do the whole job?  What happens
if the string contains newlines, control characters, or '"'?  It would
seem reasonable to make the output match the input (that is, output \",
\n, etc).

fdump-ast-original and strg:

[Guillaume]

Hello,

I'm student and I'm trying to build a tool which use the ASG given by g++
using the option -fdump-ast-original. Actually I build a basic parser
which reads the file file.c.original and stores the ASG in memory in a
hash table where the key is the number of a node. I also build a visitor
which visits the ASG in memory and extracts a CFG for some analysis.

The problem is the following. If you have something like:

-- part of a C code --

fprintf(stderr, "error strg: toto");

--

The asg given by gcc gives the following line:

@247    string_cst       type: @268    strg: error strg: toto  lngt: 5

So, I add a very basic modification inside GCC (in c-dump.c) and now, it
produces this line:

@247    string_cst       type: @268    strg: "error strg: toto"  lngt: 5

It is easier to parse. So, I'd like to know if it can be added to official
gcc futur release. It's only one line and for me it will be easier because
people won't need to recompile the gcc compiler if they want to use my
tool (ok for now I'm the only one who use it but it can change...).

Thank you
Sorry for my english

---
Guillaume Thouvenin
GASTA: Gcc Abstract Syntax Tree
http://gasta.sf.net