[PATCH] testsuite: mips: use noinline attribute instead of -fno-inline

Xi Ruoyao xry111@mengyan1223.wang
Fri Jul 9 06:42:58 GMT 2021


On Thu, 2021-07-08 at 17:44 -0600, Jeff Law wrote:
> 
> 
> On 6/25/2021 8:40 AM, Richard Sandiford wrote:
> > Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > > On Fri, 2021-06-25 at 01:02 +0800, Xi Ruoyao wrote:
> > > > On Thu, 2021-06-24 at 10:48 -0600, Jeff Law wrote:
> > > > > I'd like to know a bit more here.  mips.exp shouldn't care
> > > > > about the
> > > > > options passed to the compiler and to the best of my knowledge
> > > > > patch itself is wrong, I question if it's necessary and
> > > > > whether or
> > > > > not
> > > > > your just papering over some other issue.
> > > > There is some logic processing options in mips.exp.  Some
> > > > options are
> > > > overrided for multilib.  It seems the mips.exp was originally
> > > > designed
> > > > as:
> > > > 
> > > > * MIPS options should go in dg-options
> > > > * Other options should go in dg-additional-options
> > > > 
> > > > In d2148424165 marxin merged some dg-additional-options into dg-
> > > > options,
> > > > exploited the problem.
> > > > 
> > > > And, the "origin" convention seems already broken: there is
> > > > something
> > > > like -funroll-loops which is not a MIPS option, but accepted by
> > > > mips.exp
> > > > in dg-options.
> > > > 
> > > > Possiblities are:
> > > > 
> > > > (1) this patch
> > > > (2) make mips.exp accept -fno-inline as "if it is a MIPS option"
> > > > (3) refactor mips.exp to pass everything itself doesn't know
> > > > directly
> > > > to gcc
> > > Attached a diff for mips.exp trying to make it pass everything in
> > > dg-
> > > options which is not known by itself directly to the compiler.
> > > 
> > > The "smallest fix" is simply adding -fno-inline into mips.exp. 
> > > However
> > > I don't like it because I agree with you that mips.exp shouldn't
> > > care
> > > about dg-options, at least don't do it too much.
> > As I said in the other message, I think the smallest fix is the way
> > to
> > go though.
> THanks for chiming in Richard.  I didn't know all the background
> here.   
> Let's just go with the small fix based on your recommendation.  We can
> always revisit if we keep running into issues in this code.

Pushed at 3b33b113.



More information about the Gcc-patches mailing list