public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/61732] Derivation from final class incorrectly allowed
       [not found] <bug-61732-4@http.gcc.gnu.org/bugzilla/>
@ 2014-07-07 13:08 ` joaquin at tid dot es
  2014-07-07 15:51 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 4+ messages in thread
From: joaquin at tid dot es @ 2014-07-07 13:08 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Joaquín M López Muñoz <joaquin at tid dot es> ---
Umm... This is not how I read [class]/3 (no mention to instances there). And,
moreover, if your interpretation was right then the following should compile
too:

struct X final{};

struct derived:X{};

void foo(derived*){}

int main()
{
  foo(0);
}

but GCC, here, does complain that derived can't derive from X.
>From gcc-bugs-return-455776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 07 13:22:44 2014
Return-Path: <gcc-bugs-return-455776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30841 invoked by alias); 7 Jul 2014 13:22:44 -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 30692 invoked by uid 48); 7 Jul 2014 13:22:37 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61680] [4.8/4.9/4.10 Regression] vectorization gives wrong answer for sandybridge target
Date: Mon, 07 Jul 2014 13:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth 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: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61680-4-X5A9r9Ejw4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61680-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61680-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-07/txt/msg00367.txt.bz2
Content-length: 1806

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
          /* When we perform grouped accesses and perform implicit CSE
             by detecting equal accesses and doing disambiguation with
             runtime alias tests like for
                .. = a[i];
                .. = a[i+1];
                a[i] = ..;
                a[i+1] = ..;
                *p = ..;
                .. = a[i];
                .. = a[i+1];
             where we will end up loading { a[i], a[i+1] } once, make
             sure that inserting group loads before the first load and
             stores after the last store will do the right thing.  */
          if ((STMT_VINFO_GROUPED_ACCESS (stmtinfo_a)
               && GROUP_SAME_DR_STMT (stmtinfo_a))
              || (STMT_VINFO_GROUPED_ACCESS (stmtinfo_b)
                  && GROUP_SAME_DR_STMT (stmtinfo_b)))
            {
              gimple earlier_stmt;
              earlier_stmt = get_earlier_stmt (DR_STMT (dra), DR_STMT (drb));
              if (DR_IS_WRITE
                    (STMT_VINFO_DATA_REF (vinfo_for_stmt (earlier_stmt))))
                {
                  if (dump_enabled_p ())
                    dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
                                     "READ_WRITE dependence in interleaving."
                                     "\n");
                  return true;
                }
            }

is supposed to catch this kind of issue ... but it's very simple-minded
and GROUP_SAME_DR_STMT is not set (we don't have redundant loads to CSE).

What is interesting is that we don't CSE the loads from w[i_26][{0,1}].
That would have likely "fixed" this as well ...

Removing the GROUP_SAME_DR_STMT tests fixes the testcase.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/61732] Derivation from final class incorrectly allowed
       [not found] <bug-61732-4@http.gcc.gnu.org/bugzilla/>
  2014-07-07 13:08 ` [Bug c++/61732] Derivation from final class incorrectly allowed joaquin at tid dot es
@ 2014-07-07 15:51 ` redi at gcc dot gnu.org
  2014-07-07 16:36 ` joaquin at tid dot es
  2014-07-07 17:45 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2014-07-07 15:51 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Joaquín M López Muñoz from comment #2)
> Umm... This is not how I read [class]/3 (no mention to instances there).

That refers to classes. in Your original example derived is not a class, it's a
class template. It becomes a class when instantiated, but you never instantiate
it.




> And, moreover, if your interpretation was right then the following should
> compile too:
> 
> struct X final{};
> 
> struct derived:X{};
> 
> void foo(derived*){}
> 
> int main()
> {
>   foo(0);
> }
> 
> but GCC, here, does complain that derived can't derive from X.

But there are no templates to be instantiated there. The definition of derived
is ill-formed, period.

In your original example the definition of derived is only ill-formed if the
base class is final, and base classes are only checked when the template is
instantiated (because there could be an explicit specialization later in the
translation unit that doesn't derive from the template argument, making
derived<X> well-formed).

[temp.arg]/6 "If the use of a template-argument gives rise to an ill-formed
construct in the instantiation of a template specialization, the program is
ill-formed."

N.B. "in the instantiation" not earlier. [temp.inst] says when the point of
instantiation is, and your program doesn't instantiate derived<X>.

FWIW clang and EDG accept your first example too.
>From gcc-bugs-return-455795-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 07 15:59:25 2014
Return-Path: <gcc-bugs-return-455795-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30412 invoked by alias); 7 Jul 2014 15:59:24 -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 30287 invoked by uid 48); 7 Jul 2014 15:59:18 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/61735] basic_string bug when type_size is char.
Date: Mon, 07 Jul 2014 15:59: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: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: WAITING
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 everconfirmed
Message-ID: <bug-61735-4-d8W7k9FFCr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61735-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61735-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-07/txt/msg00386.txt.bz2
Content-length: 598

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-07-07
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Please provide the information requested at http://gcc.gnu.org/bugs not just a
link to a stackoverflow question without code.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/61732] Derivation from final class incorrectly allowed
       [not found] <bug-61732-4@http.gcc.gnu.org/bugzilla/>
  2014-07-07 13:08 ` [Bug c++/61732] Derivation from final class incorrectly allowed joaquin at tid dot es
  2014-07-07 15:51 ` redi at gcc dot gnu.org
