RE: Plan for bug-fixing g77-3.1.

RE: Plan for bug-fixing g77-3.1.

[Billinghurst, David (CRTS)]

I agree with your analysis that, in isolation, swapping BIT_SIZE and BITEST in intrin.def only paper over the cracks.  

However, this patch is required in conjunction with Toon's patch to use strcasecmp when comparing intrinsic names. 

-----Original Message-----
From: David Edelsohn [mailto:dje@watson.ibm.com]
Sent: Wednesday, 30 January 2002 2:14 
To: Billinghurst, David (CRTS)
Cc: Toon Moene; gcc@gcc.gnu.org
Subject: Re: Plan for bug-fixing g77-3.1. 


>>>>> Billinghurst, David (CRTS) writes:

David> Swapping BIT_SIZE and BITEST in intrin.def fixes the problem on
David> irix.  I will test this on cygwin before submitting a patch. 

	No.  This is completely wrong.  Please re-read my explanation of
the problem.  Swapping BIT_SIZE and BITEST papers over the symptom without
fixing the problem.  Do not even bother submitting your patch.

David

Re: Plan for bug-fixing g77-3.1.

[David Edelsohn]

>>>>> Billinghurst, David (CRTS) writes:

David> I agree with your analysis that, in isolation, swapping BIT_SIZE
David> and BITEST in intrin.def only paper over the cracks.   
David> However, this patch is required in conjunction with Toon's patch to
David> use strcasecmp when comparing intrinsic names.  

	This only fixes the testcase example.  There are other intrinsics
with underscores in the name.

David

Re: Plan for bug-fixing g77-3.1.

[Toon Moene]

David Edelsohn wrote:

> >>>>> Billinghurst, David (CRTS) writes:

> DavidB> I agree with your analysis that, in isolation, swapping BIT_SIZE
> DavidB> and BITEST in intrin.def only paper over the cracks.
> DavidB> However, this patch is required in conjunction with Toon's patch to
> DavidB> use strcasecmp when comparing intrinsic names.
> 
>         This only fixes the testcase example.  There are other intrinsics
> with underscores in the name.

While that is true, the BITEST/BIT_SIZE couple is special in that the
first differing character is a letter in one and an underscore in the
other entry.  This means that exactly *those* entries will sort
differently when sorted "upper cased" vs. sorted "lower case".

I should have been more careful with strcasecmp (the man page explicitly
states that the case-insensitive compare will be effected by converting
both names to lower case - which is just the wrong way for solving this
problem).

I'm now testing a patch that uses a specially written "compare upper
case", that will convert the would-be-intrinsic-name to upper case when
comparing it with the first of the three entries from the table. 
AFAICS, this should correct the problem.

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam

Correct comparison to the intrinsics table, was: Re: Plan for bug-fixing g77-3.1.

[Toon Moene]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

I wrote:

> I'm now testing a patch that uses a specially written "compare upper
> case", that will convert the would-be-intrinsic-name to upper case when
> comparing it with the first of the three entries from the table.
> AFAICS, this should correct the problem.

OK, the attached patch gives the correct results on mips-sgi-irix6.5. 
If no-one objects, I'll commit it later this evening (around 23:00 UTC).

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam

[-- Attachment #2: upcase.patch --]
[-- Type: text/plain, Size: 1219 bytes --]

*** intrin.c.orig	Fri Jan 25 22:15:28 2002
--- intrin.c	Tue Jan 29 21:33:01 2002
*************** ffeintrin_check_any_ (ffebld arglist)
*** 1154,1158 ****
  }
  
