[Bug c++/63362] New: The c++11 triviality-traits need front-end help

[Bug c++/63362] New: The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

            Bug ID: 63362
           Summary: The c++11 triviality-traits need front-end help
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ville.voutilainen at gmail dot com
                CC: jason at redhat dot com

Jason wrote in a private email:

"I think what we need is a compiler hook to say whether a particular expression
is trivial or not."
and further
"I'm thinking that parsing would be similar to parsing any other unevaluated
context (sizeof/alignof/decltype), and then we would walk_tree through the
resulting expression to find any calls and see if any of them are to
non-trivial functions."

See
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html
Table 1.2. C++ 2011 Implementation Status
20.9.4.3    Type properties

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> ---
Created attachment 33560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33560&action=edit
initial patch

Here's an initial patch, but I'm not sure how to write an expression to test
that doesn't call any non-trivial function like operator new.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33560|0                           |1
        is obsolete|                            |

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> ---
Created attachment 33565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33565&action=edit
new patch

how does this look?

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Looks good so far. I think this is a sufficient start for implementing the
library traits. Does the patch cover template cases as well? Such as

struct B {B();};

template <class T> struct C : T
{
};

SA(__calls_nontrivial_fn(C<B>()));

Anyway, I'll give it a spin.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.0

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Implemented in r215735-r215738.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2014-10-01
         Resolution|FIXED                       |---
     Ever confirmed|0                           |1

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Let's keep this open until the following also works fine:

template <class T, class... Args> void bar() {
  static_assert(__is_trivially_constructible(T, Args...), "");
}

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Wed Oct  1 17:21:08 2014
New Revision: 215772

URL: https://gcc.gnu.org/viewcvs?rev=215772&root=gcc&view=rev
Log:
    PR c++/63362
    * method.c (constructible_expr): Handle value-init of non-class.
    * parser.c (cp_parser_trait_expr): Allow pack expansion.
    * pt.c (tsubst_copy_and_build): Handle pack expansion.

Added:
    trunk/gcc/testsuite/g++.dg/ext/is_trivially_constructible3.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/method.c
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Wed Oct  1 17:21:01 2014
New Revision: 215771

URL: https://gcc.gnu.org/viewcvs?rev=215771&root=gcc&view=rev
Log:
    PR c++/63362
    * class.c (type_has_non_user_provided_default_constructor): Rename
    from type_has_user_provided_default_constructor, reverse sense.
    (default_init_uninitialized_part, explain_non_literal_class): Adjust.
    (check_bases_and_members): Set TYPE_HAS_COMPLEX_DFLT.
    * call.c (build_new_method_call_1): Adjust.
    * cp-tree.h: Adjust.
    * decl.c (grok_special_member_properties): Don't set
    TYPE_HAS_COMPLEX_DFLT.
    * init.c (build_value_init_noctor): Don't use
    type_has_user_provided_default_constructor.

Added:
    trunk/gcc/testsuite/g++.dg/ext/is_trivially_constructible2.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/class.c
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/decl.c
    trunk/gcc/cp/init.c

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #9 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Ouch. The test snippet is extracted from an attempt to implement
is_trivially_constructible.

#include <type_traits>

template <typename T, class... Args>
struct mytrait : public std::__and_<std::is_constructible<T, Args...>,
std::integral_constant<bool,
            __is_trivially_constructible(T, Args...)>>::type
{
}

trivial_trait.cpp:5:43: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in strip_typedefs, at cp/tree.c:1204
    __is_trivially_constructible(T, Args...)>>::type
                                           ^
0xe02687 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
    ../../gcc/tree.c:9226
0x735d28 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
    ../../gcc/tree.h:2856
0x735d28 strip_typedefs(tree_node*)
    ../../gcc/cp/tree.c:1204
0x734c40 strip_typedefs_expr(tree_node*)
    ../../gcc/cp/tree.c:1396
0x5fe7d7 convert_template_argument
    ../../gcc/cp/pt.c:6658
0x5e125b coerce_template_parms
    ../../gcc/cp/pt.c:7080
0x5e92de lookup_template_class_1
    ../../gcc/cp/pt.c:7661
0x5e92de lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
    ../../gcc/cp/pt.c:7979
