RFC -- Re: Smoke (x86_64/4 cpu)

On Fri, 21 Sep 2007 08:06 +0200, "H.Merijn Brand"
<h.m.brandxs4all.nl> wrote:

> Automated smoke report for 5.10.0 patch 31933
> pc09: Intel(R) Xeon(R) CPU E5320  1.86GHz (GenuineIntel
1596MHz) (x86_64/4 cpu)
>     on        linux - 2.6.18.8-0.5-default [SuSE]
>     using     ccache gcc version 4.1.2 20061115
(prerelease) (SUSE Linux)
>     smoketime 9 hours 45 minutes (average 29 minutes 16
seconds)

Looking at the smoke reports, this made me think that this
looks wrong!

All other smokes have a row of 'O's for the 32bit smokes,
and a row of
'X's for the 64bit smokes, so I feared that this new 64bit
PC generated
64bit objects by default. I tested, and I was correct.

So, we're too short before 5.10 to change anything now, but
we have to
make some choices here

* Do we need -Duse32bit, -Duse32bitint, and/or -Duse32bitall
to force
  what most people might expect to be the (undocumented)
default for
  for Configure when called without arguments

* Do we generate a warning and just go on in 64bit mode
(just as what
  is now done if you build perl on HP-UX with a 64bit-only
GNU gcc)

* Do we croak, exit, whatever

* Do we document this somewhere and just leave the
status-quo

At least the current smoke reports are a bit silly, as they
do NOT
reflect what the avarage smoke-report-reader expects

> Summary: FAIL(X)
> 
> O = OK  F = Failure(s), extended report at the bottom
> X = Failure(s) under TEST but not under harness
> ? = still running or test results not (yet) available
> Build failures during:       - = unknown or N/A
> c = Configure, m = make, M = make (after miniperl), t =
make test-prep
> 
>    31933     Configuration (common) none
> -----------
---------------------------------------------------------
> X X X X X X 
> X X X X X X -Duse64bitint
> X X X X X X -Duselongdouble
> X X X X X X -Dusemorebits
> X X X X X X -Duse64bitall
> X X X X X X -Duseithreads
> X X X X X X -Duseithreads -Duse64bitint
> X X X X X X -Duseithreads -Duselongdouble
> X X X X X X -Duseithreads -Dusemorebits
> X X X X X X -Duseithreads -Duse64bitall
> | | | | | +- LC_ALL = en_US.utf8 -DDEBUGGING
> | | | | +--- PERLIO = stdio -DDEBUGGING
> | | | +----- PERLIO = perlio -DDEBUGGING
> | | +------- LC_ALL = en_US.utf8
> | +--------- PERLIO = perlio
> +----------- PERLIO = stdio
> Locally applied patches:
>     DEVEL
>     SMOKE31933


-- 
H.Merijn Brand         Amsterdam Perl Mongers (http://amsterdam.pm.org/
)
using & porting perl 5.6.2, 5.8.x, 5.9.x   on HP-UX
10.20, 11.00, 11.11,
& 11.23, SuSE 10.0 & 10.2, AIX 4.3 & 5.2, and
Cygwin. http://qa.perl.org
http://mirrors.de
velooper.com/hpux/            http://www.test-smoke.org
                        http
://www.goldmark.org/jeff/stupid-disclaimers/

On 21/09/2007, H.Merijn Brand <h.m.brandxs4all.nl> wrote:
> On Fri, 21 Sep 2007 08:06 +0200, "H.Merijn
Brand" <h.m.brandxs4all.nl> wrote:
>
> > Automated smoke report for 5.10.0 patch 31933
> > pc09: Intel(R) Xeon(R) CPU E5320  1.86GHz
(GenuineIntel 1596MHz) (x86_64/4 cpu)
> >     on        linux - 2.6.18.8-0.5-default [SuSE]
> >     using     ccache gcc version 4.1.2 20061115
(prerelease) (SUSE Linux)
> >     smoketime 9 hours 45 minutes (average 29
minutes 16 seconds)
>
> Looking at the smoke reports, this made me think that
this looks wrong!
>
> All other smokes have a row of 'O's for the 32bit
smokes, and a row of
> 'X's for the 64bit smokes, so I feared that this new
64bit PC generated
> 64bit objects by default. I tested, and I was correct.
>
> So, we're too short before 5.10 to change anything now,
but we have to
> make some choices here
>
> * Do we need -Duse32bit, -Duse32bitint, and/or
-Duse32bitall to force
>   what most people might expect to be the
(undocumented) default for
>   for Configure when called without arguments

I think that adding those options would be a good idea
anyway.

> * Do we generate a warning and just go on in 64bit mode
(just as what
>   is now done if you build perl on HP-UX with a
64bit-only GNU gcc)

Since that's the platform's default configuration, that
looks like a
sensible default behaviour.

> * Do we croak, exit, whatever
>
> * Do we document this somewhere and just leave the
status-quo

But for 5.10, that should be documented (in INSTALL or in
README.linux)