! /* Compare name to intrinsic's name.  Uses strcmp on arguments' names.
     The intrinsics table is sorted on the upper case entries; so first
     compare irrespective of case on the `uc' entry.  If it matches,
--- 1154,1174 ----
  }
  
! /* Compare a forced-to-uppercase name with a known-upper-case name.  */
! 
! static int
! upcasecmp_ (const char *name, const char *ucname)
! {
!   for ( ; *name != 0 && *ucname != 0; name++, ucname++)
!     {
!       int i = TOUPPER(*name) - *ucname;
! 
!       if (i != 0)
!         return i;
!     }
! 
!   return *name - *ucname;
! }
! 
! /* Compare name to intrinsic's name.
     The intrinsics table is sorted on the upper case entries; so first
     compare irrespective of case on the `uc' entry.  If it matches,
*************** ffeintrin_cmp_name_ (const void *name, c
*** 1167,1171 ****
    int i;
  
!   if ((i = strcasecmp (name, uc)) == 0)
      {
        switch (ffe_case_intrin ())
--- 1183,1187 ----
    int i;
  
!   if ((i = upcasecmp_ (name, uc)) == 0)
      {
        switch (ffe_case_intrin ())

Re: Plan for bug-fixing g77-3.1.

[Toon Moene]

"Billinghurst, David (CRTS)" wrote:

> Fixed by Richard Henderson - many thanks.

>                 === g77 Summary for unix/-mabi=64 ===
> 
> # of expected passes            1410
> # of unsupported tests          8

>    PR 3392 ICE in function_arg, at config/mips/mips.c:4007
>    PR 3393 ICE in extract_insn, at recog.c:2173

Wow - all of them !

David, don't forget to close the two PR's.

Thanks, Richard !

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

RE: Plan for bug-fixing g77-3.1.

[Billinghurst, David (CRTS)]

Fixed by Richard Henderson - many thanks.

		=== g77 tests ===


Running target unix

		=== g77 Summary for unix ===

# of expected passes		1410
# of unsupported tests		8

Running target unix/-mabi=64

		=== g77 Summary for unix/-mabi=64 ===

# of expected passes		1410
# of unsupported tests		8

		=== g77 Summary ===

# of expected passes		2820
# of unsupported tests		16
/exd4/billingd/obj/gcc/gcc/testsuite/../g77 version 3.1 20020205 (experimental)


-----Original Message-----
From: Toon Moene [mailto:toon@moene.indiv.nluug.nl]
Sent: Tuesday, 22 January 2002 6:42 
To: gcc@gcc.gnu.org
Subject: Plan for bug-fixing g77-3.1.


L.S.,

I'm planning to do the following to fix extant bugs in g77 for the 3.1
release:

5. Two MIPS (mabi=64) backend bugs:

   PR 3392 ICE in function_arg, at config/mips/mips.c:4007
   PR 3393 ICE in extract_insn, at recog.c:2173

Re: Plan for bug-fixing g77-3.1.

[David Edelsohn]

>>>>> Billinghurst, David (CRTS) writes:

David> Yes, but they remain sorted.  

	Okay ... if that is the only one where the underscore determines
the sort order.

David

RE: Plan for bug-fixing g77-3.1.

[Billinghurst, David (CRTS)]

Yes, but they remain sorted.  
 - DATE_AND_TIME tested in u77-test.f
 - LEN_TRIM tested in u77-test.f
 - SYSTEM_CLOCK tested in u77-test.f
 - RANDOM_NUMBER not implemented
 - RANDOM_SEED not implemented


-----Original Message-----
From: David Edelsohn [mailto:dje@watson.ibm.com]
Sent: Wednesday, 30 January 2002 3:23 
To: Billinghurst, David (CRTS)
Cc: Toon Moene; gcc@gcc.gnu.org
Subject: Re: Plan for bug-fixing g77-3.1. 


>>>>> Billinghurst, David (CRTS) writes:

David> I agree with your analysis that, in isolation, swapping BIT_SIZE
David> and BITEST in intrin.def only paper over the cracks.   
David> However, this patch is required in conjunction with Toon's patch to
David> use strcasecmp when comparing intrinsic names.  

	This only fixes the testcase example.  There are other intrinsics
with underscores in the name.

David

Re: Plan for bug-fixing g77-3.1.

[David Edelsohn]

>>>>> Billinghurst, David (CRTS) writes:

David> Swapping BIT_SIZE and BITEST in intrin.def fixes the problem on
David> irix.  I will test this on cygwin before submitting a patch. 

	No.  This is completely wrong.  Please re-read my explanation of
the problem.  Swapping BIT_SIZE and BITEST papers over the symptom without
fixing the problem.  Do not even bother submitting your patch.

David

RE: Plan for bug-fixing g77-3.1.

[Billinghurst, David (CRTS)]

Swapping BIT_SIZE and BITEST in intrin.def fixes the problem on irix.  I will test this on cygwin before submitting a patch.

-----Original Message-----
From: David Edelsohn [mailto:dje@watson.ibm.com]
Sent: Wednesday, 30 January 2002 3:10 
To: Toon Moene
Cc: gcc@gcc.gnu.org
Subject: Re: Plan for bug-fixing g77-3.1. 


	If this fails, you have broken something with the way G77 invokes
bsearch, possibly the size of the table G77 is providing to the call.

	Your fix is not correct because strcasecmp uses lower case as the
common case for the comparison.  The table still is upper case.  Your
change has absolutely no affect on the mismatch between the trinary signed
result of the comparison and the upper case collation of the table.
strcasecmp still responds with the wrong sign for words including
underscores which straddle upper case and lower case ASCII.

David

Re: Plan for bug-fixing g77-3.1.

[David Edelsohn]

	If this fails, you have broken something with the way G77 invokes
bsearch, possibly the size of the table G77 is providing to the call.

	Your fix is not correct because strcasecmp uses lower case as the
common case for the comparison.  The table still is upper case.  Your
change has absolutely no affect on the mismatch between the trinary signed
result of the comparison and the upper case collation of the table.
strcasecmp still responds with the wrong sign for words including
underscores which straddle upper case and lower case ASCII.

David

Re: Plan for bug-fixing g77-3.1.

[Toon Moene]

[ On the problem of finding BIT_SIZE in the intrinsics table ]

I wrote, two days ago:

> "Billinghurst, David (CRTS)" wrote:

>> This doesn't seem to work for me on irix.  I am away from the 
>> office, but will have a look once I get back.

> Yep, I noted that too

> 14 XFAILs; same as before.

I just tried this on mips-sgi-irix6.5 with some debug printf's in
f/intrin.c and there's something fishy about its `bsearch' function.

If I look at compile/pr3743.f in the Fortran testsuite, the following
happens:

It starts the search at `bitest' in the intrinsics table (f/intrin.def)
- the search then fails.  If I force the build to use libiberty's
`bsearch' (by including the source of it in f/intrin.c), the search
starts at `iiqint', which indeed is the middle of the table - the search
succeeds.

Does this indicate a problem with IRIX's bsearch ?  I assume a binary
search *has* to start with the middle of the table ...

--
Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206443, Fax +31302210407,  e-mail moene@knmi.nl
URL: http://www.knmi.nl/hirlam

Re: Plan for bug-fixing g77-3.1.

[Toon Moene]

I wrote:

> "Billinghurst, David (CRTS)" wrote:
> 
> > This doesn't seem to work for me on irix.  I am away from the office,
> > but will have a look once I get back.
> 
> Yep, I noted that too
> 
>         (http://gcc.gnu.org/ml/gcc-testresults/2002-01/msg00535.html)
> 
> 14 XFAILs; same as before.
> 
> I hope you can find out what's going wrong ...

Just to guide that search, these are the things we held true:

1. Intrinsics are considered to be written in lower case:

   See:

target.h:#define FFETARGET_defaultCASE_INTRIN FFE_caseLOWER
top.c:ffeCase ffe_case_intrin_ = FFETARGET_defaultCASE_INTRIN;

2. The "lower case" part of the intrinsics table in intrin.def is not
   correctly sorted:

DEFNAME ("BITEST",      "bitest",       "BITest",       genNONE,       
specBITEST)     /* VXT */
DEFNAME ("BIT_SIZE",    "bit_size",     "Bit_Size",     genNONE,       
specBIT_SIZE)   /* F90 */

   cat /tmp/a
   bitest
   bit_size

   sort /tmp/a
   bit_size
   bitest

