[gimplefe] Ran into a internal compiler error

2011-09-19 Thread Sandeep Soni 
Hi,
I was trying to make a symbol table for all the variable declarations
for the gimple front end. Following is a patch:

Index: parser.c
===
--- parser.c(revision 174754)
+++ parser.c(working copy)
@@ -28,6 +28,7 @@
 #include "tree.h"
 #include "gimple.h"
 #include "parser.h"
+#include "hashtab.h"
 #include "ggc.h"

 /* The GIMPLE parser.  Note: do not use this variable directly.  It is
@@ -807,6 +808,31 @@
 }
 }

+
+struct gimple_symtab_entry_def
+{
+  tree decl;
+};
+
+static hashval_t
+gimple_symtab_entry_hash (const void *entry)
+{
+  const struct gimple_symtab_entry_def *base =
+(const struct gimple_symtab_entry_def *)entry;
+  return IDENTIFIER_HASH_VALUE (base->decl);
+}
+
+static int
+gimple_symtab_eq_hash (const void *entry1, const void *entry2)
+{
+  const struct gimple_symtab_entry_def *p1 =
+(const struct gimple_symtab_entry_def *)entry1;
+  const struct gimple_symtab_entry_def *p2 =
+(const struct gimple_symtab_entry_def *)entry2;
+
+  return (p1->decl == p2->decl);
+}
+
 /* The Declaration section within a .gimple file can consist of
a) Declaration of variables.
b) Declaration of functions.
@@ -871,10 +897,29 @@
 gp_parse_var_decl (gimple_parser *parser)
 {
   const gimple_token *next_token;
+  const gimple_token *name_token;
+  const char* name;
   enum tree_code code ;

+  htab_t gimple_symtab;
+  void **slot1, **slot2;
+  struct gimple_symtab_entry_def e;
+
+  gimple_symtab = htab_create_ggc (10, gimple_symtab_entry_hash,
gimple_symtab_eq_hash, NULL);
   gl_consume_expected_token (parser->lexer, CPP_LESS);
-  gl_consume_expected_token (parser->lexer, CPP_NAME);
+  name_token = gl_consume_expected_token (parser->lexer, CPP_NAME);
+  name = gl_token_as_text(name_token);
+  e.decl = build_decl (UNKNOWN_LOCATION, VAR_DECL,
get_identifier(name), void_type_node);
+  slot1 = htab_find_slot (gimple_symtab ,&e, INSERT);
+  slot2 = htab_find_slot (gimple_symtab, &e, NO_INSERT);
+  if (slot1 == slot2)
+{
+  printf ("I think this is right\n");
+}
+  else
+{
+  printf ("Or this is wrong\n");
+}
   gl_consume_expected_token (parser->lexer, CPP_COMMA);

   next_token = gl_consume_token (parser->lexer);
@@ -1391,7 +1436,6 @@
   parser_gc_root__ = NULL;
 }

-
 /* Main entry point for the GIMPLE front end.  */

 void
@@ -1402,7 +1446,6 @@
   parser_gc_root__ = parser = gp_init (main_input_filename);
   if (parser->lexer->filename == NULL)
 return;
-
   gl_lex (parser->lexer);
   gp_parse (parser);
   gp_finish (parser);


It gives me a internal compiler error saying:
gimple1: internal compiler error: tree check: expected
identifier_node, have var_decl in gimple_symtab_entry_hash

Is there something that I have gotten wrong or something that I had to
do before that I missed?

-- 
Cheers
Sandy

Re: cc1.exe: warnings being treated as errors

2011-09-19 Thread Jonathan Wakely 
On 19 September 2011 18:59, Jon Grant wrote:
> Hello
>
> I noticed that when compiling C files with GCC and using the -Werror
> option, I see this additional output:
>
> cc1.exe: warnings being treated as errors
> ./src/main.c: In function 'main':
> ./src/main.c:41:15: error: unused variable 'hello'
>
> Is the "cc1" line output needed? Just wondering if it could be
> removed. Appears superfluous.

It's not superfluous, it says that the error following might have been
a warning, except that -Werror was used.

If you don't want it you can either fix the warning or not use -Werror.

cc1.exe: warnings being treated as errors

2011-09-19 Thread Jon Grant 
Hello

I noticed that when compiling C files with GCC and using the -Werror
option, I see this additional output:

cc1.exe: warnings being treated as errors
./src/main.c: In function 'main':
./src/main.c:41:15: error: unused variable 'hello'

Is the "cc1" line output needed? Just wondering if it could be
removed. Appears superfluous.

If compiling with g++ it is :

cc1plus: warnings being treated as errors

I saw this in two slightly old builds of GCC:
arm-none-eabi-gcc-4.5.1.exe (Sourcery G++ Lite 2010.09-51) 4.5.1
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

Please keep my email address in any replies as I'm not on the mailing list.

Best regards, Jon

RE: Derive more alias information from named address space

2011-09-19 Thread Bingfeng Mei 
Thanks. I will prepare a patch.

Bingfeng

> -Original Message-
> From: Ulrich Weigand [mailto:uweig...@de.ibm.com]
> Sent: 19 September 2011 12:56
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Derive more alias information from named address space
> 
> Bingfeng Mei wrote:
> 
> > Therefore, A & B could only be disjoint, i.e., not aliased to each
> other.
> > We should be able to write:
> >
> >   if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
> >   {
> > if (!targetm.addr_space.subset_p (MEM_ADDR_SPACE (mem),
> MEM_ADDR_SPACE (x))
> >&& !targetm.addr_space.subset_p (MEM_ADDR_SPACE (x),
> MEM_ADDR_SPACE (mem)))
> >   return 0;
> > else
> >   return 1;
> >   }
> >
> > Is this correct?
> 
> Yes, this looks correct to me ...
> 
> Bye,
> Ulrich
> 
> --
>   Dr. Ulrich Weigand
>   GNU Toolchain for Linux on System z and Cell BE
>   ulrich.weig...@de.ibm.com

Re: Derive more alias information from named address space

2011-09-19 Thread Ulrich Weigand 
Bingfeng Mei wrote:

> Therefore, A & B could only be disjoint, i.e., not aliased to each other.
> We should be able to write:
> 
>   if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
>   {
> if (!targetm.addr_space.subset_p (MEM_ADDR_SPACE (mem), MEM_ADDR_SPACE 
> (x))
>&& !targetm.addr_space.subset_p (MEM_ADDR_SPACE (x), MEM_ADDR_SPACE 
> (mem)))
>   return 0;
> else
>   return 1;
>   }
> 
> Is this correct?

Yes, this looks correct to me ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com