[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

["juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #32 from Jürgen Reuter <juergen.reuter at desy dot de> ---
With gcc-6.0 trunk I cannot test our complete code because of 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
For gcc 5 trunk I have massive problems in checking out the svn at the moment,
always getting timeouts.
>From gcc-bugs-return-484939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 29 08:09:10 2015
Return-Path: <gcc-bugs-return-484939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 117379 invoked by alias); 29 Apr 2015 08:09:10 -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 113695 invoked by uid 55); 29 Apr 2015 08:09:06 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
Date: Wed, 29 Apr 2015 08:09: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: prathamesh3492 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65837-4-QncrQAeFjO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65837-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65837-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: 2015-04/txt/msg02491.txt.bz2
Content-length: 3814

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

--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 29 Apr 2015, ramana at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?ide837
>
> --- Comment #23 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #20)
> > On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?ide837
> > >
> > > --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
> > > (In reply to clyon from comment #16)
> > > > (In reply to prathamesh3492 from comment #15)
> > > >
> > > > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > > > > run_gcc().
> > > > Isn't this because you configured GCC --with-fpu=vfpv3-d16?
> > >
> > > COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
> > > /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
> > >      the compiler.  */
> > >   obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
> > >                 sizeof ("COLLECT_GCC_OPTIONS=") - 1);
> > >
> > > and at the end of set_collect_gcc_options():
> > > xputenv (XOBFINISH (&collect_obstack, char *));
> > > which makes it environment variable.
> > >
> > > set_collect_gcc_options() is called by do_spec, which is called by
> > > driver::maybe_run_linker(), before executing linker.
> > > So the driver has no knowledge of options passed at compile-time,
> > > it sets the default -mfpu=vfpv3-d16.
> > >
> > > When lto-wrapper executes,
> > > it gets linker command line options from environment variable
> > > COLLECT_GCC_OPTIONS,
> > > which contains -mfpu=vfpv3-d16.
> > > and since that was being appended after compile-time options
> > > (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
> > >
> > > This also explains why it works in one shot
> > > arm-linux-gnueabihf -flto -mfpu=neon test.c
> > >
> > > COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
> > > line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
> > >
> > > When compiler and linker are run separately, at link time, the driver has no
> > > knowledege of flags of compile-time run,
> > > and hence sets default flags in COLLECT_GCC_OPTIONS.
> > >
> > > I think correct way to fix would be in run_gcc() to get values from
> > > COLLECT_GCC_OPTIONS in decoded_options as is currently done.
> > > run_gcc() walks through options in object file and saves it in
> > > fdecoded_options. So override the value in
> > > decoded_options for the same option found in fdecoded_options.
> > > Would that be a right approach ?
> >
> > No, link-time options always override compile-time ones.
> >
> > I suspect the fix will be to somehow avoid setting defaults when linking?
>
> Well I'm not sure how easy that's going to be - You will need some amount of
> defaults to get through especially if the user hasn't provided the options in
> the first place :( .

The other option is to special-case only those options that are slipping
in that way (-march, -mtune, -mcpu, -mfpu?) and emit those always first,
hoping that explicit ones will override that.  Of course lto-wrapper
cannot distinguish between implicitely and explicitely such given
arguments at link-time.  Which means the only solution would be to
completely ignore these at link-time.

But I suspect this might break otherwise working cases (due to the fact
that which -march/-mtune/-mcpu/-mfpu options lto-wrapper chooses from
the object files is essentially "random" if they don't agree for all
objects).

It's really unfortunate that these configure-time defaults appear
as regular user command-line arguments :(  I suppose this was done
to make them visible to specs processing.