Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 19575
Product:  
Component:  
Status: RESOLVED
Resolution: FIXED
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 19575 depends on: Show dependency tree
Show dependency graph
Bug 19575 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug


Description:   Last confirmed: 2005-04-24 17:53 Opened: 2005-01-22 11:57
The following code:

program abs_test1
   implicit none
   intrinsic cdabs

!   write(*,*) cdabs((4,3)) ! Causes ICE, as well
   call sub(cdabs)
end program abs_test1

subroutine sub(f)
   implicit none
   interface
      elemental function f(x)
         complex(kind(1.0d0)), intent(in) :: x
         real(kind(x)) :: f
      end function f
   end interface
   complex(kind(1.0d0)) x

   x = (4,3)
   write(*,*) f(x)
end subroutine sub


has an incorrect behavior when -std=f95 is specified (according to James Van
Buskirk, see
http://home.comcast.net/~kmbtib/gfortran_bugs/REF_JVB_GFTN_003.html). On
powerpc-apple-darwin, I get:

$ gfortran abs_test1.f90 && ./a.out
   5.00000000000000     
$ gfortran abs_test1.f90 -std=f95 && ./a.out
   2.25000000000000     

while on i686-mingw:

$ gfortran abs_test1.f90 && ./a.out
        5.00000000000000     
$ gfortran abs_test1.f90 -std=f95 && ./a.out
        NaN


Another related issue: when uncommenting the commented line, the behavior is
correct without -std=f95 (error issued at compile-time), but -std=f95 causes ICE:

$ gfortran abs_test1.f90 -std=f95 && ./a.out
abs_test1.f90: In function 'MAIN__':
abs_test1.f90:12: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:613

------- Comment #1 From Andrew Pinski 2005-01-22 15:48 -------
  sub (specific__abs_c8);
  sub (specific__abs_c4);
Hmm, I don't know what should be happening with intrinsics at all in this case

------- Comment #2 From Steve Kargl 2005-01-22 19:25 -------
Part of the problem is due to the following from intrinsic.c

  add_sym_1 ("zabs", 1, 1, BT_REAL, dd, GFC_STD_GNU, 
	     NULL, gfc_simplify_abs, gfc_resolve_abs, 
	     a, BT_COMPLEX, dd, REQUIRED);

  make_alias ("cdabs");

make_alias() does not set the GFC_STD_GNU flag.  If you change
cdabs to zabs, you get

kargl[216] gfc -o y -std=f95 y.f90
 In file y.f90:3

   intrinsic zabs
                1
Error: Intrinsic at (1) does not exist

which is the expected behavior.  We still get the
NaN if -std=f95 is removed from the command line.
NAG's compiler states

kargl[224] f95 -o y -dcfuns y.f90
Error: y.f90, line 5: Intrinsic CDABS cannot be an actual argument
[f95 error termination]



------- Comment #3 From Steve Kargl 2005-01-22 20:00 -------
Patch to fix the nonstandard issue with -std=f95.

http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01596.html

------- Comment #4 From Andrew Pinski 2005-01-22 22:38 -------
Confirmed.

------- Comment #5 From Andrew Pinski 2005-05-23 22:57 -------
Fixed since 4.0.0, someone forgot to close the bug.

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug