[Bug fortran/54120] New: [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[Bug fortran/54120] New: [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

             Bug #: 54120
           Summary: [4.8 Regression] FAIL:
                    gfortran.fortran-torture/execute/random_2.f90
                    execution
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: danglin@gcc.gnu.org
              Host: hppa*-*-* (32-bit)
            Target: hppa*-*-* (32-bit)
             Build: hppa*-*-* (32-bit)


Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-
torture/execute/random_2.f90  -fno-diagnostics-show-caret  -w  -O0  
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs      -o
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/random_2.x    (timeout = 300)spawn
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execu
te/random_2.f90 -fno-diagnostics-show-caret -w -O0
-B/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -o
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/random_2.x
PASS: gfortran.fortran-torture/execute/random_2.f90 compilation,  -O0 
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc
spawn [open ...]

Backtrace for this error:
#0  0xC1D3A1BB
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O0 

FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O1 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2
-fomit-frame
-pointer -finline-functions 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2
-fomit-frame
-pointer -finline-functions -funroll-loops 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O2
-fbounds-che
ck 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -O3 -g 
FAIL: gfortran.fortran-torture/execute/random_2.f90 execution,  -Os 

Problem was introduced between 189245 (ok) and 189394.

[Bug fortran/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steven at gcc dot gnu.org

--- Comment #1 from John David Anglin <danglin at gcc dot gnu.org> 2012-07-30 20:55:42 UTC ---
Introduced in 189366.  Does this change affect recog_memoized?

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org
          Component|fortran                     |middle-end
   Target Milestone|---                         |4.8.0

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-07-31 14:50:09 UTC ---
(In reply to comment #1)
> Introduced in 189366.  Does this change affect recog_memoized?

That's the following commit:

Author: steven
Date: Mon Jul  9 08:45:12 2012
New Revision: 189366

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189366
Log:
    * gensupport.c (init_rtx_reader_args_cb): Start counting code
    generating patterns from 1 to free up 0 for CODE_FOR_nothing.
    * gencodes.c (main): Give CODE_FOR_nothing the value 0.  Add
    the LAST_INSN_CODE marker at the end.
    * genoutput.c (nothing): New static struct data.
    (idata): Initialize to &nothing.
    (idata_end): Initialize to &nothing.next.
    (init_insn_for_nothing): New function to create dummy 'nothing' insn.
    (main): Use it.
    * genpeep.c (insn_code_number): Remove global variable.
    (gen_peephole): Take it as an argument instead.
    (main): Take insn_code_number from read_md_rtx.
    * optabs.h: Revert r161809:
    (optab_handlers): Change type of insn_code back to insn_code.
    (optab_handler, widening_optab_handler, set_optab_handler,
    set_widening_optab_handler, convert_optab_handler,
    set_convert_optab_handler, direct_optab_handler,
    set_direct_optab_handler): Remove int casts.
    Revert to treating the insn_code field as "insn_code".

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gencodes.c
    trunk/gcc/genoutput.c
    trunk/gcc/genpeep.c
    trunk/gcc/gensupport.c
    trunk/gcc/optabs.h

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-19 10:54:42 UTC ---
I don't see any code differences on random_2.f90 with x86_64-linux ->
hppa2.0w-hp-hpux11.11 crosses r189365 vs. r189366, -O0 or -O2.
The r189366 changes needed a follow-up:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189672
but that certainly doesn't affect this testcase.
Or is it libgfortran itself that when built with r189365 works and when r189366
doesn't?  If so, can you find where are the code differences?

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #4 from dave.anglin at bell dot net 2012-12-19 12:58:32 UTC ---
On 19-Dec-12, at 5:54 AM, jakub at gcc dot gnu.org wrote:

> Or is it libgfortran itself that when built with r189365 works and  
> when r189366
> doesn't?  If so, can you find where are the code differences?

I'll try and debug this regression as soon as I can but it might not  
be until the weekend.

--
John David Anglin    dave.anglin@bell.net

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #5 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-22 23:00:21 UTC ---
As might have been expected, libgfortran/random.o differs between revisions
189365 and 189366.  Even in the .i files, there are many differences.  For
example,

# diff -u random.i /test/gnu/gcc/objdir-189366/hppa2.0w-hp-hpux11.11/libgfortr>
--- random.i    Sat Dec 22 17:25:17 2012
+++ /test/gnu/gcc/objdir-189366/hppa2.0w-hp-hpux11.11/libgfortran/random.i     
Sat Dec 22 17:27:36 2012
@@ -8,26 +8,26 @@
 # 1 "./config.h" 1
 # 43 "../../../gcc/libgfortran/libgfortran.h" 2

-# 1 "/test/gnu/gcc/objdir/gcc/include-fixed/stdio.h" 1 3 4
-# 14 "/test/gnu/gcc/objdir/gcc/include-fixed/stdio.h" 3 4
-# 1 "/test/gnu/gcc/objdir/gcc/include/stdarg.h" 1 3 4
-# 41 "/test/gnu/gcc/objdir/gcc/include/stdarg.h" 3 4
+# 1 "/test/gnu/gcc/objdir/./gcc/include-fixed/stdio.h" 1 3 4
+# 14 "/test/gnu/gcc/objdir/./gcc/include-fixed/stdio.h" 3 4
+# 1 "/test/gnu/gcc/objdir/./gcc/include/stdarg.h" 1 3 4
+# 41 "/test/gnu/gcc/objdir/./gcc/include/stdarg.h" 3 4

There are also many differences in the .s files.

I see this with bootstrap disabled.

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #6 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-22 23:01:46 UTC ---
Created attachment 29031
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29031
.s file difference

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-22 23:06:42 UTC ---
Can you please attach random.i and what exact gcc options were used to compile
random.c ?

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #8 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-22 23:35:02 UTC ---
Created attachment 29032
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29032
Preprocessed source from r189366

Compilation command:

/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../../../gcc/libgfortran/../libquadmath -I../.././gcc
-I../../../gcc/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite-strings -fcx-fortran-rules -g -O2 -MT random.lo -MD -MP -MF
.deps/random.Tpo -c ../../../gcc/libgfortran/intrinsics/random.c -o random.o

# ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.8
--with-gmp=/opt/gnu/gcc/gmp --enable-threads=posix --enable-debug=no
--disable-nls --disable-lto --without-cloog --without-ppl
--enable-languages=fortran --disable-bootstrap
Thread model: posix
gcc version 4.8.0 20120709 (experimental) [trunk revision 189366] (GCC)

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #9 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-22 23:38:11 UTC ---
Created attachment 29033
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29033
Preprocessed source from r189365

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-07 14:51:26 UTC ---
I don't see any differences in assembly, when I compile either version of
random.i with -std=gnu99 -fcx-fortran-rules -g -O2 with a r189365 vs. r189366
x86_64-linux -> hppa2.0w-hp-hpux11.11 cross.  Can try i686-linux ->
hppa2.0w-hp-hpux11.11 cross in case it is HWINT related...

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-07 16:34:14 UTC ---
Ah, ok, seems indeed to be HWI size related and also (due to an earlier bug)
related to the revision you've mentioned.
So, with an i686-linux -> hppa2.0w-hp-hpux11.11 cross this is reproduceable
with -O2 on:
extern unsigned int *kiss_seed_1;
extern unsigned int *kiss_seed_2;
unsigned int kiss_random_kernel(unsigned int * seed);

void
foo (double *x)
{
  unsigned long long mask, kiss = ((unsigned long long) kiss_random_kernel
(kiss_seed_1)) << 32;
  kiss += kiss_random_kernel (kiss_seed_2);
  mask = ~ (unsigned long long) 0u << (64 - 53);
  kiss = kiss & mask;
  *x = (double) kiss * (0x1.p-64);
}

and the problem is that starting with r189366 VRP incorrectly does:
   kiss_9 = kiss_8 & 0xfffffffffffff800;
-  D.1358_10 = (double) kiss_9;
+  D.1363_17 = (signed int) kiss_9;
+  D.1358_10 = (double) D.1363_17;

The bugs seem to be in simplify_float_conversion_using_ranges and
range_fits_type_p.  The simplify_float_conversion_using_ranges bug (now just
code consistency issue, before r189366 a real bug) is that the second
can_float_p is tested for != 0 (implicitly) instead of != CODE_FOR_nothing.
Starting with r189366 it doesn't make a real difference, before that
CODE_FOR_nothing was some big number and this fact hid the other bug.

>From the kiss_9 assignment, VRP determines vr to be
[0, 0xfffffffffffff800]
(in unsigned long long type).

And now the bug is that while range_fits_type_p (vr, 8, 0) and
range_fits_type_p (vr, 64, 0) correctly return false, such big 64-bit range
really doesn't fit into signed 8-bit or signed 64-bit range,
range_fits_type_p (vr, 16, 0) and range_fits_type_p (vr, 32, 0) incorrectly
return true - and for floatsidf2 there is a pattern, which is why we miscompile
it.

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-07 17:27:56 UTC ---
Created attachment 29100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29100
gcc48-pr54120.patch

So, I wrote a fix against r189366, only to find out that Richard Sandiford
already fixed it the same way (just different comment):
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194800

I'm thus attaching just the unimportant other two changes (unimportant because
right now range_fits_type_p is always called with unsigned_p = false (so the
first problem never happens, the issue is that while say unsigned 8-bit
src_type always fits into signed 16-bit, the same isn't true for signed 8-bit
src_type and unsigned 16-bit - if min or max is negative in the signed type, it
won't fit).
And the second issue is after r189366 only pure consistency issue, as
CODE_FOR_nothing is always 0.

I'd say after with r194800 or later you shouldn't get this failure.

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[dave.anglin at bell dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #13 from dave.anglin at bell dot net 2013-01-07 18:09:29 UTC ---
On 1/7/2013 12:27 PM, jakub at gcc dot gnu.org wrote:
> I'd say after with r194800 or later you shouldn't get this failure.
Yes, the failure is gone.  So, PR can be closed when secondary issues
are resolved.

Thanks,
Dave

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-08 08:33:50 UTC ---
Author: jakub
Date: Tue Jan  8 08:33:43 2013
New Revision: 195007

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195007
Log:
    PR tree-optimization/54120
    * tree-vrp.c (range_fits_type_p): Don't allow
    src_precision < precision from signed vr to unsigned_p
    if vr->min or vr->max is negative.
    (simplify_float_conversion_using_ranges): Test can_float_p
    against CODE_FOR_nothing.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vrp.c

[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-08 09:08:58 UTC ---
Fixed.