0x6ffd62 finish_template_type(tree_node*, tree_node*, int)
    ../../gcc/cp/semantics.c:2981
0x692bf9 cp_parser_template_id
    ../../gcc/cp/parser.c:13664
0x692f08 cp_parser_class_name
    ../../gcc/cp/parser.c:19491
0x68707a cp_parser_qualifying_entity
    ../../gcc/cp/parser.c:5571
0x68707a cp_parser_nested_name_specifier_opt
    ../../gcc/cp/parser.c:5296
0x69f3a0 cp_parser_simple_type_specifier
    ../../gcc/cp/parser.c:14871
0x67ae55 cp_parser_type_specifier
    ../../gcc/cp/parser.c:14617
0x67c0ab cp_parser_type_specifier_seq
    ../../gcc/cp/parser.c:18359
0x691362 cp_parser_type_id_1
    ../../gcc/cp/parser.c:18231
0x69145e cp_parser_template_type_arg
    ../../gcc/cp/parser.c:18281
0x691692 cp_parser_template_argument
    ../../gcc/cp/parser.c:14044
0x691692 cp_parser_template_argument_list
    ../../gcc/cp/parser.c:13954
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.
>From gcc-bugs-return-463147-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 02 22:35:56 2014
Return-Path: <gcc-bugs-return-463147-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19433 invoked by alias); 2 Oct 2014 22:35:55 -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 19391 invoked by uid 48); 2 Oct 2014 22:35:47 -0000
From: "ville.voutilainen at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63362] The c++11 triviality-traits need front-end help
Date: Thu, 02 Oct 2014 22:35: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: 5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ville.voutilainen at gmail dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63362-4-7jWZGaTnv4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63362-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63362-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: 2014-10/txt/msg00168.txt.bz2
Content-length: 2295

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

--- Comment #10 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Reduced:

template <bool b> 
struct bool_
{
};

template <typename T, class... Args>
struct mytrait : bool_<__is_trivially_constructible(T, Args...)>
{
}

trivial_trait2.cpp:7:64: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in strip_typedefs, at cp/tree.c:1204
 struct mytrait : bool_<__is_trivially_constructible(T, Args...)>
                                                                ^
0xe02687 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
    ../../gcc/tree.c:9226
0x735d28 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
    ../../gcc/tree.h:2856
0x735d28 strip_typedefs(tree_node*)
    ../../gcc/cp/tree.c:1204
0x734c40 strip_typedefs_expr(tree_node*)
    ../../gcc/cp/tree.c:1396
0x5fe7d7 convert_template_argument
    ../../gcc/cp/pt.c:6658
0x5e125b coerce_template_parms
    ../../gcc/cp/pt.c:7080
0x5e92de lookup_template_class_1
    ../../gcc/cp/pt.c:7661
0x5e92de lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
    ../../gcc/cp/pt.c:7979
0x6ffd62 finish_template_type(tree_node*, tree_node*, int)
    ../../gcc/cp/semantics.c:2981
0x692bf9 cp_parser_template_id
    ../../gcc/cp/parser.c:13664
0x692f08 cp_parser_class_name
    ../../gcc/cp/parser.c:19491
0x68707a cp_parser_qualifying_entity
    ../../gcc/cp/parser.c:5571
0x68707a cp_parser_nested_name_specifier_opt
    ../../gcc/cp/parser.c:5296
0x67a1bb cp_parser_base_specifier
    ../../gcc/cp/parser.c:21239
0x67a1bb cp_parser_base_clause
    ../../gcc/cp/parser.c:21088
0x67a1bb cp_parser_class_head
    ../../gcc/cp/parser.c:20297
0x67a1bb cp_parser_class_specifier_1
    ../../gcc/cp/parser.c:19571
0x67b0c0 cp_parser_class_specifier
    ../../gcc/cp/parser.c:19863
0x67b0c0 cp_parser_type_specifier
    ../../gcc/cp/parser.c:14539
