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 81B193858D37; Tue, 11 Aug 2020 13:47:13 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 81B193858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1597153633;
 bh=ptzF2m+nKaDQn8Ef/NuNt5tDXPw9E2FkTTtBkEjoZm4=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=xn5aAEiydEhAhB46zgxYuhlE3p89OTeu0jDgGJspgNpg8thUoyjMukYcFD2cKVrB5
 wJT17pcY6y3rFIDYMsR2cS3ZeLitUMz98q94p9HYQBdkPU/qOj8QjLJb5L6/VQmjtU
 M0tDqkdGu/XvFc90w8BWMeNrd66wVDSBWEJrh30E=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c
Date: Tue, 11 Aug 2020 13:47:13 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: 
Message-ID: <bug-96566-4-KaNQh6R5Pd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-96566-4@http.gcc.gnu.org/bugzilla/>
References: <bug-96566-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 13:47:13 -0000

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm not sure a target specific option is the way to go here, the only
difference is that nvptx spends all the time on this (adjusted) testcase at
compile time (and eats all disk space there too), while on x86_64 it is at
assembly time.
gcc -O2 -c -o /tmp/1.o /tmp/1.c
/tmp/ccUN9rYB.s: Assembler messages:
/tmp/ccUN9rYB.s: Fatal error: can't fill 256 bytes in section .data of
/tmp/1.o: 'No space left on device'
In real-world people will only compile code that is useful for something, a=
nd
we should honor there the no hardcoded limits unless really necessary rule,
some users may need 20GB initializers some day (sure, on most PTX decides it
wouldn't likely fit, but that can be diagnosed later).
For the error recovery, it is ok to throw away the initializers if it doesn=
't
result in further diagnostics, but otherwise, let's let users do what they =
want
if they have time and disk space for that.=