[Bug c++/57416] New: internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575

["FBergemann at web dot de" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 57416
           Summary: internal compiler error: in gimple_expand_cfg, at
                    cfgexpand.c:4575
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: FBergemann at web dot de

Created attachment 30193
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30193&action=edit
test program main.cpp compiled in eclipse with -std=c++11

while experimenting with
http://www.drdobbs.com/cpp/access-data-items-in-ancestor-stack-fram/240155450 i
got this error here:

**** Build of configuration Debug for project RetainRecall ****

make all 
Building file: ../main.cpp
Invoking: GCC C++ Compiler
/opt/gcc-4.8.0/bin/g++ -O0 -g3 -Wall -c -fmessage-length=0 -std=c++11 -MMD -MP
-MF"main.d" -MT"main.d" -o "main.o" "../main.cpp"
../main.cpp: In constructor ‘constexpr func1(PARENTDATA&) [with PARENTDATA =
Nothing]::Data::Data()’:
../main.cpp:43:9: internal compiler error: in gimple_expand_cfg, at
cfgexpand.c:4575
  struct Data
         ^
0x655603 gimple_expand_cfg
    ../../gcc/cfgexpand.c:4575
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.
make: *** [main.o] Error 1

**** Build Finished ****
>From gcc-bugs-return-423153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 25 17:39:32 2013
Return-Path: <gcc-bugs-return-423153-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30629 invoked by alias); 25 May 2013 17:39: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 30563 invoked by uid 48); 25 May 2013 17:39:26 -0000
From: "sandra at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
Date: Sat, 25 May 2013 17:39: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: 4.7.2
X-Bugzilla-Keywords: ABI, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sandra at codesourcery dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-56564-4-hPyFzsov94@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56564-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56564-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-05/txt/msg01826.txt.bz2
Content-length: 1681

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

Sandra Loosemore <sandra at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandra at codesourcery dot com

--- Comment #11 from Sandra Loosemore <sandra at codesourcery dot com> ---
This affects at least PowerPC, too, which implements DATA_ALIGNMENT to add
additional alignment beyond that specified by the ABI.

Isn't TYPE_ALIGN already supposed to return the ABI-mandated alignment for
objects of a given type?  The documentation for DATA_ALIGNMENT already suggests
that its purpose is to add additional alignment for optimization purposes and I
suspect other targets may be using it that way, too.  Perhaps what's needed
here is more careful monitoring of the places where DATA_ALIGNMENT is being
used, rather than splitting it into two macros or adding an argument to control
the two uses.  Or at least, we'd have to clarify how the requirements for the
ABI-conforming use of DATA_ALIGNMENT differ from what TYPE_ALIGN is supposed to
do.

It seems to me that DATA_ALIGNMENT's original purpose was to add additional
alignment on variable definitions, and IIUC the problem now is either that it
is being used in other contexts or that its intended use is not taking into
account common, weak, and/or comdat definitions where the linker may substitute
a less-aligned definition from another compilation unit.

Also, somebody should check whether vect_can_force_dr_alignment_p in
tree-vect-data-refs.c is catching all the cases it needs to for ABI
conformance.