0x6961c1 cp_parser_decl_specifier_seq
    ../../gcc/cp/parser.c:11780
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.
>From gcc-bugs-return-463148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 02 22:59:04 2014
Return-Path: <gcc-bugs-return-463148-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3453 invoked by alias); 2 Oct 2014 22:59:03 -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 3425 invoked by uid 48); 2 Oct 2014 22:58:59 -0000
From: "M8R-ynb11d at mailinator dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63446] New: dangling reference results in confusing diagnostic from -Wuninitialized
Date: Thu, 02 Oct 2014 22:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: M8R-ynb11d at mailinator 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-63446-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: 2014-10/txt/msg00169.txt.bz2
Content-length: 1629

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

            Bug ID: 63446
           Summary: dangling reference results in confusing diagnostic
                    from -Wuninitialized
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: M8R-ynb11d at mailinator dot com

struct foo {
    int &ref;
    foo(int &i) : ref(i) {}
};

foo make_foo()
{
    int x = 42;
    return foo(x);
}

int func()
{
    foo f = make_foo();
    return f.ref;
}

This code is obviously broken due to the dangling reference, so I'm glad gcc
gives a warning (clang is silent) but the warning is a bit confusing:

$ g++ -O2 -Wall -c wuninit.cpp
wuninit.cpp: In function ‘int func()’:
wuninit.cpp:15:14: warning: ‘x’ is used uninitialized in this function
[-Wuninitialized]
     return f.ref;
              ^

I get that the diagnostic is generated after inlining has moved x into func(),
but it's still rather confusing as the person that wrote func() might have no
knowledge of the internals of make_foo(), and this would be a real head
scratcher for them.  Additionally, it mentions x being used uninitialized, but
x is initialized.  (I understand that the initialization becomes dead code and
is removed, but that's not immediately obvious.)

In an ideal world gcc would warn about the last line of make_foo() instead of
func(), and it would mention a dangling reference instead of an uninitialized
use.
>From gcc-bugs-return-463149-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Oct 02 23:30:04 2014
Return-Path: <gcc-bugs-return-463149-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17591 invoked by alias); 2 Oct 2014 23:30:03 -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 17470 invoked by uid 48); 2 Oct 2014 23:29:58 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/13423] sh-elf: V4SFmode passed in integer registers
Date: Thu, 02 Oct 2014 23:30:00 -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: 3.4.0
X-Bugzilla-Keywords: ABI, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-13423-4-DjW0sGvT9E@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-13423-4@http.gcc.gnu.org/bugzilla/>
References: <bug-13423-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: 2014-10/txt/msg00170.txt.bz2
Content-length: 758

https://gcc.gnu.org/bugzilla/show_bug.cgi?id\x13423

--- Comment #5 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #3)
> Although this is an ABI issue, passing float vector by reference should not
> actually suffer from this problem, but it does:
>
> typedef float v4sf __attribute__ ((vector_size (16)));
>
> void test00 (v4sf& a, const v4sf& b)
> {
>   a += b;
> }

The reason for that are missing various vec_* patterns, in particular
vec_extractv4sf, vec_setv4sf, movv4sf, etc.  If those are not specified
fallback options will be used by the RTL expansion, which loads/stores the
vectors as SImode subregs.

Adding vector arithmetic patterns such as addv4sf3 is not necessary, but might
simplify a thing or two.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Fri Oct  3 15:52:03 2014
New Revision: 215860

URL: https://gcc.gnu.org/viewcvs?rev=215860&root=gcc&view=rev
Log:
    PR c++/63362
    * tree.c (strip_typedefs): Handle TREE_LIST.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/tree.c

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> ---
Should be fixed now.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #13 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Hmm. The first of the two ICE tests still ICEs. It no longer stops my build,
though - and I don't quite understand why, because previously the build
ICEd when building the library pre-compiled headers.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Ville Voutilainen from comment #13)
> Hmm. The first of the two ICE tests still ICEs.

