public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Fritz Reese <fritzoreese@gmail.com>
To: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject: Ping! Re: [PATCH, Fortran] PR71523 - Static variables given automatic initializers with -finit-* and -fmax-stack-var-size
Date: Fri, 15 Jul 2016 20:32:00 -0000	[thread overview]
Message-ID: <CAE4aFAkn-2UUgUXMj2w7GO+UyAyK5XTeJcojykV2BppEjwYLMw@mail.gmail.com> (raw)

https://gcc.gnu.org/ml/fortran/2016-06/msg00032.html

I have plenty more DEC extension patches ready to submit but I've been
waiting on this one to get integrated to avoid bit rot. I'd like to
get my DEC patches through before stage 1 closes up for gcc 7 (in
about a month, right?). Can someone review/commit this (and the other
DEC extensions when they come up) please?

Thanks,

---
Fritz Reese


On Mon, Jun 13, 2016 at 12:46 PM, Fritz Reese <fritzoreese@gmail.com> wrote:
> RE: https://gcc.gnu.org/ml/fortran/2016-06/msg00023.html
>
> On Thu, Jun 9, 2016 at 2:01 PM, Fritz Reese <fritzoreese@gmail.com> wrote:
>> It looks like when -fautomatic and -finit-local-zero are set with
>> -fmax-stack-var-size=X, an automatic initializer is generated even for
>> variables larger than X which are given static storage, causing such
>> static variables to have their value re-initialized upon each entry to
>> their namespace.
>> ...
> <snip>
>
> After doing more research I noticed PR41860
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41860) was very similar
> to this issue, so I've decided this is a bug and created PR71523
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71523). Here's a patch
> for it.
>
> The bug seems to be due to an oversight - since the size of a variable
> is not known at resolution time when initializer expressions are
> applied, -finit-* is too greedy in the case that the variable is large
> enough to be removed from the stack according to -fmax-stack-var-size.
> This patch removes automatic initializers at translation time which
> were inserted by -finit-* (and inserts the appropriate static
> initializer) according to -fmax-stack-var-size.
>
> The patch passes all regression tests (on x86_64-redhat-linux),
> including the two additional tests of its own demonstrating the issue.
>
> ---
> Fritz Reese

             reply	other threads:[~2016-07-15 20:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15 20:32 Fritz Reese [this message]
2016-07-17 15:54 ` Jerry DeLisle
2016-07-18 14:03   ` Fritz Reese

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=CAE4aFAkn-2UUgUXMj2w7GO+UyAyK5XTeJcojykV2BppEjwYLMw@mail.gmail.com \
    --to=fritzoreese@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=sgk@troutmask.apl.washington.edu \
    /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: link
Be 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).