[Bug fortran/38946] New: gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[Bug fortran/38946] New: gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

I built gcc and submitted a Test Report here:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02341.html
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02197.html 

...
=== gfortran tests ===
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution
test
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/array_constructor_23.f -O3 -g execution test
...


When I view the log I see this (dupe blank lines removed):

Executing on host:
/usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran
-B/usr/share/src/gcc_build/gcc/testsui$
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03:13.26:

    CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [(" ", i = 1, MAXFLD)]

                          1

Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type

/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03:13.15:

    CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [(" ", i = 1, MAXFLD)]

               1

Error: Character length of component 'dwfdhd' needs to be a constant
specification expression at (1)

compiler exited with status 1



/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03:11.14:

  character (a) :: arr (1) = [ "a" ]

              1

Error: Symbol 'a' at (1) has no IMPLICIT type

/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03:11.13:

  character (a) :: arr (1) = [ "a" ]

             1

Error: Character length of component 'arr' needs to be a constant specification
expression at (1)



/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_28.f03:8.35:

  character (2) :: arr (2) = [ "a", "ab" ] ! { dg-error "Different CHARACTER" }

                                   1

Error: Different CHARACTER lengths (1/2) in array constructor at (1)

compiler exited with status 1



FAIL: gfortran.dg/default_format_denormal_2.f90  -Os  execution test
Executing on host:
/usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran
-B/usr/share/src/gcc_build/gcc/testsui$
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/default_initialization_1.f90:17.34:

   type (default_initialization) t ! { dg-error "default initialization" }

                                  1

Error: Object 't' at (1) must have the SAVE attribute for default
initialization of a component

compiler exited with status 1



Executing on host:
/usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran
-B/usr/share/src/gcc_build/gcc/testsui$
/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/defined_operators_1.f90:14.69:

     module procedure foo_1_OK  ! { dg-error "Ambiguous interfaces" }

                                                                     1

Error: Ambiguous interfaces 'foo_1_ok' and 'foo_1' in operator interface 'foo'
at (1)

/usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/defined_operators_1.f90:20.23:

     subroutine bad_foo (chr) ! { dg-error "must be a FUNCTION" }

                       1

Error: User operator procedure 'bad_foo' at (1) must be a FUNCTION

...


There were far fewer errors here, these issues are a week old:

Results for 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html

Thanks,
Rob


-- 
           Summary: gcc trunk 143562 - Testsuite - gfortran failing tests
                    that worked previously
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug fortran/38946] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[mikael at gcc dot gnu dot org]

------- Comment #1 from mikael at gcc dot gnu dot org  2009-01-23 20:04 -------
(In reply to comment #0)
> === gfortran tests ===
> FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution
> test
> FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer
> -funroll-loops execution test
> FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer
> -funroll-all-loops -finline-functions execution test
> FAIL: gfortran.dg/array_constructor_23.f -O3 -g execution test
Those were failing in your previous report too. ;)

> When I view the log I see this (dupe blank lines removed):
> 
> Executing on host:
> /usr/share/src/gcc_build/gcc/testsuite/gfortran/../../gfortran
> -B/usr/share/src/gcc_build/gcc/testsui$
> /usr/share/src/gcc_trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03:13.26:
> 
>     CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [(" ", i = 1, MAXFLD)]
> 
>                           1
> 
> Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type
>
This error (like the others) is expected: we test that the compiler gives the
expected output. Look for lines starting with FAIL for real failures. 
But as they are run-time, it won't help probably. 


Quite many of the newly-failing tests are about I/O; I suspect the following to
be the culprit. 
Could you try before/after this?

------------------------------------------------------------------------
r143462 | pault | 2009-01-17 12:32:02 +0100 (sam. 17 janv. 2009) | 17 lines

2009-01-17  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/34955
        * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer):


Note that some of the tests require specific features (such as denormalized
long doubles) and are x-failed(which means: known to fail) on some targets or
have some dg-require-effective-targets conditions on them. Thus, maybe the
correct behaviour for these tests is to fail on solaris. 


-- 


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

