[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #14)
> (In reply to Uroš Bizjak from comment #13)
> > (In reply to Jakub Jelinek from comment #12)
> > > Created attachment 31332 [details]
> > > gcc49-pr59163.patch
> > > 
> > > So like this?
> > 
> > Yes, with adjusted comment in ix86_legitimate_combined_insn.
> > 
> > IIRC, unaligned moves won't be propagated during or after reload, so it
> > looks to me that the approach is correct.
> 
> Running the testsuite with your patch applied exposed a minor problem:
> 
> FAIL: gcc.target/i386/sse-1.c scan-assembler-not movaps
> 
> movlps/movhps and movlpd/movhpd can also handle unaligned operands (please
> see ix86_expand_vector_move_misalign). We should simply tag instructions
> that operate on unaligned operands (attribute type = ssemovu) and check type
> attribute instead.
> 
> The proposed approach would mean to change all scheduler and attribute
> calculation checks from "ssemov" to "ssemov,ssemovu", but this would be a
> simple mechanical change.

Yeah, I've noticed that too, plus the dumps I've used to note what instructions
have been rejected by the patch show that UNSPEC_LDDQU would need to be treated
like UNSPEC_LOADU.
The patch made difference for 32-bit:
gcc.target/i386/sse-1.c (as you write above)
gcc.dg/torture/pr18582-1.c (UNSPEC_LDDQU)
gcc.target/i386/sse4_1-movntdqa.c (UNSPEC_MOVNTDQA)
and 64-bit also
g++.dg/torture/pr59163.C (desirable)

Now, for movntdqa, I think it accepts only aligned memory, but the MEM in there
is supposed to be aligned and is created by
          if (i == memory)
            {
              /* This must be the memory operand.  */
              op = ix86_zero_extend_to_Pmode (op);
              op = gen_rtx_MEM (mode, op); 
              gcc_assert (GET_MODE (op) == mode
                          || GET_MODE (op) == VOIDmode);
            }
and there is similar code for builtins that store.
Supposedly for this we should use get_pointer_alignment (arg) and at least
set_mem_align (op, get_pointer_alignment (arg)); if it is larger than MEM_ALIGN
(op).  The gcc_assert doesn't make any sense to me, result of gen_rtx_MEM
(mode, op) will always have GET_MODE (op) == mode, no need to assert that and
it will never have VOIDmode.
Now, if we could easily find out which of the builtins assume aligned memory
(and to what extent), we should also set it, because say using
_mm_stream_load_si128 with not 128-bit aligned memory is user error, so GCC
should be able to assume A128 there.  I'd say the sse-1.c case is similar,
isn't it?
>From gcc-bugs-return-436294-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 29 20:37:18 2013
Return-Path: <gcc-bugs-return-436294-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30293 invoked by alias); 29 Nov 2013 20:37:18 -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 30264 invoked by uid 48); 29 Nov 2013 20:37:14 -0000
From: "dimhen at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/59347] New: ICE on invalid: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10798
Date: Fri, 29 Nov 2013 20:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dimhen at gmail dot com
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
Message-ID: <bug-59347-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/msg03071.txt.bz2
Content-length: 3967

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

            Bug ID: 59347
           Summary: ICE on invalid: tree check: expected class 'type',
                    have 'exceptional' (error_mark) in tsubst_decl, at
                    cp/pt.c:10798
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dimhen at gmail dot com

$ uname -a
Linux dim.cp.ru 3.11.9-200.fc19.x86_64 #1 SMP Wed Nov 20 21:22:24 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20131129 (experimental) [trunk revision 205527] (GCC)

$ cat x.ii
struct cast_retty_wrap;
template <class> struct cast_retty {
  typedef cast_retty_wrap<>::ret_type
} class Y cast_retty<Y>::

$ g++ -fpreprocessed -fsyntax-only x.ii
x.ii:3:11: error: 'cast_retty_wrap' is not a template
   typedef cast_retty_wrap<>::ret_type
           ^
x.ii:3:30: error: typedef name may not be a nested-name-specifier
   typedef cast_retty_wrap<>::ret_type
                              ^
x.ii:3:30: error: expected ';' at end of member declaration
x.ii:4:1: error: expected ';' after struct definition
 } class Y cast_retty<Y>::
 ^
x.ii: In instantiation of 'struct cast_retty<Y>':
x.ii:4:24:   required from here
x.ii:3:30: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10798
   typedef cast_retty_wrap<>::ret_type
                              ^
0xeea097 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
    /home/dimhen/src/gcc_current/gcc/tree.c:9241
0x6c14d8 tree_class_check
    /home/dimhen/src/gcc_current/gcc/tree.h:2825
0x6c14d8 tsubst_decl
    /home/dimhen/src/gcc_current/gcc/cp/pt.c:10798
0x6abd2c tsubst(tree_node*, tree_node*, int, tree_node*)
    /home/dimhen/src/gcc_current/gcc/cp/pt.c:11338
0x6da18f instantiate_class_template_1
    /home/dimhen/src/gcc_current/gcc/cp/pt.c:8987
0x6da18f instantiate_class_template(tree_node*)
    /home/dimhen/src/gcc_current/gcc/cp/pt.c:9251
0x76a933 complete_type(tree_node*)
    /home/dimhen/src/gcc_current/gcc/cp/typeck.c:134
0x743298 cp_parser_nested_name_specifier_opt
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:5389
0x743d7b cp_parser_nested_name_specifier
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:5452
0x743eb7 cp_parser_ptr_operator
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:17485
0x74b800 cp_parser_declarator
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:16834
0x756939 cp_parser_init_declarator
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:16433
0x758699 cp_parser_simple_declaration
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:11134
0x73c5a3 cp_parser_block_declaration
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:11015
0x762c26 cp_parser_declaration
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:10912
0x761918 cp_parser_declaration_seq_opt
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:10798
0x7631eb cp_parser_translation_unit
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:4018
0x7631eb c_parse_file()
    /home/dimhen/src/gcc_current/gcc/cp/parser.c:31261
0x880973 c_common_parse_file()
    /home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.