public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/63904] New: ICE when acessing array member of constexpr struct
@ 2014-11-16 21:38 gcc-bugzilla at bmevers dot de
  2014-11-18 10:49 ` [Bug c++/63904] ICE when accessing " paolo.carlini at oracle dot com
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: gcc-bugzilla at bmevers dot de @ 2014-11-16 21:38 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6253 bytes --]

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

            Bug ID: 63904
           Summary: ICE when acessing array member of constexpr struct
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugzilla at bmevers dot de

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

The following code causes an internal compiler error:


template<int N>
struct foo {
    constexpr foo() : a() {}
    int a[N];
};

int main() {
    foo< (foo<1>{}).a[0] > f;
}


constexpr-initalization.cpp:7:25:   in constexpr expansion of
‘f.foo<N>::foo<0>()’
constexpr-initalization.cpp:7:25: internal compiler error: in tree_low_cst, at
tree.h:4849
 foo< (foo<1>{}).a[0] > f;
>From gcc-bugs-return-466970-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Nov 16 21:39:39 2014
Return-Path: <gcc-bugs-return-466970-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7760 invoked by alias); 16 Nov 2014 21:39:39 -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 7711 invoked by uid 48); 16 Nov 2014 21:39:35 -0000
From: "paul.richard.thomas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/63205] [OOP] Wrongly rejects  type = class (for identical declared type)
Date: Sun, 16 Nov 2014 21:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paul.richard.thomas at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: pault at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-63205-4-WPyI3PuoNW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63205-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63205-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-11/txt/msg01442.txt.bz2
Content-length: 3350

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

paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> changed:

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

--- Comment #4 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Created attachment 33995
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3995&actioníit
Patch that fixes testcase in the comment but causes regressions.

The attached patch runs the testcase below without memory leaks but causes
regressions in:
class_allocate_7.f03
class_to_type_2.f90
typebound_operator_7.f03
typebound_operator_8.f03

All of these are run time errors caused by finalization occurring too soon. The
additions to gfc_conv_procedure_call will have to be moved to
gfc_trans_assignment_1 so that the specific case of class function assignment
to derived type is caught. I will attend to this during this week.

Paul

program test
  implicit none
  type t
    integer :: ii
  end type t
  type, extends(t) :: u
    real :: rr
  end type u
  type, extends(t) :: v
    real, allocatable :: rr(:)
  end type v
  type, extends(v) :: w
    real, allocatable :: rrr(:)
  end type w

  type(t) :: x, y(3)
  type(v) :: a, b(3)

  x = func1() ! scalar to scalar - no alloc comps
  print *, x%ii

  y = func2() ! array to array - no alloc comps
  print *, y%ii

  y = func1() ! scalar to array - no alloc comps
  print *, y%ii

  x = func3() ! scalar daughter type to scalar - no alloc comps
  print *, x%ii

  y = func4() ! array daughter type to array - no alloc comps
  print *, y%ii

  a = func5() ! scalar to scalar - alloc comps in parent type
  print *, a%rr

  b = func6() ! array to array - alloc comps in parent type
  print *, b(3)%rr

  a = func7() ! scalar daughter type to scalar - alloc comps in parent type
  print *, a%rr

  b = func8() ! array daughter type to array - alloc comps in parent type
  print *, b(3)%rr

contains

  function func1() result(res)
    class(t), allocatable :: res
    allocate (res, source = t(77))
  end function func1

  function func2() result(res)
    class(t), allocatable :: res(:)
    allocate (res(3), source = [u(1,1.0),u(2,2.0),u(3,3.0)])
  end function func2

  function func3() result(res)
    class(t), allocatable :: res
    allocate (res, source = v(99,[99.0,99.0,99.0]))
  end function func3

  function func4() result(res)
    class(t), allocatable :: res(:)
    allocate (res(3), source = [v(3,[1.0,2.0]),v(4,[2.0,3.0]),v(5,[3.0,4.0])])
  end function func4

  function func5() result(res)
    class(v), allocatable :: res
    allocate (res, source = v(3,[10.0,20.0]))
  end function func5

  function func6() result(res)
    class(v), allocatable :: res(:)
    allocate (res(3), source = [v(3,[1.0,2.0]),v(4,[2.0,3.0]),v(5,[3.0,4.0])])
  end function func6

  function func7() result(res)
    class(v), allocatable :: res
    allocate (res, source = w(3,[10.0,20.0],[100,200]))
  end function func7

  function func8() result(res)
    class(v), allocatable :: res(:)
    allocate (res(3), source [w(3,[1.0,2.0],[0.0]),w(4,[2.0,3.0],[0.0]),w(5,[3.0,4.0],[0.0])])
  end function func8

end program test


^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-11-27 13:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-16 21:38 [Bug c++/63904] New: ICE when acessing array member of constexpr struct gcc-bugzilla at bmevers dot de
2014-11-18 10:49 ` [Bug c++/63904] ICE when accessing " paolo.carlini at oracle dot com
2014-11-18 11:26 ` ktietz at gcc dot gnu.org
2014-11-27 13:03 ` ktietz at gcc dot gnu.org
2014-11-27 13:07 ` ktietz 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).