3. Hence, a `bsearch' on this table could produce wrong answers.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Plan for bug-fixing g77-3.1.

[Toon Moene]

"Billinghurst, David (CRTS)" wrote:

> This doesn't seem to work for me on irix.  I am away from the office, 
> but will have a look once I get back.

Yep, I noted that too

	(http://gcc.gnu.org/ml/gcc-testresults/2002-01/msg00535.html)

14 XFAILs; same as before.

I hope you can find out what's going wrong ...

Thanks in advance,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

RE: Plan for bug-fixing g77-3.1.

[Billinghurst, David (CRTS)]

This doesn't seem to work for me on irix.  I am away from the office, but will have a look once I get back.   

-----Original Message-----
From: Toon Moene [mailto:toon@moene.indiv.nluug.nl]
Sent: Saturday, 26 January 2002 11:10 
To: gcc@gcc.gnu.org
Subject: Re: Plan for bug-fixing g77-3.1.


I wrote:

> I'm planning to do the following to fix extant bugs in g77 for the 3.1
> release:
> 
> 1. PR 3743 Reference to intrinsic `ISHFT' invalid
> 
>    This is due to the subtle bug in the intrinsics table that David
>    Edelsohn showed.  I'll probably follow his advice in
> 
>         http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00000.html
> 
>    (use strcasecmp in libiberty) to fix this problem.

The proposed patch is attached - it passes make bootstrap (C and
Fortran), make check (Fortran only) and make install (C and Fortran) on
i686-pc-linux-gnu.  I send it to the list now, so that other people
might try it on their systems.  I'll certainly _not_ commit it before it
passes on SPARC, MIPS, Alpha and PowerPC.

Now for the proof that this is correct.

As David Edelsohn showed, the intrinsics table of g77 (in f/intrin.def)
is sorted _on the upper case names only_.

