Re: [PATCH] almost-trivial fix for MIPS -mlong64 + -membedded-pic

[cgd at sibyte dot com (Chris G. Demetriou)]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> There are scan-assembler and scan-assembler-not, but simplest might be to
> put it in gcc.c-torture/execute, and the problem would show up if anyone
> does run c-torture with appropriate target configuration, options and
> libraries.

I looked at the gcc.c-torture/execute tests to see what all i'd have
to do to add a new test there.  ("that's pretty easy..." 8-)

Anyway, while doing this i found 20010106-1.c which looks like the
problem sample i provided.  I assembled it, and traced through the
resulting code and indeed, it is an adequate test case for the
problem.  ("that's even easier!" 8-)


> (I'd hope people do run the testsuite for their embedded target and
> option combinations - more posted testresults for such
> configurations would be good - and track down failures relative to
> similar hosted configurations, if the CPU is used for both.)

So, the problem that I have with this is, it's very easy to have minor
changes (esp. w.r.t. configuration) creep into one's set of tool
sources, and you don't want to submit test results that are bogus
because of those mods.

Also, in cases like this, the whole setup and e.g. runtime would have
to be ... rather nonstandard, and so it's especially hard to make sure
that the bugs reported are really GCC's fault...

What's reasonable in this regard?



chris