[Bug sanitizer/59307] New: ICE with boost::format and ubsan

[Bug sanitizer/59307] New: ICE with boost::format and ubsan

[larsbj at gullik dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59307

            Bug ID: 59307
           Summary: ICE with boost::format and ubsan
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: larsbj at gullik dot net
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Created attachment 31304
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31304&action=edit
Preprocessed file showing the ICE

With g++ (GCC) 4.9.0 20131121 (experimental) and this program:

----------------
#include <boost/format.hpp>

int main()
{
    boost::format f("%s");
    return 0;
}
----------------

I get this ICE (shown with the preprocessed code in attachment):

g++ -std=gnu++11 -O0 --sanitize=undefined format-ice.ii
format-ice.cpp: In member function ‘bool
(boost::optional_detail::optional_base<T>::*
boost::optional_detail::optional_base<T>::safe_bool() const)() const [with T =
std::locale; boost::optional_detail::optional_base<T>::unspecified_bool_type =
bool (boost::optional_detail::optional_base<std::locale>::*)() const;
boost::optional_detail::optional_base<T>::this_type =
boost::optional_detail::optional_base<std::locale>]’:
format-ice.cpp:10:1: internal compiler error: Segmentation fault
 }
 ^
0x93c0af crash_signal
        ../../gcc/gcc/toplev.c:336
0xa1dbf6 get_expr_operands
        ../../gcc/gcc/tree-ssa-operands.c:732
0xa1e563 parse_ssa_operands
        ../../gcc/gcc/tree-ssa-operands.c:951
0xa1fb47 build_ssa_operands
        ../../gcc/gcc/tree-ssa-operands.c:966
0xa1fb47 update_stmt_operands(gimple_statement_base*)
        ../../gcc/gcc/tree-ssa-operands.c:1103
0x7c0bdf update_stmt_if_modified
        ../../gcc/gcc/gimple-ssa.h:154
0x7c0bdf update_modified_stmt
        ../../gcc/gcc/gimple-iterator.c:50
0x7c0bdf gsi_insert_before(gimple_stmt_iterator_d*, gimple_statement_base*,
gsi_iterator_update)
        ../../gcc/gcc/gimple-iterator.c:517
0x9516ad instrument_member_call
        ../../gcc/gcc/ubsan.c:595
0x9516ad instrument_null
        ../../gcc/gcc/ubsan.c:628
0xae1acb walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, pointer_set_t*, tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, pointer_set_t*))
        ../../gcc/gcc/tree.c:10927
0x7cddc2 walk_gimple_op(gimple_statement_base*, tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
        ../../gcc/gcc/gimple-walk.c:203
0x95150a ubsan_pass
        ../../gcc/gcc/ubsan.c:655
0x95150a execute
        ../../gcc/gcc/ubsan.c:694

--sanitize=address does not give the same ICE.

Possibly related to pr59250.
>From gcc-bugs-return-435957-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 27 01:44:09 2013
Return-Path: <gcc-bugs-return-435957-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2034 invoked by alias); 27 Nov 2013 01:44:09 -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 1986 invoked by uid 48); 27 Nov 2013 01:44:04 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59304] #pragma diagnostic pop fails with -Wswitch-enum
Date: Wed, 27 Nov 2013 01:44:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-59304-4-yIhfVTOJL3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59304-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-SW-Source: 2013-11/txt/msg02734.txt.bz2
Content-length: 1927

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-27
                 CC|                            |dj at redhat dot com,
                   |                            |jsm28 at gcc dot gnu.org,
                   |                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Hi DJ,

Do you remember how the push/pop was supposed to work?

I see that push saves 

context->push_list[context->n_push ++] = context->n_classification_history;

which is just zero.

Then, the "pragma diagnostic warning" calls control_warning_option which
changes the option flag (enabling it).

The pop operation simply stores one more item in history pointing to item 0,
but it does not modify the option flag.

Then, diagnostic_report_diagnostic simply checks the global option, then
searches the history, finds the pop, which points to zero, so the search stops.
Since nothing has modified diagnostic->kind, then the warning is printed (and
the option is still enabled).

Perhaps the "pop" operation needs to reset whatever was changed since the push.

Or perhaps after a pop that reaches the command-line, we need to check the
original value of the options instead of the current value. I am not sure what
is the best way to do this.

Note that it is not enough to look through the history and undo the changes,
since control_warning_option may have enabled a cascade of options which are
not recorded in the classification history.

Joseph, what do you think can be done here?
>From gcc-bugs-return-435958-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 27 02:12:59 2013
Return-Path: <gcc-bugs-return-435958-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11662 invoked by alias); 27 Nov 2013 02:12:58 -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 11596 invoked by uid 48); 27 Nov 2013 02:12:53 -0000
From: "dj at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59304] #pragma diagnostic pop fails with -Wswitch-enum
Date: Wed, 27 Nov 2013 02:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dj at redhat dot com
X-Bugzilla-Status: NEW
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-59304-4-cAj50TXUoy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59304-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: 2013-11/txt/msg02735.txt.bz2
Content-length: 1010

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY304

--- Comment #2 from DJ Delorie <dj at redhat dot com> ---
The diagnostic changes that happen with #pragmas are stored in a linear array,
which corresponds (somehow) to the linear input source file representation.
So, given a location in the source, we can find the spot in the array that
corresponds to the state at that point, with earlier array entries being
"before" that location, and later ones being "after".

Once found, we scan backwards through the array looking for #pragmas that might
affect the diagnostic.  If we see one, that's what we use.  If we see a DK_POP
code, we skip over the chunk of the array to the matching PUSH ([i].option),
i.e. it's as if those actions never happened.

What's supposed to happen is that changing a diagnostic via a #pragma should
push a change code onto that stack also, this should happen via a call to
diagnostic_classify_diagnostic when the #pragma changes the handling (with
WHERE set to a known location).

[Bug sanitizer/59307] ICE with boost::format and ubsan

[larsbj at lyx dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59307

larsbj at lyx dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |larsbj at lyx dot org

--- Comment #1 from larsbj at lyx dot org ---
I just verified that I see the same with

g++ --version
g++ (GCC) 4.9.0 20131127 (experimental)

That is up to date as of r205428.

(and with -fsanitize=undefined)

[Bug sanitizer/59307] ICE with boost::format and ubsan

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59307

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |DUPLICATE

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Dup.

format-ice.cpp:10:1: internal compiler error: gimple check: expected
gimple_call(error_mark), have gimple_assign(addr_expr) in gimple_call_arg, at
gimple.h:2477
0x96b8cc gimple_check_failed(gimple_statement_base const*, char const*, int,
char const*, gimple_code, tree_code)

*** This bug has been marked as a duplicate of bug 59306 ***