This means that, in order to fix the deficiency, we have to rely on
comparing to the the upper case entry only as long as this defines the
search direction for `bsearch'.

The attached patch does that.

It first compares the would-be-intrinsic-name case-insensitively to the
upper case entry of the table.
In case the g77 options indicate that intrinsics have no case
sensitivity or are upper case only, the result of this comparison is
used directly.
In case the g77 options indicate that intrinsics should have been
written in lower case, the next comparison is against the exact lower
case name.
In case the g77 options indicate that intrinsics should have been
written to a predefined "initial caps" convention, the next comparison
is against the string according to that convention.
If the case-insensitive comparison to the upper case entry didn't match,
the comparison is returned, which will direct `bsearch' in choosing the
right half of the table for further search.

The interesting part is what happens if the case insensitive comparison
succeeds, but the case sensitive one doesn't.  Due to the fact that
`bsearch' will always either choose or cut a half, this search must
terminate in case there's no match.  Because the comparison that's
returned is always the same for each entry of the 380-entry table for
invariant "intrinsic capitalisation mode", this will always be the case.

End-of-proof.

Note that I do not have to prove anything about alias analysis in
Fortran - that's dead simple by comparison:

If you don't indicate to the compiler that two items can overlap (by
using EQUIVALENCE) they better don't - or else [1].

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

[1] According to the comp.lang.fortran FAQ, "or else" means: "could
start 
    WW III, if the right - optional - hardware is installed."

    Obviously, the comp.lang.fortran FAQ was written during the Cold
War.

Re: Plan for bug-fixing g77-3.1.

[Toon Moene]

[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]

I wrote:

> I'm planning to do the following to fix extant bugs in g77 for the 3.1
> release:
> 
> 1. PR 3743 Reference to intrinsic `ISHFT' invalid
> 
>    This is due to the subtle bug in the intrinsics table that David
>    Edelsohn showed.  I'll probably follow his advice in
> 
>         http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00000.html
> 
>    (use strcasecmp in libiberty) to fix this problem.

The proposed patch is attached - it passes make bootstrap (C and
Fortran), make check (Fortran only) and make install (C and Fortran) on
i686-pc-linux-gnu.  I send it to the list now, so that other people
might try it on their systems.  I'll certainly _not_ commit it before it
passes on SPARC, MIPS, Alpha and PowerPC.

Now for the proof that this is correct.

As David Edelsohn showed, the intrinsics table of g77 (in f/intrin.def)
is sorted _on the upper case names only_.

This means that, in order to fix the deficiency, we have to rely on
comparing to the the upper case entry only as long as this defines the
search direction for `bsearch'.

The attached patch does that.

It first compares the would-be-intrinsic-name case-insensitively to the
upper case entry of the table.
In case the g77 options indicate that intrinsics have no case
sensitivity or are upper case only, the result of this comparison is
used directly.
In case the g77 options indicate that intrinsics should have been
written in lower case, the next comparison is against the exact lower
case name.
In case the g77 options indicate that intrinsics should have been
written to a predefined "initial caps" convention, the next comparison
is against the string according to that convention.
If the case-insensitive comparison to the upper case entry didn't match,
the comparison is returned, which will direct `bsearch' in choosing the
right half of the table for further search.

The interesting part is what happens if the case insensitive comparison
succeeds, but the case sensitive one doesn't.  Due to the fact that
`bsearch' will always either choose or cut a half, this search must
terminate in case there's no match.  Because the comparison that's
returned is always the same for each entry of the 380-entry table for
invariant "intrinsic capitalisation mode", this will always be the case.

End-of-proof.

Note that I do not have to prove anything about alias analysis in
Fortran - that's dead simple by comparison:

If you don't indicate to the compiler that two items can overlap (by
using EQUIVALENCE) they better don't - or else [1].

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

[1] According to the comp.lang.fortran FAQ, "or else" means: "could
start 
    WW III, if the right - optional - hardware is installed."

    Obviously, the comp.lang.fortran FAQ was written during the Cold
War.

[-- Attachment #2: ffe-intrin.patch --]
[-- Type: text/plain, Size: 1369 bytes --]

*** intrin.c.orig	Mon Jan 14 21:57:55 2002
--- intrin.c	Fri Jan 25 22:15:28 2002
*************** ffeintrin_check_any_ (ffebld arglist)
*** 1154,1158 ****
  }
  
! /* Compare name to intrinsic's name.  Uses strcmp on arguments' names.	*/
  
  static int
--- 1154,1161 ----
  }
  
! /* Compare name to intrinsic's name.  Uses strcmp on arguments' names.
!    The intrinsics table is sorted on the upper case entries; so first
!    compare irrespective of case on the `uc' entry.  If it matches,
!    compare according to the setting of intrinsics case comparison mode.  */
  
  static int
