From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108428 invoked by alias); 29 Apr 2015 08:06:07 -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 108371 invoked by uid 48); 29 Apr 2015 08:06:02 -0000 From: "juergen.reuter at desy dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call Date: Wed, 29 Apr 2015 08:06: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: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: vehre at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-04/txt/msg02490.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65548 --- Comment #32 from J=C3=BCrgen Reuter --- With gcc-6.0 trunk I cannot test our complete code because of=20 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65894 For gcc 5 trunk I have massive problems in checking out the svn at the mome= nt, 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: 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: List-Archive: List-Post: List-Help: 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" 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: 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-04/txt/msg02491.txt.bz2 Content-length: 3814 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #24 from 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?id=65837 > > --- Comment #23 from Ramana Radhakrishnan --- > (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?id=65837 > > > > > > --- 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.