From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5730 invoked by alias); 21 Jan 2015 11:18:12 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 4659 invoked by uid 48); 21 Jan 2015 11:18:01 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/64535] Emergency buffer for exception allocation too small Date: Wed, 21 Jan 2015 11:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-SW-Source: 2015-01/txt/msg02189.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D64535 --- Comment #12 from Jonathan Wakely --- (In reply to Richard Biener from comment #11) > If reading 15.1.4 (Exception Handling / Throwing an exception) correctly > then allocation happens in an unspecified way but according to 3.7.3.1 > which specifies that if "the allocation function" that fails to allocate > storage shall throw std::bad_alloc (if not marked with throw ()). But > it isn't specified if the "unspecified" EH allocation "function" is > marked with throw (). An "allocation function" specifically refers to an overload of operator new. The reference from 15.1.4 [except.throw] to [basic.stc.dynamic.allocation] = is apparently meant to refer to the final paragraph, which says: "[ Note: In particular, a global allocation function is not called to allocate storage = for [...] an exception object (15.1). =E2=80=94 end note ]" so it's saying that= operator new must not be used to allocate memory for exceptions (but it's OK to use malloc or a static buffer or both). That means the rules for how operator n= ew indicates OOM are not relevant for exception handling. > In particular 15.5.1 (The std::terminate function) doesn't list OOM > in allocating an exception as cause of abandoning exception handling. >=20 > It would be nice to get clarification from the standards body on what > shall happen if EH allocation runs into OOM situations. Undefined behaviour. >>From gcc-bugs-return-474196-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 21 11:20:37 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 9306 invoked by alias); 21 Jan 2015 11:20:36 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 9234 invoked by uid 48); 21 Jan 2015 11:20:29 -0000 From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgomp/64707] New: FAIL: libgomp.c/target-9.c with -ftree-parallelize-loops=0 Date: Wed, 21 Jan 2015 11:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgomp X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED 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 cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg02190.txt.bz2 Content-length: 2909 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64707 Bug ID: 64707 Summary: FAIL: libgomp.c/target-9.c with -ftree-parallelize-loops=0 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org CC: jakub at gcc dot gnu.org When running libgomp testsuite with --target_board=unix/-ftree-parallelize-loops=0, we run into this failure: ... FAIL: libgomp.c/target-9.c (internal compiler error) FAIL: libgomp.c/target-9.c (test for excess errors) UNRESOLVED: libgomp.c/target-9.c compilation failed to produce executable ... More specifically: ... lto1: internal compiler error: in streamer_get_builtin_tree, at tree-streamer-in.c:1151^M 0xfea939 streamer_get_builtin_tree(lto_input_block*, data_in*)^M /home/vries/gcc_versions/devel/master/src/gcc/tree-streamer-in.c:1151^M 0xb579f3 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)^M /home/vries/gcc_versions/devel/master/src/gcc/lto-streamer-in.c:1320^M 0xb577ba lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned int*)^M /home/vries/gcc_versions/devel/master/src/gcc/lto-streamer-in.c:1248^M 0x6a8238 lto_read_decls^M /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:1900^M 0x6a8efa lto_file_finalize^M /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2229^M 0x6a8f47 lto_create_files_from_ids^M /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2239^M 0x6a906e lto_file_read^M /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2280^M 0x6ac807 read_cgraph_and_symbols^M /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:2981^M 0x6ad803 lto_main()^M /home/vries/gcc_versions/devel/master/src/gcc/lto/lto.c:3436^M Please submit a full bug report,^M ... Investigating the ICE site: ... (gdb) #5 0x0000000000fea93a in streamer_get_builtin_tree (ib=0x7fffffffd860, data_in=0x2ea2390) at /home/vries/gcc_versions/devel/master/src/gcc/tree-streamer-in.c:1151 1151 gcc_assert (result); (gdb) l 1146 { 1147 fcode = (enum built_in_function) (fcode - BEGIN_CHKP_BUILTINS - 1); 1148 result = builtin_decl_explicit (fcode); 1149 result = chkp_maybe_clone_builtin_fndecl (result); 1150 } 1151 gcc_assert (result); 1152 } 1153 else if (fclass == BUILT_IN_MD) 1154 { 1155 result = targetm.builtin_decl (fcode, true); (gdb) p fcode $1 = BUILT_IN_GOMP_TARGET (gdb) p builtin_info builtin_info builtin_info_type (gdb) p builtin_info.decl[BUILT_IN_GOMP_TARGET] $3 = (tree_node *) 0x0 ... The omp builtin is not enabled in lto1 (consistent with the observation in PR 64672 comment 9).