Which test?  None of the tests are ICEing for me.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #15 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Jason Merrill from comment #14)
> (In reply to Ville Voutilainen from comment #13)
> > Hmm. The first of the two ICE tests still ICEs.
> 
> Which test?  None of the tests are ICEing for me.

This one:

#include <type_traits>

template <typename T, class... Args>
struct mytrait : public std::__and_<std::is_constructible<T, Args...>,
std::integral_constant<bool,
            __is_trivially_constructible(T, Args...)>>::type
{
}

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #16 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Ville Voutilainen from comment #15)
> (In reply to Jason Merrill from comment #14)
> > (In reply to Ville Voutilainen from comment #13)
> > > Hmm. The first of the two ICE tests still ICEs.
> > 
> > Which test?  None of the tests are ICEing for me.
> 
> This one:
> 
> #include <type_traits>
> 
> template <typename T, class... Args>
> struct mytrait : public std::__and_<std::is_constructible<T, Args...>,
> std::integral_constant<bool,
> 			__is_trivially_constructible(T, Args...)>>::type
> {
> }

And the trace is

[ville@localhost ~]$ g++ --std=c++14 -c trivial_trait.cpp
trivial_trait.cpp:5:43: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in comptypes, at cp/typeck.c:1391
    __is_trivially_constructible(T, Args...)>>::type
                                           ^
0xe07427 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
    ../../gcc/tree.c:9226
0x6b4f50 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
    ../../gcc/tree.h:2856
0x6b4f50 comptypes(tree_node*, tree_node*, int)
    ../../gcc/cp/typeck.c:1391
0x5c2934 template_args_equal
    ../../gcc/cp/pt.c:7223
0x5c2fbe comp_template_args_with_info
    ../../gcc/cp/pt.c:7250
0x5c30ec comp_template_args(tree_node*, tree_node*)
    ../../gcc/cp/pt.c:7268
0x5c30ec eq_specializations
    ../../gcc/cp/pt.c:1512
0x123c2c4 htab_find_with_hash
    ../../libiberty/hashtab.c:598
0x5e9b31 lookup_template_class_1
    ../../gcc/cp/pt.c:7688
0x5e9b31 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
    ../../gcc/cp/pt.c:7979
0x700da2 finish_template_type(tree_node*, tree_node*, int)
    ../../gcc/cp/semantics.c:2981
0x6936e9 cp_parser_template_id
    ../../gcc/cp/parser.c:13658
0x6939f8 cp_parser_class_name
    ../../gcc/cp/parser.c:19487
0x687b4a cp_parser_qualifying_entity
    ../../gcc/cp/parser.c:5570
0x687b4a cp_parser_nested_name_specifier_opt
    ../../gcc/cp/parser.c:5295
0x69fec0 cp_parser_simple_type_specifier
    ../../gcc/cp/parser.c:14864
0x67b725 cp_parser_type_specifier
    ../../gcc/cp/parser.c:14610
0x67c97b cp_parser_type_specifier_seq
    ../../gcc/cp/parser.c:18355
0x691e52 cp_parser_type_id_1
    ../../gcc/cp/parser.c:18227
0x691f4e cp_parser_template_type_arg
    ../../gcc/cp/parser.c:18277
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
>From gcc-bugs-return-463462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 16:57:31 2014
Return-Path: <gcc-bugs-return-463462-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29375 invoked by alias); 7 Oct 2014 16:57:31 -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 28869 invoked by uid 48); 7 Oct 2014 16:57:25 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63362] The c++11 triviality-traits need front-end help
Date: Tue, 07 Oct 2014 16:57: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: 5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63362-4-LhPMPPemq9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63362-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63362-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: 2014-10/txt/msg00483.txt.bz2
Content-length: 539

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

--- Comment #17 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Ville Voutilainen from comment #16)
> > This one:
> > 
> > #include <type_traits>
> > 
> > template <typename T, class... Args>
> > struct mytrait : public std::__and_<std::is_constructible<T, Args...>,
> > std::integral_constant<bool,
> > 			__is_trivially_constructible(T, Args...)>>::type
> > {
> > }

Yeah, that works fine for me.  Perhaps the ICE is related to changes you've
made to type_traits?
>From gcc-bugs-return-463463-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 17:08:44 2014
Return-Path: <gcc-bugs-return-463463-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3503 invoked by alias); 7 Oct 2014 17:08:43 -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 3471 invoked by uid 48); 7 Oct 2014 17:08:39 -0000
From: "spear at cse dot lehigh.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63472] New: transaction_atomic within while loop causes ICE
Date: Tue, 07 Oct 2014 17:08: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: critical
X-Bugzilla-Who: spear at cse dot lehigh.edu
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-63472-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: 2014-10/txt/msg00484.txt.bz2
Content-length: 1732

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

            Bug ID: 63472
           Summary: transaction_atomic within while loop causes ICE
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: spear at cse dot lehigh.edu

