[Bug c++/61834] New: __attribute__((may_alias)) causes compilation error with forward-declared constructor

[Bug c++/61834] New: __attribute__((may_alias)) causes compilation error with forward-declared constructor

[lopresti at gmail dot com]

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

            Bug ID: 61834
           Summary: __attribute__((may_alias)) causes compilation error
                    with forward-declared constructor
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lopresti at gmail dot com

Created attachment 33135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33135&action=edit
Source file demonstrating bug with may_alias

If you compile the attached stand-alone test case with:

  g++ -S may_alias_bug.cc

...it compiles fine.

If you compile with:

  g++ -DBUG -S may_alias_bug.cc

...it produces a compilation error:

  may_alias_bug2.cc:16:8: error: prototype for ‘Thing1::Thing1(Thing2)’ does
not match any in class ‘Thing1’



This bug appears to exist at least as far back as GCC 4.4.7. The code compiles
fine with Clang and with the Intel C++ compiler, as you can see by
experimenting here: http://goo.gl/dDyljx
>From gcc-bugs-return-456665-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 17 19:14:27 2014
Return-Path: <gcc-bugs-return-456665-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3343 invoked by alias); 17 Jul 2014 19:14:26 -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 3220 invoked by uid 48); 17 Jul 2014 19:14:20 -0000
From: "juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated
Date: Thu, 17 Jul 2014 19:14: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: juergen.reuter at desy dot de
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-61831-4-C5oPomjlAB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61831-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/msg01256.txt.bz2
Content-length: 322

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

--- Comment #2 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to kargl from comment #1)
> Can you rebuild your code with compile with the -fcheck=all option?

I did. This does not change anything. And it does not give any further
information.
>From gcc-bugs-return-456666-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 17 19:19:30 2014
Return-Path: <gcc-bugs-return-456666-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10997 invoked by alias); 17 Jul 2014 19:19:30 -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 10793 invoked by uid 55); 17 Jul 2014 19:19:22 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
Date: Thu, 17 Jul 2014 19:19: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: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61320-4-T0QKm4i4cM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61320-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61320-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/msg01257.txt.bz2
Content-length: 1536

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

--- Comment #54 from rguenther at suse dot de <rguenther at suse dot de> ---
On July 17, 2014 5:50:44 PM CEST, "ebotcazou at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?ida320
>
>--- Comment #51 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
>> Ah, we also expand one from a TARGET_MEM_REF:
>>
>> ;;   basic block 76, loop depth 2
>> ;;    pred:       79
>>   load_dst_215 = MEM[base: ptr_110, offset: 0B];
>>
>> and TARGET_MEM_REF only handles the movmisalign case.  So it's either
>IVOPTs
>> not punting properly here (it does for unaligned accesses - grep for
>> STRICT_ALIGNMENT) or we need to put a bitfield extraction case into
>> TARGET_MEM_REF expansion (IMHO that's missing anyway, IVOPTs is too
>much
>> pessimized by not considering this).
>
>TARGET_MEM_REF is supposed to be a valid memory access for the target
>though
>and, by definition, an unaligned access is not valid for a strict
>alignment
>target (unless you have a movmisalign pattern), so the problem is the
>TARGET_MEM_REF.

Ivopts does not change the memory addresses, so even when not using a
target_men_ref the access will be unaligned. It's only that we had no way of
specifying whether an access is unaligned or not.  The addressing mode costs
may not reflect reality though.

Richard.
>
>If you want to make IVOPTS generate unaligned TARGET_MEM_REFs, you'll
>need to
>make sure that the costs are properly adjusted and benchmark the
>result.

[Bug c++/61834] __attribute__((may_alias)) causes compilation error with forward-declared constructor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=53725,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=49377

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed in GCC 6.1 and above.