Patch for PR analyzer/98797

David Malcolm dmalcolm@redhat.com
Thu Feb 18 00:27:15 GMT 2021


On Wed, 2021-02-17 at 23:18 +0000, brian.sobulefsky wrote:
> Hi David,
> 
> I'm sorry but I wanted to get this out to you. To clarify, I had a
> statement of the form:
> 
> end_offset <= covering_field->field_decl.bit_offset->int_cst.val[0]
>     covering_field->decl_common.size->int_cst.val[0] - 1;
> 
> (Sorry if my email is clobbering the angle brackets). I have replaced
> the first
> expression with int_bit_position (covering_field), I am not sure
> where to properly
> access the size of the field. FWIW, I found your
> region::get_byte_size, which
> calls int_size_in_bytes, but this crashes gcc for a field tree, it
> wants a
> type tree.

BTW, gcc/stor-layout.{c|h} holds the compiler's logic for laying out
the fields of structs and unions, determining bit-offsets and sizes. 
place_field is called repeatedly per field, and handles things like
sizes, alignments, etc.

I think you want DECL_SIZE() on the FIELD_DECL, which is typically a
INTEGER_CST (but won't necessarily be, consider VLAs, trailing empty
arrays, etc).  Quoting tree.h:

/* Holds the size of the datum, in bits, as a tree expression.
   Need not be constant and may be null.  May be less than TYPE_SIZE
   for a C++ FIELD_DECL representing a base class subobject with its
   own virtual base classes (which are laid out separately).  */
#define DECL_SIZE(NODE) (DECL_COMMON_CHECK (NODE)->decl_common.size)


> Additionally, is there some proper way to access a bit_offset_t other
> than
> bit_off.get_val ()[0]? That is what I am using now, but I can swap it
> out.

bit_offset_t is an offset_int, which is defined in gcc/wide-int.h
though I confess I find that header file difficult to understand. 
There are some overloaded operators and member functions for working
with them; see that header.  That said, looking at the analyzer
sources, I've typically been converting them to HOST_WIDE_INT via
to_shwi ().  I suspect the way I'm doing that is buggy when dealing
with very large types.


> Sorry for the newbie questions, but these things aren't really
> documented
> in one place, at least that I am aware of.

Fair enough, and don't worry, we were all new once.  There is some
documentation in
  https://gcc.gnu.org/onlinedocs/gccint/index.html
e.g.:
  https://gcc.gnu.org/onlinedocs/gccint/GENERIC.html
but it's a lot to wade through and is mostly just as an API reference
rather than a tutorial.

Hope this is helpful
Dave



More information about the Gcc-patches mailing list