@ 2014-07-07 16:36 ` joaquin at tid dot es
  2014-07-07 17:45 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: joaquin at tid dot es @ 2014-07-07 16:36 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Joaquín M López Muñoz <joaquin at tid dot es> ---
I see. The following is slightly off-topic, so please tell me if you can carry
on the discussion offline. Why is such an instantiation error not
SFINAE-protected in the following example?

template<class Base> struct derived:Base{typedef int type;};

struct X final{};

template<typename T>
void foo(T*,typename derived<T>::type=0){}

void foo(...){}

int main()
{
  X* x;
  foo(x);
}

GCC fails to compile with "cannot derive from X" instead of omitting the
instantiation of foo<X> and resorting to foo(...) instead.
>From gcc-bugs-return-455799-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 07 16:42:38 2014
Return-Path: <gcc-bugs-return-455799-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 919 invoked by alias); 7 Jul 2014 16:42:37 -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 478 invoked by uid 48); 7 Jul 2014 16:42:32 -0000
From: "eric.niebler at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61738] New: ICE using template template parameters and template aliases
Date: Mon, 07 Jul 2014 16:42: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: eric.niebler 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 attachments.created
Message-ID: <bug-61738-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-07/txt/msg00390.txt.bz2
Content-length: 3510

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

            Bug ID: 61738
           Summary: ICE using template template parameters and template
                    aliases
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric.niebler at gmail dot com

Created attachment 33083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33083&action=edit
preprocessed source

The attached preprocessed code, compiled with -std=gnu++11, causes the
following ICE:

In file included from ../range-v3/include/range/v3/utility/concepts.hpp:22:0,
                 from ../range-v3/test/utility/concepts.cpp:12:
../range-v3/include/range/v3/utility/meta.hpp: In substitution of
‘template<template<class ...> class C, class ... As> using meta_apply =
ranges::v3::meta_eval<C<As ...> > [with C = ranges::v3::range_concept; As =
{std::vector<int, std::allocator<int> >}]’:
../range-v3/include/range/v3/range_concepts.hpp:255:61:   required by
substitution of ‘template<class T> using range_concept_t =
ranges::v3::meta_apply<ranges::v3::range_concept, T> [with T =
std::vector<int>]’
../range-v3/test/utility/concepts.cpp:106:48:   required from here
../range-v3/include/range/v3/utility/meta.hpp:40:47: internal compiler error:
Segmentation fault
         using meta_apply = meta_eval<C<As...>>;
                                               ^
0x94ac7f crash_signal
    /home/eric/gcc-4.9.0/gcc/toplev.c:337
0x943000 layout_decl(tree_node*, unsigned int)
    /home/eric/gcc-4.9.0/gcc/stor-layout.c:676
0x56d116 tsubst_decl
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:11159
0x5665e7 tsubst(tree_node*, tree_node*, int, tree_node*)
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:11501
0x56ea9b instantiate_template_1
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:15510
0x56ea9b instantiate_template(tree_node*, tree_node*, int)
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:15560
0x5666f7 instantiate_alias_template
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:15590
0x5666f7 tsubst(tree_node*, tree_node*, int, tree_node*)
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:11528
0x56d012 tsubst_decl
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:11052
0x5665e7 tsubst(tree_node*, tree_node*, int, tree_node*)
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:11501
0x56ea9b instantiate_template_1
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:15510
0x56ea9b instantiate_template(tree_node*, tree_node*, int)
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:15560
0x5666f7 instantiate_alias_template
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:15590
0x5666f7 tsubst(tree_node*, tree_node*, int, tree_node*)
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:11528
0x56a316 lookup_template_class_1
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:7636
0x56a316 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
    /home/eric/gcc-4.9.0/gcc/cp/pt.c:7862
0x5f7952 finish_template_type(tree_node*, tree_node*, int)
    /home/eric/gcc-4.9.0/gcc/cp/semantics.c:2965
0x5b819a cp_parser_template_id
    /home/eric/gcc-4.9.0/gcc/cp/parser.c:13467
0x5b8332 cp_parser_class_name
    /home/eric/gcc-4.9.0/gcc/cp/parser.c:19185
0x5ad913 cp_parser_qualifying_entity
    /home/eric/gcc-4.9.0/gcc/cp/parser.c:5540
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-455800-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 07 17:04:06 2014
Return-Path: <gcc-bugs-return-455800-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27994 invoked by alias); 7 Jul 2014 17:04:06 -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 27933 invoked by uid 48); 7 Jul 2014 17:04:02 -0000
From: "andi-gcc at firstfloor dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59850] Support sparse-style pointer address spaces (type attributes)
Date: Mon, 07 Jul 2014 17:04: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: enhancement
X-Bugzilla-Who: andi-gcc at firstfloor dot 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:
Message-ID: <bug-59850-4-KunPTwx7YP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59850-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59850-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-07/txt/msg00391.txt.bz2
Content-length: 229

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

--- Comment #30 from Andi Kleen <andi-gcc at firstfloor dot org> ---
Please don't invent your own syntax for this. Use the one that has been widely
deployed for years. Thanks.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/61732] Derivation from final class incorrectly allowed
       [not found] <bug-61732-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2014-07-07 16:36 ` joaquin at tid dot es
@ 2014-07-07 17:45 ` redi at gcc dot gnu.org
  3 siblings, 0 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2014-07-07 17:45 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The error happens outside the immediate context.

See http://stackoverflow.com/a/15261234/981959


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-07-07 17:45 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-61732-4@http.gcc.gnu.org/bugzilla/>
2014-07-07 13:08 ` [Bug c++/61732] Derivation from final class incorrectly allowed joaquin at tid dot es
2014-07-07 15:51 ` redi at gcc dot gnu.org
2014-07-07 16:36 ` joaquin at tid dot es
2014-07-07 17:45 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).