This is caused by r263298.

I have seen failure at same point coming and going while working on the streaming changes. I think it is some kind of overflow problem in linemaps that needs specific series of events to trigger which is there for some time.

(In reply to H.J. Lu from comment #0)
> On x86-64, r263300 gave

Annotating it with the code in question:

> In function ‘gimple_simplify_32’:
> lto1: internal compiler error: in linemap_check_ordinary, at libcpp/include/line-map.h:587
> 0x5e2991 ???
>         ../../src-trunk/libcpp/include/line-map.h:587

  linemap_assert (MAP_ORDINARY_P (map));

> 0x93aeae ???
>         ../../src-trunk/libcpp/line-map.c:754

In linemap_line_start:
      /* Allocate the new line_map.  However, if the current map only has a
	 single line we can sometimes just increase its column_bits instead. */
      if (line_delta < 0
	  || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
	  || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits))
	  || range_bits < map->m_range_bits)
	map = linemap_check_ordinary
	        (const_cast <line_map *>
		  (linemap_add (set, LC_RENAME,
				ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
				ORDINARY_MAP_FILE_NAME (map),
				to_line)));

> 0x1d653e2 ???
>         ../../src-trunk/gcc/lto-streamer-in.c:194

in lto_location_cache::apply_location_cache ():
	  linemap_line_start (line_table, loc.line, max + 1);

> 0x1d6661f ???
>         ../../src-trunk/gcc/lto-streamer-in.c:304

in stream_input_location_now:

  data_in->location_cache.apply_location_cache ();


> 0xbc5f88 ???
>         ../../src-trunk/gcc/gimple-streamer-in.c:111

in input_gimple_stmt:
  /* Read location information.  Caching here makes no sense until streamer
     cache can handle the following gimple_set_block.  */
  gimple_set_location (stmt, stream_input_location_now (&bp, data_in));


(etc)


linemap_add can return NULL with LC_LEAVE, but we have LC_RENAME.
The return value ("map") comes from:

  linemap_assert (reason != LC_ENTER_MACRO);
  line_map_ordinary *map
    = linemap_check_ordinary (new_linemap (set, start_location));
  map->reason = reason;


linemap_check_ordinary is:
   linemap_assert (MAP_ORDINARY_P (map));

which, in turn is:

inline bool
MAP_ORDINARY_P (const line_map *map)
{
  return map->start_location < LINE_MAP_MAX_LOCATION;
}

map->start_location shouldn't be able to change.

I believe what's happened is that:
  to_line >= LINE_MAP_MAX_LOCATION
within linemap_line_start.

That way, linemap_add would (unexpectedly) create a macro map, rather than an ordinary map.

Presumably we need some kind of overflow handling here (assuming that the above correctly characterizes the cause of the crash).

Also, it seems bad to be running out of location_t values.  We probably should double-check that we're packing things efficiently.

line-map.c has

 linemap_assert (reason != LC_ENTER_MACRO);
  line_map_ordinary *map
    = linemap_check_ordinary (new_linemap (set, start_location));
  map->reason = reason;

We get here with reason != LC_ENTER_MACRO and create linemap with
start_location >= LINE_MAP_MAX_LOCATION.

A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00866.html

Author: hjl
Date: Fri Aug 24 23:37:53 2018
New Revision: 263845

URL: https://gcc.gnu.org/viewcvs?rev=263845&root=gcc&view=rev
Log:
Set start_location to 0 if we ran out of line map space

With profiledbootstrap and --with-build-config=bootstrap-lto, linemap_add
may create a macro map when we run out of line map space.  This patch
changes start_location to UNKNOWN_LOCATION (0) in this case.

Tested with profiledbootstrap and --with-build-config=bootstrap-lto on
Linux/x86-64.

	PR bootstrap/86872
	* line-map.c (pure_location_p): Return true if linemap_lookup
	returns NULL.
	(linemap_add): Set start_location to 0 if we run out of line map
	space.

Modified:
    trunk/libcpp/ChangeLog
    trunk/libcpp/line-map.c

Fixed.