https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147
--- Comment #18 from David Malcolm <dmalcolm at gcc dot gnu.org> --- (In reply to Martin Liška from comment #15) > During the bug investigation I noticed a strange thing in line-map.c: > > 700 if (line_delta < 0 > 701 || (line_delta > 10 > 702 && line_delta * map->m_column_and_range_bits > 1000) > 703 || (max_column_hint >= (1U << effective_column_bits)) > 704 || (max_column_hint <= 80 && effective_column_bits >= 10) > 705 || (highest > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES > 706 && map->m_range_bits > 0) > 707 || (highest > LINE_MAP_MAX_LOCATION_WITH_COLS > 708 && (set->max_column_hint || highest >= > LINE_MAP_MAX_LOCATION))) > 709 add_map = true; > > m_column_and_range_bits > 1000 is always false as: > > /* Number of the low-order source_location bits used for column numbers > and ranges. */ > unsigned int m_column_and_range_bits : 8; > > and the sub-expression on lines 701 and 702 is ugly as well. > What's the purpose of the check? It's not: m_column_and_range_bits > 1000 it's: line_delta * map->m_column_and_range_bits > 1000 where line_delta is an int; presumably the 8 bits of the field get widened. The purpose of the check is impose a limit on the size of the jumps that occur within the location_t representation, so that if there's a big jump in line numbers, we start a linemap, where big is "> 1000" within the location_t value. The idea is to avoid wasting location_t values, without creating too many linemap instances.
