From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38936 invoked by alias); 24 Feb 2015 08:39:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 38913 invoked by uid 48); 24 Feb 2015 08:39:36 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/65187] New: Bogus error with ASSOCIATE and deferred-length CHARACTER Date: Tue, 24 Feb 2015 09:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org 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: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter Message-ID: 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: 2015-02/txt/msg02592.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65187 Bug ID: 65187 Summary: Bogus error with ASSOCIATE and deferred-length CHARACTER Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Found at https://groups.google.com/forum/#!topic/comp.lang.fortran/AxqHqIav= LwA The following is rejected with asc: associate ( s =3D> foo ) 1 Error: Entity =E2=80=98s=E2=80=99 at (1) has a deferred type parameter and = requires either the pointer or allocatable attribute program p implicit none character(len=3D:), allocatable :: foo foo =3D "Hello World!" asc: associate ( s =3D> foo ) print *, " foo says ", s blk: block print *, " foo says ", s end block blk end associate asc stop end program p >>From gcc-bugs-return-478261-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 24 08:47:02 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 53874 invoked by alias); 24 Feb 2015 08:47:02 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 53815 invoked by uid 48); 24 Feb 2015 08:46:58 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/63890] [4.9/5 regression] Compiling trivial program with -O -p leads to misaligned stack Date: Tue, 24 Feb 2015 09:22: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: 5.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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: 2015-02/txt/msg02593.txt.bz2 Content-length: 885 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63890 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rth at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- I guess the question is, do we guarantee the standard stack alignment for the _mcount call or not? In any case, this call is very special, has different calling conventions than other functions, and sometimes (e.g. for fentry) is performed before the prologue, so even less likely to have aligned stack. So, do we want any stack guarantees for mcount and/or fentry on Linux? Similarly other OSes. Aligning stack in the callers can be of course done, but isn't without code size and performance implications.