C++ front-end question

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

Hi,

This is related to PR opt/8396, a high-priority PR on Sparc.

Is it normal for the C++ front-end to pass the following tree to the RTL 
expander in the following situation, when compiled with -O (i.e inlining 
on)?

struct Foo
{
  static void bar(const short int xs, const int short xe)
  {
    if (xe && (xs < xe))
      ;
  }
};

void f()
{   
  short int xe;

  Foo::bar(0, xe);
}


(gdb) p debug_tree(0x40162c60)
 <lt_expr 0x40162c60
    type <boolean_type 0x40186b54 bool unsigned QI
        size <integer_cst 0x4015ba20 constant 8>
        unit size <integer_cst 0x4015b8a0 constant 1>
        align 8 symtab 0 alias set -1 precision 1 min <integer_cst 0x40162580 
0> max <integer_cst 0x401625c0 1>>
    readonly
    arg 0 <integer_cst 0x40162ba0 type <integer_type 0x40156488 int> constant 
0>
    arg 1 <var_decl 0x401a489c xe
        type <integer_type 0x401a1244 short int readonly HI
            size <integer_cst 0x4015b160 constant 16>
            unit size <integer_cst 0x4015b240 constant 2>
            align 16 symtab 0 alias set -1 precision 16 min <integer_cst 
0x4015b200 -32768> max <integer_cst 0x4015b220 32767>>
        readonly used HI file ../pr8396.cpp line 6 size <integer_cst 
0x4015b160 16> unit size <integer_cst 0x4015b240 2>
        align 16 context <function_decl 0x401a45e4 f> abstract_origin 
<parm_decl 0x401a132c xe> initial <nop_expr 0x401a60b4>
        (reg/v:HI 108 [ xe ])>>


Note the <integer_type 0x40156488 int> for 0 and <integer_type 0x401a1244 
short int> for xe.

In the same situation (i.e inlining on), the C front-end is more careful (it 
promotes 0 and xe to 'int', but using 'short int' for 0 would be fine too).

-- 
Eric Botcazou