[Bug libstdc++/64535] Emergency buffer for exception allocation too small

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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). — 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 new
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.
> 
> 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: <gcc-bugs-return-474196-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-64707-4@http.gcc.gnu.org/bugzilla/>
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?idd707

            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).