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

* [Bug c++/63904] ICE when accessing array member of constexpr struct
  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 ` paolo.carlini at oracle dot com
  2014-11-18 11:26 ` ktietz at gcc dot gnu.org
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: paolo.carlini at oracle dot com @ 2014-11-18 10:49 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-18
             Blocks|                            |55004
            Summary|ICE when acessing array     |ICE when accessing array
                   |member of constexpr struct  |member of constexpr struct
     Ever confirmed|0                           |1


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

* [Bug c++/63904] ICE when accessing array member of constexpr struct
  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
  3 siblings, 0 replies; 5+ messages in thread
From: ktietz at gcc dot gnu.org @ 2014-11-18 11:26 UTC (permalink / raw)
  To: gcc-bugs

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #1 from Kai Tietz <ktietz at gcc dot gnu.org> ---
It seems to be related to constexpr.c:cxx_eval_vec_init_1 function.  The line '
int max = tree_to_shwi (array_type_nelts (atype));' there should be changed
into 'int max = (int) tree_to_uhwi (array_type_nelts (atype));'.

Issue is that array_type_netls returns size_type node (which is unsigned) with
UHWI_MAX as value.  Means that on conversions the value won't fit into shwi. 
By reading value as unsigned and then later on casting it to signed (btw
shouldn't we use here instead HOST_WIDE_INT?), we solve this issue.


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

* [Bug c++/63904] ICE when accessing array member of constexpr struct
  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
  3 siblings, 0 replies; 5+ messages in thread
From: ktietz at gcc dot gnu.org @ 2014-11-27 13:03 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Kai Tietz <ktietz at gcc dot gnu.org> ---
Author: ktietz
Date: Thu Nov 27 13:02:45 2014
New Revision: 218123

URL: https://gcc.gnu.org/viewcvs?rev=218123&root=gcc&view=rev
Log:
2014-11-27  Kai Tietz  <ktietz@redhat.com>

    PR c++/63904
    * constexpr.c (cxx_eval_vec_init_1): Avoid
    type-overflow issue.


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


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

* [Bug c++/63904] ICE when accessing array member of constexpr struct
  2014-11-16 21:38 [Bug c++/63904] New: ICE when acessing array member of constexpr struct gcc-bugzilla at bmevers dot de
                   ` (2 preceding siblings ...)
  2014-11-27 13:03 ` ktietz at gcc dot gnu.org
@ 2014-11-27 13:07 ` ktietz at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: ktietz at gcc dot gnu.org @ 2014-11-27 13:07 UTC (permalink / raw)
  To: gcc-bugs

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> ---
So fixed.


^ 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).