Summary:

The following code produces an ICE when compiled with "g++ -fgnu-tm bug.cc -c"

int val;

void test() {
    while (true) {
        __transaction_atomic {
            if (val == 42)
                return;
        }
    }
}

Error Message:

bug.cc: In function ‘void test()’:
bug.cc:12:1: internal compiler error: in duplicate_block, at cfghooks.c:1032
 }
 ^
0x84c987 duplicate_block(basic_block_def*, edge_def*, basic_block_def*)
        ../../source_git/gcc/cfghooks.c:1032
0x84cca5 copy_bbs(basic_block_def**, unsigned int, basic_block_def**,
edge_def**, unsigned int, edge_def**, loop*, basic_block_def*, bool)
        ../../source_git/gcc/cfghooks.c:1312
0xbd6139 ipa_uninstrument_transaction
        ../../source_git/gcc/trans-mem.c:4093
0xbd6139 ipa_tm_scan_calls_transaction
        ../../source_git/gcc/trans-mem.c:4167
0xbd6139 ipa_tm_execute
        ../../source_git/gcc/trans-mem.c:5340
0xbd6139 execute
        ../../source_git/gcc/trans-mem.c:5578
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.

GCC Information:
gcc (GCC) 5.0.0 20141007 (experimental)
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215970
138bc75d-0d04-0410-961f-82ee72b054a4
>From gcc-bugs-return-463464-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 17:13:42 2014
Return-Path: <gcc-bugs-return-463464-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6088 invoked by alias); 7 Oct 2014 17:13:41 -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 6054 invoked by uid 48); 7 Oct 2014 17:13:38 -0000
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/56183] [meta-bug][avr] Problems with register allocation
Date: Tue, 07 Oct 2014 17:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: meta-bug, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gjl 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 resolution
Message-ID: <bug-56183-4-li4BMgzukz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56183-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56183-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: 2014-10/txt/msg00485.txt.bz2
Content-length: 500

https://gcc.gnu.org/bugzilla/show_bug.cgi?idV183
Bug 56183 depends on bug 52278, which changed state.

Bug 52278 Summary: [4.8/4.9/5 Regression] [avr] inefficient register allocation for SUBREGs
https://gcc.gnu.org/bugzilla/show_bug.cgi?idR278

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #18 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Jason Merrill from comment #17)
> (In reply to Ville Voutilainen from comment #16)
> > > This one:
> > > 
> > > #include <type_traits>
> > > 
> > > template <typename T, class... Args>
> > > struct mytrait : public std::__and_<std::is_constructible<T, Args...>,
> > > std::integral_constant<bool,
> > > 			__is_trivially_constructible(T, Args...)>>::type
> > > {
> > > }
> 
> Yeah, that works fine for me.  Perhaps the ICE is related to changes you've
> made to type_traits?

Fishy. Taking integral_constant and __and_ (and conditional) from type_traits 
and faking is_constructible works fine. My modifications to type_traits work 
fine when used in a test program, so compiling the actual trait itself seems
to work just fine. Yet this particular test will not work with my
modifications,
but works without them (I just tested that).

Well, this test is an ill-formed program, it's using names reserved to 
the implementation. :)
>From gcc-bugs-return-463470-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 17:50:50 2014
Return-Path: <gcc-bugs-return-463470-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9197 invoked by alias); 7 Oct 2014 17:50:49 -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 9155 invoked by uid 48); 7 Oct 2014 17:50:46 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63362] The c++11 triviality-traits need front-end help
Date: Tue, 07 Oct 2014 17:50: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: 5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63362-4-fRVQ8uiQvj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63362-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63362-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: 2014-10/txt/msg00491.txt.bz2
Content-length: 337

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc362

--- Comment #19 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Ville Voutilainen from comment #18)
> to work just fine. Yet this particular test will not work with my
> modifications, but works without them (I just tested that).

