public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "lopresti at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/61834] New: __attribute__((may_alias)) causes compilation error with forward-declared constructor Date: Thu, 17 Jul 2014 18:22:00 -0000 [thread overview] Message-ID: <bug-61834-4@http.gcc.gnu.org/bugzilla/> (raw) 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.
next reply other threads:[~2014-07-17 18:22 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-17 18:22 lopresti at gmail dot com [this message] 2021-07-23 1:26 ` [Bug c++/61834] " pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-61834-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).