From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E6C8D3857C44; Wed, 11 Jan 2023 21:09:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E6C8D3857C44 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673471371; bh=AZU1jpHKVeHruF+6jQPo41xdI9zpIR3ImVLu0gnCiT0=; h=From:To:Subject:Date:From; b=UP5HMIU+LAC3R+0jyQxDSgh/kr3SHE3Avqcm/vZdNYg3vUoWHQxqPHicPtmQp1Unx w5tUQqH6jZof/lN9LC/IpEttU1+Bb82ypg0saxfKCd0CXi2UNj0Kez0Zmi8bOuOhZE 1GSUwsbCR7tZp6umuUCNTMe59C08cAbgTPW83fVg= From: "tschwinge at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108377] New: Unexpected 'exceeds maximum object size' diagnostic, wrong-code? Date: Wed, 11 Jan 2023 21:09:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tschwinge at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108377 Bug ID: 108377 Summary: Unexpected 'exceeds maximum object size' diagnostic, wrong-code? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- Created attachment 54249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D54249&action=3Dedit 1.c Am I confused (it's late), or is GCC? For '-O2' and higher: 1.c: In function =E2=80=98f=E2=80=99: 1.c:22:12: warning: argument 1 value =E2=80=9818446744073709551615=E2= =80=99 exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=3D] 22 | needle =3D __builtin_malloc(n); /* { dg-bogus {exceeds maximum object size} } */ | ^~~~~~~~~~~~~~~~~~~ 1.c:22:12: note: in a call to built-in allocation function =E2=80=98__builtin_malloc=E2=80=99 Manually reduced from some other test case. Same issue for actual 'malloc', and 'size_t'. This supposedly bogus 'needle' diagnostic disappears if I disable the 'haystack' allocation of 'n + 1'. Actually, is this wrong-code? 1.c.128t.sra: _2 =3D __builtin_malloc (_1); 1.c.128t.sra: _5 =3D __builtin_malloc (n_14); 1.c.129t.thread1: _2 =3D __builtin_malloc (_1); 1.c.129t.thread1: _10 =3D __builtin_malloc (n_14); 1.c.129t.thread1: _5 =3D __builtin_malloc (n_14); 1.c.130t.dom2: _2 =3D __builtin_malloc (_1); 1.c.130t.dom2: _10 =3D __builtin_malloc (18446744073709551615); 1.c.130t.dom2: _5 =3D __builtin_malloc (n_14); [...] 1.c.194t.fre5: _2 =3D __builtin_malloc (_1); 1.c.194t.fre5: _10 =3D __builtin_malloc (18446744073709551615); 1.c.194t.fre5: _5 =3D __builtin_malloc (n_14); 1.c.195t.thread2: _2 =3D __builtin_malloc (_1); 1.c.195t.thread2: _10 =3D __builtin_malloc (18446744073709551615); 1.c.195t.thread2: _33 =3D __builtin_malloc (n_14); 1.c.195t.thread2: _5 =3D __builtin_malloc (n_14); 1.c.196t.dom3: _2 =3D __builtin_malloc (_1); 1.c.196t.dom3: _10 =3D __builtin_malloc (18446744073709551615); 1.c.196t.dom3: _33 =3D __builtin_malloc (i_51); 1.c.196t.dom3: _5 =3D __builtin_malloc (0); [...] 1.c.254t.optimized: _2 =3D __builtin_malloc (_1); 1.c.254t.optimized: _10 =3D __builtin_malloc (18446744073709551615); 1.c.254t.optimized: _33 =3D __builtin_malloc (i_51); 1.c.254t.optimized: _5 =3D __builtin_malloc (0);=