https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121663
--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
> Looks like that. LOCATION_LINE is int, so when #line overflows it becomes
> negative up to -2 and -1. The hash_map uses int_hash<int64_t, -1, -2> though,
> which is 64-bit signed with -1 and -2 special values (Empty and Deleted).
> So, one possibility would be
> --- gcc/tree-cfg.cc.jj 2025-08-23 15:00:04.928779140 +0200
> +++ gcc/tree-cfg.cc 2025-09-01 15:50:45.491819750 +0200
> @@ -1098,7 +1098,8 @@ assign_discriminator (location_t loc, un
> hash_map<int_hash <int64_t, -1, -2>, discrim_entry>
> &map)
> {
> bool existed;
> - discrim_entry &e = map.get_or_insert (LOCATION_LINE (loc), &existed);
> + discrim_entry &e
> + = map.get_or_insert ((unsigned) LOCATION_LINE (loc), &existed);
Thanks for looking into that. I think it is odd to have LOCATION_LINE
set up in a way it can meaningfully return negative values. Casting to
unsigned here look good to me.
Honza
