On Thu, 19 May 2022 10:52:35 -0400
David Malcolm <dmalc...@redhat.com> wrote:

> > In file included from ../../../src/gcc-13.mine/gcc/tree-vrp.h:23,
> >                  from ../../../src/gcc-13.mine/gcc/ssa.h:28,
> >                  from ../../../src/gcc-13.mine/gcc/gimple-warn-
> > types.cc:30:
> > ../../../src/gcc-13.mine/gcc/value-range.h: In member function
> > ‘unsigned int irange::num_pairs() const’:
> > ../../../src/gcc-13.mine/gcc/value-range.h:217:22: warning: Function
> > ‘num_pairs’ could return ‘unsigned char’ [--all-warnings]
> >   217 | irange::num_pairs () const
> >       |                      ^~~~~
> >       |                      unsigned char
> > ../../../src/gcc-13.mine/gcc/value-range.h:217:22: note: with a range
> > of [0,255]  
> 
> The location for that warning does look wrong, but this doesn't quite
> look like one of our warnings - was this from GCC?  Which version? 
> Otherwise, which compiler emitted it?

It's a pass i'm writing to help me deal with some fortran PR.
And yes, as said, the location is wrong, see
https://gcc.gnu.org/pipermail/gcc-help/2022-April/141434.html
where i asked about how to deal with this. Moving the building to
grokfndecl, like Jason suggested, does not seem completely trivial, so
i'm leaving this alone. We don't have them in the fortran FE, so
i don't really care much right now TBH. Maybe i'll get back to that
later.

Of course I won't complain if somebody more familiar with the C++ FE
fixes it.

> > The C++ member function decl result locations are all wrong, i know,
> > but i think the warning is correct. We've got:
> > class GTY((user)) irange
> > {
> >   unsigned char m_num_ranges;
> > }
> > but
> > inline unsigned
> > irange::num_pairs () const
> > { 
> >   if (m_kind == VR_ANTI_RANGE)
> >     return constant_p () ? 2 : 1;
> >   else
> >     return m_num_ranges;
> > }  
> 
> I don't see what's wrong with the code.  It's OK to promote an unsigned
> char to an unsigned int, isn't it?  The compiler is required to
> preserve the value.

It's sure ok to promote it, at least later on, if
targetm.calls.promote_prototypes or by other means if deemed profitable.
For PR78798 i want to demote the types though.

> Sorry if I'm missing something here

np :)

Reply via email to