Attach a preprocessed file that ICEs?

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #20 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Jason Merrill from comment #19)
> (In reply to Ville Voutilainen from comment #18)
> > to work just fine. Yet this particular test will not work with my
> > modifications, but works without them (I just tested that).
> 
> Attach a preprocessed file that ICEs?

The presence of a libiberty hash operation
and comptypes would suggest that it's something to do with the lookup of
templates,
when there's already a template that is more or less similar, and then
a definition of another one quite like it with a different name...

This test fails even without my changes in type_traits:

#include <type_traits>

template <typename T, class... Args>
struct mytrait : public std::__and_<std::is_constructible<T, Args...>,
std::integral_constant<bool,
            __is_trivially_constructible(T, Args...)>>::type
{
};

template <typename T, class... Args>
struct mytrait2 : public std::__and_<std::is_constructible<T, Args...>,
std::integral_constant<bool,
            __is_trivially_constructible(T, Args...)>>::type
{
};

Ok, I can even reduce it, again:

template <bool b> struct bool_
{
};

template <typename T, class... Args>
struct mytrait : bool_<__is_trivially_constructible(T, Args...)>
{
};

template <typename T, class... Args>
struct mytrait2 : bool_<__is_trivially_constructible(T, Args...)>
{
};

[ville@localhost ~]$ g++ --std=c++14 -c trivial_trait3.cpp
trivial_trait3.cpp:11:65: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in comptypes, at cp/typeck.c:1391
 struct mytrait2 : bool_<__is_trivially_constructible(T, Args...)>
                                                                 ^
0xe07427 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
    ../../gcc/tree.c:9226
0x6b4f50 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
    ../../gcc/tree.h:2856
0x6b4f50 comptypes(tree_node*, tree_node*, int)
    ../../gcc/cp/typeck.c:1391
0x5c2934 template_args_equal
    ../../gcc/cp/pt.c:7223
0x5c2fbe comp_template_args_with_info
    ../../gcc/cp/pt.c:7250
0x5c30ec comp_template_args(tree_node*, tree_node*)
    ../../gcc/cp/pt.c:7268
0x5c30ec eq_specializations
    ../../gcc/cp/pt.c:1512
0x123c2c4 htab_find_with_hash
    ../../libiberty/hashtab.c:598
0x5e9b31 lookup_template_class_1
    ../../gcc/cp/pt.c:7688
0x5e9b31 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
    ../../gcc/cp/pt.c:7979
0x700da2 finish_template_type(tree_node*, tree_node*, int)
    ../../gcc/cp/semantics.c:2981
0x6936e9 cp_parser_template_id
    ../../gcc/cp/parser.c:13658
0x6939f8 cp_parser_class_name
    ../../gcc/cp/parser.c:19487
0x687b4a cp_parser_qualifying_entity
    ../../gcc/cp/parser.c:5570
0x687b4a cp_parser_nested_name_specifier_opt
    ../../gcc/cp/parser.c:5295
0x67aae9 cp_parser_base_specifier
    ../../gcc/cp/parser.c:21231
0x67aae9 cp_parser_base_clause
    ../../gcc/cp/parser.c:21080
0x67aae9 cp_parser_class_head
    ../../gcc/cp/parser.c:20293
0x67aae9 cp_parser_class_specifier_1
    ../../gcc/cp/parser.c:19567
0x67b990 cp_parser_class_specifier
    ../../gcc/cp/parser.c:19859
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.
>From gcc-bugs-return-463474-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 18:06:40 2014
Return-Path: <gcc-bugs-return-463474-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23402 invoked by alias); 7 Oct 2014 18:06:40 -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 23371 invoked by uid 55); 7 Oct 2014 18:06:36 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
Date: Tue, 07 Oct 2014 18:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law 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-63432-4-yy1EdgFCYb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63432-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63432-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: 2014-10/txt/msg00495.txt.bz2
Content-length: 2505

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc432

