From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id CA7053858D35; Thu, 29 Jun 2023 20:22:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA7053858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688070179;
	bh=OWjaV1/90vNiYcyiDxH2HLpjK34VYncMi2vtV8Fq4rc=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=RgaeXGB3UYMk2aSQBpq2kvXspSzN4/zpNX8dF2cUDmj3P0NfQjiI6ox86+rAlveDd
	 acgEGYZJnMKHFjOrkXPE0V0S04p3cYlp+Fns93wky4BjJMH7J9jm1I29V8OjmuvAUb
	 oJkVXp+50Wii1Zql5DISsDBWFSGTAZ9fFc+9WmBY=
From: "dmalcolm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug analyzer/110483] Several
 gcc.dg/analyzer/out-of-bounds-diagram-*.c tests FAIL
Date: Thu, 29 Jun 2023 20:22:59 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: analyzer
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dmalcolm at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110483-4-R7wyWnjBSk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110483

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Thanks for filing this; sorry about the failures.

What's the endianness of the hosts that this is happening on?

Is there a machine in the GCC compile farm that this happens on?

The row of indices is is created here in
string_region_spatial_item::make_table:
    if (m_show_full_string)
      {
       for (byte_offset_t byte_idx =3D bytes.get_start_byte_offset ();
            byte_idx < bytes.get_next_byte_offset ();
            byte_idx =3D byte_idx + 1)
         add_column_for_byte (t, btm, sm, byte_idx,
                              byte_idx_table_y, byte_val_table_y);
where class string_region_spatial_item has:
  void add_column_for_byte (table &t, const bit_to_table_map &btm,
                            style_manager &sm,
                            const byte_offset_t byte_idx,
                            const int byte_idx_table_y,
                            const int byte_val_table_y) const
  {
    tree string_cst =3D get_string_cst ();
    gcc_assert (byte_idx >=3D 0);
    gcc_assert (byte_idx < TREE_STRING_LENGTH (string_cst));

    const byte_range bytes (byte_idx, 1);
    if (1) // show_byte_indices
      {
        const table::rect_t idx_table_rect
          =3D btm.get_table_rect (&m_string_reg, bytes, byte_idx_table_y, 1=
);
        t.set_cell_span (idx_table_rect,
                         fmt_styled_string (sm, "[%li]",
                                            byte_idx.ulow ()));
      }

so presumably an issue with:

                         fmt_styled_string (sm, "[%li]",
                                            byte_idx.ulow ()));
on those hosts.

Possibly an endianness-handling mistake by me?=