This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: VAR_DECL accessed as expression



  In message <199804230959.LAA26295@mira.isdn.cs.tu-berlin.de>you write:
  > After modifying my checking patch to process expressions (nodes of
  > classes "rse<12"), I found that VAR_DECLs are accessed using
  > TREE_OPERAND. AFAIK, this macro is not suited for tree_decl nodes.
  > The bug manifests in gcc.c-torture/compile/920501-4.c. Details below.
  > 
  > Martin
  > 
  > (gdb) l
  > 2797	  in_p = 0, low = high = convert (TREE_TYPE (exp), integer_zero
  > _node);
  > 2798	
  > 2799	  while (1)
  > 2800	    {
  > 2801	      code = TREE_CODE (exp);
  > 2802	      arg0 = TREE_OPERAND (exp, 0), arg1 = TREE_OPERAND (exp, 1
  > );
  > 2803	      if (TREE_CODE_CLASS (code) == '<' || TREE_CODE_CLASS (cod
  > e) == '1'
  > 2804		  || TREE_CODE_CLASS (code) == '2')
  > 2805		type = TREE_TYPE (arg0);
  > 2806	
  > (gdb) p debug_tree(exp)
  >  <var_decl 0x8249f2c m_max
  >     type <integer_type 0x8235c6c int allocated from permanent_obstack
  >         permanent SI
  >         size <integer_cst 0x8235e1c constant permanent 32>
  >         align 32 symtab 0 precision 32
  >         min <integer_cst 0x8235cc4 constant permanent -2147483648>
  >         max <integer_cst 0x8235cdc constant permanent 2147483647>
  >         pointer_to_this <pointer_type 0x823bf84>>
  >     allocated from function maybepermanent obstack
  >     used common SI file /home/martin/t/920501-4.c line 10 size <integer_cst
  >  0x8235e1c 32>
  >     align 32 context <function_decl 0x8245664 foo>
  >     (reg/v:SI 31) chain <var_decl 0x8249ecc n>>
  > $3 = void
  > (gdb) bt
  > #0  fatal (s=0x820317b "%s:%d: Expect expression, have '%s'\n")
  >     at /usr/src1/egcs/gcc/toplev.c:1560
  > #1  0x809514a in expr_check (node=0x8249f2c, ignored=0, 
  >     file=0x82036b6 "/usr/src1/egcs/gcc/fold-const.c", line=2802, nofatal=0)
  >     at /usr/src1/egcs/gcc/tree.c:5014
  > #2  0x80a5bc2 in make_range (exp=0x8249f2c, pin_p=0xbffff364, plow=0xbffff3
  > 58, 
  >     phigh=0xbffff34c) at /usr/src1/egcs/gcc/fold-const.c:2802
  > #3  0x80a6d19 in fold_range_test (exp=0x8237578)
  >     at /usr/src1/egcs/gcc/fold-const.c:3213
  > #4  0x80ae329 in fold (expr=0x8237578) at /usr/src1/egcs/gcc/fold-const.c:5
  > 043
  > #5  0x806d75f in build_binary_op (code=TRUTH_ANDIF_EXPR, orig_op0=0x8237548
  > , 
  >     orig_op1=0x8237560, convert_p=1) at /usr/src1/egcs/gcc/c-typeck.c:2638
  > #6  0x806b4fa in parser_build_binary_op (code=TRUTH_ANDIF_EXPR, 
  >     arg1=0x8237548, arg2=0x8237560) at /usr/src1/egcs/gcc/c-typeck.c:1811
  > #7  0x804b346 in yyparse () at c-parse.y:533
  > #8  0x808321b in compile_file (name=0xbffffc79 "/home/martin/t/920501-4.c")
  >     at /usr/src1/egcs/gcc/toplev.c:2545
  > #9  0x8087260 in main (argc=3, argv=0xbffffb24, envp=0xbffffb34)
  >     at /usr/src1/egcs/gcc/toplev.c:4366
Mark Mitchell fixed this recently.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]