--- Comment #19 from Jeffrey A. Law <law at redhat dot com> ---
On 10/04/14 09:34, Teresa Johnson wrote:
>
> Looking at the code, I think it attempts to check for this case and
> prevent it but that code does not work in this case because of the
> order the paths are identified and subsequently iterated in the paths
> vec. In mark_threaded_blocks it looks at paths with joiners and if
> there are any edges along the path already part of another path it
> will skip that path. But in this case, we registered the paths in this
> order:
>
>    Registering jump thread: (119, 150) incoming edge;  (150, 13)
> joiner;  (13, 15) normal;
> ...
>    Registering jump thread: (150, 13) incoming edge;  (13, 15) joiner;
> (15, 17) normal;
>
> For the first path, the path is attached to incoming edge 119->150. So
> when we walk edges in the 2nd path we don't see the first path. If we
> looked at the paths in the reverse order we would have seen the path
> attached to incoming edge 150->13 and skipped the 119->150 path. Note
> that we end up doing the actual threading in the reverse order - first
> we do the threading through 13 (the second path), then later the
> threading through 150 (the first path), leading to the issue I am
> seeing.
>
> Jeff, what is intended here - should we not be threading both of these paths?
The code in mark_threaded_jumps looks for cases where there is a jump
threading path with a joiner block is subsumed by a jump threading path
without a joiner block and it will suppress the jump threading path with
the joiner.  We had more suppressed paths in the past, but they mostly
got ripped out as the implementation solidified.

In the case shown above, we have two paths with joiner blocks so the
suppression code in mark_threaded_blocks does not fire and we attempt to
realize both jump threading paths.

 From a correctness standpoint the code should handle this case;
however, there may be strong reasons to suppress one path or the other
from a code bloat and/or performance standpoint.

I typically have to draw out the CFG and the intermediate steps to gain
clarity into the desired result and there's not enough info here to do
that.   My gut tells me suppression of one jump thread path is
desirable, we aren't going to have anything good to guide which path to
suppress, the vast majority of the time it won't matter which path is
suppressed.  So I'm comfortable with suppressing either path.

jeff

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

--- Comment #23 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Ville Voutilainen from comment #22)
> This test fails the static_assert for TType (which is a trivial type),
> PODType and DelDef, and it would be expected that all those static_asserts
> succeed.

No:

struct A { };

int main()
{
  volatile A a;
  volatile A a2(a); // ill-formed
}

test_category is testing whether volatile TType is trivially
copy-constructible, and it isn't copy-constructible at all.

Incidentally, you don't need to test anything else before
__is_trivially_constructible, it will just return false if the type isn't
constructible at all.  Likewise for assignable.

Looking at the ICE.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #24 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Jason Merrill from comment #23)
> (In reply to Ville Voutilainen from comment #22)
> > This test fails the static_assert for TType (which is a trivial type),
> > PODType and DelDef, and it would be expected that all those static_asserts
> > succeed.
> No:
> struct A { };
> int main()
> {
>   volatile A a;
>   volatile A a2(a); // ill-formed
> }
> test_category is testing whether volatile TType is trivially
> copy-constructible, and it isn't copy-constructible at all.

Argh, thanks, I'll need to make those tests saner.

> Incidentally, you don't need to test anything else before
> __is_trivially_constructible, it will just return false if the type isn't
> constructible at all.  Likewise for assignable.

These library traits require that for a true-answer, the type used
must be referenceable. The 'main' traits do that, I wasn't sure whether
the intrinsic does. The 'main' traits also limit the accepted types
as per the standard, so I'm inclined to leave the general testing
approach as is. Jonathan took a quick look at it and thought it looks
ok. ;)

> Looking at the ICE.

Excellent.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[jason at gcc dot gnu.org]

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

--- Comment #25 from Jason Merrill <jason at gcc dot gnu.org> ---
And the ICE reduces to

struct A {
  A(...);
};

int main()
{
  volatile A a;
  volatile A a2(a);
}

which crashes from infinite recursion trying to copy a for passing to ....  So,
not an __is_trivially_constructible issue.

[Bug c++/63362] The c++11 triviality-traits need front-end help

[ville.voutilainen at gmail dot com]

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

--- Comment #26 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Jason Merrill from comment #25)
> And the ICE reduces to
> 
> struct A {
>   A(...);
> };
> 
> int main()
> {
>   volatile A a;
>   volatile A a2(a);
> }
> 
> which crashes from infinite recursion trying to copy a for passing to .... 
> So, not an __is_trivially_constructible issue.

Ah, yes, my test for a construct::Ellipsis will do that.