Matthew Knepley <[email protected]> writes: > On Wed, May 2, 2018 at 1:14 PM, Jed Brown <[email protected]> wrote: > >> Matthew Knepley <[email protected]> writes: >> >> > On Wed, May 2, 2018 at 12:15 PM, Jed Brown <[email protected]> wrote: >> > >> >> Lisandro Dalcin <[email protected]> writes: >> >> >> >> > On Wed, 2 May 2018 at 17:29, Satish Balay <[email protected]> wrote: >> >> > >> >> >> So we need a 64bit arm with gcc8 - for this testcase failure? >> >> > >> >> > >> >> > Or a big-endian machine/OS ? >> >> >> >> Shouldn't be necessary, but why are we so concerned about making a test >> >> case fail instead of implementing correct behavior? >> >> >> > >> > How would you know your fix was correct? >> >> Documentation and/or reading assembly. > > > Its good that tests are superfluous for code you write because it conforms > to standards and > you check the assembly. We should take out all the SF tests. That would > decrease runtime.
Dude, it's nothing alike. This is about a calling convention (something not defined by the standard, and where "getting it wrong" gives undefined behavior rather than a defined error). The current configure does not attempt to get a failing test for HAVE_FORTRAN_MIXED_STR_ARG, which is the closest analogy. Your insistence on us demonstrating failing code is like being informed of an obvious security hole (e.g., unvalidated sprintf) and insisting on a working exploit before patching.