[Bug fortran/38946] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #2 from rob1weld at aol dot com  2009-01-25 16:59 -------
(In reply to comment #1)
> (In reply to comment #0)
> > === gfortran tests ===
> > FAIL: gfortran.dg/array_constructor_23.f -O3 -fomit-frame-pointer execution
> > ...
> > 
> > Error: Symbol 'max_fld_hed' at (1) has no IMPLICIT type
> >
> This error (like the others) is expected: we test that the compiler gives the
> expected output. Look for lines starting with FAIL for real failures. 
> But as they are run-time, it won't help probably. 
> 
> 
> Quite many of the newly-failing tests are about I/O; I suspect the following > to be the culprit. Could you try before/after this?
> 
> ------------------------------------------------------------------------
> r143462 | pault | 2009-01-17 12:32:02 +0100 (sam. 17 janv. 2009) | 17 lines
> 2009-01-17  Paul Thomas  <pault@gcc.gnu.org>
>         PR fortran/34955
>         * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer):
> ...
> Note that some of the tests require specific features (such as denormalized
> long doubles) and are x-failed(which means: known to fail) on some targets or
> have some dg-require-effective-targets conditions on them. Thus, maybe the
> correct behaviour for these tests is to fail on solaris. 
> 

They worked last week.

I am in favor of them working again and enabling, rather than disabling,
as many features as possible. That includes both in gcc and in the Testsuite.
I don't use Fortran but will offer a little assistance if I can. 

Here is my most recent test. Above you ask "Could you try before/after this"
do you mean compile and run the Testuite on bothboth "r143461" and "r143463"?


Results for 4.4.0 20090125 (experimental) [trunk revision 143660] (GCC)
testsuite on i386-pc-solaris2.11
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02585.html


Thanks for fixing this,
Rob


-- 


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

[Bug fortran/38946] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #3 from rob1weld at aol dot com  2009-01-25 17:35 -------
# ./e_d_fmt.exe
Abort (core dumped)

# ldd ./e_d_fmt.exe
        libgfortran.so.3 =>     
/usr/share/src/gcc_build/i386-pc-solaris2.11/./libgfortran/.libs/libgfortran.so.3
        libm.so.2 =>     /usr/lib/libm.so.2
        libgcc_s.so.1 =>         /usr/share/src/gcc_build/gcc/libgcc_s.so.1
        libc.so.1 =>     /usr/lib/libc.so.1

# export set
LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/opt/csw/lib:/usr/local/Trolltech/Qt-4.4.3/lib

# ldd ./e_d_fmt.exe
        libgfortran.so.3 =>      /usr/local/lib/libgfortran.so.3
        libm.so.2 =>     /usr/lib/libm.so.2
        libgcc_s.so.1 =>         /usr/local/lib/libgcc_s.so.1
        libc.so.1 =>     /usr/lib/libc.so.1

If I use the Testsuite's LD_LIBRARY_PATH then some of the Tests will
load the wrong Libraries. If I use _my_ own LD_LIBRARY_PATH (as it is
during configuration) then the Test programs use the correct Libraries
and the programs run OK.

In http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg01790.html we only
had array_constructor_23.f now we seem to have a few more.

This is not so much an error in Fortran than it is an error in the
scripting and it's ability to add it's own LD_LIBRARY_PATH components.

Reducing the Severity to NORMAL.

Thanks,
Rob


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


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

[Bug fortran/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[mikael at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]



------- Comment #4 from mikael at gcc dot gnu dot org  2009-01-26 18:42 -------
(In reply to comment #3)
> This is not so much an error in Fortran than it is an error in the
> scripting and it's ability to add it's own LD_LIBRARY_PATH components.
No. The current linking scheme links to the just-built libgfortran, not to the
system libgfortran. This is fine, because it is the newly built library that we
want to test. 

> They worked last week.
Sure, this is a regression. 

> Here is my most recent test. Above you ask "Could you try before/after this"
> do you mean compile and run the Testuite on bothboth "r143461" and "r143463"?
Yes. But to save time you can update only fortran or libgfortran and narrow the
testsuite run to the failing tests using the RUNTESTFLAGS variable as explained
here http://gcc.gnu.org/wiki/TestCaseWriting
Furthermore, as your tests show that the failure is in the libgfortran, there
is only one commit in that area in the window you gave (r143454-r143562): 

------------------------------------------------------------------------
r143541 | domob | 2009-01-21 14:34:55 +0100 (mer. 21 janv. 2009) | 29 lines

I don't know though how this could cause system-dependent failures :-(. Daniel?

> Thanks for fixing this,
Thanks for helping to fix this. 


-- 

mikael at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|gcc trunk 143562 - Testsuite|[trunk regression] gcc trunk
                   |- gfortran failing tests    |143562 - Testsuite -
                   |that worked previously      |gfortran failing tests that
                   |                            |worked previously


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

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-26 19:28 -------
! Test XFAILed on these platforms because the system's printf() lacks
! proper support for denormalized long doubles. See PR24685


Looks like this testcase should be xfailed on solaris also.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |testsuite


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

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #6 from rob1weld at aol dot com  2009-01-27 15:50 -------
Here is a newer result on Fedora 10:

                === gfortran tests ===

Running target unix

                === gfortran Summary ===

# of expected passes            29107
# of expected failures          14
# of unsupported tests          113
/mnt/drive2/gcc_build/gcc/testsuite/gfortran/../../gfortran  version 4.4.0
20090126 (experimental) [trunk revision 143680] (GCC) 

# grep FAIL /mnt/drive2/gcc_build/gcc/testsuite/gfortran/gfortran.log | grep -v
XFAIL
# grep FAIL /mnt/drive2/gcc_build/gcc/testsuite/gfortran/gfortran.log | wc -l
14


It works OK (now) on i386-redhat-linux-* .

Rob


-- 


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

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #7 from rob1weld at aol dot com  2009-01-27 16:00 -------
(In reply to comment #5)
> ! Test XFAILed on these platforms because the system's printf() lacks
> ! proper support for denormalized long doubles. See PR24685
> 
> Looks like this testcase should be xfailed on solaris also.
> 

Eric says PR24685 works on "Solaris" (which is not the same OS as mine):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685#c27

Should libiberty test if the printf() fails and replace it we a better one?

Rob


-- 


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

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #8 from rob1weld at aol dot com  2009-01-27 16:18 -------
(In reply to comment #4)
> (In reply to comment #3)
> > This is not so much an error in Fortran than it is an error in the
> > scripting and it's ability to add it's own LD_LIBRARY_PATH components.
> No. The current linking scheme links to the just-built libgfortran, not to
> the system libgfortran. This is fine, because it is the newly built library
> that we want to test. 

No. It is the same library since I type "make install" before I type "make
-i check".


> > They worked last week.
> Sure, this is a regression. 

I installed cloog in /usr/local on F10 and needed to use LD_LIBRARY_PATH
on this platform also. On i386-redhat-linux we don't have any trouble.


> > Here is my most recent test. Above you ask "Could you try before/after this"
> > do you mean compile and run the Testuite on both "r143461" and "r143463"?
> Yes. But to save time you can update only fortran or libgfortran and narrow
> the testsuite run to the failing tests using the RUNTESTFLAGS variable as
> explained here http://gcc.gnu.org/wiki/TestCaseWriting

OK, I'll be back on my OpenSolaris platform tomorrow.


> Furthermore, as your tests show that the failure is in the libgfortran, there
> is only one commit in that area in the window you gave (r143454-r143562): 
> 
> ------------------------------------------------------------------------
> r143541 | domob | 2009-01-21 14:34:55 +0100 (mer. 21 janv. 2009) | 29 lines
> 
> I don't know though how this could cause system-dependent failures :-(. Daniel?

No reply.


> > Thanks for fixing this,
> Thanks for helping to fix this. 

One piece at a time ...

Rob


-- 


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

Re: [Bug testsuite/38946] [trunk regression]?gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[DJ Delorie]

I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[dj at redhat dot com]

------- Comment #9 from dj at redhat dot com  2009-01-27 19:38 -------
Subject: Re:  [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously


I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.


-- 


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

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #10 from rob1weld at aol dot com  2009-01-27 22:28 -------
(In reply to comment #1)
Note that some of the tests require specific features (such as denormalized
long doubles) and are ...


(In reply to comment #4)
> (In reply to comment #3)
> > This is not so much an error in Fortran than it is an error in the
> > scripting and it's ability to add it's own LD_LIBRARY_PATH components.
> No. The current linking scheme links to the just-built libgfortran, not to the
> system libgfortran. This is fine, because it is the newly built library that > we want to test. 
> 
...

> I don't know though how this could cause system-dependent failures :-(. Daniel?


How about this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38820
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443#c36

Rob


-- 


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

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #11 from rob1weld at aol dot com  2009-01-27 22:45 -------
(In reply to comment #9)
> Subject: Re:  [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
> failing tests that worked previously
> 
> 
> I think adding a printf() clone to libiberty is WAY overkill just to
> silence one failing test.

Two alternatives are:

1. A POSIX compliant Testsuite to check gcc libraries. Any program, on
any platform, using (new) gcc _must_ printf() the _same_ output under
any circumstances.

2. Incorrect operation.


Sometimes there is "one failing test" because the Testsuite Coverage
is poor (and we hope more Tests will be forthcoming).

RFE - Need Makefile to test coverage of Testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38833

By the term "Testsuite Coverage" I mean both in that the tests that we 
do have do not fully exercise the features they test _and_ also that
we do not test all possible features but instead we slack off and
simply disable the Tests (as is being suggested in this Thread).

I believe Bug 36443 should be investigated first but failing that
is it not the place of Libiberty to fix what GNU believes is broken?

Wave @ DJ (net-acquaintance of 25+ years),
Rob


-- 


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

[Bug testsuite/38946] [trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #12 from rob1weld at aol dot com  2009-01-27 23:26 -------
(In reply to comment #11)
> (In reply to comment #9)
> Two alternatives are:
I guess there is three.

3. The gcc Testsuite is testing 'outside of gcc' and exercising the
libraries of the Operating System (maybe GNU libc / libmath, maybe not).

Features of the Operating System are checked for in ./configure and
compensated for with: 1. alternate source, 2. "#ifdef"s, 3. Libiberty.

Using the Testsuite to check outside the scope of the Testsuite is not
valid and should be removed _OR_ at the very least we should split this
into a different test and have it excluded on all platforms that do not
support this ONE Operating System specific feature.

That course of action means that other system libraries would also
need to be excluded. You would not want to test Sun's libm for errors,
compare that with any other library, and on that basis determine that
the gcc Testsuite passed or failed.

Rob


-- 


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

[Bug testsuite/38946] [4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]



------- Comment #13 from rob1weld at aol dot com  2009-01-27 23:47 -------
This post: http://gcc.gnu.org/ml/gcc/2008-12/msg00135.html says:

To get on the radar regressions have to be marked [4.4 Regression],
with the target milestone set to 4.4.0 ...


Changing "Summary" from / to:

[trunk regression] gcc trunk 143562 - Testsuite - gfortran failing tests that
worked previously

[4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that
worked previously

I do not have permission to change "Milestone" on my own Bug Report
from none to 4.4.0 - could someone do that please (if you can fix my 
bits please do ;).

Thanks,
Rob


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[trunk regression] gcc trunk|[4.4 Regression] gcc trunk
                   |143562 - Testsuite -        |143562 - Testsuite -
                   |gfortran failing tests that |gfortran failing tests that
                   |worked previously           |worked previously


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

[Bug testsuite/38946] [4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #14 from rob1weld at aol dot com  2009-01-29 12:32 -------
(In reply to comment #5)
> ! Test XFAILed on these platforms because the system's printf() lacks
> ! proper support for denormalized long doubles. See PR24685
> Looks like this testcase should be xfailed on solaris also.

(In reply to comment #9)
> Subject: Re:  [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
> failing tests that worked previously
> I think adding a printf() clone to libiberty is WAY overkill just to
> silence one failing test.

I took a look around for some existing tests that could help us.


The files: 
gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-* 
gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-* 
are setup only for mingw. I added OpenSolaris and got this result:

Mod:
/* { dg-do compile { target { *-*-mingw* } } } */
/* { dg-do compile { target { *-*-mingw* *-*-solaris2.11* } } } */


Result:

FAIL: gcc.dg/format/ms_c90-printf-1.c   (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-1.c:56:
warning: use of 'h' length modifier with 'c' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-1.c:57:
warning: use of 'h' length modifier with 's' type character

FAIL: gcc.dg/format/ms_c90-printf-2.c   %hh is unsupported (test for warnings,
line 17)
FAIL: gcc.dg/format/ms_c90-printf-2.c   %j is unsupported (test for warnings,
line 19)
FAIL: gcc.dg/format/ms_c90-printf-2.c   %z is unsupported (test for warnings,
line 20)
FAIL: gcc.dg/format/ms_c90-printf-2.c   %t is unsupported (test for warnings,
line 21)
FAIL: gcc.dg/format/ms_c90-printf-2.c   (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:17:
warning: ISO C90 does not support the 'hh' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:18:
warning: format '%I64d' expects type 'int', but argument 2 has type 'llong'
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:19:
warning: ISO C90 does not support the 'j' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:20:
warning: ISO C90 does not support the 'z' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:21:
warning: ISO C90 does not support the 't' gnu_printf length modifier

FAIL: gcc.dg/format/ms_c90-printf-2.c  -DWIDE  %hh is unsupported (test for
warnings, line 17)
FAIL: gcc.dg/format/ms_c90-printf-2.c  -DWIDE  %j is unsupported (test for
warnings, line 19)
FAIL: gcc.dg/format/ms_c90-printf-2.c  -DWIDE  %z is unsupported (test for
warnings, line 20)
FAIL: gcc.dg/format/ms_c90-printf-2.c  -DWIDE  %t is unsupported (test for
warnings, line 21)
FAIL: gcc.dg/format/ms_c90-printf-2.c  -DWIDE  (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:17:
warning: ISO C90 does not support the 'hh' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:18:
warning: format '%I64d' expects type 'int', but argument 2 has type 'llong'
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:19:
warning: ISO C90 does not support the 'j' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:20:
warning: ISO C90 does not support the 'z' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-printf-2.c:21:
warning: ISO C90 does not support the 't' gnu_printf length modifier

FAIL: gcc.dg/format/ms_c90-scanf-1.c   %L is unsupported (test for warnings,
line 75)
FAIL: gcc.dg/format/ms_c90-scanf-1.c   %L is unsupported (test for warnings,
line 76)
FAIL: gcc.dg/format/ms_c90-scanf-1.c   %L is unsupported (test for warnings,
line 77)
FAIL: gcc.dg/format/ms_c90-scanf-1.c   %L is unsupported (test for warnings,
line 78)
FAIL: gcc.dg/format/ms_c90-scanf-1.c   %L is unsupported (test for warnings,
line 79)
FAIL: gcc.dg/format/ms_c90-scanf-1.c   (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:56:
warning: use of 'h' length modifier with 's' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:58:
warning: use of 'h' length modifier with 'c' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:75:
warning: use of 'L' length modifier with 's' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:76:
warning: use of 'L' length modifier with '[' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:77:
warning: use of 'L' length modifier with 'c' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:78:
warning: use of 'L' length modifier with 'p' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-scanf-1.c:79:
warning: use of 'L' length modifier with 'n' type character

FAIL: gcc.dg/format/ms_c90-strftime-2.c   (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-strftime-2.c:15:
warning: '%D' yields only last 2 digits of year
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c90-strftime-2.c:18:
warning: '%g' yields only last 2 digits of year

FAIL: gcc.dg/format/ms_c99-printf-1.c   bad use of %hF (test for warnings, line
27)
FAIL: gcc.dg/format/ms_c99-printf-1.c   bad use of %ha (test for warnings, line
32)
FAIL: gcc.dg/format/ms_c99-printf-1.c   bad use of %hA (test for warnings, line
33)
FAIL: gcc.dg/format/ms_c99-printf-1.c   (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-1.c:27:
warning: use of 'h' length modifier with 'F' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-1.c:32:
warning: use of 'h' length modifier with 'a' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-1.c:33:
warning: use of 'h' length modifier with 'A' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-1.c:34:
warning: use of 'h' length modifier with 'c' type character
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-1.c:35:
warning: use of 'h' length modifier with 's' type character

FAIL: gcc.dg/format/ms_c99-printf-2.c   %q length is unsupported (test for
warnings, line 18)
FAIL: gcc.dg/format/ms_c99-printf-2.c   %Z length is unsupported (test for
warnings, line 20)
FAIL: gcc.dg/format/ms_c99-printf-2.c   printf %m is unsupported (test for
warnings, line 24)
FAIL: gcc.dg/format/ms_c99-printf-2.c   printf I format (test for warnings,
line 32)
FAIL: gcc.dg/format/ms_c99-printf-2.c   (test for excess errors)
Excess errors:
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-2.c:18:
warning: ISO C does not support the 'q' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-2.c:20:
warning: ISO C does not support the 'Z' gnu_printf length modifier
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-2.c:24:
warning: ISO C does not support the '%m' gnu_printf format
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/format/ms_c99-printf-2.c:32:
warning: 'I' flag used with '%x' gnu_printf format

There are a small sample of some of the FAIL:s that I get. There are
many PASS:es also. It is true that some of the FAIL results are due 
to MinGW extensions but some of them seem to indicate that we would
get different results on different OSes - not what we want.



Support for Andrew's position that "... >> lacks proper support 
>> for denormalized long doubles. See PR24685
> Looks like this testcase should be xfailed on solaris also."
is provided by these gcc.log entries:

...
Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/compat/compat.exp ...
Executing on host: /usr/share/src/gcc_build/gcc/xgcc
-B/usr/share/src/gcc_build/gcc/ dfprt17039.c   -lm   -o dfprt17039.exe   
(timeout = 300)
/var/tmp//cc7eaOLo.o: In function `main':


dfprt17039.c:(.text+0x25): undefined reference to `__dpd_extendsdtd2'


dfprt17039.c:(.text+0x4f): undefined reference to `__dpd_extendddtd2'


dfprt17039.c:(.text+0x8a): undefined reference to `__dpd_addtd3'


collect2: ld returned 1 exit status


compiler exited with status 1
output is:
/var/tmp//cc7eaOLo.o: In function `main':


dfprt17039.c:(.text+0x25): undefined reference to `__dpd_extendsdtd2'


dfprt17039.c:(.text+0x4f): undefined reference to `__dpd_extendddtd2'


dfprt17039.c:(.text+0x8a): undefined reference to `__dpd_addtd3'


collect2: ld returned 1 exit status



Executing on host: /usr/share/src/gcc_build/gcc/xgcc
-B/usr/share/src/gcc_build/gcc/   -DSKIP_DECIMAL_FLOAT -c  -o
c_compat_main_tst.o
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/compat/fnptr-by-value-1_main.c   
(timeout = 300)
PASS: gcc.dg/compat/fnptr-by-value-1 c_compat_main_tst.o compile
...
PASS: gcc.dg/dfp/func-vararg-dfp.c (test for excess errors)
Executing on host: /usr/share/src/gcc_build/gcc/xgcc
-B/usr/share/src/gcc_build/gcc/
/usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/dfp/func-vararg-mixed-2.c  
-std=gnu99 -mpreferred-stack-boundary=2  -lm   -o ./func-vararg-mixed-2.exe   
(timeout = 300)
/var/tmp//cclEaaXH.o: In function `vararg_d64':


func-vararg-mixed-2.c:(.text+0xaa): undefined reference to `__dpd_truncddsd2'


/var/tmp//cclEaaXH.o: In function `main':


func-vararg-mixed-2.c:(.text+0x1c1): undefined reference to `__dpd_nesd2'


func-vararg-mixed-2.c:(.text+0x215): undefined reference to `__dpd_extendsddd2'


func-vararg-mixed-2.c:(.text+0x231): undefined reference to `__dpd_nedd2'


func-vararg-mixed-2.c:(.text+0x2b8): undefined reference to `__dpd_netd2'


collect2: ld returned 1 exit status


compiler exited with status 1
output is:
/var/tmp//cclEaaXH.o: In function `vararg_d64':


func-vararg-mixed-2.c:(.text+0xaa): undefined reference to `__dpd_truncddsd2'


/var/tmp//cclEaaXH.o: In function `main':


func-vararg-mixed-2.c:(.text+0x1c1): undefined reference to `__dpd_nesd2'


func-vararg-mixed-2.c:(.text+0x215): undefined reference to `__dpd_extendsddd2'


func-vararg-mixed-2.c:(.text+0x231): undefined reference to `__dpd_nedd2'


func-vararg-mixed-2.c:(.text+0x2b8): undefined reference to `__dpd_netd2'


collect2: ld returned 1 exit status



FAIL: gcc.dg/dfp/func-vararg-mixed-2.c (test for excess errors)
Excess errors:
func-vararg-mixed-2.c:(.text+0xaa): undefined reference to `__dpd_truncddsd2'
func-vararg-mixed-2.c:(.text+0x1c1): undefined reference to `__dpd_nesd2'
func-vararg-mixed-2.c:(.text+0x215): undefined reference to `__dpd_extendsddd2'
func-vararg-mixed-2.c:(.text+0x231): undefined reference to `__dpd_nedd2'
func-vararg-mixed-2.c:(.text+0x2b8): undefined reference to `__dpd_netd2'
...(more)...

I think we would benefit from fixing the "dg-do compile" lines in
those tests to include both "*-*-solaris2.11*" and "*-*-linux*" .

If we find we get inconsistent results from different OSes then
it may well be worth using some libiberty with gcc and ensuring
that if we ./configure using "--enable-decimal-float 
--with-long-double-128 --enable-largefile" that it either 
works correctly _or_ is correctly excluded from testing.

Thanks
Rob


-- 


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

[Bug testsuite/38946] [4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #15 from rob1weld at aol dot com  2009-01-30 03:24 -------
(In reply to comment #9)
> Subject: Re:  [trunk regression]?gcc trunk 143562 - Testsuite - gfortran
> failing tests that worked previously
> 
> I think adding a printf() clone to libiberty is WAY overkill just to
> silence one failing test.

It looks like Sun is fleshing out some of the libc on it's own:
http://opensolaris.org/os/community/on/flag-days/pages/2009011401/


-- 


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

[Bug testsuite/38946] [4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |4.4.0


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

[Bug testsuite/38946] [4.4/4.5 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |4.4.1


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

[Bug testsuite/38946] [4.4/4.5 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.1                       |4.4.2


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

[Bug testsuite/38946] [4.4/4.5 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.2                       |4.4.3


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

[Bug testsuite/38946] [4.4/4.5 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.3                       |4.4.4


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.4                       |4.4.5


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #16 from ro at gcc dot gnu dot org  2010-06-04 12:53 -------
Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9.


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
 GCC target triplet|i386-pc-solaris2.11         |i386-pc-solaris2.1[01]
      Known to fail|                            |4.4.5 4.5.1 4.6.0
   Last reconfirmed|0000-00-00 00:00:00         |2010-06-04 12:53:55
               date|                            |


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #17 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-07 16:32 -------
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

I've now analysed this further: the test only fails at -O3.  The failure
is an abort in l.23:

      DDA1 = ATAN2 ((/(REAL(J1,KV),J1=1,10)/),
     $                 REAL((/(J1,J1=nf10,nf1,mf1)/), KV))   !fails
      DDA2 = ATAN2 (DDA, DDA(10:1:-1))
      if (any (DDA1 .ne. DDA2)) call abort ()

Investigating with gdb, I find that only the 10th array element differs:

(gdb ) p dda1
$1 = (0.0996686518, 0.218668953, 0.358770669, 0.519146085, 0.694738269,
0.876058042, 1.05165017, 1.21202564, 1.35212743, 1.47112763)
(gdb) p dda2
$2 = (0.0996686518, 0.218668953, 0.358770669, 0.519146085, 0.694738269,
0.876058042, 1.05165017, 1.21202564, 1.35212743, 8.40779079e-45)

I've verified that atan2f is called with exactly the same input sequence
in both cases.  The problem is that at -O0 (and probably up to -O2),
atan2f is called 2 x 10 times as expected, and atan2f only appears twice
in the assembler output.

On the other hand, at -O3 the second time through, atan2f(1.0) isn't
called.  Instead, the loop is unrolled, but incorrectly, it seems: there
are now only19 calls to atan2f in the assembler output.

        Rainer


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #18 from ro at gcc dot gnu dot org  2010-06-07 16:48 -------
Created an attachment (id=20857)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20857&action=view)
assembler output at -O0


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #19 from ro at gcc dot gnu dot org  2010-06-07 16:49 -------
Created an attachment (id=20858)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20858&action=view)
assembler output at -O3


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #20 from rob1weld at aol dot com  2010-06-20 02:05 -------
(In reply to comment #16)
> Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9.
> 

Thanks for looking into this,
Rob


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #21 from ro at gcc dot gnu dot org  2010-06-25 18:56 -------
Jerry, could you perhaps have a look at this one, too?  This is the last
remaining
fortran testsuite failure on Solaris 11/x86.

Thanks.
  Rainer


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

------- Comment #22 from jvdelisle at gcc dot gnu dot org  2010-06-25 19:24 -------
Rainer,

I will look at the array_constructor_23.f itself and see what the front-end is
doing with it.


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #23 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 19:26 -------
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

Great, thanks.


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

------- Comment #24 from jvdelisle at gcc dot gnu dot org  2010-06-25 20:20 -------
Created an attachment (id=21009)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21009&action=view)
Modified array_constructor_23.f to allow for some precision error

Rainer,

Try this version of the test case and see what it does.  If this fails, I will
send one instrumented a bit more.


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #25 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 20:34 -------
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

Jerry,

> Try this version of the test case and see what it does.  If this fails, I will
> send one instrumented a bit more.

this one works without problems, both 32 and 64-bit, at all optimization
levels (tested with

DEJAGNU=site.exp runtest --tool gfortran --srcdir $srcdir
dg.exp=array_constructor_23.f

        Rainer


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

------- Comment #26 from jvdelisle at gcc dot gnu dot org  2010-06-25 20:41 -------
I will commit the change


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #27 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-25 20:43 -------
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

> ------- Comment #26 from jvdelisle at gcc dot gnu dot org  2010-06-25 20:41 -------
> I will commit the change

Excellent: no remaining fortran testsuite failures :-)

        Rainer


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

------- Comment #28 from jvdelisle at gcc dot gnu dot org  2010-06-25 21:32 -------
Subject: Bug 38946

Author: jvdelisle
Date: Fri Jun 25 21:32:37 2010
New Revision: 161416

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161416
Log:
2010-06-25  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR testsuite/38946
        * gfortran.dg/array_constructor_23.f: Update test to allow for small
        error in comparing reals.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/array_constructor_23.f


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #29 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-07-09 19:17 -------
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

May I backport the patch to the 4.4 and 4.5 branches, too?

Thanks.
        Rainer


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #30 from rob1weld at aol dot com  2010-07-20 18:46 -------
(In reply to comment #28)
> Subject: Bug 38946
> Author: jvdelisle
> Date: Fri Jun 25 21:32:37 2010
> New Revision: 161416
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161416
> Log:
> 2010-06-25  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
>         PR testsuite/38946
>         * gfortran.dg/array_constructor_23.f: Update test to allow for small
>         error in comparing reals.
> Modified:
>     trunk/gcc/testsuite/ChangeLog
>     trunk/gcc/testsuite/gfortran.dg/array_constructor_23.f

Thanks for fixing the Trunk, when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946#c29 is complete I (or someone
else) will close this Bug.

Rob


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #31 from ro at gcc dot gnu dot org  2010-07-20 19:23 -------
Please refrain from fiddling with the bug status: whoever does the backport
will
do this himself.

Thanks.
  Rainer


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
      Known to fail|4.4.5 4.5.1 4.6.0           |4.4.5 4.5.1
      Known to work|                            |4.6.0
   Last reconfirmed|2010-06-04 12:53:55         |2010-07-20 19:23:33
               date|                            |


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[jvdelisle at gcc dot gnu dot org]

------- Comment #32 from jvdelisle at gcc dot gnu dot org  2010-07-21 04:37 -------
Rainer, this is OK to back port.  Do you want me to do so?


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #33 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-07-21 07:56 -------
Subject: Re:  [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran
failing tests that worked previously

> ------- Comment #32 from jvdelisle at gcc dot gnu dot org  2010-07-21 04:37 -------
> Rainer, this is OK to back port.  Do you want me to do so?

No need, I can easily do it myself.

Thanks.
        Rainer


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #34 from ro at gcc dot gnu dot org  2010-07-21 09:06 -------
Subject: Bug 38946

Author: ro
Date: Wed Jul 21 09:05:47 2010
New Revision: 162366

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162366
Log:
        Backport from mainline:
        2010-06-25  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR testsuite/38946
        * gfortran.dg/array_constructor_23.f: Update test to allow for small
        error in comparing reals.

Modified:
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/array_constructor_23.f


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #35 from ro at gcc dot gnu dot org  2010-07-21 09:06 -------
Subject: Bug 38946

Author: ro
Date: Wed Jul 21 09:06:42 2010
New Revision: 162367

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162367
Log:
        Backport from mainline:
        2010-06-25  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR testsuite/38946
        * gfortran.dg/array_constructor_23.f: Update test to allow for small
        error in comparing reals.

Modified:
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/array_constructor_23.f


-- 


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

------- Comment #36 from ro at gcc dot gnu dot org  2010-07-21 09:09 -------
Fixed on all active branches.


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to fail|4.4.5 4.5.1                 |
      Known to work|4.6.0                       |4.4.5 4.5.1 4.6.0
         Resolution|                            |FIXED


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[rob1weld at aol dot com]

------- Comment #37 from rob1weld at aol dot com  2010-07-23 08:43 -------
(In reply to comment #31)
> Please refrain from fiddling with the bug status: whoever does the backport
> will
> do this himself.
> 
> Thanks.
>   Rainer
> 

I have no interest in your posts and have marked your emails to me as SPAM.
Rob


-- 


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