*************** ffeintrin_cmp_name_ (const void *name, c
*** 1162,1167 ****
    const char *const lc = ((const struct _ffeintrin_name_ *) intrinsic)->name_lc;
    const char *const ic = ((const struct _ffeintrin_name_ *) intrinsic)->name_ic;
  
!   return ffesrc_strcmp_2c (ffe_case_intrin (), name, uc, lc, ic);
  }
  
--- 1165,1184 ----
    const char *const lc = ((const struct _ffeintrin_name_ *) intrinsic)->name_lc;
    const char *const ic = ((const struct _ffeintrin_name_ *) intrinsic)->name_ic;
+   int i;
  
!   if ((i = strcasecmp (name, uc)) == 0)
!     {
!       switch (ffe_case_intrin ())
! 	{
! 	case FFE_caseLOWER:
! 	  return strcmp(name, lc);
! 	case FFE_caseINITCAP:
! 	  return strcmp(name, ic);
! 	default:
! 	  return 0;
! 	}
!     }
! 
!   return i;
  }
  

Re: Plan for bug-fixing g77-3.1.

[Reichelt]

Hello again,

PR 3393 can be boiled down to the following lines of code:

      PROGRAM LABUG2
      INTEGER I, J, M
      REAL    A(5,2)
      M = 1
      DO J = 1, 2
        DO I = 1, M
          CALL F1( A(I,J) )
        END DO
      END DO
      CALL F2(M)
      END

I get the following error message when compiling with "g77 -O2 -mabi=64"
on mips-sgi-irix6.5:

labug2.f:11: unrecognizable insn:
(insn 203 84 144 (set (reg:DI 114)
        (plus:DI (reg:DI 114)
            (sign_extend:DI (const_int 20 [0x14])))) -1 (nil)
    (nil))
labug2.f:11: Internal compiler error in extract_insn, at recog.c:2129

Again, there's a two-dimensional array involded, so that PR 3393 is
probably related to PR 3392.

Greetings,
Volker Reichelt

http://gcc.gnu.org/ml/gcc/2002-01/msg01379.html
http://gcc.gnu.org/ml/gcc/2002-01/msg01389.html

Re: Plan for bug-fixing g77-3.1.

[Reichelt]

Hi,

the problems from PR 3392 can be reduced a little.
There seems to be a problem with two-dimensional arrays:

Just try to compile the following code with "g77 -mabi=64" (you don't
even need optimization for this reduced example):
      subroutine f(n,a)
      integer n
      real a(n,n)
      end
This will cause an ICE with gcc 3.1 on mips-sgi-irix6.5. You can also
use "complex" or "double precision" instead of "real".

Greetings,
Volker Reichelt

Plan for bug-fixing g77-3.1.

[Toon Moene]

L.S.,

I'm planning to do the following to fix extant bugs in g77 for the 3.1
release:

1. PR 3743 Reference to intrinsic `ISHFT' invalid

   This is due to the subtle bug in the intrinsics table that David
   Edelsohn showed.  I'll probably follow his advice in

	http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00000.html

   (use strcasecmp in libiberty) to fix this problem.

2. Fix two cases where the compiler rejects perfectly sensible uses
   of INTEGER*2:

   PR  947 Data statement initialization of an array element whose
           index is [an INTEGER*2 constant]
   PR 5122 g77 rejects accepted use of INTEGER*2 as type of DATA
           statement loop index

3. Fix two ICEs on legal code:

   PR 4730 ICE on valid input using CALL EXIT(%VAL(...))
   PR 5397 ICE on compiling source with 540 000 000 REAL array

PR 1832 -list directed i/o overflow hangs, -fbounds-check doesn't
        detect

is probably too difficult.

And on the libf2c front:

4. PR 4392 Error with list directed format on internal file - ERR=XXX 
           ignored

PR 941 Configuration fails when cross-compiling

is too vague - does someone have an idea what to ask the submitter to
get info about what actually is going wrong (I'm not well-versed in
cross-compiling at all).

For the other open or analyzed PR's I need help (because I've no access
to MIPS or DOS-based systems):

5. Two MIPS (mabi=64) backend bugs:

   PR 3392 ICE in function_arg, at config/mips/mips.c:4007
   PR 3393 ICE in extract_insn, at recog.c:2173

6. Invalid assembly code for COFF debugging (this is for DJGPP):

   PR 3924 g77 generates code which is rejected by GAS if COFF
           debugging info is requested

Thanks for any help offered !

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)