summaryrefslogtreecommitdiffstats
path: root/contrib/gcc/f/g77.texi
blob: 23172315fbcc4e7e65df7371c9aba80134ee0ee5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395
5396
5397
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573
5574
5575
5576
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
5653
5654
5655
5656
5657
5658
5659
5660
5661
5662
5663
5664
5665
5666
5667
5668
5669
5670
5671
5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
5723
5724
5725
5726
5727
5728
5729
5730
5731
5732
5733
5734
5735
5736
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
5791
5792
5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805
5806
5807
5808
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
5838
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848
5849
5850
5851
5852
5853
5854
5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870
5871
5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
5882
5883
5884
5885
5886
5887
5888
5889
5890
5891
5892
5893
5894
5895
5896
5897
5898
5899
5900
5901
5902
5903
5904
5905
5906
5907
5908
5909
5910
5911
5912
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
5932
5933
5934
5935
5936
5937
5938
5939
5940
5941
5942
5943
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
5968
5969
5970
5971
5972
5973
5974
5975
5976
5977
5978
5979
5980
5981
5982
5983
5984
5985
5986
5987
5988
5989
5990
5991
5992
5993
5994
5995
5996
5997
5998
5999
6000
6001
6002
6003
6004
6005
6006
6007
6008
6009
6010
6011
6012
6013
6014
6015
6016
6017
6018
6019
6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052
6053
6054
6055
6056
6057
6058
6059
6060
6061
6062
6063
6064
6065
6066
6067
6068
6069
6070
6071
6072
6073
6074
6075
6076
6077
6078
6079
6080
6081
6082
6083
6084
6085
6086
6087
6088
6089
6090
6091
6092
6093
6094
6095
6096
6097
6098
6099
6100
6101
6102
6103
6104
6105
6106
6107
6108
6109
6110
6111
6112
6113
6114
6115
6116
6117
6118
6119
6120
6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133
6134
6135
6136
6137
6138
6139
6140
6141
6142
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
6160
6161
6162
6163
6164
6165
6166
6167
6168
6169
6170
6171
6172
6173
6174
6175
6176
6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187
6188
6189
6190
6191
6192
6193
6194
6195
6196
6197
6198
6199
6200
6201
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
6213
6214
6215
6216
6217
6218
6219
6220
6221
6222
6223
6224
6225
6226
6227
6228
6229
6230
6231
6232
6233
6234
6235
6236
6237
6238
6239
6240
6241
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
6293
6294
6295
6296
6297
6298
6299
6300
6301
6302
6303
6304
6305
6306
6307
6308
6309
6310
6311
6312
6313
6314
6315
6316
6317
6318
6319
6320
6321
6322
6323
6324
6325
6326
6327
6328
6329
6330
6331
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
6351
6352
6353
6354
6355
6356
6357
6358
6359
6360
6361
6362
6363
6364
6365
6366
6367
6368
6369
6370
6371
6372
6373
6374
6375
6376
6377
6378
6379
6380
6381
6382
6383
6384
6385
6386
6387
6388
6389
6390
6391
6392
6393
6394
6395
6396
6397
6398
6399
6400
6401
6402
6403
6404
6405
6406
6407
6408
6409
6410
6411
6412
6413
6414
6415
6416
6417
6418
6419
6420
6421
6422
6423
6424
6425
6426
6427
6428
6429
6430
6431
6432
6433
6434
6435
6436
6437
6438
6439
6440
6441
6442
6443
6444
6445
6446
6447
6448
6449
6450
6451
6452
6453
6454
6455
6456
6457
6458
6459
6460
6461
6462
6463
6464
6465
6466
6467
6468
6469
6470
6471
6472
6473
6474
6475
6476
6477
6478
6479
6480
6481
6482
6483
6484
6485
6486
6487
6488
6489
6490
6491
6492
6493
6494
6495
6496
6497
6498
6499
6500
6501
6502
6503
6504
6505
6506
6507
6508
6509
6510
6511
6512
6513
6514
6515
6516
6517
6518
6519
6520
6521
6522
6523
6524
6525
6526
6527
6528
6529
6530
6531
6532
6533
6534
6535
6536
6537
6538
6539
6540
6541
6542
6543
6544
6545
6546
6547
6548
6549
6550
6551
6552
6553
6554
6555
6556
6557
6558
6559
6560
6561
6562
6563
6564
6565
6566
6567
6568
6569
6570
6571
6572
6573
6574
6575
6576
6577
6578
6579
6580
6581
6582
6583
6584
6585
6586
6587
6588
6589
6590
6591
6592
6593
6594
6595
6596
6597
6598
6599
6600
6601
6602
6603
6604
6605
6606
6607
6608
6609
6610
6611
6612
6613
6614
6615
6616
6617
6618
6619
6620
6621
6622
6623
6624
6625
6626
6627
6628
6629
6630
6631
6632
6633
6634
6635
6636
6637
6638
6639
6640
6641
6642
6643
6644
6645
6646
6647
6648
6649
6650
6651
6652
6653
6654
6655
6656
6657
6658
6659
6660
6661
6662
6663
6664
6665
6666
6667
6668
6669
6670
6671
6672
6673
6674
6675
6676
6677
6678
6679
6680
6681
6682
6683
6684
6685
6686
6687
6688
6689
6690
6691
6692
6693
6694
6695
6696
6697
6698
6699
6700
6701
6702
6703
6704
6705
6706
6707
6708
6709
6710
6711
6712
6713
6714
6715
6716
6717
6718
6719
6720
6721
6722
6723
6724
6725
6726
6727
6728
6729
6730
6731
6732
6733
6734
6735
6736
6737
6738
6739
6740
6741
6742
6743
6744
6745
6746
6747
6748
6749
6750
6751
6752
6753
6754
6755
6756
6757
6758
6759
6760
6761
6762
6763
6764
6765
6766
6767
6768
6769
6770
6771
6772
6773
6774
6775
6776
6777
6778
6779
6780
6781
6782
6783
6784
6785
6786
6787
6788
6789
6790
6791
6792
6793
6794
6795
6796
6797
6798
6799
6800
6801
6802
6803
6804
6805
6806
6807
6808
6809
6810
6811
6812
6813
6814
6815
6816
6817
6818
6819
6820
6821
6822
6823
6824
6825
6826
6827
6828
6829
6830
6831
6832
6833
6834
6835
6836
6837
6838
6839
6840
6841
6842
6843
6844
6845
6846
6847
6848
6849
6850
6851
6852
6853
6854
6855
6856
6857
6858
6859
6860
6861
6862
6863
6864
6865
6866
6867
6868
6869
6870
6871
6872
6873
6874
6875
6876
6877
6878
6879
6880
6881
6882
6883
6884
6885
6886
6887
6888
6889
6890
6891
6892
6893
6894
6895
6896
6897
6898
6899
6900
6901
6902
6903
6904
6905
6906
6907
6908
6909
6910
6911
6912
6913
6914
6915
6916
6917
6918
6919
6920
6921
6922
6923
6924
6925
6926
6927
6928
6929
6930
6931
6932
6933
6934
6935
6936
6937
6938
6939
6940
6941
6942
6943
6944
6945
6946
6947
6948
6949
6950
6951
6952
6953
6954
6955
6956
6957
6958
6959
6960
6961
6962
6963
6964
6965
6966
6967
6968
6969
6970
6971
6972
6973
6974
6975
6976
6977
6978
6979
6980
6981
6982
6983
6984
6985
6986
6987
6988
6989
6990
6991
6992
6993
6994
6995
6996
6997
6998
6999
7000
7001
7002
7003
7004
7005
7006
7007
7008
7009
7010
7011
7012
7013
7014
7015
7016
7017
7018
7019
7020
7021
7022
7023
7024
7025
7026
7027
7028
7029
7030
7031
7032
7033
7034
7035
7036
7037
7038
7039
7040
7041
7042
7043
7044
7045
7046
7047
7048
7049
7050
7051
7052
7053
7054
7055
7056
7057
7058
7059
7060
7061
7062
7063
7064
7065
7066
7067
7068
7069
7070
7071
7072
7073
7074
7075
7076
7077
7078
7079
7080
7081
7082
7083
7084
7085
7086
7087
7088
7089
7090
7091
7092
7093
7094
7095
7096
7097
7098
7099
7100
7101
7102
7103
7104
7105
7106
7107
7108
7109
7110
7111
7112
7113
7114
7115
7116
7117
7118
7119
7120
7121
7122
7123
7124
7125
7126
7127
7128
7129
7130
7131
7132
7133
7134
7135
7136
7137
7138
7139
7140
7141
7142
7143
7144
7145
7146
7147
7148
7149
7150
7151
7152
7153
7154
7155
7156
7157
7158
7159
7160
7161
7162
7163
7164
7165
7166
7167
7168
7169
7170
7171
7172
7173
7174
7175
7176
7177
7178
7179
7180
7181
7182
7183
7184
7185
7186
7187
7188
7189
7190
7191
7192
7193
7194
7195
7196
7197
7198
7199
7200
7201
7202
7203
7204
7205
7206
7207
7208
7209
7210
7211
7212
7213
7214
7215
7216
7217
7218
7219
7220
7221
7222
7223
7224
7225
7226
7227
7228
7229
7230
7231
7232
7233
7234
7235
7236
7237
7238
7239
7240
7241
7242
7243
7244
7245
7246
7247
7248
7249
7250
7251
7252
7253
7254
7255
7256
7257
7258
7259
7260
7261
7262
7263
7264
7265
7266
7267
7268
7269
7270
7271
7272
7273
7274
7275
7276
7277
7278
7279
7280
7281
7282
7283
7284
7285
7286
7287
7288
7289
7290
7291
7292
7293
7294
7295
7296
7297
7298
7299
7300
7301
7302
7303
7304
7305
7306
7307
7308
7309
7310
7311
7312
7313
7314
7315
7316
7317
7318
7319
7320
7321
7322
7323
7324
7325
7326
7327
7328
7329
7330
7331
7332
7333
7334
7335
7336
7337
7338
7339
7340
7341
7342
7343
7344
7345
7346
7347
7348
7349
7350
7351
7352
7353
7354
7355
7356
7357
7358
7359
7360
7361
7362
7363
7364
7365
7366
7367
7368
7369
7370
7371
7372
7373
7374
7375
7376
7377
7378
7379
7380
7381
7382
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
7395
7396
7397
7398
7399
7400
7401
7402
7403
7404
7405
7406
7407
7408
7409
7410
7411
7412
7413
7414
7415
7416
7417
7418
7419
7420
7421
7422
7423
7424
7425
7426
7427
7428
7429
7430
7431
7432
7433
7434
7435
7436
7437
7438
7439
7440
7441
7442
7443
7444
7445
7446
7447
7448
7449
7450
7451
7452
7453
7454
7455
7456
7457
7458
7459
7460
7461
7462
7463
7464
7465
7466
7467
7468
7469
7470
7471
7472
7473
7474
7475
7476
7477
7478
7479
7480
7481
7482
7483
7484
7485
7486
7487
7488
7489
7490
7491
7492
7493
7494
7495
7496
7497
7498
7499
7500
7501
7502
7503
7504
7505
7506
7507
7508
7509
7510
7511
7512
7513
7514
7515
7516
7517
7518
7519
7520
7521
7522
7523
7524
7525
7526
7527
7528
7529
7530
7531
7532
7533
7534
7535
7536
7537
7538
7539
7540
7541
7542
7543
7544
7545
7546
7547
7548
7549
7550
7551
7552
7553
7554
7555
7556
7557
7558
7559
7560
7561
7562
7563
7564
7565
7566
7567
7568
7569
7570
7571
7572
7573
7574
7575
7576
7577
7578
7579
7580
7581
7582
7583
7584
7585
7586
7587
7588
7589
7590
7591
7592
7593
7594
7595
7596
7597
7598
7599
7600
7601
7602
7603
7604
7605
7606
7607
7608
7609
7610
7611
7612
7613
7614
7615
7616
7617
7618
7619
7620
7621
7622
7623
7624
7625
7626
7627
7628
7629
7630
7631
7632
7633
7634
7635
7636
7637
7638
7639
7640
7641
7642
7643
7644
7645
7646
7647
7648
7649
7650
7651
7652
7653
7654
7655
7656
7657
7658
7659
7660
7661
7662
7663
7664
7665
7666
7667
7668
7669
7670
7671
7672
7673
7674
7675
7676
7677
7678
7679
7680
7681
7682
7683
7684
7685
7686
7687
7688
7689
7690
7691
7692
7693
7694
7695
7696
7697
7698
7699
7700
7701
7702
7703
7704
7705
7706
7707
7708
7709
7710
7711
7712
7713
7714
7715
7716
7717
7718
7719
7720
7721
7722
7723
7724
7725
7726
7727
7728
7729
7730
7731
7732
7733
7734
7735
7736
7737
7738
7739
7740
7741
7742
7743
7744
7745
7746
7747
7748
7749
7750
7751
7752
7753
7754
7755
7756
7757
7758
7759
7760
7761
7762
7763
7764
7765
7766
7767
7768
7769
7770
7771
7772
7773
7774
7775
7776
7777
7778
7779
7780
7781
7782
7783
7784
7785
7786
7787
7788
7789
7790
7791
7792
7793
7794
7795
7796
7797
7798
7799
7800
7801
7802
7803
7804
7805
7806
7807
7808
7809
7810
7811
7812
7813
7814
7815
7816
7817
7818
7819
7820
7821
7822
7823
7824
7825
7826
7827
7828
7829
7830
7831
7832
7833
7834
7835
7836
7837
7838
7839
7840
7841
7842
7843
7844
7845
7846
7847
7848
7849
7850
7851
7852
7853
7854
7855
7856
7857
7858
7859
7860
7861
7862
7863
7864
7865
7866
7867
7868
7869
7870
7871
7872
7873
7874
7875
7876
7877
7878
7879
7880
7881
7882
7883
7884
7885
7886
7887
7888
7889
7890
7891
7892
7893
7894
7895
7896
7897
7898
7899
7900
7901
7902
7903
7904
7905
7906
7907
7908
7909
7910
7911
7912
7913
7914
7915
7916
7917
7918
7919
7920
7921
7922
7923
7924
7925
7926
7927
7928
7929
7930
7931
7932
7933
7934
7935
7936
7937
7938
7939
7940
7941
7942
7943
7944
7945
7946
7947
7948
7949
7950
7951
7952
7953
7954
7955
7956
7957
7958
7959
7960
7961
7962
7963
7964
7965
7966
7967
7968
7969
7970
7971
7972
7973
7974
7975
7976
7977
7978
7979
7980
7981
7982
7983
7984
7985
7986
7987
7988
7989
7990
7991
7992
7993
7994
7995
7996
7997
7998
7999
8000
8001
8002
8003
8004
8005
8006
8007
8008
8009
8010
8011
8012
8013
8014
8015
8016
8017
8018
8019
8020
8021
8022
8023
8024
8025
8026
8027
8028
8029
8030
8031
8032
8033
8034
8035
8036
8037
8038
8039
8040
8041
8042
8043
8044
8045
8046
8047
8048
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
8059
8060
8061
8062
8063
8064
8065
8066
8067
8068
8069
8070
8071
8072
8073
8074
8075
8076
8077
8078
8079
8080
8081
8082
8083
8084
8085
8086
8087
8088
8089
8090
8091
8092
8093
8094
8095
8096
8097
8098
8099
8100
8101
8102
8103
8104
8105
8106
8107
8108
8109
8110
8111
8112
8113
8114
8115
8116
8117
8118
8119
8120
8121
8122
8123
8124
8125
8126
8127
8128
8129
8130
8131
8132
8133
8134
8135
8136
8137
8138
8139
8140
8141
8142
8143
8144
8145
8146
8147
8148
8149
8150
8151
8152
8153
8154
8155
8156
8157
8158
8159
8160
8161
8162
8163
8164
8165
8166
8167
8168
8169
8170
8171
8172
8173
8174
8175
8176
8177
8178
8179
8180
8181
8182
8183
8184
8185
8186
8187
8188
8189
8190
8191
8192
8193
8194
8195
8196
8197
8198
8199
8200
8201
8202
8203
8204
8205
8206
8207
8208
8209
8210
8211
8212
8213
8214
8215
8216
8217
8218
8219
8220
8221
8222
8223
8224
8225
8226
8227
8228
8229
8230
8231
8232
8233
8234
8235
8236
8237
8238
8239
8240
8241
8242
8243
8244
8245
8246
8247
8248
8249
8250
8251
8252
8253
8254
8255
8256
8257
8258
8259
8260
8261
8262
8263
8264
8265
8266
8267
8268
8269
8270
8271
8272
8273
8274
8275
8276
8277
8278
8279
8280
8281
8282
8283
8284
8285
8286
8287
8288
8289
8290
8291
8292
8293
8294
8295
8296
8297
8298
8299
8300
8301
8302
8303
8304
8305
8306
8307
8308
8309
8310
8311
8312
8313
8314
8315
8316
8317
8318
8319
8320
8321
8322
8323
8324
8325
8326
8327
8328
8329
8330
8331
8332
8333
8334
8335
8336
8337
8338
8339
8340
8341
8342
8343
8344
8345
8346
8347
8348
8349
8350
8351
8352
8353
8354
8355
8356
8357
8358
8359
8360
8361
8362
8363
8364
8365
8366
8367
8368
8369
8370
8371
8372
8373
8374
8375
8376
8377
8378
8379
8380
8381
8382
8383
8384
8385
8386
8387
8388
8389
8390
8391
8392
8393
8394
8395
8396
8397
8398
8399
8400
8401
8402
8403
8404
8405
8406
8407
8408
8409
8410
8411
8412
8413
8414
8415
8416
8417
8418
8419
8420
8421
8422
8423
8424
8425
8426
8427
8428
8429
8430
8431
8432
8433
8434
8435
8436
8437
8438
8439
8440
8441
8442
8443
8444
8445
8446
8447
8448
8449
8450
8451
8452
8453
8454
8455
8456
8457
8458
8459
8460
8461
8462
8463
8464
8465
8466
8467
8468
8469
8470
8471
8472
8473
8474
8475
8476
8477
8478
8479
8480
8481
8482
8483
8484
8485
8486
8487
8488
8489
8490
8491
8492
8493
8494
8495
8496
8497
8498
8499
8500
8501
8502
8503
8504
8505
8506
8507
8508
8509
8510
8511
8512
8513
8514
8515
8516
8517
8518
8519
8520
8521
8522
8523
8524
8525
8526
8527
8528
8529
8530
8531
8532
8533
8534
8535
8536
8537
8538
8539
8540
8541
8542
8543
8544
8545
8546
8547
8548
8549
8550
8551
8552
8553
8554
8555
8556
8557
8558
8559
8560
8561
8562
8563
8564
8565
8566
8567
8568
8569
8570
8571
8572
8573
8574
8575
8576
8577
8578
8579
8580
8581
8582
8583
8584
8585
8586
8587
8588
8589
8590
8591
8592
8593
8594
8595
8596
8597
8598
8599
8600
8601
8602
8603
8604
8605
8606
8607
8608
8609
8610
8611
8612
8613
8614
8615
8616
8617
8618
8619
8620
8621
8622
8623
8624
8625
8626
8627
8628
8629
8630
8631
8632
8633
8634
8635
8636
8637
8638
8639
8640
8641
8642
8643
8644
8645
8646
8647
8648
8649
8650
8651
8652
8653
8654
8655
8656
8657
8658
8659
8660
8661
8662
8663
8664
8665
8666
8667
8668
8669
8670
8671
8672
8673
8674
8675
8676
8677
8678
8679
8680
8681
8682
8683
8684
8685
8686
8687
8688
8689
8690
8691
8692
8693
8694
8695
8696
8697
8698
8699
8700
8701
8702
8703
8704
8705
8706
8707
8708
8709
8710
8711
8712
8713
8714
8715
8716
8717
8718
8719
8720
8721
8722
8723
8724
8725
8726
8727
8728
8729
8730
8731
8732
8733
8734
8735
8736
8737
8738
8739
8740
8741
8742
8743
8744
8745
8746
8747
8748
8749
8750
8751
8752
8753
8754
8755
8756
8757
8758
8759
8760
8761
8762
8763
8764
8765
8766
8767
8768
8769
8770
8771
8772
8773
8774
8775
8776
8777
8778
8779
8780
8781
8782
8783
8784
8785
8786
8787
8788
8789
8790
8791
8792
8793
8794
8795
8796
8797
8798
8799
8800
8801
8802
8803
8804
8805
8806
8807
8808
8809
8810
8811
8812
8813
8814
8815
8816
8817
8818
8819
8820
8821
8822
8823
8824
8825
8826
8827
8828
8829
8830
8831
8832
8833
8834
8835
8836
8837
8838
8839
8840
8841
8842
8843
8844
8845
8846
8847
8848
8849
8850
8851
8852
8853
8854
8855
8856
8857
8858
8859
8860
8861
8862
8863
8864
8865
8866
8867
8868
8869
8870
8871
8872
8873
8874
8875
8876
8877
8878
8879
8880
8881
8882
8883
8884
8885
8886
8887
8888
8889
8890
8891
8892
8893
8894
8895
8896
8897
8898
8899
8900
8901
8902
8903
8904
8905
8906
8907
8908
8909
8910
8911
8912
8913
8914
8915
8916
8917
8918
8919
8920
8921
8922
8923
8924
8925
8926
8927
8928
8929
8930
8931
8932
8933
8934
8935
8936
8937
8938
8939
8940
8941
8942
8943
8944
8945
8946
8947
8948
8949
8950
8951
8952
8953
8954
8955
8956
8957
8958
8959
8960
8961
8962
8963
8964
8965
8966
8967
8968
8969
8970
8971
8972
8973
8974
8975
8976
8977
8978
8979
8980
8981
8982
8983
8984
8985
8986
8987
8988
8989
8990
8991
8992
8993
8994
8995
8996
8997
8998
8999
9000
9001
9002
9003
9004
9005
9006
9007
9008
9009
9010
9011
9012
9013
9014
9015
9016
9017
9018
9019
9020
9021
9022
9023
9024
9025
9026
9027
9028
9029
9030
9031
9032
9033
9034
9035
9036
9037
9038
9039
9040
9041
9042
9043
9044
9045
9046
9047
9048
9049
9050
9051
9052
9053
9054
9055
9056
9057
9058
9059
9060
9061
9062
9063
9064
9065
9066
9067
9068
9069
9070
9071
9072
9073
9074
9075
9076
9077
9078
9079
9080
9081
9082
9083
9084
9085
9086
9087
9088
9089
9090
9091
9092
9093
9094
9095
9096
9097
9098
9099
9100
9101
9102
9103
9104
9105
9106
9107
9108
9109
9110
9111
9112
9113
9114
9115
9116
9117
9118
9119
9120
9121
9122
9123
9124
9125
9126
9127
9128
9129
9130
9131
9132
9133
9134
9135
9136
9137
9138
9139
9140
9141
9142
9143
9144
9145
9146
9147
9148
9149
9150
9151
9152
9153
9154
9155
9156
9157
9158
9159
9160
9161
9162
9163
9164
9165
9166
9167
9168
9169
9170
9171
9172
9173
9174
9175
9176
9177
9178
9179
9180
9181
9182
9183
9184
9185
9186
9187
9188
9189
9190
9191
9192
9193
9194
9195
9196
9197
9198
9199
9200
9201
9202
9203
9204
9205
9206
9207
9208
9209
9210
9211
9212
9213
9214
9215
9216
9217
9218
9219
9220
9221
9222
9223
9224
9225
9226
9227
9228
9229
9230
9231
9232
9233
9234
9235
9236
9237
9238
9239
9240
9241
9242
9243
9244
9245
9246
9247
9248
9249
9250
9251
9252
9253
9254
9255
9256
9257
9258
9259
9260
9261
9262
9263
9264
9265
9266
9267
9268
9269
9270
9271
9272
9273
9274
9275
9276
9277
9278
9279
9280
9281
9282
9283
9284
9285
9286
9287
9288
9289
9290
9291
9292
9293
9294
9295
9296
9297
9298
9299
9300
9301
9302
9303
9304
9305
9306
9307
9308
9309
9310
9311
9312
9313
9314
9315
9316
9317
9318
9319
9320
9321
9322
9323
9324
9325
9326
9327
9328
9329
9330
9331
9332
9333
9334
9335
9336
9337
9338
9339
9340
9341
9342
9343
9344
9345
9346
9347
9348
9349
9350
9351
9352
9353
9354
9355
9356
9357
9358
9359
9360
9361
9362
9363
9364
9365
9366
9367
9368
9369
9370
9371
9372
9373
9374
9375
9376
9377
9378
9379
9380
9381
9382
9383
9384
9385
9386
9387
9388
9389
9390
9391
9392
9393
9394
9395
9396
9397
9398
9399
9400
9401
9402
9403
9404
9405
9406
9407
9408
9409
9410
9411
9412
9413
9414
9415
9416
9417
9418
9419
9420
9421
9422
9423
9424
9425
9426
9427
9428
9429
9430
9431
9432
9433
9434
9435
9436
9437
9438
9439
9440
9441
9442
9443
9444
9445
9446
9447
9448
9449
9450
9451
9452
9453
9454
9455
9456
9457
9458
9459
9460
9461
9462
9463
9464
9465
9466
9467
9468
9469
9470
9471
9472
9473
9474
9475
9476
9477
9478
9479
9480
9481
9482
9483
9484
9485
9486
9487
9488
9489
9490
9491
9492
9493
9494
9495
9496
9497
9498
9499
9500
9501
9502
9503
9504
9505
9506
9507
9508
9509
9510
9511
9512
9513
9514
9515
9516
9517
9518
9519
9520
9521
9522
9523
9524
9525
9526
9527
9528
9529
9530
9531
9532
9533
9534
9535
9536
9537
9538
9539
9540
9541
9542
9543
9544
9545
9546
9547
9548
9549
9550
9551
9552
9553
9554
9555
9556
9557
9558
9559
9560
9561
9562
9563
9564
9565
9566
9567
9568
9569
9570
9571
9572
9573
9574
9575
9576
9577
9578
9579
9580
9581
9582
9583
9584
9585
9586
9587
9588
9589
9590
9591
9592
9593
9594
9595
9596
9597
9598
9599
9600
9601
9602
9603
9604
9605
9606
9607
9608
9609
9610
9611
9612
9613
9614
9615
9616
9617
9618
9619
9620
9621
9622
9623
9624
9625
9626
9627
9628
9629
9630
9631
9632
9633
9634
9635
9636
9637
9638
9639
9640
9641
9642
9643
9644
9645
9646
9647
9648
9649
9650
9651
9652
9653
9654
9655
9656
9657
9658
9659
9660
9661
9662
9663
9664
9665
9666
9667
9668
9669
9670
9671
9672
9673
9674
9675
9676
9677
9678
9679
9680
9681
9682
9683
9684
9685
9686
9687
9688
9689
9690
9691
9692
9693
9694
9695
9696
9697
9698
9699
9700
9701
9702
9703
9704
9705
9706
9707
9708
9709
9710
9711
9712
9713
9714
9715
9716
9717
9718
9719
9720
9721
9722
9723
9724
9725
9726
9727
9728
9729
9730
9731
9732
9733
9734
9735
9736
9737
9738
9739
9740
9741
9742
9743
9744
9745
9746
9747
9748
9749
9750
9751
9752
9753
9754
9755
9756
9757
9758
9759
9760
9761
9762
9763
9764
9765
9766
9767
9768
9769
9770
9771
9772
9773
9774
9775
9776
9777
9778
9779
9780
9781
9782
9783
9784
9785
9786
9787
9788
9789
9790
9791
9792
9793
9794
9795
9796
9797
9798
9799
9800
9801
9802
9803
9804
9805
9806
9807
9808
9809
9810
9811
9812
9813
9814
9815
9816
9817
9818
9819
9820
9821
9822
9823
9824
9825
9826
9827
9828
9829
9830
9831
9832
9833
9834
9835
9836
9837
9838
9839
9840
9841
9842
9843
9844
9845
9846
9847
9848
9849
9850
9851
9852
9853
9854
9855
9856
9857
9858
9859
9860
9861
9862
9863
9864
9865
9866
9867
9868
9869
9870
9871
9872
9873
9874
9875
9876
9877
9878
9879
9880
9881
9882
9883
9884
9885
9886
9887
9888
9889
9890
9891
9892
9893
9894
9895
9896
9897
9898
9899
9900
9901
9902
9903
9904
9905
9906
9907
9908
9909
9910
9911
9912
9913
9914
9915
9916
9917
9918
9919
9920
9921
9922
9923
9924
9925
9926
9927
9928
9929
9930
9931
9932
9933
9934
9935
9936
9937
9938
9939
9940
9941
9942
9943
9944
9945
9946
9947
9948
9949
9950
9951
9952
9953
9954
9955
9956
9957
9958
9959
9960
9961
9962
9963
9964
9965
9966
9967
9968
9969
9970
9971
9972
9973
9974
9975
9976
9977
9978
9979
9980
9981
9982
9983
9984
9985
9986
9987
9988
9989
9990
9991
9992
9993
9994
9995
9996
9997
9998
9999
10000
10001
10002
10003
10004
10005
10006
10007
10008
10009
10010
10011
10012
10013
10014
10015
10016
10017
10018
10019
10020
10021
10022
10023
10024
10025
10026
10027
10028
10029
10030
10031
10032
10033
10034
10035
10036
10037
10038
10039
10040
10041
10042
10043
10044
10045
10046
10047
10048
10049
10050
10051
10052
10053
10054
10055
10056
10057
10058
10059
10060
10061
10062
10063
10064
10065
10066
10067
10068
10069
10070
10071
10072
10073
10074
10075
10076
10077
10078
10079
10080
10081
10082
10083
10084
10085
10086
10087
10088
10089
10090
10091
10092
10093
10094
10095
10096
10097
10098
10099
10100
10101
10102
10103
10104
10105
10106
10107
10108
10109
10110
10111
10112
10113
10114
10115
10116
10117
10118
10119
10120
10121
10122
10123
10124
10125
10126
10127
10128
10129
10130
10131
10132
10133
10134
10135
10136
10137
10138
10139
10140
10141
10142
10143
10144
10145
10146
10147
10148
10149
10150
10151
10152
10153
10154
10155
10156
10157
10158
10159
10160
10161
10162
10163
10164
10165
10166
10167
10168
10169
10170
10171
10172
10173
10174
10175
10176
10177
10178
10179
10180
10181
10182
10183
10184
10185
10186
10187
10188
10189
10190
10191
10192
10193
10194
10195
10196
10197
10198
10199
10200
10201
10202
10203
10204
10205
10206
10207
10208
10209
10210
10211
10212
10213
10214
10215
10216
10217
10218
10219
10220
10221
10222
10223
10224
10225
10226
10227
10228
10229
10230
10231
10232
10233
10234
10235
10236
10237
10238
10239
10240
10241
10242
10243
10244
10245
10246
10247
10248
10249
10250
10251
10252
10253
10254
10255
10256
10257
10258
10259
10260
10261
10262
10263
10264
10265
10266
10267
10268
10269
10270
10271
10272
10273
10274
10275
10276
10277
10278
10279
10280
10281
10282
10283
10284
10285
10286
10287
10288
10289
10290
10291
10292
10293
10294
10295
10296
10297
10298
10299
10300
10301
10302
10303
10304
10305
10306
10307
10308
10309
10310
10311
10312
10313
10314
10315
10316
10317
10318
10319
10320
10321
10322
10323
10324
10325
10326
10327
10328
10329
10330
10331
10332
10333
10334
10335
10336
10337
10338
10339
10340
10341
10342
10343
10344
10345
10346
10347
10348
10349
10350
10351
10352
10353
10354
10355
10356
10357
10358
10359
10360
10361
10362
10363
10364
10365
10366
10367
10368
10369
10370
10371
10372
10373
10374
10375
10376
10377
10378
10379
10380
10381
10382
10383
10384
10385
10386
10387
10388
10389
10390
10391
10392
10393
10394
10395
10396
10397
10398
10399
10400
10401
10402
10403
10404
10405
10406
10407
10408
10409
10410
10411
10412
10413
10414
10415
10416
10417
10418
10419
10420
10421
10422
10423
10424
10425
10426
10427
10428
10429
10430
10431
10432
10433
10434
10435
10436
10437
10438
10439
10440
10441
10442
10443
10444
10445
10446
10447
10448
10449
10450
10451
10452
10453
10454
10455
10456
10457
10458
10459
10460
10461
10462
10463
10464
10465
10466
10467
10468
10469
10470
10471
10472
10473
10474
10475
10476
10477
10478
10479
10480
10481
10482
10483
10484
10485
10486
10487
10488
10489
10490
10491
10492
10493
10494
10495
10496
10497
10498
10499
10500
10501
10502
10503
10504
10505
10506
10507
10508
10509
10510
10511
10512
10513
10514
10515
10516
10517
10518
10519
10520
10521
10522
10523
10524
10525
10526
10527
10528
10529
10530
10531
10532
10533
10534
10535
10536
10537
10538
10539
10540
10541
10542
10543
10544
10545
10546
10547
10548
10549
10550
10551
10552
10553
10554
10555
10556
10557
10558
10559
10560
10561
10562
10563
10564
10565
10566
10567
10568
10569
10570
10571
10572
10573
10574
10575
10576
10577
10578
10579
10580
10581
10582
10583
10584
10585
10586
10587
10588
10589
10590
10591
10592
10593
10594
10595
10596
10597
10598
10599
10600
10601
10602
10603
10604
10605
10606
10607
10608
10609
10610
10611
10612
10613
10614
10615
10616
10617
10618
10619
10620
10621
10622
10623
10624
10625
10626
10627
10628
10629
10630
10631
10632
10633
10634
10635
10636
10637
10638
10639
10640
10641
10642
10643
10644
10645
10646
10647
10648
10649
10650
10651
10652
10653
10654
10655
10656
10657
10658
10659
10660
10661
10662
10663
10664
10665
10666
10667
10668
10669
10670
10671
10672
10673
10674
10675
10676
10677
10678
10679
10680
10681
10682
10683
10684
10685
10686
10687
10688
10689
10690
10691
10692
10693
10694
10695
10696
10697
10698
10699
10700
10701
10702
10703
10704
10705
10706
10707
10708
10709
10710
10711
10712
10713
10714
10715
10716
10717
10718
10719
10720
10721
10722
10723
10724
10725
10726
10727
10728
10729
10730
10731
10732
10733
10734
10735
10736
10737
10738
10739
10740
10741
10742
10743
10744
10745
10746
10747
10748
10749
10750
10751
10752
10753
10754
10755
10756
10757
10758
10759
10760
10761
10762
10763
10764
10765
10766
10767
10768
10769
10770
10771
10772
10773
10774
10775
10776
10777
10778
10779
10780
10781
10782
10783
10784
10785
10786
10787
10788
10789
10790
10791
10792
10793
10794
10795
10796
10797
10798
10799
10800
10801
10802
10803
10804
10805
10806
10807
10808
10809
10810
10811
10812
10813
10814
10815
10816
10817
10818
10819
10820
10821
10822
10823
10824
10825
10826
10827
10828
10829
10830
10831
10832
10833
10834
10835
10836
10837
10838
10839
10840
10841
10842
10843
10844
10845
10846
10847
10848
10849
10850
10851
10852
10853
10854
10855
10856
10857
10858
10859
10860
10861
10862
10863
10864
10865
10866
10867
10868
10869
10870
10871
10872
10873
10874
10875
10876
10877
10878
10879
10880
10881
10882
10883
10884
10885
10886
10887
10888
10889
10890
10891
10892
10893
10894
10895
10896
10897
10898
10899
10900
10901
10902
10903
10904
10905
10906
10907
10908
10909
10910
10911
10912
10913
10914
10915
10916
10917
10918
10919
10920
10921
10922
10923
10924
10925
10926
10927
10928
10929
10930
10931
10932
10933
10934
10935
10936
10937
10938
10939
10940
10941
10942
10943
10944
10945
10946
10947
10948
10949
10950
10951
10952
10953
10954
10955
10956
10957
10958
10959
10960
10961
10962
10963
10964
10965
10966
10967
10968
10969
10970
10971
10972
10973
10974
10975
10976
10977
10978
10979
10980
10981
10982
10983
10984
10985
10986
10987
10988
10989
10990
10991
10992
10993
10994
10995
10996
10997
10998
10999
11000
11001
11002
11003
11004
11005
11006
11007
11008
11009
11010
11011
11012
11013
11014
11015
11016
11017
11018
11019
11020
11021
11022
11023
11024
11025
11026
11027
11028
11029
11030
11031
11032
11033
11034
11035
11036
11037
11038
11039
11040
11041
11042
11043
11044
11045
11046
11047
11048
11049
11050
11051
11052
11053
11054
11055
11056
11057
11058
11059
11060
11061
11062
11063
11064
11065
11066
11067
11068
11069
11070
11071
11072
11073
11074
11075
11076
11077
11078
11079
11080
11081
11082
11083
11084
11085
11086
11087
11088
11089
11090
11091
11092
11093
11094
11095
11096
11097
11098
11099
11100
11101
11102
11103
11104
11105
11106
11107
11108
11109
11110
11111
11112
11113
11114
11115
11116
11117
11118
11119
11120
11121
11122
11123
11124
11125
11126
11127
11128
11129
11130
11131
11132
11133
11134
11135
11136
11137
11138
11139
11140
11141
11142
11143
11144
11145
11146
11147
11148
11149
11150
11151
11152
11153
11154
11155
11156
11157
11158
11159
11160
11161
11162
11163
11164
11165
11166
11167
11168
11169
11170
11171
11172
11173
11174
11175
11176
11177
11178
11179
11180
11181
11182
11183
11184
11185
11186
11187
11188
11189
11190
11191
11192
11193
11194
11195
11196
11197
11198
11199
11200
11201
11202
11203
11204
11205
11206
11207
11208
11209
11210
11211
11212
11213
11214
11215
11216
11217
11218
11219
11220
11221
11222
11223
11224
11225
11226
11227
11228
11229
11230
11231
11232
11233
11234
11235
11236
11237
11238
11239
11240
11241
11242
11243
11244
11245
11246
11247
11248
11249
11250
11251
11252
11253
11254
11255
11256
11257
11258
11259
11260
11261
11262
11263
11264
11265
11266
11267
11268
11269
11270
11271
11272
11273
11274
11275
11276
11277
11278
11279
11280
11281
11282
11283
11284
11285
11286
11287
11288
11289
11290
11291
11292
11293
11294
11295
11296
11297
11298
11299
11300
11301
11302
11303
11304
11305
11306
11307
11308
11309
11310
11311
11312
11313
11314
11315
11316
11317
11318
11319
11320
11321
11322
11323
11324
11325
11326
11327
11328
11329
11330
11331
11332
11333
11334
11335
11336
11337
11338
11339
11340
11341
11342
11343
11344
11345
11346
11347
11348
11349
11350
11351
11352
11353
11354
11355
11356
11357
11358
11359
11360
11361
11362
11363
11364
11365
11366
11367
11368
11369
11370
11371
11372
11373
11374
11375
11376
11377
11378
11379
11380
11381
11382
11383
11384
11385
11386
11387
11388
11389
11390
11391
11392
11393
11394
11395
11396
11397
11398
11399
11400
11401
11402
11403
11404
11405
11406
11407
11408
11409
11410
11411
11412
11413
11414
11415
11416
11417
11418
11419
11420
11421
11422
11423
11424
11425
11426
11427
11428
11429
11430
11431
11432
11433
11434
11435
11436
11437
11438
11439
11440
11441
11442
11443
11444
11445
11446
11447
11448
11449
11450
11451
11452
11453
11454
11455
11456
11457
11458
11459
11460
11461
11462
11463
11464
11465
11466
11467
11468
11469
11470
11471
11472
11473
11474
11475
11476
11477
11478
11479
11480
11481
11482
11483
11484
11485
11486
11487
11488
11489
11490
11491
11492
11493
11494
11495
11496
11497
11498
11499
11500
11501
11502
11503
11504
11505
11506
11507
11508
11509
11510
11511
11512
11513
11514
11515
11516
11517
11518
11519
11520
11521
11522
11523
11524
11525
11526
11527
11528
11529
11530
11531
11532
11533
11534
11535
11536
11537
11538
11539
11540
11541
11542
11543
11544
11545
11546
11547
11548
11549
11550
11551
11552
11553
11554
11555
11556
11557
11558
11559
11560
11561
11562
11563
11564
11565
11566
11567
11568
11569
11570
11571
11572
11573
11574
11575
11576
11577
11578
11579
11580
11581
11582
11583
11584
11585
11586
11587
11588
11589
11590
11591
11592
11593
11594
11595
11596
11597
11598
11599
11600
11601
11602
11603
11604
11605
11606
11607
11608
11609
11610
11611
11612
11613
11614
11615
11616
11617
11618
11619
11620
11621
11622
11623
11624
11625
11626
11627
11628
11629
11630
11631
11632
11633
11634
11635
11636
11637
11638
11639
11640
11641
11642
11643
11644
11645
11646
11647
11648
11649
11650
11651
11652
11653
11654
11655
11656
11657
11658
11659
11660
11661
11662
11663
11664
11665
11666
11667
11668
11669
11670
11671
11672
11673
11674
11675
11676
11677
11678
11679
11680
11681
11682
11683
11684
11685
11686
11687
11688
11689
11690
11691
11692
11693
11694
11695
11696
11697
11698
11699
11700
11701
11702
11703
11704
11705
11706
11707
11708
11709
11710
11711
11712
11713
11714
11715
11716
11717
11718
11719
11720
11721
11722
11723
11724
11725
11726
11727
11728
11729
11730
11731
11732
11733
11734
11735
11736
11737
11738
11739
11740
11741
11742
11743
11744
11745
11746
11747
11748
11749
11750
11751
11752
11753
11754
11755
11756
11757
11758
11759
11760
11761
11762
11763
11764
11765
11766
11767
11768
11769
11770
11771
11772
11773
11774
11775
11776
11777
11778
11779
11780
11781
11782
11783
11784
11785
11786
11787
11788
11789
11790
11791
11792
11793
11794
11795
11796
11797
11798
11799
11800
11801
11802
11803
11804
11805
11806
11807
11808
11809
11810
11811
11812
11813
11814
11815
11816
11817
11818
11819
11820
11821
11822
11823
11824
11825
11826
11827
11828
11829
11830
11831
11832
11833
11834
11835
11836
11837
11838
11839
11840
11841
11842
11843
11844
11845
11846
11847
11848
11849
\input texinfo  @c -*-texinfo-*-
@c %**start of header
@setfilename g77.info

@set last-update 2004-03-21
@set copyrights-g77 1995,1996,1997,1998,1999,2000,2001,2002,2003,2004

@include root.texi

@c This tells @include'd files that they're part of the overall G77 doc
@c set.  (They might be part of a higher-level doc set too.)
@set DOC-G77

@c @setfilename useg77.info
@c @setfilename portg77.info
@c To produce the full manual, use the "g77.info" setfilename, and
@c make sure the following do NOT begin with '@c' (and the @clear lines DO)
@set INTERNALS
@set USING
@c To produce a user-only manual, use the "useg77.info" setfilename, and
@c make sure the following does NOT begin with '@c':
@c @clear INTERNALS
@c To produce a porter-only manual, use the "portg77.info" setfilename,
@c and make sure the following does NOT begin with '@c':
@c @clear USING

@ifset INTERNALS
@ifset USING
@settitle Using and Porting GNU Fortran
@end ifset
@end ifset
@c seems reasonable to assume at least one of INTERNALS or USING is set...
@ifclear INTERNALS
@settitle Using GNU Fortran
@end ifclear
@ifclear USING
@settitle Porting GNU Fortran
@end ifclear
@c then again, have some fun
@ifclear INTERNALS
@ifclear USING
@settitle Doing Squat with GNU Fortran
@end ifclear
@end ifclear

@syncodeindex fn cp
@syncodeindex vr cp
@c %**end of header

@c Cause even numbered pages to be printed on the left hand side of
@c the page and odd numbered pages to be printed on the right hand
@c side of the page.  Using this, you can print on both sides of a
@c sheet of paper and have the text on the same part of the sheet.

@c The text on right hand pages is pushed towards the right hand
@c margin and the text on left hand pages is pushed toward the left
@c hand margin.
@c (To provide the reverse effect, set bindingoffset to -0.75in.)

@c @tex
@c \global\bindingoffset=0.75in
@c \global\normaloffset =0.75in
@c @end tex

@copying
Copyright @copyright{} @value{copyrights-g77} Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being ``GNU General Public License'' and ``Funding
Free Software'', the Front-Cover
texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below).  A copy of the license is included in the section entitled
``GNU Free Documentation License''.

(a) The FSF's Front-Cover Text is:

     A GNU Manual

(b) The FSF's Back-Cover Text is:

     You have freedom to copy and modify this GNU Manual, like GNU
     software.  Copies published by the Free Software Foundation raise
     funds for GNU development.
@end copying

@ifinfo
@dircategory Programming
@direntry
* g77: (g77).                  The GNU Fortran compiler.
@end direntry
@ifset INTERNALS
@ifset USING
This file documents the use and the internals of the GNU Fortran (@command{g77})
compiler.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifset
@end ifset
@ifclear USING
This file documents the internals of the GNU Fortran (@command{g77}) compiler.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear
@ifclear INTERNALS
This file documents the use of the GNU Fortran (@command{g77}) compiler.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear

Published by the Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA

@insertcopying
@end ifinfo

Contributed by James Craig Burley (@email{@value{email-burley}}).
Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that
was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}).

@setchapternewpage odd
@titlepage
@ifset INTERNALS
@ifset USING
@center @titlefont{Using and Porting GNU Fortran}

@end ifset
@end ifset
@ifclear INTERNALS
@title Using GNU Fortran
@end ifclear
@ifclear USING
@title Porting GNU Fortran
@end ifclear
@sp 2
@center James Craig Burley
@sp 3
@center Last updated @value{last-update}
@sp 1
@center for version @value{which-g77}
@page
@vskip 0pt plus 1filll
For the @value{which-g77} Version*
@sp 1
Published by the Free Software Foundation @*
59 Temple Place - Suite 330@*
Boston, MA 02111-1307, USA@*
@c Last printed ??ber, 19??.@*
@c Printed copies are available for $? each.@*
@c ISBN ???
@sp 1
@insertcopying
@end titlepage
@summarycontents
@contents
@page

@node Top, Copying,, (DIR)
@top Introduction
@cindex Introduction

@ifset INTERNALS
@ifset USING
This manual documents how to run, install and port @command{g77},
as well as its new features and incompatibilities,
and how to report bugs.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifset
@end ifset

@ifclear INTERNALS
This manual documents how to run and install @command{g77},
as well as its new features and incompatibilities, and how to report
bugs.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear
@ifclear USING
This manual documents how to port @command{g77},
as well as its new features and incompatibilities,
and how to report bugs.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear

@ifset DEVELOPMENT
@emph{Warning:} This document is still under development,
and might not accurately reflect the @command{g77} code base
of which it is a part.
Efforts are made to keep it somewhat up-to-date,
but they are particularly concentrated
on any version of this information
that is distributed as part of a @emph{released} @command{g77}.

In particular, while this document is intended to apply to
the @value{which-g77} version of @command{g77},
only an official @emph{release} of that version
is expected to contain documentation that is
most consistent with the @command{g77} product in that version.
@end ifset

@menu
* Copying::         GNU General Public License says
                    how you can copy and share GNU Fortran.
* GNU Free Documentation License::
		    How you can copy and share this manual.
* Contributors::    People who have contributed to GNU Fortran.
* Funding::         How to help assure continued work for free software.
* Funding GNU Fortran::  How to help assure continued work on GNU Fortran.
@ifset USING
* Getting Started:: Finding your way around this manual.
* What is GNU Fortran?::  How @command{g77} fits into the universe.
* G77 and GCC::     You can compile Fortran, C, or other programs.
* Invoking G77::    Command options supported by @command{g77}.
* News::            News about recent releases of @command{g77}.
* Changes::         User-visible changes to recent releases of @command{g77}.
* Language::        The GNU Fortran language.
* Compiler::        The GNU Fortran compiler.
* Other Dialects::  Dialects of Fortran supported by @command{g77}.
* Other Compilers:: Fortran compilers other than @command{g77}.
* Other Languages:: Languages other than Fortran.
* Debugging and Interfacing::  How @command{g77} generates code.
* Collected Fortran Wisdom::  How to avoid Trouble.
* Trouble::         If you have trouble with GNU Fortran.
* Open Questions::  Things we'd like to know.
* Bugs::            How, why, and where to report bugs.
* Service::         How to find suppliers of support for GNU Fortran.
@end ifset
@ifset INTERNALS
* Adding Options::  Guidance on teaching @command{g77} about new options.
* Projects::        Projects for @command{g77} internals hackers.
* Front End::       Design and implementation of the @command{g77} front end.
@end ifset

* M: Diagnostics.   Diagnostics produced by @command{g77}.

* Keyword Index::   Index of concepts and symbol names.
@end menu
@c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!

@include gpl.texi

@include fdl.texi

@node Contributors
@unnumbered Contributors to GNU Fortran
@cindex contributors
@cindex credits

In addition to James Craig Burley, who wrote the front end,
many people have helped create and improve GNU Fortran.

@itemize @bullet
@item
The packaging and compiler portions of GNU Fortran are based largely
on the GCC compiler.
@xref{Contributors,,Contributors to GCC,gcc,Using the GNU Compiler
Collection (GCC)},
for more information.

@item
The run-time library used by GNU Fortran is a repackaged version
of the @code{libf2c} library (combined from the @code{libF77} and
@code{libI77} libraries) provided as part of @command{f2c}, available for
free from @code{netlib} sites on the Internet.

@item
Cygnus Support and The Free Software Foundation contributed
significant money and/or equipment to Craig's efforts.

@item
The following individuals served as alpha testers prior to @command{g77}'s
public release.  This work consisted of testing, researching, sometimes
debugging, and occasionally providing small amounts of code and fixes
for @command{g77}, plus offering plenty of helpful advice to Craig:

@itemize @w{}
@item
Jonathan Corbet
@item
Dr.@: Mark Fernyhough
@item
Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
@item
Kate Hedstrom
@item
Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
@item
Dr.@: A. O. V. Le Blanc
@item
Dave Love
@item
Rick Lutowski
@item
Toon Moene
@item
Rick Niles
@item
Derk Reefman
@item
Wayne K. Schroll
@item
Bill Thorson
@item
Pedro A. M. Vazquez
@item
Ian Watson
@end itemize

@item
Dave Love (@email{d.love@@dl.ac.uk})
wrote the libU77 part of the run-time library.

@item
Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
provided the patch to add rudimentary support
for @code{INTEGER*1}, @code{INTEGER*2}, and
@code{LOGICAL*1}.
This inspired Craig to add further support,
even though the resulting support
would still be incomplete.
This support is believed to be completed at version 3.4
of @command{gcc} by Roger Sayle (@email{roger@@eyesopen.com}).

@item
David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
and encouraged Craig to rewrite the documentation in texinfo
format by contributing a first pass at a translation of the
old @file{g77-0.5.16/f/DOC} file.

@item
Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
some analysis of generated code as part of an overall project
to improve @command{g77} code generation to at least be as good
as @command{f2c} used in conjunction with @command{gcc}.
So far, this has resulted in the three, somewhat
experimental, options added by @command{g77} to the @command{gcc}
compiler and its back end.

(These, in turn, had made their way into the @code{egcs}
version of the compiler, and do not exist in @command{gcc}
version 2.8 or versions of @command{g77} based on that version
of @command{gcc}.)

@item
John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.

@item
Thanks to Mary Cortani and the staff at Craftwork Solutions
(@email{support@@craftwork.com}) for all of their support.

@item
Many other individuals have helped debug, test, and improve @command{g77}
over the past several years, and undoubtedly more people
will be doing so in the future.
If you have done so, and would like
to see your name listed in the above list, please ask!
The default is that people wish to remain anonymous.
@end itemize

@include funding.texi

@node Funding GNU Fortran
@chapter Funding GNU Fortran
@cindex funding improvements
@cindex improvements, funding

James Craig Burley (@email{@value{email-burley}}), the original author
of @command{g77}, stopped working on it in September 1999
(He has a web page at @uref{@value{www-burley}}.)

GNU Fortran is currently maintained by Toon Moene
(@email{toon@@moene.indiv.nluug.nl}), with the help of countless other
volunteers.

As with other GNU software, funding is important because it can pay for
needed equipment, personnel, and so on.

@cindex FSF, funding the
@cindex funding the FSF
The FSF provides information on the best way to fund ongoing
development of GNU software (such as GNU Fortran) in documents
such as the ``GNUS Bulletin''.
Email @email{gnu@@gnu.org} for information on funding the FSF.

Another important way to support work on GNU Fortran is to volunteer
to help out.

Email @email{@value{email-general}} to volunteer for this work.

However, we strongly expect that there will never be a version 0.6
of @command{g77}.  Work on this compiler has stopped as of the release
of GCC 3.1, except for bug fixing.  @command{g77} will be succeeded by
@command{g95} - see @uref{http://g95.sourceforge.net}.

@xref{Funding,,Funding Free Software}, for more information.

@node Getting Started
@chapter Getting Started
@cindex getting started
@cindex new users
@cindex newbies
@cindex beginners

If you don't need help getting started reading the portions
of this manual that are most important to you, you should skip
this portion of the manual.

If you are new to compilers, especially Fortran compilers, or
new to how compilers are structured under UNIX and UNIX-like
systems, you'll want to see @ref{What is GNU Fortran?}.

If you are new to GNU compilers, or have used only one GNU
compiler in the past and not had to delve into how it lets
you manage various versions and configurations of @command{gcc},
you should see @ref{G77 and GCC}.

Everyone except experienced @command{g77} users should
see @ref{Invoking G77}.

If you're acquainted with previous versions of @command{g77},
you should see @ref{News,,News About GNU Fortran}.
Further, if you've actually used previous versions of @command{g77},
especially if you've written or modified Fortran code to
be compiled by previous versions of @command{g77}, you
should see @ref{Changes}.

If you intend to write or otherwise compile code that is
not already strictly conforming ANSI FORTRAN 77---and this
is probably everyone---you should see @ref{Language}.

If you run into trouble getting Fortran code to compile,
link, run, or work properly, you might find answers
if you see @ref{Debugging and Interfacing},
see @ref{Collected Fortran Wisdom},
and see @ref{Trouble}.
You might also find that the problems you are encountering
are bugs in @command{g77}---see @ref{Bugs}, for information on
reporting them, after reading the other material.

If you need further help with @command{g77}, or with
freely redistributable software in general,
see @ref{Service}.

If you would like to help the @command{g77} project,
see @ref{Funding GNU Fortran}, for information on
helping financially, and see @ref{Projects}, for information
on helping in other ways.

If you're generally curious about the future of
@command{g77}, see @ref{Projects}.
If you're curious about its past,
see @ref{Contributors},
and see @ref{Funding GNU Fortran}.

To see a few of the questions maintainers of @command{g77} have,
and that you might be able to answer,
see @ref{Open Questions}.

@ifset USING
@node What is GNU Fortran?
@chapter What is GNU Fortran?
@cindex concepts, basic
@cindex basic concepts

GNU Fortran, or @command{g77}, is designed initially as a free replacement
for, or alternative to, the UNIX @command{f77} command.
(Similarly, @command{gcc} is designed as a replacement
for the UNIX @command{cc} command.)

@command{g77} also is designed to fit in well with the other
fine GNU compilers and tools.

Sometimes these design goals conflict---in such cases, resolution
often is made in favor of fitting in well with Project GNU.
These cases are usually identified in the appropriate
sections of this manual.

@cindex compilers
As compilers, @command{g77}, @command{gcc}, and @command{f77}
share the following characteristics:

@itemize @bullet
@cindex source code
@cindex file, source
@cindex code, source
@cindex source file
@item
They read a user's program, stored in a file and
containing instructions written in the appropriate
language (Fortran, C, and so on).
This file contains @dfn{source code}.

@cindex translation of user programs
@cindex machine code
@cindex code, machine
@cindex mistakes
@item
They translate the user's program into instructions
a computer can carry out more quickly than it takes
to translate the instructions in the first place.
These instructions are called @dfn{machine code}---code
designed to be efficiently translated and processed
by a machine such as a computer.
Humans usually aren't as good writing machine code
as they are at writing Fortran or C, because
it is easy to make tiny mistakes writing machine code.
When writing Fortran or C, it is easy
to make big mistakes.

@cindex debugger
@cindex bugs, finding
@cindex @command{gdb}, command
@cindex commands, @command{gdb}
@item
They provide information in the generated machine code
that can make it easier to find bugs in the program
(using a debugging tool, called a @dfn{debugger},
such as @command{gdb}).

@cindex libraries
@cindex linking
@cindex @command{ld} command
@cindex commands, @command{ld}
@item
They locate and gather machine code already generated
to perform actions requested by statements in
the user's program.
This machine code is organized
into @dfn{libraries} and is located and gathered
during the @dfn{link} phase of the compilation
process.
(Linking often is thought of as a separate
step, because it can be directly invoked via the
@command{ld} command.
However, the @command{g77} and @command{gcc}
commands, as with most compiler commands, automatically
perform the linking step by calling on @command{ld}
directly, unless asked to not do so by the user.)

@cindex language, incorrect use of
@cindex incorrect use of language
@item
They attempt to diagnose cases where the user's
program contains incorrect usages of the language.
The @dfn{diagnostics} produced by the compiler
indicate the problem and the location in the user's
source file where the problem was first noticed.
The user can use this information to locate and
fix the problem.
@cindex diagnostics, incorrect
@cindex incorrect diagnostics
@cindex error messages, incorrect
@cindex incorrect error messages
(Sometimes an incorrect usage
of the language leads to a situation where the
compiler can no longer make any sense of what
follows---while a human might be able to---and
thus ends up complaining about many ``problems''
it encounters that, in fact, stem from just one
problem, usually the first one reported.)

@cindex warnings
@cindex questionable instructions
@item
They attempt to diagnose cases where the user's
program contains a correct usage of the language,
but instructs the computer to do something questionable.
These diagnostics often are in the form of @dfn{warnings},
instead of the @dfn{errors} that indicate incorrect
usage of the language.
@end itemize

How these actions are performed is generally under the
control of the user.
Using command-line options, the user can specify
how persnickety the compiler is to be regarding
the program (whether to diagnose questionable usage
of the language), how much time to spend making
the generated machine code run faster, and so on.

@cindex components of @command{g77}
@cindex @command{g77}, components of
@command{g77} consists of several components:

@cindex @command{gcc}, command
@cindex commands, @command{gcc}
@itemize @bullet
@item
A modified version of the @command{gcc} command, which also might be
installed as the system's @command{cc} command.
(In many cases, @command{cc} refers to the
system's ``native'' C compiler, which
might be a non-GNU compiler, or an older version
of @command{gcc} considered more stable or that is
used to build the operating system kernel.)

@cindex @command{g77}, command
@cindex commands, @command{g77}
@item
The @command{g77} command itself, which also might be installed as the
system's @command{f77} command.

@cindex libg2c library
@cindex libf2c library
@cindex libraries, libf2c
@cindex libraries, libg2c
@cindex run-time, library
@item
The @code{libg2c} run-time library.
This library contains the machine code needed to support
capabilities of the Fortran language that are not directly
provided by the machine code generated by the @command{g77}
compilation phase.

@code{libg2c} is just the unique name @command{g77} gives
to its version of @code{libf2c} to distinguish it from
any copy of @code{libf2c} installed from @command{f2c}
(or versions of @command{g77} that built @code{libf2c} under
that same name)
on the system.

The maintainer of @code{libf2c} currently is
@email{dmg@@bell-labs.com}.

@cindex @code{f771}, program
@cindex programs, @code{f771}
@cindex assembler
@cindex @command{as} command
@cindex commands, @command{as}
@cindex assembly code
@cindex code, assembly
@item
The compiler itself, internally named @code{f771}.

Note that @code{f771} does not generate machine code directly---it
generates @dfn{assembly code} that is a more readable form
of machine code, leaving the conversion to actual machine code
to an @dfn{assembler}, usually named @command{as}.
@end itemize

@command{gcc} is often thought of as ``the C compiler'' only,
but it does more than that.
Based on command-line options and the names given for files
on the command line, @command{gcc} determines which actions to perform, including
preprocessing, compiling (in a variety of possible languages), assembling,
and linking.

@cindex driver, gcc command as
@cindex @command{gcc}, command as driver
@cindex executable file
@cindex files, executable
@cindex cc1 program
@cindex programs, cc1
@cindex preprocessor
@cindex cpp program
@cindex programs, cpp
For example, the command @samp{gcc foo.c} @dfn{drives} the file
@file{foo.c} through the preprocessor @command{cpp}, then
the C compiler (internally named
@code{cc1}), then the assembler (usually @command{as}), then the linker
(@command{ld}), producing an executable program named @file{a.out} (on
UNIX systems).

@cindex cc1plus program
@cindex programs, cc1plus
As another example, the command @samp{gcc foo.cc} would do much the same as
@samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
@command{gcc} would use the C++ compiler (named @code{cc1plus}).

@cindex @code{f771}, program
@cindex programs, @code{f771}
In a GNU Fortran installation, @command{gcc} recognizes Fortran source
files by name just like it does C and C++ source files.
It knows to use the Fortran compiler named @code{f771}, instead of
@code{cc1} or @code{cc1plus}, to compile Fortran files.

@cindex @command{gcc}, not recognizing Fortran source
@cindex unrecognized file format
@cindex file format not recognized
Non-Fortran-related operation of @command{gcc} is generally
unaffected by installing the GNU Fortran version of @command{gcc}.
However, without the installed version of @command{gcc} being the
GNU Fortran version, @command{gcc} will not be able to compile
and link Fortran programs---and since @command{g77} uses @command{gcc}
to do most of the actual work, neither will @command{g77}!

@cindex @command{g77}, command
@cindex commands, @command{g77}
The @command{g77} command is essentially just a front-end for
the @command{gcc} command.
Fortran users will normally use @command{g77} instead of @command{gcc},
because @command{g77}
knows how to specify the libraries needed to link with Fortran programs
(@code{libg2c} and @code{lm}).
@command{g77} can still compile and link programs and
source files written in other languages, just like @command{gcc}.

@cindex printing version information
@cindex version information, printing
The command @samp{g77 -v} is a quick
way to display lots of version information for the various programs
used to compile a typical preprocessed Fortran source file---this
produces much more output than @samp{gcc -v} currently does.
(If it produces an error message near the end of the output---diagnostics
from the linker, usually @command{ld}---you might
have an out-of-date @code{libf2c} that improperly handles
complex arithmetic.)
In the output of this command, the line beginning @samp{GNU Fortran Front
End} identifies the version number of GNU Fortran; immediately
preceding that line is a line identifying the version of @command{gcc}
with which that version of @command{g77} was built.

@cindex libf2c library
@cindex libraries, libf2c
The @code{libf2c} library is distributed with GNU Fortran for
the convenience of its users, but is not part of GNU Fortran.
It contains the procedures
needed by Fortran programs while they are running.

@cindex in-line code
@cindex code, in-line
For example, while code generated by @command{g77} is likely
to do additions, subtractions, and multiplications @dfn{in line}---in
the actual compiled code---it is not likely to do trigonometric
functions this way.

Instead, operations like trigonometric
functions are compiled by the @code{f771} compiler
(invoked by @command{g77} when compiling Fortran code) into machine
code that, when run, calls on functions in @code{libg2c}, so
@code{libg2c} must be linked with almost every useful program
having any component compiled by GNU Fortran.
(As mentioned above, the @command{g77} command takes
care of all this for you.)

The @code{f771} program represents most of what is unique to GNU Fortran.
While much of the @code{libg2c} component comes from
the @code{libf2c} component of @command{f2c},
a free Fortran-to-C converter distributed by Bellcore (AT&T),
plus @code{libU77}, provided by Dave Love,
and the @command{g77} command is just a small front-end to @command{gcc},
@code{f771} is a combination of two rather
large chunks of code.

@cindex GNU Back End (GBE)
@cindex GBE
@cindex @command{gcc}, back end
@cindex back end, gcc
@cindex code generator
One chunk is the so-called @dfn{GNU Back End}, or GBE,
which knows how to generate fast code for a wide variety of processors.
The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
@code{cc1plus}, and @code{f771}, plus others.
Often the GBE is referred to as the ``gcc back end'' or
even just ``gcc''---in this manual, the term GBE is used
whenever the distinction is important.

@cindex GNU Fortran Front End (FFE)
@cindex FFE
@cindex @command{g77}, front end
@cindex front end, @command{g77}
The other chunk of @code{f771} is the
majority of what is unique about GNU Fortran---the code that knows how
to interpret Fortran programs to determine what they are intending to
do, and then communicate that knowledge to the GBE for actual compilation
of those programs.
This chunk is called the @dfn{Fortran Front End} (FFE).
The @code{cc1} and @code{cc1plus} programs have their own front ends,
for the C and C++ languages, respectively.
These fronts ends are responsible for diagnosing
incorrect usage of their respective languages by the
programs the process, and are responsible for most of
the warnings about questionable constructs as well.
(The GBE handles producing some warnings, like those
concerning possible references to undefined variables.)

Because so much is shared among the compilers for various languages,
much of the behavior and many of the user-selectable options for these
compilers are similar.
For example, diagnostics (error messages and
warnings) are similar in appearance; command-line
options like @option{-Wall} have generally similar effects; and the quality
of generated code (in terms of speed and size) is roughly similar
(since that work is done by the shared GBE).

@node G77 and GCC
@chapter Compile Fortran, C, or Other Programs
@cindex compiling programs
@cindex programs, compiling

@cindex @command{gcc}, command
@cindex commands, @command{gcc}
A GNU Fortran installation includes a modified version of the @command{gcc}
command.

In a non-Fortran installation, @command{gcc} recognizes C, C++,
and Objective-C source files.

In a GNU Fortran installation, @command{gcc} also recognizes Fortran source
files and accepts Fortran-specific command-line options, plus some
command-line options that are designed to cater to Fortran users
but apply to other languages as well.

@xref{G++ and GCC,,Programming Languages Supported by GCC,gcc,Using
the GNU Compiler Collection (GCC)},
for information on the way different languages are handled
by the GCC compiler (@command{gcc}).

@cindex @command{g77}, command
@cindex commands, @command{g77}
Also provided as part of GNU Fortran is the @command{g77} command.
The @command{g77} command is designed to make compiling and linking Fortran
programs somewhat easier than when using the @command{gcc} command for
these tasks.
It does this by analyzing the command line somewhat and changing it
appropriately before submitting it to the @command{gcc} command.

@cindex -v option
@cindex @command{g77} options, -v
@cindex options, -v
Use the @option{-v} option with @command{g77}
to see what is going on---the first line of output is the invocation
of the @command{gcc} command.

@include invoke.texi

@include news.texi

@set USERVISONLY
@include news.texi
@clear USERVISONLY

@node Language
@chapter The GNU Fortran Language

@cindex standard, ANSI FORTRAN 77
@cindex ANSI FORTRAN 77 standard
@cindex reference works
GNU Fortran supports a variety of extensions to, and dialects
of, the Fortran language.
Its primary base is the ANSI FORTRAN 77 standard, currently available on
the network at
@uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
or as monolithic text at
@uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
It offers some extensions that are popular among users
of UNIX @command{f77} and @command{f2c} compilers, some that
are popular among users of other compilers (such as Digital
products), some that are popular among users of the
newer Fortran 90 standard, and some that are introduced
by GNU Fortran.

@cindex textbooks
(If you need a text on Fortran,
a few freely available electronic references have pointers from
@uref{http://www.fortran.com/F/books.html}.  There is a `cooperative
net project', @cite{User Notes on Fortran Programming} at
@uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
material might not apply specifically to @command{g77}.)

Part of what defines a particular implementation of a Fortran
system, such as @command{g77}, is the particular characteristics
of how it supports types, constants, and so on.
Much of this is left up to the implementation by the various
Fortran standards and accepted practice in the industry.

The GNU Fortran @emph{language} is described below.
Much of the material is organized along the same lines
as the ANSI FORTRAN 77 standard itself.

@xref{Other Dialects}, for information on features @command{g77} supports
that are not part of the GNU Fortran language.

@emph{Note}: This portion of the documentation definitely needs a lot
of work!

@menu
Relationship to the ANSI FORTRAN 77 standard:
* Direction of Language Development::  Where GNU Fortran is headed.
* Standard Support::  Degree of support for the standard.

Extensions to the ANSI FORTRAN 77 standard:
* Conformance::
* Notation Used::
* Terms and Concepts::
* Characters Lines Sequence::
* Data Types and Constants::
* Expressions::
* Specification Statements::
* Control Statements::
* Functions and Subroutines::
* Scope and Classes of Names::
* I/O::
* Fortran 90 Features::
@end menu

@node Direction of Language Development
@section Direction of Language Development
@cindex direction of language development
@cindex features, language
@cindex language, features

The purpose of the following description of the GNU Fortran
language is to promote wide portability of GNU Fortran programs.

GNU Fortran is an evolving language, due to the
fact that @command{g77} itself is in beta test.
Some current features of the language might later
be redefined as dialects of Fortran supported by @command{g77}
when better ways to express these features are added to @command{g77},
for example.
Such features would still be supported by
@command{g77}, but would be available only when
one or more command-line options were used.

The GNU Fortran @emph{language} is distinct from the
GNU Fortran @emph{compilation system} (@command{g77}).

For example, @command{g77} supports various dialects of
Fortran---in a sense, these are languages other than
GNU Fortran---though its primary
purpose is to support the GNU Fortran language, which also is
described in its documentation and by its implementation.

On the other hand, non-GNU compilers might offer
support for the GNU Fortran language, and are encouraged
to do so.

Currently, the GNU Fortran language is a fairly fuzzy object.
It represents something of a cross between what @command{g77} accepts
when compiling using the prevailing defaults and what this
document describes as being part of the language.

Future versions of @command{g77} are expected to clarify the
definition of the language in the documentation.
Often, this will mean adding new features to the language, in the form
of both new documentation and new support in @command{g77}.
However, it might occasionally mean removing a feature
from the language itself to ``dialect'' status.
In such a case, the documentation would be adjusted
to reflect the change, and @command{g77} itself would likely be changed
to require one or more command-line options to continue supporting
the feature.

The development of the GNU Fortran language is intended to strike
a balance between:

@itemize @bullet
@item
Serving as a mostly-upwards-compatible language from the
de facto UNIX Fortran dialect as supported by @command{f77}.

@item
Offering new, well-designed language features.
Attributes of such features include
not making existing code any harder to read
(for those who might be unaware that the new
features are not in use) and
not making state-of-the-art
compilers take longer to issue diagnostics,
among others.

@item
Supporting existing, well-written code without gratuitously
rejecting non-standard constructs, regardless of the origin
of the code (its dialect).

@item
Offering default behavior and command-line options to reduce
and, where reasonable, eliminate the need for programmers to make
any modifications to code that already works in existing
production environments.

@item
Diagnosing constructs that have different meanings in different
systems, languages, and dialects, while offering clear,
less ambiguous ways to express each of the different meanings
so programmers can change their code appropriately.
@end itemize

One of the biggest practical challenges for the developers of the
GNU Fortran language is meeting the sometimes contradictory demands
of the above items.

For example, a feature might be widely used in one popular environment,
but the exact same code that utilizes that feature might not work
as expected---perhaps it might mean something entirely different---in
another popular environment.

Traditionally, Fortran compilers---even portable ones---have solved this
problem by simply offering the appropriate feature to users of
the respective systems.
This approach treats users of various Fortran systems and dialects
as remote ``islands'', or camps, of programmers, and assume that these
camps rarely come into contact with each other (or,
especially, with each other's code).

Project GNU takes a radically different approach to software and language
design, in that it assumes that users of GNU software do not necessarily
care what kind of underlying system they are using, regardless
of whether they are using software (at the user-interface
level) or writing it (for example, writing Fortran or C code).

As such, GNU users rarely need consider just what kind of underlying
hardware (or, in many cases, operating system) they are using at any
particular time.
They can use and write software designed for a general-purpose,
widely portable, heterogeneous environment---the GNU environment.

In line with this philosophy, GNU Fortran must evolve into a product
that is widely ported and portable not only in the sense that it can
be successfully built, installed, and run by users, but in the larger
sense that its users can use it in the same way, and expect largely the
same behaviors from it, regardless of the kind of system they are using
at any particular time.

This approach constrains the solutions @command{g77} can use to resolve
conflicts between various camps of Fortran users.
If these two camps disagree about what a particular construct should
mean, @command{g77} cannot simply be changed to treat that particular construct as
having one meaning without comment (such as a warning), lest the users
expecting it to have the other meaning are unpleasantly surprised that
their code misbehaves when executed.

The use of the ASCII backslash character in character constants is
an excellent (and still somewhat unresolved) example of this kind of
controversy.
@xref{Backslash in Constants}.
Other examples are likely to arise in the future, as @command{g77} developers
strive to improve its ability to accept an ever-wider variety of existing
Fortran code without requiring significant modifications to said code.

Development of GNU Fortran is further constrained by the desire
to avoid requiring programmers to change their code.
This is important because it allows programmers, administrators,
and others to more faithfully evaluate and validate @command{g77}
(as an overall product and as new versions are distributed)
without having to support multiple versions of their programs
so that they continue to work the same way on their existing
systems (non-GNU perhaps, but possibly also earlier versions
of @command{g77}).

@node Standard Support
@section ANSI FORTRAN 77 Standard Support
@cindex ANSI FORTRAN 77 support
@cindex standard, support for
@cindex support, FORTRAN 77
@cindex compatibility, FORTRAN 77
@cindex FORTRAN 77 compatibility

GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
In summary, the only ANSI FORTRAN 77 features @command{g77} doesn't
support are those that are probably rarely used in actual code,
some of which are explicitly disallowed by the Fortran 90 standard.

@menu
* No Passing External Assumed-length::  CHAR*(*) CFUNC restriction.
* No Passing Dummy Assumed-length::     CHAR*(*) CFUNC restriction.
* No Pathological Implied-DO::          No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
* No Useless Implied-DO::               No @samp{(A, I=1, 1)}.
@end menu

@node No Passing External Assumed-length
@subsection No Passing External Assumed-length

@command{g77} disallows passing of an external procedure
as an actual argument if the procedure's
type is declared @code{CHARACTER*(*)}.  For example:

@example
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
@end example

@noindent
It isn't clear whether the standard considers this conforming.

@node No Passing Dummy Assumed-length
@subsection No Passing Dummy Assumed-length

@command{g77} disallows passing of a dummy procedure
as an actual argument if the procedure's
type is declared @code{CHARACTER*(*)}.

@example
SUBROUTINE BAR(CFUNC)
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
@end example

@noindent
It isn't clear whether the standard considers this conforming.

@node No Pathological Implied-DO
@subsection No Pathological Implied-DO

The @code{DO} variable for an implied-@code{DO} construct in a
@code{DATA} statement may not be used as the @code{DO} variable
for an outer implied-@code{DO} construct.  For example, this
fragment is disallowed by @command{g77}:

@smallexample
DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
@end smallexample

@noindent
This also is disallowed by Fortran 90, as it offers no additional
capabilities and would have a variety of possible meanings.

Note that it is @emph{very} unlikely that any production Fortran code
tries to use this unsupported construct.

@node No Useless Implied-DO
@subsection No Useless Implied-DO

An array element initializer in an implied-@code{DO} construct in a
@code{DATA} statement must contain at least one reference to the @code{DO}
variables of each outer implied-@code{DO} construct.  For example,
this fragment is disallowed by @command{g77}:

@smallexample
DATA (A, I= 1, 1) /1./
@end smallexample

@noindent
This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
requirements offer no additional capabilities.
However, @command{g77} doesn't necessarily diagnose all cases
where this requirement is not met.

Note that it is @emph{very} unlikely that any production Fortran code
tries to use this unsupported construct.

@node Conformance
@section Conformance

(The following information augments or overrides the information in
Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 1 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

The definition of the GNU Fortran language is akin to that of
the ANSI FORTRAN 77 language in that it does not generally require
conforming implementations to diagnose cases where programs do
not conform to the language.

However, @command{g77} as a compiler is being developed in a way that
is intended to enable it to diagnose such cases in an easy-to-understand
manner.

A program that conforms to the GNU Fortran language should, when
compiled, linked, and executed using a properly installed @command{g77}
system, perform as described by the GNU Fortran language definition.
Reasons for different behavior include, among others:

@itemize @bullet
@item
Use of resources (memory---heap, stack, and so on; disk space; CPU
time; etc.) exceeds those of the system.

@item
Range and/or precision of calculations required by the program
exceeds that of the system.

@item
Excessive reliance on behaviors that are system-dependent
(non-portable Fortran code).

@item
Bugs in the program.

@item
Bug in @command{g77}.

@item
Bugs in the system.
@end itemize

Despite these ``loopholes'', the availability of a clear specification
of the language of programs submitted to @command{g77}, as this document
is intended to provide, is considered an important aspect of providing
a robust, clean, predictable Fortran implementation.

The definition of the GNU Fortran language, while having no special
legal status, can therefore be viewed as a sort of contract, or agreement.
This agreement says, in essence, ``if you write a program in this language,
and run it in an environment (such as a @command{g77} system) that supports
this language, the program should behave in a largely predictable way''.

@node Notation Used
@section Notation Used in This Chapter

(The following information augments or overrides the information in
Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 1 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
and ``must not'' and ``may not'' denote prohibition.
Terms such as ``might'', ``should'', and ``can'' generally add little or
nothing in the way of weight to the GNU Fortran language itself,
but are used to explain or illustrate the language.

For example:

@display
``The @code{FROBNITZ} statement must precede all executable
statements in a program unit, and may not specify any dummy
arguments.  It may specify local or common variables and arrays.
Its use should be limited to portions of the program designed to
be non-portable and system-specific, because it might cause the
containing program unit to behave quite differently on different
systems.''
@end display

Insofar as the GNU Fortran language is specified,
the requirements and permissions denoted by the above sample statement
are limited to the placement of the statement and the kinds of
things it may specify.
The rest of the statement---the content regarding non-portable portions
of the program and the differing behavior of program units containing
the @code{FROBNITZ} statement---does not pertain the GNU Fortran
language itself.
That content offers advice and warnings about the @code{FROBNITZ}
statement.

@emph{Remember:} The GNU Fortran language definition specifies
both what constitutes a valid GNU Fortran program and how,
given such a program, a valid GNU Fortran implementation is
to interpret that program.

It is @emph{not} incumbent upon a valid GNU Fortran implementation
to behave in any particular way, any consistent way, or any
predictable way when it is asked to interpret input that is
@emph{not} a valid GNU Fortran program.

Such input is said to have @dfn{undefined} behavior when
interpreted by a valid GNU Fortran implementation, though
an implementation may choose to specify behaviors for some
cases of inputs that are not valid GNU Fortran programs.

Other notation used herein is that of the GNU texinfo format,
which is used to generate printed hardcopy, on-line hypertext
(Info), and on-line HTML versions, all from a single source
document.
This notation is used as follows:

@itemize @bullet
@item
Keywords defined by the GNU Fortran language are shown
in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
@code{BLOCK DATA}.

Note that, in practice, many Fortran programs are written
in lowercase---uppercase is used in this manual as a
means to readily distinguish keywords and sample Fortran-related
text from the prose in this document.

@item
Portions of actual sample program, input, or output text
look like this: @samp{Actual program text}.

Generally, uppercase is used for all Fortran-specific and
Fortran-related text, though this does not always include
literal text within Fortran code.

For example: @samp{PRINT *, 'My name is Bob'}.

@item
A metasyntactic variable---that is, a name used in this document
to serve as a placeholder for whatever text is used by the
user or programmer---appears as shown in the following example:

``The @code{INTEGER @var{ivar}} statement specifies that
@var{ivar} is a variable or array of type @code{INTEGER}.''

In the above example, any valid text may be substituted for
the metasyntactic variable @var{ivar} to make the statement
apply to a specific instance, as long as the same text is
substituted for @emph{both} occurrences of @var{ivar}.

@item
Ellipses (``@dots{}'') are used to indicate further text that
is either unimportant or expanded upon further, elsewhere.

@item
Names of data types are in the style of Fortran 90, in most
cases.

@xref{Kind Notation}, for information on the relationship
between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
and the more traditional, less portably concise nomenclature
(such as @code{INTEGER*4}).
@end itemize

@node Terms and Concepts
@section Fortran Terms and Concepts

(The following information augments or overrides the information in
Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 2 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

@menu
* Syntactic Items::
* Statements Comments Lines::
* Scope of Names and Labels::
@end menu

@node Syntactic Items
@subsection Syntactic Items

(Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)

@cindex limits, lengths of names
In GNU Fortran, a symbolic name is at least one character long,
and has no arbitrary upper limit on length.
However, names of entities requiring external linkage (such as
external functions, external subroutines, and @code{COMMON} areas)
might be restricted to some arbitrary length by the system.
Such a restriction is no more constrained than that of one
through six characters.

Underscores (@samp{_}) are accepted in symbol names after the first
character (which must be a letter).

@node Statements Comments Lines
@subsection Statements, Comments, and Lines

(Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)

@cindex trailing comment
@cindex comment
@cindex characters, comment
@cindex !
@cindex exclamation point
@cindex continuation character
@cindex characters, continuation
Use of an exclamation point (@samp{!}) to begin a
trailing comment (a comment that extends to the end of the same
source line) is permitted under the following conditions:

@itemize @bullet
@item
The exclamation point does not appear in column 6.
Otherwise, it is treated as an indicator of a continuation
line.

@item
The exclamation point appears outside a character or Hollerith
constant.
Otherwise, the exclamation point is considered part of the
constant.

@item
The exclamation point appears to the left of any other possible
trailing comment.
That is, a trailing comment may contain exclamation points
in their commentary text.
@end itemize

@cindex ;
@cindex semicolon
@cindex statements, separated by semicolon
Use of a semicolon (@samp{;}) as a statement separator
is permitted under the following conditions:

@itemize @bullet
@item
The semicolon appears outside a character or Hollerith
constant.
Otherwise, the semicolon is considered part of the
constant.

@item
The semicolon appears to the left of a trailing comment.
Otherwise, the semicolon is considered part of that
comment.

@item
Neither a logical @code{IF} statement nor a non-construct
@code{WHERE} statement (a Fortran 90 feature) may be
followed (in the same, possibly continued, line) by
a semicolon used as a statement separator.

This restriction avoids the confusion
that can result when reading a line such as:

@smallexample
IF (VALIDP) CALL FOO; CALL BAR
@end smallexample

@noindent
Some readers might think the @samp{CALL BAR} is executed
only if @samp{VALIDP} is @code{.TRUE.}, while others might
assume its execution is unconditional.

(At present, @command{g77} does not diagnose code that
violates this restriction.)
@end itemize

@node Scope of Names and Labels
@subsection Scope of Symbolic Names and Statement Labels
@cindex scope

(Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)

Included in the list of entities that have a scope of a
program unit are construct names (a Fortran 90 feature).
@xref{Construct Names}, for more information.

@node Characters Lines Sequence
@section Characters, Lines, and Execution Sequence

(The following information augments or overrides the information in
Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 3 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

@menu
* Character Set::
* Lines::
* Continuation Line::
* Statements::
* Statement Labels::
* Order::
* INCLUDE::
* Cpp-style directives::
@end menu

@node Character Set
@subsection GNU Fortran Character Set
@cindex characters

(Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)

Letters include uppercase letters (the twenty-six characters
of the English alphabet) and lowercase letters (their lowercase
equivalent).
Generally, lowercase letters may be used in place of uppercase
letters, though in character and Hollerith constants, they
are distinct.

Special characters include:

@itemize @bullet
@item
@cindex ;
@cindex semicolon
Semicolon (@samp{;})

@item
@cindex !
@cindex exclamation point
Exclamation point (@samp{!})

@item
@cindex "
@cindex double quote
Double quote (@samp{"})

@item
@cindex \
@cindex backslash
Backslash (@samp{\})

@item
@cindex ?
@cindex question mark
Question mark (@samp{?})

@item
@cindex #
@cindex hash mark
@cindex pound sign
Hash mark (@samp{#})

@item
@cindex &
@cindex ampersand
Ampersand (@samp{&})

@item
@cindex %
@cindex percent sign
Percent sign (@samp{%})

@item
@cindex _
@cindex underscore
Underscore (@samp{_})

@item
@cindex <
@cindex open angle
@cindex left angle
@cindex open bracket
@cindex left bracket
Open angle (@samp{<})

@item
@cindex >
@cindex close angle
@cindex right angle
@cindex close bracket
@cindex right bracket
Close angle (@samp{>})

@item
The FORTRAN 77 special characters (@key{SPC}, @samp{=},
@samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
@samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
and @samp{:})
@end itemize

@cindex blank
@cindex space
@cindex SPC
Note that this document refers to @key{SPC} as @dfn{space},
while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.

@node Lines
@subsection Lines
@cindex lines
@cindex source file format
@cindex source format
@cindex file, source
@cindex source code
@cindex code, source
@cindex fixed form
@cindex free form

(Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)

The way a Fortran compiler views source files depends entirely on the
implementation choices made for the compiler, since those choices
are explicitly left to the implementation by the published Fortran
standards.

The GNU Fortran language mandates a view applicable to UNIX-like
text files---files that are made up of an arbitrary number of lines,
each with an arbitrary number of characters (sometimes called stream-based
files).

This view does not apply to types of files that are specified as
having a particular number of characters on every single line (sometimes
referred to as record-based files).

Because a ``line in a program unit is a sequence of 72 characters'',
to quote X3.9-1978, the GNU Fortran language specifies that a
stream-based text file is translated to GNU Fortran lines as follows:

@itemize @bullet
@item
A newline in the file is the character that represents the end of
a line of text to the underlying system.
For example, on ASCII-based systems, a newline is the @key{NL}
character, which has ASCII value 10 (decimal).

@item
Each newline in the file serves to end the line of text that precedes
it (and that does not contain a newline).

@item
The end-of-file marker (@code{EOF}) also serves to end the line
of text that precedes it (and that does not contain a newline).

@item
@cindex blank
@cindex space
@cindex SPC
Any line of text that is shorter than 72 characters is padded to that length
with spaces (called ``blanks'' in the standard).

@item
Any line of text that is longer than 72 characters is truncated to that
length, but the truncated remainder must consist entirely of spaces.

@item
Characters other than newline and the GNU Fortran character set
are invalid.
@end itemize

For the purposes of the remainder of this description of the GNU
Fortran language, the translation described above has already
taken place, unless otherwise specified.

The result of the above translation is that the source file appears,
in terms of the remainder of this description of the GNU Fortran language,
as if it had an arbitrary
number of 72-character lines, each character being among the GNU Fortran
character set.

For example, if the source file itself has two newlines in a row,
the second newline becomes, after the above translation, a single
line containing 72 spaces.

@node Continuation Line
@subsection Continuation Line
@cindex continuation line, number of
@cindex lines, continuation
@cindex number of continuation lines
@cindex limits, continuation lines

(Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)

A continuation line is any line that both

@itemize @bullet
@item
Contains a continuation character, and

@item
Contains only spaces in columns 1 through 5
@end itemize

A continuation character is any character of the GNU Fortran character set
other than space (@key{SPC}) or zero (@samp{0})
in column 6, or a digit (@samp{0} through @samp{9}) in column
7 through 72 of a line that has only spaces to the left of that
digit.

The continuation character is ignored as far as the content of
the statement is concerned.

The GNU Fortran language places no limit on the number of
continuation lines in a statement.
In practice, the limit depends on a variety of factors, such as
available memory, statement content, and so on, but no
GNU Fortran system may impose an arbitrary limit.

@node Statements
@subsection Statements

(Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)

Statements may be written using an arbitrary number of continuation
lines.

Statements may be separated using the semicolon (@samp{;}), except
that the logical @code{IF} and non-construct @code{WHERE} statements
may not be separated from subsequent statements using only a semicolon
as statement separator.

The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
and @code{END BLOCK DATA} statements are alternatives to the @code{END}
statement.
These alternatives may be written as normal statements---they are not
subject to the restrictions of the @code{END} statement.

However, no statement other than @code{END} may have an initial line
that appears to be an @code{END} statement---even @code{END PROGRAM},
for example, must not be written as:

@example
      END
     &PROGRAM
@end example

@node Statement Labels
@subsection Statement Labels

(Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)

A statement separated from its predecessor via a semicolon may be
labeled as follows:

@itemize @bullet
@item
The semicolon is followed by the label for the statement,
which in turn follows the label.

@item
The label must be no more than five digits in length.

@item
The first digit of the label for the statement is not
the first non-space character on a line.
Otherwise, that character is treated as a continuation
character.
@end itemize

A statement may have only one label defined for it.

@node Order
@subsection Order of Statements and Lines

(Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)

Generally, @code{DATA} statements may precede executable statements.
However, specification statements pertaining to any entities
initialized by a @code{DATA} statement must precede that @code{DATA}
statement.
For example,
after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
@samp{INTEGER J} is permitted.

The last line of a program unit may be an @code{END} statement,
or may be:

@itemize @bullet
@item
An @code{END PROGRAM} statement, if the program unit is a main program.

@item
An @code{END SUBROUTINE} statement, if the program unit is a subroutine.

@item
An @code{END FUNCTION} statement, if the program unit is a function.

@item
An @code{END BLOCK DATA} statement, if the program unit is a block data.
@end itemize

@node INCLUDE
@subsection Including Source Text
@cindex INCLUDE directive

Additional source text may be included in the processing of
the source file via the @code{INCLUDE} directive:

@example
INCLUDE @var{filename}
@end example

@noindent
The source text to be included is identified by @var{filename},
which is a literal GNU Fortran character constant.
The meaning and interpretation of @var{filename} depends on the
implementation, but typically is a filename.

(@command{g77} treats it as a filename that it searches for
in the current directory and/or directories specified
via the @option{-I} command-line option.)

The effect of the @code{INCLUDE} directive is as if the
included text directly replaced the directive in the source
file prior to interpretation of the program.
Included text may itself use @code{INCLUDE}.
The depth of nested @code{INCLUDE} references depends on
the implementation, but typically is a positive integer.

This virtual replacement treats the statements and @code{INCLUDE}
directives in the included text as syntactically distinct from
those in the including text.

Therefore, the first non-comment line of the included text
must not be a continuation line.
The included text must therefore have, after the non-comment
lines, either an initial line (statement), an @code{INCLUDE}
directive, or nothing (the end of the included text).

Similarly, the including text may end the @code{INCLUDE}
directive with a semicolon or the end of the line, but it
cannot follow an @code{INCLUDE} directive at the end of its
line with a continuation line.
Thus, the last statement in an included text may not be
continued.

Any statements between two @code{INCLUDE} directives on the
same line are treated as if they appeared in between the
respective included texts.
For example:

@smallexample
INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
@end smallexample

@noindent
If the text included by @samp{INCLUDE 'A'} constitutes
a @samp{PRINT *, 'A'} statement and the text included by
@samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
then the output of the above sample program would be

@example
A
B
C
@end example

@noindent
(with suitable allowances for how an implementation defines
its handling of output).

Included text must not include itself directly or indirectly,
regardless of whether the @var{filename} used to reference
the text is the same.

Note that @code{INCLUDE} is @emph{not} a statement.
As such, it is neither a non-executable or executable
statement.
However, if the text it includes constitutes one or more
executable statements, then the placement of @code{INCLUDE}
is subject to effectively the same restrictions as those
on executable statements.

An @code{INCLUDE} directive may be continued across multiple
lines as if it were a statement.
This permits long names to be used for @var{filename}.

@node Cpp-style directives
@subsection Cpp-style directives
@cindex #
@cindex preprocessor

@code{cpp} output-style @code{#} directives
(@pxref{C Preprocessor Output,,, cpp, The C Preprocessor})
are recognized by the compiler even
when the preprocessor isn't run on the input (as it is when compiling
@samp{.F} files).  (Note the distinction between these @command{cpp}
@code{#} @emph{output} directives and @code{#line} @emph{input}
directives.)

@node Data Types and Constants
@section Data Types and Constants

(The following information augments or overrides the information in
Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 4 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

To more concisely express the appropriate types for
entities, this document uses the more concise
Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
instead of the more traditional, but less portably concise,
byte-size-based nomenclature such as @code{INTEGER*4},
wherever reasonable.

When referring to generic types---in contexts where the
specific precision and range of a type are not important---this
document uses the generic type names @code{INTEGER}, @code{LOGICAL},
@code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.

In some cases, the context requires specification of a
particular type.
This document uses the @samp{KIND=} notation to accomplish
this throughout, sometimes supplying the more traditional
notation for clarification, though the traditional notation
might not work the same way on all GNU Fortran implementations.

Use of @samp{KIND=} makes this document more concise because
@command{g77} is able to define values for @samp{KIND=} that
have the same meanings on all systems, due to the way the
Fortran 90 standard specifies these values are to be used.

(In particular, that standard permits an implementation to
arbitrarily assign nonnegative values.
There are four distinct sets of assignments: one to the @code{CHARACTER}
type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
and the fourth to both the @code{REAL} and @code{COMPLEX} types.
Implementations are free to assign these values in any order,
leave gaps in the ordering of assignments, and assign more than
one value to a representation.)

This makes @samp{KIND=} values superior to the values used
in non-standard statements such as @samp{INTEGER*4}, because
the meanings of the values in those statements vary from machine
to machine, compiler to compiler, even operating system to
operating system.

However, use of @samp{KIND=} is @emph{not} generally recommended
when writing portable code (unless, for example, the code is
going to be compiled only via @command{g77}, which is a widely
ported compiler).
GNU Fortran does not yet have adequate language constructs to
permit use of @samp{KIND=} in a fashion that would make the
code portable to Fortran 90 implementations; and, this construct
is known to @emph{not} be accepted by many popular FORTRAN 77
implementations, so it cannot be used in code that is to be ported
to those.

The distinction here is that this document is able to use
specific values for @samp{KIND=} to concisely document the
types of various operations and operands.

A Fortran program should use the FORTRAN 77 designations for the
appropriate GNU Fortran types---such as @code{INTEGER} for
@code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
where no such designations exist, make use of appropriate
techniques (preprocessor macros, parameters, and so on)
to specify the types in a fashion that may be easily adjusted
to suit each particular implementation to which the program
is ported.
(These types generally won't need to be adjusted for ports of
@command{g77}.)

Further details regarding GNU Fortran data types and constants
are provided below.

@menu
* Types::
* Constants::
* Integer Type::
* Character Type::
@end menu

@node Types
@subsection Data Types

(Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)

GNU Fortran supports these types:

@enumerate
@item
Integer (generic type @code{INTEGER})

@item
Real (generic type @code{REAL})

@item
Double precision

@item
Complex (generic type @code{COMPLEX})

@item
Logical (generic type @code{LOGICAL})

@item
Character (generic type @code{CHARACTER})

@item
Double Complex
@end enumerate

(The types numbered 1 through 6 above are standard FORTRAN 77 types.)

The generic types shown above are referred to in this document
using only their generic type names.
Such references usually indicate that any specific type (kind)
of that generic type is valid.

For example, a context described in this document as accepting
the @code{COMPLEX} type also is likely to accept the
@code{DOUBLE COMPLEX} type.

The GNU Fortran language supports three ways to specify
a specific kind of a generic type.

@menu
* Double Notation::  As in @code{DOUBLE COMPLEX}.
* Star Notation::    As in @code{INTEGER*4}.
* Kind Notation::    As in @code{INTEGER(KIND=1)}.
@end menu

@node Double Notation
@subsubsection Double Notation

The GNU Fortran language supports two uses of the keyword
@code{DOUBLE} to specify a specific kind of type:

@itemize @bullet
@item
@code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}

@item
@code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
@end itemize

Use one of the above forms where a type name is valid.

While use of this notation is popular, it doesn't scale
well in a language or dialect rich in intrinsic types,
as is the case for the GNU Fortran language (especially
planned future versions of it).

After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
@samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
often are substituted for these, respectively, even though they
do not always have the same meanings on all systems.
(And, the fact that @samp{DOUBLE REAL} does not exist as such
is an inconsistency.)

Therefore, this document uses ``double notation'' only on occasion
for the benefit of those readers who are accustomed to it.

@node Star Notation
@subsubsection Star Notation
@cindex *@var{n} notation

The following notation specifies the storage size for a type:

@smallexample
@var{generic-type}*@var{n}
@end smallexample

@noindent
@var{generic-type} must be a generic type---one of
@code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
or @code{CHARACTER}.
@var{n} must be one or more digits comprising a decimal
integer number greater than zero.

Use the above form where a type name is valid.

The @samp{*@var{n}} notation specifies that the amount of storage
occupied by variables and array elements of that type is @var{n}
times the storage occupied by a @code{CHARACTER*1} variable.

This notation might indicate a different degree of precision and/or
range for such variables and array elements, and the functions that
return values of types using this notation.
It does not limit the precision or range of values of that type
in any particular way---use explicit code to do that.

Further, the GNU Fortran language requires no particular values
for @var{n} to be supported by an implementation via the @samp{*@var{n}}
notation.
@command{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
on all systems, for example,
but not all implementations are required to do so, and @command{g77}
is known to not support @code{REAL*1} on most (or all) systems.

As a result, except for @var{generic-type} of @code{CHARACTER},
uses of this notation should be limited to isolated
portions of a program that are intended to handle system-specific
tasks and are expected to be non-portable.

(Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
only @code{CHARACTER}, where it signifies not only the amount
of storage occupied, but the number of characters in entities
of that type.
However, almost all Fortran compilers have supported this
notation for generic types, though with a variety of meanings
for @var{n}.)

Specifications of types using the @samp{*@var{n}} notation
always are interpreted as specifications of the appropriate
types described in this document using the @samp{KIND=@var{n}}
notation, described below.

While use of this notation is popular, it doesn't serve well
in the context of a widely portable dialect of Fortran, such as
the GNU Fortran language.

For example, even on one particular machine, two or more popular
Fortran compilers might well disagree on the size of a type
declared @code{INTEGER*2} or @code{REAL*16}.
Certainly there
is known to be disagreement over such things among Fortran
compilers on @emph{different} systems.

Further, this notation offers no elegant way to specify sizes
that are not even multiples of the ``byte size'' typically
designated by @code{INTEGER*1}.
Use of ``absurd'' values (such as @code{INTEGER*1000}) would
certainly be possible, but would perhaps be stretching the original
intent of this notation beyond the breaking point in terms
of widespread readability of documentation and code making use
of it.

Therefore, this document uses ``star notation'' only on occasion
for the benefit of those readers who are accustomed to it.

@node Kind Notation
@subsubsection Kind Notation
@cindex KIND= notation

The following notation specifies the kind-type selector of a type:

@smallexample
@var{generic-type}(KIND=@var{n})
@end smallexample

@noindent
Use the above form where a type name is valid.

@var{generic-type} must be a generic type---one of
@code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
or @code{CHARACTER}.
@var{n} must be an integer initialization expression that
is a positive, nonzero value.

Programmers are discouraged from writing these values directly
into their code.
Future versions of the GNU Fortran language will offer
facilities that will make the writing of code portable
to @command{g77} @emph{and} Fortran 90 implementations simpler.

However, writing code that ports to existing FORTRAN 77
implementations depends on avoiding the @samp{KIND=} construct.

The @samp{KIND=} construct is thus useful in the context
of GNU Fortran for two reasons:

@itemize @bullet
@item
It provides a means to specify a type in a fashion that
is portable across all GNU Fortran implementations (though
not other FORTRAN 77 and Fortran 90 implementations).

@item
It provides a sort of Rosetta stone for this document to use
to concisely describe the types of various operations and
operands.
@end itemize

The values of @var{n} in the GNU Fortran language are
assigned using a scheme that:

@itemize @bullet
@item
Attempts to maximize the ability of readers
of this document to quickly familiarize themselves
with assignments for popular types

@item
Provides a unique value for each specific desired
meaning

@item
Provides a means to automatically assign new values so
they have a ``natural'' relationship to existing values,
if appropriate, or, if no such relationship exists, will
not interfere with future values assigned on the basis
of such relationships

@item
Avoids using values that are similar to values used
in the existing, popular @samp{*@var{n}} notation,
to prevent readers from expecting that these implied
correspondences work on all GNU Fortran implementations
@end itemize

The assignment system accomplishes this by assigning
to each ``fundamental meaning'' of a specific type a
unique prime number.
Combinations of fundamental meanings---for example, a type
that is two times the size of some other type---are assigned
values of @var{n} that are the products of the values for
those fundamental meanings.

A prime value of @var{n} is never given more than one fundamental
meaning, to avoid situations where some code or system
cannot reasonably provide those meanings in the form of a
single type.

The values of @var{n} assigned so far are:

@table @code
@item KIND=0
This value is reserved for future use.

The planned future use is for this value to designate,
explicitly, context-sensitive kind-type selection.
For example, the expression @samp{1D0 * 0.1_0} would
be equivalent to @samp{1D0 * 0.1D0}.

@item KIND=1
This corresponds to the default types for
@code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
and @code{CHARACTER}, as appropriate.

These are the ``default'' types described in the Fortran 90 standard,
though that standard does not assign any particular @samp{KIND=}
value to these types.

(Typically, these are @code{REAL*4}, @code{INTEGER*4},
@code{LOGICAL*4}, and @code{COMPLEX*8}.)

@item KIND=2
This corresponds to types that occupy twice as much
storage as the default types.
@code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
@code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),

These are the ``double precision'' types described in the Fortran 90
standard,
though that standard does not assign any particular @samp{KIND=}
value to these types.

@var{n} of 4 thus corresponds to types that occupy four times
as much storage as the default types, @var{n} of 8 to types that
occupy eight times as much storage, and so on.

The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
are not necessarily supported by every GNU Fortran implementation.

@item KIND=3
This corresponds to types that occupy as much
storage as the default @code{CHARACTER} type,
which is the same effective type as @code{CHARACTER(KIND=1)}
(making that type effectively the same as @code{CHARACTER(KIND=3)}).

(Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)

@var{n} of 6 thus corresponds to types that occupy twice as
much storage as the @var{n}=3 types, @var{n} of 12 to types
that occupy four times as much storage, and so on.

These are not necessarily supported by every GNU Fortran
implementation.

@item KIND=5
This corresponds to types that occupy half the
storage as the default (@var{n}=1) types.

(Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)

@var{n} of 25 thus corresponds to types that occupy one-quarter
as much storage as the default types.

These are not necessarily supported by every GNU Fortran
implementation.

@item KIND=7
@cindex pointers
This is valid only as @code{INTEGER(KIND=7)} and
denotes the @code{INTEGER} type that has the smallest
storage size that holds a pointer on the system.

A pointer representable by this type is capable of uniquely
addressing a @code{CHARACTER*1} variable, array, array element,
or substring.

(Typically this is equivalent to @code{INTEGER*4} or,
on 64-bit systems, @code{INTEGER*8}.
In a compatible C implementation, it typically would
be the same size and semantics of the C type @code{void *}.)
@end table

Note that these are @emph{proposed} correspondences and might change
in future versions of @command{g77}---avoid writing code depending
on them while @command{g77}, and therefore the GNU Fortran language
it defines, is in beta testing.

Values not specified in the above list are reserved to
future versions of the GNU Fortran language.

Implementation-dependent meanings will be assigned new,
unique prime numbers so as to not interfere with other
implementation-dependent meanings, and offer the possibility
of increasing the portability of code depending on such
types by offering support for them in other GNU Fortran
implementations.

Other meanings that might be given unique values are:

@itemize @bullet
@item
Types that make use of only half their storage size for
representing precision and range.

For example, some compilers offer options that cause
@code{INTEGER} types to occupy the amount of storage
that would be needed for @code{INTEGER(KIND=2)} types, but the
range remains that of @code{INTEGER(KIND=1)}.

@item
The IEEE single floating-point type.

@item
Types with a specific bit pattern (endianness), such as the
little-endian form of @code{INTEGER(KIND=1)}.
These could permit, conceptually, use of portable code and
implementations on data files written by existing systems.
@end itemize

Future @emph{prime} numbers should be given meanings in as incremental
a fashion as possible, to allow for flexibility and
expressiveness in combining types.

For example, instead of defining a prime number for little-endian
IEEE doubles, one prime number might be assigned the meaning
``little-endian'', another the meaning ``IEEE double'', and the
value of @var{n} for a little-endian IEEE double would thus
naturally be the product of those two respective assigned values.
(It could even be reasonable to have IEEE values result from the
products of prime values denoting exponent and fraction sizes
and meanings, hidden bit usage, availability and representations
of special values such as subnormals, infinities, and Not-A-Numbers
(NaNs), and so on.)

This assignment mechanism, while not inherently required for
future versions of the GNU Fortran language, is worth using
because it could ease management of the ``space'' of supported
types much easier in the long run.

The above approach suggests a mechanism for specifying inheritance
of intrinsic (built-in) types for an entire, widely portable
product line.
It is certainly reasonable that, unlike programmers of other languages
offering inheritance mechanisms that employ verbose names for classes
and subclasses, along with graphical browsers to elucidate the
relationships, Fortran programmers would employ
a mechanism that works by multiplying prime numbers together
and finding the prime factors of such products.

Most of the advantages for the above scheme have been explained
above.
One disadvantage is that it could lead to the defining,
by the GNU Fortran language, of some fairly large prime numbers.
This could lead to the GNU Fortran language being declared
``munitions'' by the United States Department of Defense.

@node Constants
@subsection Constants
@cindex constants
@cindex types, constants

(Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)

A @dfn{typeless constant} has one of the following forms:

@smallexample
'@var{binary-digits}'B
'@var{octal-digits}'O
'@var{hexadecimal-digits}'Z
'@var{hexadecimal-digits}'X
@end smallexample

@noindent
@var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
are nonempty strings of characters in the set @samp{01}, @samp{01234567},
and @samp{0123456789ABCDEFabcdef}, respectively.
(The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
is 11, and so on.)

A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
treated as typeless.  @xref{Fortran Dialect Options,, Options
Controlling Fortran Dialect}, for information on the
@option{-ftypeless-boz} option.

Typeless constants have values that depend on the context in which
they are used.

All other constants, called @dfn{typed constants}, are interpreted---converted
to internal form---according to their inherent type.
Thus, context is @emph{never} a determining factor for the type, and hence
the interpretation, of a typed constant.
(All constants in the ANSI FORTRAN 77 language are typed constants.)

For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
Fortran (called default INTEGER in Fortran 90),
@samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
additional precision specified is lost, and even when used in a
@code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
and @samp{1D0} is always type @code{REAL(KIND=2)}.

@node Integer Type
@subsection Integer Type

(Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)

An integer constant also may have one of the following forms:

@smallexample
B'@var{binary-digits}'
O'@var{octal-digits}'
Z'@var{hexadecimal-digits}'
X'@var{hexadecimal-digits}'
@end smallexample

@noindent
@var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
are nonempty strings of characters in the set @samp{01}, @samp{01234567},
and @samp{0123456789ABCDEFabcdef}, respectively.
(The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
is 11, and so on.)

@node Character Type
@subsection Character Type

(Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)

@cindex double quoted character constants
A character constant may be delimited by a pair of double quotes
(@samp{"}) instead of apostrophes.
In this case, an apostrophe within the constant represents
a single apostrophe, while a double quote is represented in
the source text of the constant by two consecutive double
quotes with no intervening spaces.

@cindex zero-length CHARACTER
@cindex null CHARACTER strings
@cindex empty CHARACTER strings
@cindex strings, empty
@cindex CHARACTER, null
A character constant may be empty (have a length of zero).

A character constant may include a substring specification,
The value of such a constant is the value of the substring---for
example, the value of @samp{'hello'(3:5)} is the same
as the value of @samp{'llo'}.

@node Expressions
@section Expressions

(The following information augments or overrides the information in
Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 6 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

@menu
* %LOC()::
@end menu

@node %LOC()
@subsection The @code{%LOC()} Construct
@cindex %LOC() construct

@example
%LOC(@var{arg})
@end example

The @code{%LOC()} construct is an expression
that yields the value of the location of its argument,
@var{arg}, in memory.
The size of the type of the expression depends on the system---typically,
it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
though it is actually type @code{INTEGER(KIND=7)}.

The argument to @code{%LOC()} must be suitable as the
left-hand side of an assignment statement.
That is, it may not be a general expression involving
operators such as addition, subtraction, and so on,
nor may it be a constant.

Use of @code{%LOC()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions that deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

Do not depend on @code{%LOC()} returning a pointer that
can be safely used to @emph{define} (change) the argument.
While this might work in some circumstances, it is hard
to predict whether it will continue to work when a program
(that works using this unsafe behavior)
is recompiled using different command-line options or
a different version of @command{g77}.

Generally, @code{%LOC()} is safe when used as an argument
to a procedure that makes use of the value of the corresponding
dummy argument only during its activation, and only when
such use is restricted to referencing (reading) the value
of the argument to @code{%LOC()}.

@emph{Implementation Note:} Currently, @command{g77} passes
arguments (those not passed using a construct such as @code{%VAL()})
by reference or descriptor, depending on the type of
the actual argument.
Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
in fact might compile to identical code.

However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
``pass, by value, the address of @samp{I} in memory''.
While @samp{CALL FOO(I)} might use that same approach in a
particular version of @command{g77}, another version or compiler
might choose a different implementation, such as copy-in/copy-out,
to effect the desired behavior---and which will therefore not
necessarily compile to the same code as would
@samp{CALL FOO(%VAL(%LOC(I)))}
using the same version or compiler.

@xref{Debugging and Interfacing}, for detailed information on
how this particular version of @command{g77} implements various
constructs.

@node Specification Statements
@section Specification Statements

(The following information augments or overrides the information in
Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 8 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

@menu
* NAMELIST::
* DOUBLE COMPLEX::
@end menu

@node NAMELIST
@subsection @code{NAMELIST} Statement
@cindex NAMELIST statement
@cindex statements, NAMELIST

The @code{NAMELIST} statement, and related I/O constructs, are
supported by the GNU Fortran language in essentially the same
way as they are by @command{f2c}.

This follows Fortran 90 with the restriction that on @code{NAMELIST}
input, subscripts must have the form
@smallexample
@var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
@end smallexample
i.e.@:
@smallexample
&xx x(1:3,8:10:2)=1,2,3,4,5,6/
@end smallexample
is allowed, but not, say,
@smallexample
&xx x(:3,8::2)=1,2,3,4,5,6/
@end smallexample

As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
@smallexample
$&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
@end smallexample
could be used instead of the example above.

@node DOUBLE COMPLEX
@subsection @code{DOUBLE COMPLEX} Statement
@cindex DOUBLE COMPLEX

@code{DOUBLE COMPLEX} is a type-statement (and type) that
specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.

@node Control Statements
@section Control Statements

(The following information augments or overrides the information in
Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 11 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

@menu
* DO WHILE::
* END DO::
* Construct Names::
* CYCLE and EXIT::
@end menu

@node DO WHILE
@subsection DO WHILE
@cindex DO WHILE
@cindex DO
@cindex MIL-STD 1753

The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
Fortran 90 standards, is provided by the GNU Fortran language.
The Fortran 90 ``do forever'' statement comprising just @code{DO} is
also supported.

@node END DO
@subsection END DO
@cindex END DO
@cindex MIL-STD 1753

The @code{END DO} statement is provided by the GNU Fortran language.

This statement is used in one of two ways:

@itemize @bullet
@item
The Fortran 90 meaning, in which it specifies the termination
point of a single @code{DO} loop started with a @code{DO} statement
that specifies no termination label.

@item
The MIL-STD 1753 meaning, in which it specifies the termination
point of one or more @code{DO} loops, all of which start with a
@code{DO} statement that specify the label defined for the
@code{END DO} statement.

This kind of @code{END DO} statement is merely a synonym for
@code{CONTINUE}, except it is permitted only when the statement
is labeled and a target of one or more labeled @code{DO} loops.

It is expected that this use of @code{END DO} will be removed from
the GNU Fortran language in the future, though it is likely that
it will long be supported by @command{g77} as a dialect form.
@end itemize

@node Construct Names
@subsection Construct Names
@cindex construct names

The GNU Fortran language supports construct names as defined
by the Fortran 90 standard.
These names are local to the program unit and are defined
as follows:

@smallexample
@var{construct-name}: @var{block-statement}
@end smallexample

@noindent
Here, @var{construct-name} is the construct name itself;
its definition is connoted by the single colon (@samp{:}); and
@var{block-statement} is an @code{IF}, @code{DO},
or @code{SELECT CASE} statement that begins a block.

A block that is given a construct name must also specify the
same construct name in its termination statement:

@example
END @var{block} @var{construct-name}
@end example

@noindent
Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
as appropriate.

@node CYCLE and EXIT
@subsection The @code{CYCLE} and @code{EXIT} Statements

@cindex CYCLE statement
@cindex EXIT statement
@cindex statements, CYCLE
@cindex statements, EXIT
The @code{CYCLE} and @code{EXIT} statements specify that
the remaining statements in the current iteration of a
particular active (enclosing) @code{DO} loop are to be skipped.

@code{CYCLE} specifies that these statements are skipped,
but the @code{END DO} statement that marks the end of the
@code{DO} loop be executed---that is, the next iteration,
if any, is to be started.
If the statement marking the end of the @code{DO} loop is
not @code{END DO}---in other words, if the loop is not
a block @code{DO}---the @code{CYCLE} statement does not
execute that statement, but does start the next iteration (if any).

@code{EXIT} specifies that the loop specified by the
@code{DO} construct is terminated.

The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
is the innermost enclosing @code{DO} loop when the following
forms are used:

@example
CYCLE
EXIT
@end example

Otherwise, the following forms specify the construct name
of the pertinent @code{DO} loop:

@example
CYCLE @var{construct-name}
EXIT @var{construct-name}
@end example

@code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
statements.
However, they cannot be easily thought of as @code{GO TO} statements
in obscure cases involving FORTRAN 77 loops.
For example:

@smallexample
      DO 10 I = 1, 5
      DO 10 J = 1, 5
         IF (J .EQ. 5) EXIT
      DO 10 K = 1, 5
         IF (K .EQ. 3) CYCLE
10    PRINT *, 'I=', I, ' J=', J, ' K=', K
20    CONTINUE
@end smallexample

@noindent
In particular, neither the @code{EXIT} nor @code{CYCLE} statements
above are equivalent to a @code{GO TO} statement to either label
@samp{10} or @samp{20}.

To understand the effect of @code{CYCLE} and @code{EXIT} in the
above fragment, it is helpful to first translate it to its equivalent
using only block @code{DO} loops:

@smallexample
      DO I = 1, 5
         DO J = 1, 5
            IF (J .EQ. 5) EXIT
            DO K = 1, 5
               IF (K .EQ. 3) CYCLE
10             PRINT *, 'I=', I, ' J=', J, ' K=', K
            END DO
         END DO
      END DO
20    CONTINUE
@end smallexample

Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
to @code{GO TO} so they may be more easily understood by programmers
accustomed to FORTRAN coding:

@smallexample
      DO I = 1, 5
         DO J = 1, 5
            IF (J .EQ. 5) GOTO 18
            DO K = 1, 5
               IF (K .EQ. 3) GO TO 12
10             PRINT *, 'I=', I, ' J=', J, ' K=', K
12          END DO
         END DO
18    END DO
20    CONTINUE
@end smallexample

@noindent
Thus, the @code{CYCLE} statement in the innermost loop skips over
the @code{PRINT} statement as it begins the next iteration of the
loop, while the @code{EXIT} statement in the middle loop ends that
loop but @emph{not} the outermost loop.

@node Functions and Subroutines
@section Functions and Subroutines

(The following information augments or overrides the information in
Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 15 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

@menu
* %VAL()::
* %REF()::
* %DESCR()::
* Generics and Specifics::
* REAL() and AIMAG() of Complex::
* CMPLX() of DOUBLE PRECISION::
* MIL-STD 1753::
* f77/f2c Intrinsics::
* Table of Intrinsic Functions::
@end menu

@node %VAL()
@subsection The @code{%VAL()} Construct
@cindex %VAL() construct

@example
%VAL(@var{arg})
@end example

The @code{%VAL()} construct specifies that an argument,
@var{arg}, is to be passed by value, instead of by reference
or descriptor.

@code{%VAL()} is restricted to actual arguments in
invocations of external procedures.

Use of @code{%VAL()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions the deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

@emph{Implementation Note:} Currently, @command{g77} passes
all arguments either by reference or by descriptor.

Thus, use of @code{%VAL()} tends to be restricted to cases
where the called procedure is written in a language other
than Fortran that supports call-by-value semantics.
(C is an example of such a language.)

@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
for detailed information on
how this particular version of @command{g77} passes arguments
to procedures.

@node %REF()
@subsection The @code{%REF()} Construct
@cindex %REF() construct

@example
%REF(@var{arg})
@end example

The @code{%REF()} construct specifies that an argument,
@var{arg}, is to be passed by reference, instead of by
value or descriptor.

@code{%REF()} is restricted to actual arguments in
invocations of external procedures.

Use of @code{%REF()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions the deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

Do not depend on @code{%REF()} supplying a pointer to the
procedure being invoked.
While that is a likely implementation choice, other
implementation choices are available that preserve Fortran
pass-by-reference semantics without passing a pointer to
the argument, @var{arg}.
(For example, a copy-in/copy-out implementation.)

@emph{Implementation Note:} Currently, @command{g77} passes
all arguments
(other than variables and arrays of type @code{CHARACTER})
by reference.
Future versions of, or dialects supported by, @command{g77} might
not pass @code{CHARACTER} functions by reference.

Thus, use of @code{%REF()} tends to be restricted to cases
where @var{arg} is type @code{CHARACTER} but the called
procedure accesses it via a means other than the method
used for Fortran @code{CHARACTER} arguments.

@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
how this particular version of @command{g77} passes arguments
to procedures.

@node %DESCR()
@subsection The @code{%DESCR()} Construct
@cindex %DESCR() construct

@example
%DESCR(@var{arg})
@end example

The @code{%DESCR()} construct specifies that an argument,
@var{arg}, is to be passed by descriptor, instead of by
value or reference.

@code{%DESCR()} is restricted to actual arguments in
invocations of external procedures.

Use of @code{%DESCR()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions the deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

Do not depend on @code{%DESCR()} supplying a pointer
and/or a length passed by value
to the procedure being invoked.
While that is a likely implementation choice, other
implementation choices are available that preserve the
pass-by-reference semantics without passing a pointer to
the argument, @var{arg}.
(For example, a copy-in/copy-out implementation.)
And, future versions of @command{g77} might change the
way descriptors are implemented, such as passing a
single argument pointing to a record containing the
pointer/length information instead of passing that same
information via two arguments as it currently does.

@emph{Implementation Note:} Currently, @command{g77} passes
all variables and arrays of type @code{CHARACTER}
by descriptor.
Future versions of, or dialects supported by, @command{g77} might
pass @code{CHARACTER} functions by descriptor as well.

Thus, use of @code{%DESCR()} tends to be restricted to cases
where @var{arg} is not type @code{CHARACTER} but the called
procedure accesses it via a means similar to the method
used for Fortran @code{CHARACTER} arguments.

@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
how this particular version of @command{g77} passes arguments
to procedures.

@node Generics and Specifics
@subsection Generics and Specifics
@cindex generic intrinsics
@cindex intrinsics, generic

The ANSI FORTRAN 77 language defines generic and specific
intrinsics.
In short, the distinctions are:

@itemize @bullet
@item
@emph{Specific} intrinsics have
specific types for their arguments and a specific return
type.

@item
@emph{Generic} intrinsics are treated,
on a case-by-case basis in the program's source code,
as one of several possible specific intrinsics.

Typically, a generic intrinsic has a return type that
is determined by the type of one or more of its arguments.
@end itemize

The GNU Fortran language generalizes these concepts somewhat,
especially by providing intrinsic subroutines and generic
intrinsics that are treated as either a specific intrinsic subroutine
or a specific intrinsic function (e.g. @code{SECOND}).

However, GNU Fortran avoids generalizing this concept to
the point where existing code would be accepted as meaning
something possibly different than what was intended.

For example, @code{ABS} is a generic intrinsic, so all working
code written using @code{ABS} of an @code{INTEGER} argument
expects an @code{INTEGER} return value.
Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
argument returns an @code{INTEGER*2} return value.

Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
an @code{INTEGER(KIND=1)} argument.
Code that passes something other than an @code{INTEGER(KIND=1)}
argument to @code{IABS} is not valid GNU Fortran code, because
it is not clear what the author intended.

For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
is not defined by the GNU Fortran language, because the programmer
might have used that construct to mean any of the following, subtly
different, things:

@itemize @bullet
@item
Convert @samp{J} to @code{INTEGER(KIND=1)} first
(as if @samp{IABS(INT(J))} had been written).

@item
Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
(as if @samp{INT(ABS(J))} had been written).

@item
No conversion (as if @samp{ABS(J)} had been written).
@end itemize

The distinctions matter especially when types and values wider than
@code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
operations performing more ``arithmetic'' than absolute-value, are involved.

The following sample program is not a valid GNU Fortran program, but
might be accepted by other compilers.
If so, the output is likely to be revealing in terms of how a given
compiler treats intrinsics (that normally are specific) when they
are given arguments that do not conform to their stated requirements:

@cindex JCB002 program
@smallexample
      PROGRAM JCB002
C Version 1:
C Modified 1999-02-15 (Burley) to delete my email address.
C Modified 1997-05-21 (Burley) to accommodate compilers that implement
C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
C
C Version 0:
C Written by James Craig Burley 1997-02-20.
C
C Purpose:
C Determine how compilers handle non-standard IDIM
C on INTEGER*2 operands, which presumably can be
C extrapolated into understanding how the compiler
C generally treats specific intrinsics that are passed
C arguments not of the correct types.
C
C If your compiler implements INTEGER*2 and INTEGER
C as the same type, change all INTEGER*2 below to
C INTEGER*1.
C
      INTEGER*2 I0, I4
      INTEGER I1, I2, I3
      INTEGER*2 ISMALL, ILARGE
      INTEGER*2 ITOOLG, ITWO
      INTEGER*2 ITMP
      LOGICAL L2, L3, L4
C
C Find smallest INTEGER*2 number.
C
      ISMALL=0
 10   I0 = ISMALL-1
      IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
      ISMALL = I0
      GOTO 10
 20   CONTINUE
C
C Find largest INTEGER*2 number.
C
      ILARGE=0
 30   I0 = ILARGE+1
      IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
      ILARGE = I0
      GOTO 30
 40   CONTINUE
C
C Multiplying by two adds stress to the situation.
C
      ITWO = 2
C
C Need a number that, added to -2, is too wide to fit in I*2.
C
      ITOOLG = ISMALL
C
C Use IDIM the straightforward way.
C
      I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
C
C Calculate result for first interpretation.
C
      I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
C
C Calculate result for second interpretation.
C
      ITMP = ILARGE - ISMALL
      I3 = (INT (ITMP)) * ITWO + ITOOLG
C
C Calculate result for third interpretation.
C
      I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
C
C Print results.
C
      PRINT *, 'ILARGE=', ILARGE
      PRINT *, 'ITWO=', ITWO
      PRINT *, 'ITOOLG=', ITOOLG
      PRINT *, 'ISMALL=', ISMALL
      PRINT *, 'I1=', I1
      PRINT *, 'I2=', I2
      PRINT *, 'I3=', I3
      PRINT *, 'I4=', I4
      PRINT *
      L2 = (I1 .EQ. I2)
      L3 = (I1 .EQ. I3)
      L4 = (I1 .EQ. I4)
      IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
         PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
         STOP
      END IF
      IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
         PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
         STOP
      END IF
      IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
         PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
         STOP
      END IF
      PRINT *, 'Results need careful analysis.'
      END
@end smallexample

No future version of the GNU Fortran language
will likely permit specific intrinsic invocations with wrong-typed
arguments (such as @code{IDIM} in the above example), since
it has been determined that disagreements exist among
many production compilers on the interpretation of
such invocations.
These disagreements strongly suggest that Fortran programmers,
and certainly existing Fortran programs, disagree about the
meaning of such invocations.

The first version of @code{JCB002} didn't accommodate some compilers'
treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
@code{INTEGER*2}.
In such a case, these compilers apparently convert both
operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
instead of doing an @code{INTEGER*2} subtraction on the
original values in @samp{I1} and @samp{I2}.

However, the results of the careful analyses done on the outputs
of programs compiled by these various compilers show that they
all implement either @samp{Interp 1} or @samp{Interp 2} above.

Specifically, it is believed that the new version of @code{JCB002}
above will confirm that:

@itemize @bullet
@item
Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
@command{f77} compilers all implement @samp{Interp 1}.

@item
IRIX 5.3 @command{f77} compiler implements @samp{Interp 2}.

@item
Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
and IRIX 6.1 @command{f77} compilers all implement @samp{Interp 3}.
@end itemize

If you get different results than the above for the stated
compilers, or have results for other compilers that might be
worth adding to the above list, please let us know the details
(compiler product, version, machine, results, and so on).

@node REAL() and AIMAG() of Complex
@subsection @code{REAL()} and @code{AIMAG()} of Complex
@cindex @code{Real} intrinsic
@cindex intrinsics, @code{Real}
@cindex @code{AImag} intrinsic
@cindex intrinsics, @code{AImag}

The GNU Fortran language disallows @code{REAL(@var{expr})}
and @code{AIMAG(@var{expr})},
where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
except when they are used in the following way:

@example
REAL(REAL(@var{expr}))
REAL(AIMAG(@var{expr}))
@end example

@noindent
The above forms explicitly specify that the desired effect
is to convert the real or imaginary part of @var{expr}, which might
be some @code{REAL} type other than @code{REAL(KIND=1)},
to type @code{REAL(KIND=1)},
and have that serve as the value of the expression.

The GNU Fortran language offers clearly named intrinsics to extract the
real and imaginary parts of a complex entity without any
conversion:

@example
REALPART(@var{expr})
IMAGPART(@var{expr})
@end example

To express the above using typical extended FORTRAN 77,
use the following constructs
(when @var{expr} is @code{COMPLEX(KIND=2)}):

@example
DBLE(@var{expr})
DIMAG(@var{expr})
@end example

The FORTRAN 77 language offers no way
to explicitly specify the real and imaginary parts of a complex expression of
arbitrary type, apparently as a result of requiring support for
only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
The concepts of converting an expression to type @code{REAL(KIND=1)} and
of extracting the real part of a complex expression were
thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
they happened to have the exact same effect in that language
(due to having only one @code{COMPLEX} type).

@emph{Note:} When @option{-ff90} is in effect,
@command{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
whereas with @samp{-fugly-complex -fno-f90} in effect, it is
treated as @samp{REAL(REALPART(@var{expr}))}.

@xref{Ugly Complex Part Extraction}, for more information.

@node CMPLX() of DOUBLE PRECISION
@subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
@cindex @code{Cmplx} intrinsic
@cindex intrinsics, @code{Cmplx}

In accordance with Fortran 90 and at least some (perhaps all)
other compilers, the GNU Fortran language defines @code{CMPLX()}
as always returning a result that is type @code{COMPLEX(KIND=1)}.

This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:

@example
CMPLX(SNGL(D1), SNGL(D2))
@end example

(It was necessary for Fortran 90 to specify this behavior
for @code{DOUBLE PRECISION} arguments, since that is
the behavior mandated by FORTRAN 77.)

The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
which is provided by some FORTRAN 77 compilers to construct
a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
operands.
However, this solution does not scale well when more @code{COMPLEX} types
(having various precisions and ranges) are offered by Fortran implementations.

Fortran 90 extends the @code{CMPLX()} intrinsic by adding
an extra argument used to specify the desired kind of complex
result.
However, this solution is somewhat awkward to use, and
@command{g77} currently does not support it.

The GNU Fortran language provides a simple way to build a complex
value out of two numbers, with the precise type of the value
determined by the types of the two numbers (via the usual
type-promotion mechanism):

@example
COMPLEX(@var{real}, @var{imag})
@end example

When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
performs no conversion other than to put them together to form a
complex result of the same (complex version of real) type.

@xref{Complex Intrinsic}, for more information.

@node MIL-STD 1753
@subsection MIL-STD 1753 Support
@cindex MIL-STD 1753

The GNU Fortran language includes the MIL-STD 1753 intrinsics
@code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
@code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
@code{ISHFTC}, @code{MVBITS}, and @code{NOT}.

@node f77/f2c Intrinsics
@subsection @command{f77}/@command{f2c} Intrinsics

The bit-manipulation intrinsics supported by traditional
@command{f77} and by @command{f2c} are available in the GNU Fortran language.
These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
and @code{XOR}.

Also supported are the intrinsics @code{CDABS},
@code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
@code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
@code{DIMAG}, @code{DREAL}, and @code{IMAG},
@code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
and @code{ZSQRT}.

@node Table of Intrinsic Functions
@subsection Table of Intrinsic Functions
@cindex intrinsics, table of
@cindex table of intrinsics

(Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)

The GNU Fortran language adds various functions, subroutines, types,
and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
The complete set of intrinsics supported by the GNU Fortran language
is described below.

Note that a name is not treated as that of an intrinsic if it is
specified in an @code{EXTERNAL} statement in the same program unit;
if a command-line option is used to disable the groups to which
the intrinsic belongs; or if the intrinsic is not named in an
@code{INTRINSIC} statement and a command-line option is used to
hide the groups to which the intrinsic belongs.

So, it is recommended that any reference in a program unit to
an intrinsic procedure that is not a standard FORTRAN 77
intrinsic be accompanied by an appropriate @code{INTRINSIC}
statement in that program unit.
This sort of defensive programming makes it more
likely that an implementation will issue a diagnostic rather
than generate incorrect code for such a reference.

The terminology used below is based on that of the Fortran 90
standard, so that the text may be more concise and accurate:

@itemize @bullet
@item
@code{OPTIONAL} means the argument may be omitted.

@item
@samp{A-1, A-2, @dots{}, A-n} means more than one argument
(generally named @samp{A}) may be specified.

@item
@samp{scalar} means the argument must not be an array (must
be a variable or array element, or perhaps a constant if expressions
are permitted).

@item
@samp{DIMENSION(4)} means the argument must be an array having 4 elements.

@item
@code{INTENT(IN)} means the argument must be an expression
(such as a constant or a variable that is defined upon invocation
of the intrinsic).

@item
@code{INTENT(OUT)} means the argument must be definable by the
invocation of the intrinsic (that is, must not be a constant nor
an expression involving operators other than array reference and
substring reference).

@item
@code{INTENT(INOUT)} means the argument must be defined prior to,
and definable by, invocation of the intrinsic (a combination of
the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.

@item
@xref{Kind Notation}, for an explanation of @code{KIND}.
@end itemize

@ifinfo
(Note that the empty lines appearing in the menu below
are not intentional---they result from a bug in the
GNU @command{makeinfo} program@dots{}a program that, if it
did not exist, would leave this document in far worse shape!)
@end ifinfo

@c The actual documentation for intrinsics comes from
@c intdoc.texi, which in turn is automatically generated
@c from the internal g77 tables in intrin.def _and_ the
@c largely hand-written text in intdoc.h.  So, if you want
@c to change or add to existing documentation on intrinsics,
@c you probably want to edit intdoc.h.
@c
@set familyF77
@set familyGNU
@set familyASC
@set familyMIL
@set familyF90
@clear familyVXT
@clear familyFVZ
@set familyF2C
@set familyF2U
@clear familyBADU77
@include intdoc.texi

@node Scope and Classes of Names
@section Scope and Classes of Symbolic Names
@cindex symbol names, scope and classes
@cindex scope

(The following information augments or overrides the information in
Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.
Chapter 18 of that document otherwise serves as the basis
for the relevant aspects of GNU Fortran.)

@menu
* Underscores in Symbol Names::
@end menu

@node Underscores in Symbol Names
@subsection Underscores in Symbol Names
@cindex underscore

Underscores (@samp{_}) are accepted in symbol names after the first
character (which must be a letter).

@node I/O
@section I/O

@cindex dollar sign
A dollar sign at the end of an output format specification suppresses
the newline at the end of the output.

@cindex <> edit descriptor
@cindex edit descriptor, <>
Edit descriptors in @code{FORMAT} statements may contain compile-time
@code{INTEGER} constant expressions in angle brackets, such as
@smallexample
10    FORMAT (I<WIDTH>)
@end smallexample

The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.

These Fortran 90 features are supported:
@itemize @bullet
@item
@cindex FORMAT descriptors
@cindex Z edit descriptor
@cindex edit descriptor, Z
@cindex O edit descriptor
@cindex edit descriptor, O
The @code{O} and @code{Z} edit descriptors are supported for I/O of
integers in octal and hexadecimal formats, respectively.
@item
The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
@code{STATUS='SCRATCH'} is supplied.  The @code{STATUS='REPLACE'}
specifier is supported.
@end itemize

@node Fortran 90 Features
@section Fortran 90 Features
@cindex Fortran 90
@cindex extensions, from Fortran 90

For convenience this section collects a list (probably incomplete) of
the Fortran 90 features supported by the GNU Fortran language, even if
they are documented elsewhere.
@xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}},
for information on additional fixed source form lexical issues.
@cindex @option{-ffree-form}
Further, the free source form is supported through the
@option{-ffree-form} option.
@cindex @option{-ff90}
Other Fortran 90 features can be turned on by the @option{-ff90} option;
see @ref{Fortran 90}.
For information on the Fortran 90 intrinsics available,
see @ref{Table of Intrinsic Functions}.

@table @asis
@item Automatic arrays in procedures
@item Character assignments
@cindex character assignments
In character assignments, the variable being assigned may occur on the
right hand side of the assignment.
@item Character strings
@cindex double quoted character constants
Strings may have zero length and substrings of character constants are
permitted.  Character constants may be enclosed in double quotes
(@code{"}) as well as single quotes.  @xref{Character Type}.
@item Construct names
(Symbolic tags on blocks.)  @xref{Construct Names}.
@item @code{CYCLE} and @code{EXIT}
@xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
@item @code{DOUBLE COMPLEX}
@xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}.
@item @code{DO WHILE}
@xref{DO WHILE}.
@item @code{END} decoration
@xref{Statements}.
@item @code{END DO}
@xref{END DO}.
@item @code{KIND}
@item @code{IMPLICIT NONE}
@item @code{INCLUDE} statements
@xref{INCLUDE}.
@item List-directed and namelist I/O on internal files
@item Binary, octal and hexadecimal constants
These are supported more generally than required by Fortran 90.
@xref{Integer Type}.
@item @samp{O} and @samp{Z} edit descriptors
@item @code{NAMELIST}
@xref{NAMELIST}.
@item @code{OPEN} specifiers
@code{STATUS='REPLACE'} is supported.
The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
@code{STATUS='SCRATCH'} is supplied.
@item @code{FORMAT} edit descriptors
@cindex FORMAT descriptors
@cindex Z edit descriptor
@cindex edit descriptor, Z
The @code{Z} edit descriptor is supported.
@item Relational operators
The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
@code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
@code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
@item @code{SELECT CASE}
Not fully implemented.
@xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}.
@item Specification statements
A limited subset of the Fortran 90 syntax and semantics for variable
declarations is supported, including @code{KIND}.  @xref{Kind Notation}.
(@code{KIND} is of limited usefulness in the absence of the
@code{KIND}-related intrinsics, since these intrinsics permit writing
more widely portable code.)  An example of supported @code{KIND} usage
is:
@smallexample
INTEGER (KIND=1) :: FOO=1, BAR=2
CHARACTER (LEN=3) FOO
@end smallexample
@code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
@end table

@node Other Dialects
@chapter Other Dialects

GNU Fortran supports a variety of features that are not
considered part of the GNU Fortran language itself, but
are representative of various dialects of Fortran that
@command{g77} supports in whole or in part.

Any of the features listed below might be disallowed by
@command{g77} unless some command-line option is specified.
Currently, some of the features are accepted using the
default invocation of @command{g77}, but that might change
in the future.

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Source Form::       Details of fixed-form and free-form source.
* Trailing Comment::  Use of @samp{/*} to start a comment.
* Debug Line::        Use of @samp{D} in column 1.
* Dollar Signs::      Use of @samp{$} in symbolic names.
* Case Sensitivity::  Uppercase and lowercase in source files.
* VXT Fortran::       @dots{}versus the GNU Fortran language.
* Fortran 90::        @dots{}versus the GNU Fortran language.
* Pedantic Compilation::  Enforcing the standard.
* Distensions::       Misfeatures supported by GNU Fortran.
@end menu

@node Source Form
@section Source Form
@cindex source file format
@cindex source format
@cindex file, source
@cindex source code
@cindex code, source
@cindex fixed form
@cindex free form

GNU Fortran accepts programs written in either fixed form or
free form.

Fixed form
corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
allowing tabs) and Fortran 90's fixed form.

Free form corresponds to
Fortran 90's free form (though possibly not entirely up-to-date, and
without complaining about some things that for which Fortran 90 requires
diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).

The way a Fortran compiler views source files depends entirely on the
implementation choices made for the compiler, since those choices
are explicitly left to the implementation by the published Fortran
standards.
GNU Fortran currently tries to be somewhat like a few popular compilers
(@command{f2c}, Digital (``DEC'') Fortran, and so on).

This section describes how @command{g77} interprets source lines.

@menu
* Carriage Returns::  Carriage returns ignored.
* Tabs::              Tabs converted to spaces.
* Short Lines::       Short lines padded with spaces (fixed-form only).
* Long Lines::        Long lines truncated.
* Ampersands::        Special Continuation Lines.
@end menu

@node Carriage Returns
@subsection Carriage Returns
@cindex carriage returns

Carriage returns (@samp{\r}) in source lines are ignored.
This is somewhat different from @command{f2c}, which seems to treat them as
spaces outside character/Hollerith constants, and encodes them as @samp{\r}
inside such constants.

@node Tabs
@subsection Tabs
@cindex tab character
@cindex horizontal tab

A source line with a @key{TAB} character anywhere in it is treated as
entirely significant---however long it is---instead of ending in
column 72 (for fixed-form source) or 132 (for free-form source).
This also is different from @command{f2c}, which encodes tabs as
@samp{\t} (the ASCII @key{TAB} character) inside character
and Hollerith constants, but nevertheless seems to treat the column
position as if it had been affected by the canonical tab positioning.

@command{g77} effectively
translates tabs to the appropriate number of spaces (a la the default
for the UNIX @command{expand} command) before doing any other processing, other
than (currently) noting whether a tab was found on a line and using this
information to decide how to interpret the length of the line and continued
constants.

@node Short Lines
@subsection Short Lines
@cindex short source lines
@cindex space, padding with
@cindex source lines, short
@cindex lines, short

Source lines shorter than the applicable fixed-form length are treated as
if they were padded with spaces to that length.
(None of this is relevant to source files written in free form.)

This affects only
continued character and Hollerith constants, and is a different
interpretation than provided by some other popular compilers
(although a bit more consistent with the traditional punched-card
basis of Fortran and the way the Fortran standard expressed fixed
source form).

@command{g77} might someday offer an option to warn about cases where differences
might be seen as a result of this treatment, and perhaps an option to
specify the alternate behavior as well.

Note that this padding cannot apply to lines that are effectively of
infinite length---such lines are specified using command-line options
like @option{-ffixed-line-length-none}, for example.

@node Long Lines
@subsection Long Lines
@cindex long source lines
@cindex truncation, of long lines
@cindex lines, long
@cindex source lines, long

Source lines longer than the applicable length are truncated to that
length.
Currently, @command{g77} does not warn if the truncated characters are
not spaces, to accommodate existing code written for systems that
treated truncated text as commentary (especially in columns 73 through 80).

@xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
for information on the @option{-ffixed-line-length-@var{n}} option,
which can be used to set the line length applicable to fixed-form
source files.

@node Ampersands
@subsection Ampersand Continuation Line
@cindex ampersand continuation line
@cindex continuation line, ampersand

A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
continuation line, imitating the behavior of @command{f2c}.

@node Trailing Comment
@section Trailing Comment

@cindex trailing comment
@cindex comment
@cindex characters, comment
@cindex /*
@cindex !
@cindex exclamation point
@command{g77} supports use of @samp{/*} to start a trailing
comment.
In the GNU Fortran language, @samp{!} is used for this purpose.

@samp{/*} is not in the GNU Fortran language
because the use of @samp{/*} in a program might
suggest to some readers that a block, not trailing, comment is
started (and thus ended by @samp{*/}, not end of line),
since that is the meaning of @samp{/*} in C.

Also, such readers might think they can use @samp{//} to start
a trailing comment as an alternative to @samp{/*}, but
@samp{//} already denotes concatenation, and such a ``comment''
might actually result in a program that compiles without
error (though it would likely behave incorrectly).

@node Debug Line
@section Debug Line
@cindex debug line
@cindex comment line, debug

Use of @samp{D} or @samp{d} as the first character (column 1) of
a source line denotes a debug line.

In turn, a debug line is treated as either a comment line
or a normal line, depending on whether debug lines are enabled.

When treated as a comment line, a line beginning with @samp{D} or
@samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
When treated as a normal line, such a line is treated as if
the first character was @key{SPC} (space).

(Currently, @command{g77} provides no means for treating debug
lines as normal lines.)

@node Dollar Signs
@section Dollar Signs in Symbol Names
@cindex dollar sign
@cindex $

Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
when the @option{-fdollar-ok} option is specified.

@node Case Sensitivity
@section Case Sensitivity
@cindex case sensitivity
@cindex source file format
@cindex code, source
@cindex source code
@cindex uppercase letters
@cindex lowercase letters
@cindex letters, uppercase
@cindex letters, lowercase

GNU Fortran offers the programmer way too much flexibility in deciding
how source files are to be treated vis-a-vis uppercase and lowercase
characters.
There are 66 useful settings that affect case sensitivity, plus 10
settings that are nearly useless, with the remaining 116 settings
being either redundant or useless.

None of these settings have any effect on the contents of comments
(the text after a @samp{c} or @samp{C} in Column 1, for example)
or of character or Hollerith constants.
Note that things like the @samp{E} in the statement
@samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
are considered built-in keywords, and so are affected by
these settings.

Low-level switches are identified in this section as follows:

@itemize @w{}
@item A
Source Case Conversion:

@itemize @w{}
@item 0
Preserve (see Note 1)
@item 1
Convert to Upper Case
@item 2
Convert to Lower Case
@end itemize

@item B
Built-in Keyword Matching:

@itemize @w{}
@item 0
Match Any Case (per-character basis)
@item 1
Match Upper Case Only
@item 2
Match Lower Case Only
@item 3
Match InitialCaps Only (see tables for spellings)
@end itemize

@item C
Built-in Intrinsic Matching:

@itemize @w{}
@item 0
Match Any Case (per-character basis)
@item 1
Match Upper Case Only
@item 2
Match Lower Case Only
@item 3
Match InitialCaps Only (see tables for spellings)
@end itemize

@item D
User-defined Symbol Possibilities (warnings only):

@itemize @w{}
@item 0
Allow Any Case (per-character basis)
@item 1
Allow Upper Case Only
@item 2
Allow Lower Case Only
@item 3
Allow InitialCaps Only (see Note 2)
@end itemize
@end itemize

Note 1: @command{g77} eventually will support @code{NAMELIST} in a manner that is
consistent with these source switches---in the sense that input will be
expected to meet the same requirements as source code in terms
of matching symbol names and keywords (for the exponent letters).

Currently, however, @code{NAMELIST} is supported by @code{libg2c},
which uppercases @code{NAMELIST} input and symbol names for matching.
This means not only that @code{NAMELIST} output currently shows symbol
(and keyword) names in uppercase even if lower-case source
conversion (option A2) is selected, but that @code{NAMELIST} cannot be
adequately supported when source case preservation (option A0)
is selected.

If A0 is selected, a warning message will be
output for each @code{NAMELIST} statement to this effect.
The behavior
of the program is undefined at run time if two or more symbol names
appear in a given @code{NAMELIST} such that the names are identical
when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
For complete and total elegance, perhaps there should be a warning
when option A2 is selected, since the output of NAMELIST is currently
in uppercase but will someday be lowercase (when a @code{libg77} is written),
but that seems to be overkill for a product in beta test.

Note 2: Rules for InitialCaps names are:

@itemize @minus
@item
Must be a single uppercase letter, @strong{or}
@item
Must start with an uppercase letter and contain at least one
lowercase letter.
@end itemize

So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
not.
Note that most, but not all, built-in names meet these
requirements---the exceptions are some of the two-letter format
specifiers, such as @code{BN} and @code{BZ}.

Here are the names of the corresponding command-line options:

@smallexample
A0: -fsource-case-preserve
A1: -fsource-case-upper
A2: -fsource-case-lower

B0: -fmatch-case-any
B1: -fmatch-case-upper
B2: -fmatch-case-lower
B3: -fmatch-case-initcap

C0: -fintrin-case-any
C1: -fintrin-case-upper
C2: -fintrin-case-lower
C3: -fintrin-case-initcap

D0: -fsymbol-case-any
D1: -fsymbol-case-upper
D2: -fsymbol-case-lower
D3: -fsymbol-case-initcap
@end smallexample

Useful combinations of the above settings, along with abbreviated
option names that set some of these combinations all at once:

@smallexample
 1: A0--  B0---  C0---  D0---    -fcase-preserve
 2: A0--  B0---  C0---  D-1--
 3: A0--  B0---  C0---  D--2-
 4: A0--  B0---  C0---  D---3
 5: A0--  B0---  C-1--  D0---
 6: A0--  B0---  C-1--  D-1--
 7: A0--  B0---  C-1--  D--2-
 8: A0--  B0---  C-1--  D---3
 9: A0--  B0---  C--2-  D0---
10: A0--  B0---  C--2-  D-1--
11: A0--  B0---  C--2-  D--2-
12: A0--  B0---  C--2-  D---3
13: A0--  B0---  C---3  D0---
14: A0--  B0---  C---3  D-1--
15: A0--  B0---  C---3  D--2-
16: A0--  B0---  C---3  D---3
17: A0--  B-1--  C0---  D0---
18: A0--  B-1--  C0---  D-1--
19: A0--  B-1--  C0---  D--2-
20: A0--  B-1--  C0---  D---3
21: A0--  B-1--  C-1--  D0---
22: A0--  B-1--  C-1--  D-1--    -fcase-strict-upper
23: A0--  B-1--  C-1--  D--2-
24: A0--  B-1--  C-1--  D---3
25: A0--  B-1--  C--2-  D0---
26: A0--  B-1--  C--2-  D-1--
27: A0--  B-1--  C--2-  D--2-
28: A0--  B-1--  C--2-  D---3
29: A0--  B-1--  C---3  D0---
30: A0--  B-1--  C---3  D-1--
31: A0--  B-1--  C---3  D--2-
32: A0--  B-1--  C---3  D---3
33: A0--  B--2-  C0---  D0---
34: A0--  B--2-  C0---  D-1--
35: A0--  B--2-  C0---  D--2-
36: A0--  B--2-  C0---  D---3
37: A0--  B--2-  C-1--  D0---
38: A0--  B--2-  C-1--  D-1--
39: A0--  B--2-  C-1--  D--2-
40: A0--  B--2-  C-1--  D---3
41: A0--  B--2-  C--2-  D0---
42: A0--  B--2-  C--2-  D-1--
43: A0--  B--2-  C--2-  D--2-    -fcase-strict-lower
44: A0--  B--2-  C--2-  D---3
45: A0--  B--2-  C---3  D0---
46: A0--  B--2-  C---3  D-1--
47: A0--  B--2-  C---3  D--2-
48: A0--  B--2-  C---3  D---3
49: A0--  B---3  C0---  D0---
50: A0--  B---3  C0---  D-1--
51: A0--  B---3  C0---  D--2-
52: A0--  B---3  C0---  D---3
53: A0--  B---3  C-1--  D0---
54: A0--  B---3  C-1--  D-1--
55: A0--  B---3  C-1--  D--2-
56: A0--  B---3  C-1--  D---3
57: A0--  B---3  C--2-  D0---
58: A0--  B---3  C--2-  D-1--
59: A0--  B---3  C--2-  D--2-
60: A0--  B---3  C--2-  D---3
61: A0--  B---3  C---3  D0---
62: A0--  B---3  C---3  D-1--
63: A0--  B---3  C---3  D--2-
64: A0--  B---3  C---3  D---3    -fcase-initcap
65: A-1-  B01--  C01--  D01--    -fcase-upper
66: A--2  B0-2-  C0-2-  D0-2-    -fcase-lower
@end smallexample

Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
(except comments, character constants, and Hollerith strings) must
be entered in uppercase.
Use @option{-fcase-strict-upper} to specify this
combination.

Number 43 is like Number 22 except all input must be lowercase.  Use
@option{-fcase-strict-lower} to specify this combination.

Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
non-UNIX machines whereby all the source is translated to uppercase.
Use @option{-fcase-upper} to specify this combination.

Number 66 is the ``canonical'' UNIX model whereby all the source is
translated to lowercase.
Use @option{-fcase-lower} to specify this combination.

There are a few nearly useless combinations:

@smallexample
67: A-1-  B01--  C01--  D--2-
68: A-1-  B01--  C01--  D---3
69: A-1-  B01--  C--23  D01--
70: A-1-  B01--  C--23  D--2-
71: A-1-  B01--  C--23  D---3
72: A--2  B01--  C0-2-  D-1--
73: A--2  B01--  C0-2-  D---3
74: A--2  B01--  C-1-3  D0-2-
75: A--2  B01--  C-1-3  D-1--
76: A--2  B01--  C-1-3  D---3
@end smallexample

The above allow some programs to be compiled but with restrictions that
make most useful programs impossible: Numbers 67 and 72 warn about
@emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
Numbers
68 and 73 warn about any user-defined symbol names longer than one
character that don't have at least one non-alphabetic character after
the first;
Numbers 69 and 74 disallow any references to intrinsics;
and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
67+69, 68+69, 72+74, and 73+74, respectively.

All redundant combinations are shown in the above tables anyplace
where more than one setting is shown for a low-level switch.
For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
The ``proper'' setting in such a case is the one that copies the setting
of switch A---any other setting might slightly reduce the speed of
the compiler, though possibly to an unmeasurable extent.

All remaining combinations are useless in that they prevent successful
compilation of non-null source files (source files with something other
than comments).

@node VXT Fortran
@section VXT Fortran

@cindex VXT extensions
@cindex extensions, VXT
@command{g77} supports certain constructs that
have different meanings in VXT Fortran than they
do in the GNU Fortran language.

Generally, this manual uses the invented term VXT Fortran to refer
VAX FORTRAN (circa v4).
That compiler offered many popular features, though not necessarily
those that are specific to the VAX processor architecture,
the VMS operating system,
or Digital Equipment Corporation's Fortran product line.
(VAX and VMS probably are trademarks of Digital Equipment
Corporation.)

An extension offered by a Digital Fortran product that also is
offered by several other Fortran products for different kinds of
systems is probably going to be considered for inclusion in @command{g77}
someday, and is considered a VXT Fortran feature.

The @option{-fvxt} option generally specifies that, where
the meaning of a construct is ambiguous (means one thing
in GNU Fortran and another in VXT Fortran), the VXT Fortran
meaning is to be assumed.

@menu
* Double Quote Meaning::  @samp{"2000} as octal constant.
* Exclamation Point::     @samp{!} in column 6.
@end menu

@node Double Quote Meaning
@subsection Meaning of Double Quote
@cindex double quotes
@cindex character constants
@cindex constants, character
@cindex octal constants
@cindex constants, octal

@command{g77} treats double-quote (@samp{"})
as beginning an octal constant of @code{INTEGER(KIND=1)} type
when the @option{-fvxt} option is specified.
The form of this octal constant is

@example
"@var{octal-digits}
@end example

@noindent
where @var{octal-digits} is a nonempty string of characters in
the set @samp{01234567}.

For example, the @option{-fvxt} option permits this:

@example
PRINT *, "20
END
@end example

@noindent
The above program would print the value @samp{16}.

@xref{Integer Type}, for information on the preferred construct
for integer constants specified using GNU Fortran's octal notation.

(In the GNU Fortran language, the double-quote character (@samp{"})
delimits a character constant just as does apostrophe (@samp{'}).
There is no way to allow
both constructs in the general case, since statements like
@samp{PRINT *,"2000 !comment?"} would be ambiguous.)

@node Exclamation Point
@subsection Meaning of Exclamation Point in Column 6
@cindex !
@cindex exclamation point
@cindex continuation character
@cindex characters, continuation
@cindex comment character
@cindex characters, comment

@command{g77} treats an exclamation point (@samp{!}) in column 6 of
a fixed-form source file
as a continuation character rather than
as the beginning of a comment
(as it does in any other column)
when the @option{-fvxt} option is specified.

The following program, when run, prints a message indicating
whether it is interpreted according to GNU Fortran (and Fortran 90)
rules or VXT Fortran rules:

@smallexample
C234567  (This line begins in column 1.)
      I = 0
     !1
      IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
      IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
      IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
      END
@end smallexample

(In the GNU Fortran and Fortran 90 languages, exclamation point is
a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
marks a line as a continuation line when it appears in column 6.)

@node Fortran 90
@section Fortran 90
@cindex compatibility, Fortran 90
@cindex Fortran 90, compatibility

The GNU Fortran language includes a number of features that are
part of Fortran 90, even when the @option{-ff90} option is not specified.
The features enabled by @option{-ff90} are intended to be those that,
when @option{-ff90} is not specified, would have another
meaning to @command{g77}---usually meaning something invalid in the
GNU Fortran language.

So, the purpose of @option{-ff90} is not to specify whether @command{g77} is
to gratuitously reject Fortran 90 constructs.
The @option{-pedantic} option specified with @option{-fno-f90} is intended
to do that, although its implementation is certainly incomplete at
this point.

When @option{-ff90} is specified:

@itemize @bullet
@item
The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
where @var{expr} is @code{COMPLEX} type,
is the same type as the real part of @var{expr}.

For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
@samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
not of type @code{REAL(KIND=1)}, since @option{-ff90} is specified.
@end itemize

@node Pedantic Compilation
@section Pedantic Compilation
@cindex pedantic compilation
@cindex compilation, pedantic

The @option{-fpedantic} command-line option specifies that @command{g77}
is to warn about code that is not standard-conforming.
This is useful for finding
some extensions @command{g77} accepts that other compilers might not accept.
(Note that the @option{-pedantic} and @option{-pedantic-errors} options
always imply @option{-fpedantic}.)

With @option{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
for conforming code.
With @option{-ff90} in force, Fortran 90 is used.

The constructs for which @command{g77} issues diagnostics when @option{-fpedantic}
and @option{-fno-f90} are in force are:

@itemize @bullet
@item
Automatic arrays, as in

@example
SUBROUTINE X(N)
REAL A(N)
@dots{}
@end example

@noindent
where @samp{A} is not listed in any @code{ENTRY} statement,
and thus is not a dummy argument.

@item
The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.

These commas are disallowed by FORTRAN 77, but, while strictly
superfluous, are syntactically elegant,
especially given that commas are required in statements such
as @samp{READ 99, I} and @samp{PRINT *, J}.
Many compilers permit the superfluous commas for this reason.

@item
@code{DOUBLE COMPLEX}, either explicitly or implicitly.

An explicit use of this type is via a @code{DOUBLE COMPLEX} or
@code{IMPLICIT DOUBLE COMPLEX} statement, for examples.

An example of an implicit use is the expression @samp{C*D},
where @samp{C} is @code{COMPLEX(KIND=1)}
and @samp{D} is @code{DOUBLE PRECISION}.
This expression is prohibited by ANSI FORTRAN 77
because the rules of promotion would suggest that it
produce a @code{DOUBLE COMPLEX} result---a type not
provided for by that standard.

@item
Automatic conversion of numeric
expressions to @code{INTEGER(KIND=1)} in contexts such as:

@itemize @minus
@item
Array-reference indexes.
@item
Alternate-return values.
@item
Computed @code{GOTO}.
@item
@code{FORMAT} run-time expressions (not yet supported).
@item
Dimension lists in specification statements.
@item
Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
@item
Sizes of @code{CHARACTER} entities in specification statements.
@item
Kind types in specification entities (a Fortran 90 feature).
@item
Initial, terminal, and incrementation parameters for implied-@code{DO}
constructs in @code{DATA} statements.
@end itemize

@item
Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
expressions are disallowed anyway).

@item
Zero-size array dimensions, as in:

@example
INTEGER I(10,20,4:2)
@end example

@item
Zero-length @code{CHARACTER} entities, as in:

@example
PRINT *, ''
@end example

@item
Substring operators applied to character constants and named
constants, as in:

@example
PRINT *, 'hello'(3:5)
@end example

@item
Null arguments passed to statement function, as in:

@example
PRINT *, FOO(,3)
@end example

@item
Disagreement among program units regarding whether a given @code{COMMON}
area is @code{SAVE}d (for targets where program units in a single source
file are ``glued'' together as they typically are for UNIX development
environments).

@item
Disagreement among program units regarding the size of a
named @code{COMMON} block.

@item
Specification statements following first @code{DATA} statement.

(In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
but not @samp{INTEGER I}.
The @option{-fpedantic} option disallows both of these.)

@item
Semicolon as statement separator, as in:

@example
CALL FOO; CALL BAR
@end example
@c
@c @item
@c Comma before list of I/O items in @code{WRITE}
@c  @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
@c statements, as with @code{READ} (as explained above).

@item
Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).

@item
Use of @code{CHARACTER} constants to initialize numeric entities, and vice
versa.

@item
Expressions having two arithmetic operators in a row, such
as @samp{X*-Y}.
@end itemize

If @option{-fpedantic} is specified along with @option{-ff90}, the
following constructs result in diagnostics:

@itemize @bullet
@item
Use of semicolon as a statement separator on a line
that has an @code{INCLUDE} directive.
@end itemize

@node Distensions
@section Distensions
@cindex distensions
@cindex ugly features
@cindex features, ugly

The @option{-fugly-*} command-line options determine whether certain
features supported by VAX FORTRAN and other such compilers, but considered
too ugly to be in code that can be changed to use safer and/or more
portable constructs, are accepted.
These are humorously referred to as ``distensions'',
extensions that just plain look ugly in the harsh light of day.

@menu
* Ugly Implicit Argument Conversion::  Disabled via @option{-fno-ugly-args}.
* Ugly Assumed-Size Arrays::           Enabled via @option{-fugly-assumed}.
* Ugly Null Arguments::                Enabled via @option{-fugly-comma}.
* Ugly Complex Part Extraction::       Enabled via @option{-fugly-complex}.
* Ugly Conversion of Initializers::    Disabled via @option{-fno-ugly-init}.
* Ugly Integer Conversions::           Enabled via @option{-fugly-logint}.
* Ugly Assigned Labels::               Enabled via @option{-fugly-assign}.
@end menu

@node Ugly Implicit Argument Conversion
@subsection Implicit Argument Conversion
@cindex Hollerith constants
@cindex constants, Hollerith

The @option{-fno-ugly-args} option disables
passing typeless and Hollerith constants as actual arguments
in procedure invocations.
For example:

@example
CALL FOO(4HABCD)
CALL BAR('123'O)
@end example

@noindent
These constructs can be too easily used to create non-portable
code, but are not considered as ``ugly'' as others.
Further, they are widely used in existing Fortran source code
in ways that often are quite portable.
Therefore, they are enabled by default.

@node Ugly Assumed-Size Arrays
@subsection Ugly Assumed-Size Arrays
@cindex arrays, assumed-size
@cindex assumed-size arrays
@cindex DIMENSION X(1)

The @option{-fugly-assumed} option enables
the treatment of any array with a final dimension specified as @samp{1}
as an assumed-size array, as if @samp{*} had been specified
instead.

For example, @samp{DIMENSION X(1)} is treated as if it
had read @samp{DIMENSION X(*)} if @samp{X} is listed as
a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
or @code{ENTRY} statement in the same program unit.

Use an explicit lower bound to avoid this interpretation.
For example, @samp{DIMENSION X(1:1)} is never treated as if
it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
Nor is @samp{DIMENSION X(2-1)} affected by this option,
since that kind of expression is unlikely to have been
intended to designate an assumed-size array.

This option is used to prevent warnings being issued about apparent
out-of-bounds reference such as @samp{X(2) = 99}.

It also prevents the array from being used in contexts that
disallow assumed-size arrays, such as @samp{PRINT *,X}.
In such cases, a diagnostic is generated and the source file is
not compiled.

The construct affected by this option is used only in old code
that pre-exists the widespread acceptance of adjustable and assumed-size
arrays in the Fortran community.

@emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
treated if @samp{X} is listed as a dummy argument only
@emph{after} the @code{DIMENSION} statement (presumably in
an @code{ENTRY} statement).
For example, @option{-fugly-assumed} has no effect on the
following program unit:

@example
SUBROUTINE X
REAL A(1)
RETURN
ENTRY Y(A)
PRINT *, A
END
@end example

@node Ugly Complex Part Extraction
@subsection Ugly Complex Part Extraction
@cindex complex values
@cindex real part
@cindex imaginary part

The @option{-fugly-complex} option enables
use of the @code{REAL()} and @code{AIMAG()}
intrinsics with arguments that are
@code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.

With @option{-ff90} in effect, these intrinsics return
the unconverted real and imaginary parts (respectively)
of their argument.

With @option{-fno-f90} in effect, these intrinsics convert
the real and imaginary parts to @code{REAL(KIND=1)}, and return
the result of that conversion.

Due to this ambiguity, the GNU Fortran language defines
these constructs as invalid, except in the specific
case where they are entirely and solely passed as an
argument to an invocation of the @code{REAL()} intrinsic.
For example,

@example
REAL(REAL(Z))
@end example

@noindent
is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
and @option{-fno-ugly-complex} is in effect, because the
meaning is clear.

@command{g77} enforces this restriction, unless @option{-fugly-complex}
is specified, in which case the appropriate interpretation is
chosen and no diagnostic is issued.

@xref{CMPAMBIG}, for information on how to cope with existing
code with unclear expectations of @code{REAL()} and @code{AIMAG()}
with @code{COMPLEX(KIND=2)} arguments.

@xref{RealPart Intrinsic}, for information on the @code{REALPART()}
intrinsic, used to extract the real part of a complex expression
without conversion.
@xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
intrinsic, used to extract the imaginary part of a complex expression
without conversion.

@node Ugly Null Arguments
@subsection Ugly Null Arguments
@cindex trailing comma
@cindex comma, trailing
@cindex characters, comma
@cindex null arguments
@cindex arguments, null

The @option{-fugly-comma} option enables use of a single trailing comma
to mean ``pass an extra trailing null argument''
in a list of actual arguments to an external procedure,
and use of an empty list of arguments to such a procedure
to mean ``pass a single null argument''.

@cindex omitting arguments
@cindex arguments, omitting
(Null arguments often are used in some procedure-calling
schemes to indicate omitted arguments.)

For example, @samp{CALL FOO(,)} means ``pass
two null arguments'', rather than ``pass one null argument''.
Also, @samp{CALL BAR()} means ``pass one null argument''.

This construct is considered ``ugly'' because it does not
provide an elegant way to pass a single null argument
that is syntactically distinct from passing no arguments.
That is, this construct changes the meaning of code that
makes no use of the construct.

So, with @option{-fugly-comma} in force, @samp{CALL FOO()}
and @samp{I = JFUNC()} pass a single null argument, instead
of passing no arguments as required by the Fortran 77 and
90 standards.

@emph{Note:} Many systems gracefully allow the case
where a procedure call passes one extra argument that the
called procedure does not expect.

So, in practice, there might be no difference in
the behavior of a program that does @samp{CALL FOO()}
or @samp{I = JFUNC()} and is compiled with @option{-fugly-comma}
in force as compared to its behavior when compiled
with the default, @option{-fno-ugly-comma}, in force,
assuming @samp{FOO} and @samp{JFUNC} do not expect any
arguments to be passed.

@node Ugly Conversion of Initializers
@subsection Ugly Conversion of Initializers

The constructs disabled by @option{-fno-ugly-init} are:

@itemize @bullet
@cindex Hollerith constants
@cindex constants, Hollerith
@item
Use of Hollerith and typeless constants in contexts where they set
initial (compile-time) values for variables, arrays, and named
constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
type-declaration statements specifying initial values.

Here are some sample initializations that are disabled by the
@option{-fno-ugly-init} option:

@example
PARAMETER (VAL='9A304FFE'X)
REAL*8 STRING/8HOUTPUT00/
DATA VAR/4HABCD/
@end example

@cindex character constants
@cindex constants, character
@item
In the same contexts as above, use of character constants to initialize
numeric items and vice versa (one constant per item).

Here are more sample initializations that are disabled by the
@option{-fno-ugly-init} option:

@example
INTEGER IA
CHARACTER BELL
PARAMETER (IA = 'A')
PARAMETER (BELL = 7)
@end example

@item
Use of Hollerith and typeless constants on the right-hand side
of assignment statements to numeric types, and in other
contexts (such as passing arguments in invocations of
intrinsic procedures and statement functions) that
are treated as assignments to known types (the dummy
arguments, in these cases).

Here are sample statements that are disabled by the
@option{-fno-ugly-init} option:

@example
IVAR = 4HABCD
PRINT *, IMAX0(2HAB, 2HBA)
@end example
@end itemize

The above constructs, when used,
can tend to result in non-portable code.
But, they are widely used in existing Fortran code in ways
that often are quite portable.
Therefore, they are enabled by default.

@node Ugly Integer Conversions
@subsection Ugly Integer Conversions

The constructs enabled via @option{-fugly-logint} are:

@itemize @bullet
@item
Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
dictated by
context (typically implies nonportable dependencies on how a
particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).

@item
Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
statements.
@end itemize

The above constructs are disabled by default because use
of them tends to lead to non-portable code.
Even existing Fortran code that uses that often turns out
to be non-portable, if not outright buggy.

Some of this is due to differences among implementations as
far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
@code{INTEGER} values---Fortran code that assumes a particular
coding is likely to use one of the above constructs, and is
also likely to not work correctly on implementations using
different encodings.

@xref{Equivalence Versus Equality}, for more information.

@node Ugly Assigned Labels
@subsection Ugly Assigned Labels
@cindex ASSIGN statement
@cindex statements, ASSIGN
@cindex assigned labels
@cindex pointers

The @option{-fugly-assign} option forces @command{g77} to use the
same storage for assigned labels as it would for a normal
assignment to the same variable.

For example, consider the following code fragment:

@example
I = 3
ASSIGN 10 TO I
@end example

@noindent
Normally, for portability and improved diagnostics, @command{g77}
reserves distinct storage for a ``sibling'' of @samp{I}, used
only for @code{ASSIGN} statements to that variable (along with
the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O
statements that reference the variable).

However, some code (that violates the ANSI FORTRAN 77 standard)
attempts to copy assigned labels among variables involved with
@code{ASSIGN} statements, as in:

@example
ASSIGN 10 TO I
ISTATE(5) = I
@dots{}
J = ISTATE(ICUR)
GOTO J
@end example

@noindent
Such code doesn't work under @command{g77} unless @option{-fugly-assign}
is specified on the command-line, ensuring that the value of @code{I}
referenced in the second line is whatever value @command{g77} uses
to designate statement label @samp{10}, so the value may be
copied into the @samp{ISTATE} array, later retrieved into a
variable of the appropriate type (@samp{J}), and used as the target of
an assigned-@code{GOTO} statement.

@emph{Note:} To avoid subtle program bugs,
when @option{-fugly-assign} is specified,
@command{g77} requires the type of variables
specified in assigned-label contexts
@emph{must} be the same type returned by @code{%LOC()}.
On many systems, this type is effectively the same
as @code{INTEGER(KIND=1)}, while, on others, it is
effectively the same as @code{INTEGER(KIND=2)}.

Do @emph{not} depend on @command{g77} actually writing valid pointers
to these variables, however.
While @command{g77} currently chooses that implementation, it might
be changed in the future.

@xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
for implementation details on assigned-statement labels.

@node Compiler
@chapter The GNU Fortran Compiler

The GNU Fortran compiler, @command{g77}, supports programs written
in the GNU Fortran language and in some other dialects of Fortran.

Some aspects of how @command{g77} works are universal regardless
of dialect, and yet are not properly part of the GNU Fortran
language itself.
These are described below.

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Compiler Limits::
* Run-time Environment Limits::
* Compiler Types::
* Compiler Constants::
* Compiler Intrinsics::
@end menu

@node Compiler Limits
@section Compiler Limits
@cindex limits, compiler
@cindex compiler limits

@command{g77}, as with GNU tools in general, imposes few arbitrary restrictions
on lengths of identifiers, number of continuation lines, number of external
symbols in a program, and so on.

@cindex options, -Nl
@cindex -Nl option
@cindex options, -Nx
@cindex -Nx option
@cindex limits, continuation lines
@cindex limits, lengths of names
For example, some other Fortran compiler have an option
(such as @option{-Nl@var{x}}) to increase the limit on the
number of continuation lines.
Also, some Fortran compilation systems have an option
(such as @option{-Nx@var{x}}) to increase the limit on the
number of external symbols.

@command{g77}, @command{gcc}, and GNU @command{ld} (the GNU linker) have
no equivalent options, since they do not impose arbitrary
limits in these areas.

@cindex rank, maximum
@cindex maximum rank
@cindex number of dimensions, maximum
@cindex maximum number of dimensions
@cindex limits, rank
@cindex limits, array dimensions
@command{g77} does currently limit the number of dimensions in an array
to the same degree as do the Fortran standards---seven (7).
This restriction might be lifted in a future version.

@node Run-time Environment Limits
@section Run-time Environment Limits
@cindex limits, run-time library
@cindex wraparound

As a portable Fortran implementation,
@command{g77} offers its users direct access to,
and otherwise depends upon,
the underlying facilities of the system
used to build @command{g77},
the system on which @command{g77} itself is used to compile programs,
and the system on which the @command{g77}-compiled program is actually run.
(For most users, the three systems are of the same
type---combination of operating environment and hardware---often
the same physical system.)

The run-time environment for a particular system
inevitably imposes some limits on a program's use
of various system facilities.
These limits vary from system to system.

Even when such limits might be well beyond the
possibility of being encountered on a particular system,
the @command{g77} run-time environment
has certain built-in limits,
usually, but not always, stemming from intrinsics
with inherently limited interfaces.

Currently, the @command{g77} run-time environment
does not generally offer a less-limiting environment
by augmenting the underlying system's own environment.

Therefore, code written in the GNU Fortran language,
while syntactically and semantically portable,
might nevertheless make non-portable assumptions
about the run-time environment---assumptions that
prove to be false for some particular environments.

The GNU Fortran language,
the @command{g77} compiler and run-time environment,
and the @command{g77} documentation
do not yet offer comprehensive portable work-arounds for such limits,
though programmers should be able to
find their own in specific instances.

Not all of the limitations are described in this document.
Some of the known limitations include:

@menu
* Timer Wraparounds::
* Year 2000 (Y2K) Problems::
* Array Size::
* Character-variable Length::
* Year 10000 (Y10K) Problems::
@end menu

@node Timer Wraparounds
@subsection Timer Wraparounds

Intrinsics that return values computed from system timers,
whether elapsed (wall-clock) timers,
process CPU timers,
or other kinds of timers,
are prone to experiencing wrap-around errors
(or returning wrapped-around values from successive calls)
due to insufficient ranges
offered by the underlying system's timers.

@cindex negative time
@cindex short time
@cindex long time
Some of the symptoms of such behaviors include
apparently negative time being computed for a duration,
an extremely short amount of time being computed for a long duration,
and an extremely long amount of time being computed for a short duration.

See the following for intrinsics
known to have potential problems in these areas
on at least some systems:
@ref{CPU_Time Intrinsic},
@ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
@ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
@ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
@ref{Secnds Intrinsic},
@ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
@ref{System_Clock Intrinsic},
@ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
@ref{Time8 Intrinsic}.

@node Year 2000 (Y2K) Problems
@subsection Year 2000 (Y2K) Problems
@cindex Y2K compliance
@cindex Year 2000 compliance

While the @command{g77} compiler itself is believed to
be Year-2000 (Y2K) compliant,
some intrinsics are not,
and, potentially, some underlying systems are not,
perhaps rendering some Y2K-compliant intrinsics
non-compliant when used on those particular systems.

Fortran code that uses non-Y2K-compliant intrinsics
(listed below)
is, itself, almost certainly not compliant,
and should be modified to use Y2K-compliant intrinsics instead.

Fortran code that uses no non-Y2K-compliant intrinsics,
but which currently is running on a non-Y2K-compliant system,
can be made more Y2K compliant by compiling and
linking it for use on a new Y2K-compliant system,
such as a new version of an old, non-Y2K-compliant, system.

Currently, information on Y2K and related issues
is being maintained at
@uref{http://www.gnu.org/software/year2000-list.html}.

See the following for intrinsics
known to have potential problems in these areas
on at least some systems:
@ref{Date Intrinsic},
@ref{IDate Intrinsic (VXT)}.

@cindex y2kbuggy
@cindex date_y2kbuggy_0
@cindex vxtidate_y2kbuggy_0
@cindex G77_date_y2kbuggy_0
@cindex G77_vxtidate_y2kbuggy_0
The @code{libg2c} library
shipped with any @command{g77} that warns
about invocation of a non-Y2K-compliant intrinsic
has renamed the @code{EXTERNAL} procedure names
of those intrinsics.
This is done so that
the @code{libg2c} implementations of these intrinsics
cannot be directly linked to
as @code{EXTERNAL} names
(which normally would avoid the non-Y2K-intrinsic warning).

The renamed forms of the @code{EXTERNAL} names
of these renamed procedures
may be linked to
by appending the string @samp{_y2kbug}
to the name of the procedure
in the source code.
For example:

@smallexample
CHARACTER*20 STR
INTEGER YY, MM, DD
EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
CALL DATE_Y2KBUG (STR)
CALL VXTIDATE_Y2KBUG (MM, DD, YY)
@end smallexample

(Note that the @code{EXTERNAL} statement
is not actually required,
since the modified names are not recognized as intrinsics
by the current version of @command{g77}.
But it is shown in this specific case,
for purposes of illustration.)

The renaming of @code{EXTERNAL} procedure names of these intrinsics
causes unresolved references at link time.
For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
is normally compiled by @command{g77}
as, in C, @samp{date_(&str, 20);}.
This, in turn, links to the @code{date_} procedure
in the @code{libE77} portion of @code{libg2c},
which purposely calls a nonexistent procedure
named @code{G77_date_y2kbuggy_0}.
The resulting link-time error is designed, via this name,
to encourage the programmer to look up the
index entries to this portion of the @command{g77} documentation.

Generally, we recommend that the @code{EXTERNAL} method
of invoking procedures in @code{libg2c}
@emph{not} be used.
When used, some of the correctness checking
normally performed by @command{g77}
is skipped.

In particular, it is probably better to use the
@code{INTRINSIC} method of invoking
non-Y2K-compliant procedures,
so anyone compiling the code
can quickly notice the potential Y2K problems
(via the warnings printing by @command{g77})
without having to even look at the code itself.

If there are problems linking @code{libg2c}
to code compiled by @command{g77}
that involve the string @samp{y2kbug},
and these are not explained above,
that probably indicates
that a version of @code{libg2c}
older than @command{g77}
is being linked to,
or that the new library is being linked
to code compiled by an older version of @command{g77}.

That's because, as of the version that warns about
non-Y2K-compliant intrinsic invocation,
@command{g77} references the @code{libg2c} implementations
of those intrinsics
using new names, containing the string @samp{y2kbug}.

So, linking newly-compiled code
(invoking one of the intrinsics in question)
to an old library
might yield an unresolved reference
to @code{G77_date_y2kbug_0}.
(The old library calls it @code{G77_date_0}.)

Similarly, linking previously-compiled code
to a new library
might yield an unresolved reference
to @code{G77_vxtidate_0}.
(The new library calls it @code{G77_vxtidate_y2kbug_0}.)

The proper fix for the above problems
is to obtain the latest release of @command{g77}
and related products
(including @code{libg2c})
and install them on all systems,
then recompile, relink, and install
(as appropriate)
all existing Fortran programs.

(Normally, this sort of renaming is steadfastly avoided.
In this case, however, it seems more important to highlight
potential Y2K problems
than to ease the transition
of potentially non-Y2K-compliant code
to new versions of @command{g77} and @code{libg2c}.)

@node Array Size
@subsection Array Size
@cindex limits, array size
@cindex array size

Currently, @command{g77} uses the default @code{INTEGER} type
for array indexes,
which limits the sizes of single-dimension arrays
on systems offering a larger address space
than can be addressed by that type.
(That @command{g77} puts all arrays in memory
could be considered another limitation---it
could use large temporary files---but that decision
is left to the programmer as an implementation choice
by most Fortran implementations.)

@c ??? Investigate this, to offer a more clear statement
@c than the following paragraphs do.  -- burley 1999-02-17
It is not yet clear whether this limitation
never, sometimes, or always applies to the
sizes of multiple-dimension arrays as a whole.

For example, on a system with 64-bit addresses
and 32-bit default @code{INTEGER},
an array with a size greater than can be addressed
by a 32-bit offset
can be declared using multiple dimensions.
Such an array is therefore larger
than a single-dimension array can be,
on the same system.

@cindex limits, multi-dimension arrays
@cindex multi-dimension arrays
@cindex arrays, dimensioning
Whether large multiple-dimension arrays are reliably supported
depends mostly on the @command{gcc} back end (code generator)
used by @command{g77}, and has not yet been fully investigated.

@node Character-variable Length
@subsection Character-variable Length
@cindex limits, on character-variable length
@cindex character-variable length

Currently, @command{g77} uses the default @code{INTEGER} type
for the lengths of @code{CHARACTER} variables
and array elements.

This means that, for example,
a system with a 64-bit address space
and a 32-bit default @code{INTEGER} type
does not, under @command{g77},
support a @code{CHARACTER*@var{n}} declaration
where @var{n} is greater than 2147483647.

@node Year 10000 (Y10K) Problems
@subsection Year 10000 (Y10K) Problems
@cindex Y10K compliance
@cindex Year 10000 compliance

Most intrinsics returning, or computing values based on,
date information are prone to Year-10000 (Y10K) problems,
due to supporting only 4 digits for the year.

See the following for examples:
@ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
@ref{IDate Intrinsic (UNIX)},
@ref{Time Intrinsic (VXT)},
@ref{Date_and_Time Intrinsic}.

@node Compiler Types
@section Compiler Types
@cindex types, of data
@cindex data types

Fortran implementations have a fair amount of freedom given them by the
standard as far as how much storage space is used and how much precision
and range is offered by the various types such as @code{LOGICAL(KIND=1)},
@code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
@code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
Further, many compilers offer so-called @samp{*@var{n}} notation, but
the interpretation of @var{n} varies across compilers and target architectures.

The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
and @code{REAL(KIND=1)}
occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
Further, it requires that @code{COMPLEX(KIND=1)}
entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
storage-associated (such as via @code{EQUIVALENCE})
with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
corresponds to the real element and @samp{R(2)} to the imaginary
element of the @code{COMPLEX(KIND=1)} variable.

(Few requirements as to precision or ranges of any of these are
placed on the implementation, nor is the relationship of storage sizes of
these types to the @code{CHARACTER} type specified, by the standard.)

@command{g77} follows the above requirements, warning when compiling
a program requires placement of items in memory that contradict the
requirements of the target architecture.
(For example, a program can require placement of a @code{REAL(KIND=2)}
on a boundary that is not an even multiple of its size, but still an
even multiple of the size of a @code{REAL(KIND=1)} variable.
On some target architectures, using the canonical
mapping of Fortran types to underlying architectural types, such
placement is prohibited by the machine definition or
the Application Binary Interface (ABI) in force for
the configuration defined for building @command{gcc} and @command{g77}.
@command{g77} warns about such
situations when it encounters them.)

@command{g77} follows consistent rules for configuring the mapping between Fortran
types, including the @samp{*@var{n}} notation, and the underlying architectural
types as accessed by a similarly-configured applicable version of the
@command{gcc} compiler.
These rules offer a widely portable, consistent Fortran/C
environment, although they might well conflict with the expectations of
users of Fortran compilers designed and written for particular
architectures.

These rules are based on the configuration that is in force for the
version of @command{gcc} built in the same release as @command{g77} (and
which was therefore used to build both the @command{g77} compiler
components and the @code{libg2c} run-time library):

@table @code
@cindex REAL(KIND=1) type
@cindex types, REAL(KIND=1)
@item REAL(KIND=1)
Same as @code{float} type.

@cindex REAL(KIND=2) type
@cindex types, REAL(KIND=2)
@item REAL(KIND=2)
Same as whatever floating-point type that is twice the size
of a @code{float}---usually, this is a @code{double}.

@cindex INTEGER(KIND=1) type
@cindex types, INTEGER(KIND=1)
@item INTEGER(KIND=1)
Same as an integral type that is occupies the same amount
of memory storage as @code{float}---usually, this is either
an @code{int} or a @code{long int}.

@cindex LOGICAL(KIND=1) type
@cindex types, LOGICAL(KIND=1)
@item LOGICAL(KIND=1)
Same @command{gcc} type as @code{INTEGER(KIND=1)}.

@cindex INTEGER(KIND=2) type
@cindex types, INTEGER(KIND=2)
@item INTEGER(KIND=2)
Twice the size, and usually nearly twice the range,
as @code{INTEGER(KIND=1)}---usually, this is either
a @code{long int} or a @code{long long int}.

@cindex LOGICAL(KIND=2) type
@cindex types, LOGICAL(KIND=2)
@item LOGICAL(KIND=2)
Same @command{gcc} type as @code{INTEGER(KIND=2)}.

@cindex INTEGER(KIND=3) type
@cindex types, INTEGER(KIND=3)
@item INTEGER(KIND=3)
Same @command{gcc} type as signed @code{char}.

@cindex LOGICAL(KIND=3) type
@cindex types, LOGICAL(KIND=3)
@item LOGICAL(KIND=3)
Same @command{gcc} type as @code{INTEGER(KIND=3)}.

@cindex INTEGER(KIND=6) type
@cindex types, INTEGER(KIND=6)
@item INTEGER(KIND=6)
Twice the size, and usually nearly twice the range,
as @code{INTEGER(KIND=3)}---usually, this is
a @code{short}.

@cindex LOGICAL(KIND=6) type
@cindex types, LOGICAL(KIND=6)
@item LOGICAL(KIND=6)
Same @command{gcc} type as @code{INTEGER(KIND=6)}.

@cindex COMPLEX(KIND=1) type
@cindex types, COMPLEX(KIND=1)
@item COMPLEX(KIND=1)
Two @code{REAL(KIND=1)} scalars (one for the real part followed by
one for the imaginary part).

@cindex COMPLEX(KIND=2) type
@cindex types, COMPLEX(KIND=2)
@item COMPLEX(KIND=2)
Two @code{REAL(KIND=2)} scalars.

@cindex *@var{n} notation
@item @var{numeric-type}*@var{n}
(Where @var{numeric-type} is any type other than @code{CHARACTER}.)
Same as whatever @command{gcc} type occupies @var{n} times the storage
space of a @command{gcc} @code{char} item.

@cindex DOUBLE PRECISION type
@cindex types, DOUBLE PRECISION
@item DOUBLE PRECISION
Same as @code{REAL(KIND=2)}.

@cindex DOUBLE COMPLEX type
@cindex types, DOUBLE COMPLEX
@item DOUBLE COMPLEX
Same as @code{COMPLEX(KIND=2)}.
@end table

Note that the above are proposed correspondences and might change
in future versions of @command{g77}---avoid writing code depending
on them.

Other types supported by @command{g77}
are derived from gcc types such as @code{char}, @code{short},
@code{int}, @code{long int}, @code{long long int}, @code{long double},
and so on.
That is, whatever types @command{gcc} already supports, @command{g77} supports
now or probably will support in a future version.
The rules for the @samp{@var{numeric-type}*@var{n}} notation
apply to these types,
and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
assigned in a way that encourages clarity, consistency, and portability.

@node Compiler Constants
@section Compiler Constants
@cindex constants
@cindex types, constants

@command{g77} strictly assigns types to @emph{all} constants not
documented as ``typeless'' (typeless constants including @samp{'1'Z},
for example).
Many other Fortran compilers attempt to assign types to typed constants
based on their context.
This results in hard-to-find bugs, nonportable
code, and is not in the spirit (though it strictly follows the letter)
of the 77 and 90 standards.

@command{g77} might offer, in a future release, explicit constructs by
which a wider variety of typeless constants may be specified, and/or
user-requested warnings indicating places where @command{g77} might differ
from how other compilers assign types to constants.

@xref{Context-Sensitive Constants}, for more information on this issue.

@node Compiler Intrinsics
@section Compiler Intrinsics

@command{g77} offers an ever-widening set of intrinsics.
Currently these all are procedures (functions and subroutines).

Some of these intrinsics are unimplemented, but their names reserved
to reduce future problems with existing code as they are implemented.
Others are implemented as part of the GNU Fortran language, while
yet others are provided for compatibility with other dialects of
Fortran but are not part of the GNU Fortran language.

To manage these distinctions, @command{g77} provides intrinsic @emph{groups},
a facility that is simply an extension of the intrinsic groups provided
by the GNU Fortran language.

@menu
* Intrinsic Groups::  How intrinsics are grouped for easy management.
* Other Intrinsics::  Intrinsics other than those in the GNU
                       Fortran language.
@end menu

@node Intrinsic Groups
@subsection Intrinsic Groups
@cindex groups of intrinsics
@cindex intrinsics, groups

A given specific intrinsic belongs in one or more groups.
Each group is deleted, disabled, hidden, or enabled
by default or a command-line option.
The meaning of each term follows.

@table @b
@cindex deleted intrinsics
@cindex intrinsics, deleted
@item Deleted
No intrinsics are recognized as belonging to that group.

@cindex disabled intrinsics
@cindex intrinsics, disabled
@item Disabled
Intrinsics are recognized as belonging to the group, but
references to them (other than via the @code{INTRINSIC} statement)
are disallowed through that group.

@cindex hidden intrinsics
@cindex intrinsics, hidden
@item Hidden
Intrinsics in that group are recognized and enabled (if implemented)
@emph{only} if the first mention of the actual name of an intrinsic
in a program unit is in an @code{INTRINSIC} statement.

@cindex enabled intrinsics
@cindex intrinsics, enabled
@item Enabled
Intrinsics in that group are recognized and enabled (if implemented).
@end table

The distinction between deleting and disabling a group is illustrated
by the following example.
Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
If group @samp{FGR} is deleted, the following program unit will
successfully compile, because @samp{FOO()} will be seen as a
reference to an external function named @samp{FOO}:

@example
PRINT *, FOO()
END
@end example

@noindent
If group @samp{FGR} is disabled, compiling the above program will produce
diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
or, if properly invoked, it is not enabled.
To change the above program so it references an external function @samp{FOO}
instead of the disabled @samp{FOO} intrinsic,
add the following line to the top:

@example
EXTERNAL FOO
@end example

@noindent
So, deleting a group tells @command{g77} to pretend as though the intrinsics in
that group do not exist at all, whereas disabling it tells @command{g77} to
recognize them as (disabled) intrinsics in intrinsic-like contexts.

Hiding a group is like enabling it, but the intrinsic must be first
named in an @code{INTRINSIC} statement to be considered a reference to the
intrinsic rather than to an external procedure.
This might be the ``safest'' way to treat a new group of intrinsics
when compiling old
code, because it allows the old code to be generally written as if
those new intrinsics never existed, but to be changed to use them
by inserting @code{INTRINSIC} statements in the appropriate places.
However, it should be the goal of development to use @code{EXTERNAL}
for all names of external procedures that might be intrinsic names.

If an intrinsic is in more than one group, it is enabled if any of its
containing groups are enabled; if not so enabled, it is hidden if
any of its containing groups are hidden; if not so hidden, it is disabled
if any of its containing groups are disabled; if not so disabled, it is
deleted.
This extra complication is necessary because some intrinsics,
such as @code{IBITS}, belong to more than one group, and hence should be
enabled if any of the groups to which they belong are enabled, and so
on.

The groups are:

@cindex intrinsics, groups of
@cindex groups of intrinsics
@table @code
@cindex @code{badu77} intrinsics group
@item badu77
UNIX intrinsics having inappropriate forms (usually functions that
have intended side effects).

@cindex @code{gnu} intrinsics group
@item gnu
Intrinsics the GNU Fortran language supports that are extensions to
the Fortran standards (77 and 90).

@cindex @command{f2c} intrinsics group
@item f2c
Intrinsics supported by AT&T's @command{f2c} converter and/or @code{libf2c}.

@cindex @code{f90} intrinsics group
@item f90
Fortran 90 intrinsics.

@cindex @code{mil} intrinsics group
@item mil
MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).

@cindex @code{mil} intrinsics group
@item unix
UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).

@cindex @code{mil} intrinsics group
@item vxt
VAX/VMS FORTRAN (current as of v4) intrinsics.
@end table

@node Other Intrinsics
@subsection Other Intrinsics
@cindex intrinsics, others
@cindex other intrinsics

@command{g77} supports intrinsics other than those in the GNU Fortran
language proper.
This set of intrinsics is described below.

@ifinfo
(Note that the empty lines appearing in the menu below
are not intentional---they result from a bug in the
@code{makeinfo} program.)
@end ifinfo

@c The actual documentation for intrinsics comes from
@c intdoc.texi, which in turn is automatically generated
@c from the internal g77 tables in intrin.def _and_ the
@c largely hand-written text in intdoc.h.  So, if you want
@c to change or add to existing documentation on intrinsics,
@c you probably want to edit intdoc.h.
@c
@clear familyF77
@clear familyGNU
@clear familyASC
@clear familyMIL
@clear familyF90
@set familyVXT
@set familyFVZ
@clear familyF2C
@clear familyF2U
@set familyBADU77
@include intdoc.texi

@node Other Compilers
@chapter Other Compilers

An individual Fortran source file can be compiled to
an object (@file{*.o}) file instead of to the final
program executable.
This allows several portions of a program to be compiled
at different times and linked together whenever a new
version of the program is needed.
However, it introduces the issue of @dfn{object compatibility}
across the various object files (and libraries, or @file{*.a}
files) that are linked together to produce any particular
executable file.

Object compatibility is an issue when combining, in one
program, Fortran code compiled by more than one compiler
(or more than one configuration of a compiler).
If the compilers
disagree on how to transform the names of procedures, there
will normally be errors when linking such programs.
Worse, if the compilers agree on naming, but disagree on issues
like how to pass parameters, return arguments, and lay out
@code{COMMON} areas, the earliest detected errors might be the
incorrect results produced by the program (and that assumes
these errors are detected, which is not always the case).

Normally, @command{g77} generates code that is
object-compatible with code generated by a version of
@command{f2c} configured (with, for example, @file{f2c.h} definitions)
to be generally compatible with @command{g77} as built by @command{gcc}.
(Normally, @command{f2c} will, by default, conform to the appropriate
configuration, but it is possible that older or perhaps even newer
versions of @command{f2c}, or versions having certain configuration changes
to @command{f2c} internals, will produce object files that are
incompatible with @command{g77}.)

For example, a Fortran string subroutine
argument will become two arguments on the C side: a @code{char *}
and an @code{int} length.

Much of this compatibility results from the fact that
@command{g77} uses the same run-time library,
@code{libf2c}, used by @command{f2c},
though @command{g77} gives its version the name @code{libg2c}
so as to avoid conflicts when linking,
installing them in the same directories,
and so on.

Other compilers might or might not generate code that
is object-compatible with @code{libg2c} and current @command{g77},
and some might offer such compatibility only when explicitly
selected via a command-line option to the compiler.

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Dropping f2c Compatibility::  When speed is more important.
* Compilers Other Than f2c::    Interoperation with code from other compilers.
@end menu

@node Dropping f2c Compatibility
@section Dropping @command{f2c} Compatibility

Specifying @option{-fno-f2c} allows @command{g77} to generate, in
some cases, faster code, by not needing to allow to the possibility
of linking with code compiled by @command{f2c}.

For example, this affects how @code{REAL(KIND=1)},
@code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
With @option{-fno-f2c}, they are
compiled as returning the appropriate @command{gcc} type
(@code{float}, @code{__complex__ float}, @code{__complex__ double},
in many configurations).

With @option{-ff2c} in force, they
are compiled differently (with perhaps slower run-time performance)
to accommodate the restrictions inherent in @command{f2c}'s use of K&R
C as an intermediate language---@code{REAL(KIND=1)} functions
return C's @code{double} type, while @code{COMPLEX} functions return
@code{void} and use an extra argument pointing to a place for the functions to
return their values.

It is possible that, in some cases, leaving @option{-ff2c} in force
might produce faster code than using @option{-fno-f2c}.
Feel free to experiment, but remember to experiment with changing the way
@emph{entire programs and their Fortran libraries are compiled} at
a time, since this sort of experimentation affects the interface
of code generated for a Fortran source file---that is, it affects
object compatibility.

Note that @command{f2c} compatibility is a fairly static target to achieve,
though not necessarily perfectly so, since, like @command{g77}, it is
still being improved.
However, specifying @option{-fno-f2c} causes @command{g77}
to generate code that will probably be incompatible with code
generated by future versions of @command{g77} when the same option
is in force.
You should make sure you are always able to recompile complete
programs from source code when upgrading to new versions of @command{g77}
or @command{f2c}, especially when using options such as @option{-fno-f2c}.

Therefore, if you are using @command{g77} to compile libraries and other
object files for possible future use and you don't want to require
recompilation for future use with subsequent versions of @command{g77},
you might want to stick with @command{f2c} compatibility for now, and
carefully watch for any announcements about changes to the
@command{f2c}/@code{libf2c} interface that might affect existing programs
(thus requiring recompilation).

It is probable that a future version of @command{g77} will not,
by default, generate object files compatible with @command{f2c},
and that version probably would no longer use @code{libf2c}.
If you expect to depend on this compatibility in the
long term, use the options @samp{-ff2c -ff2c-library} when compiling
all of the applicable code.
This should cause future versions of @command{g77} either to produce
compatible code (at the expense of the availability of some features and
performance), or at the very least, to produce diagnostics.

(The library @command{g77} produces will no longer be named @file{libg2c}
when it is no longer generally compatible with @file{libf2c}.
It will likely be referred to, and, if installed as a distinct
library, named @code{libg77}, or some other as-yet-unused name.)

@node Compilers Other Than f2c
@section Compilers Other Than @command{f2c}

On systems with Fortran compilers other than @command{f2c} and @command{g77},
code compiled by @command{g77} is not expected to work
well with code compiled by the native compiler.
(This is true for @command{f2c}-compiled objects as well.)
Libraries compiled with the native compiler probably will have
to be recompiled with @command{g77} to be used with @command{g77}-compiled code.

Reasons for such incompatibilities include:

@itemize @bullet
@item
There might be differences in the way names of Fortran procedures
are translated for use in the system's object-file format.
For example, the statement @samp{CALL FOO} might be compiled
by @command{g77} to call a procedure the linker @command{ld} sees
given the name @samp{_foo_}, while the apparently corresponding
statement @samp{SUBROUTINE FOO} might be compiled by the
native compiler to define the linker-visible name @samp{_foo},
or @samp{_FOO_}, and so on.

@item
There might be subtle type mismatches which cause subroutine arguments
and function return values to get corrupted.

This is why simply getting @command{g77} to
transform procedure names the same way a native
compiler does is not usually a good idea---unless
some effort has been made to ensure that, aside
from the way the two compilers transform procedure
names, everything else about the way they generate
code for procedure interfaces is identical.

@item
Native compilers
use libraries of private I/O routines which will not be available
at link time unless you have the native compiler---and you would
have to explicitly ask for them.

For example, on the Sun you
would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
command.
@end itemize

@node Other Languages
@chapter Other Languages

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Interoperating with C and C++::
@end menu

@node Interoperating with C and C++
@section Tools and advice for interoperating with C and C++

@cindex C, linking with
@cindex C++, linking with
@cindex linking with C
The following discussion assumes that you are running @command{g77} in @command{f2c}
compatibility mode, i.e.@: not using @option{-fno-f2c}.
It provides some
advice about quick and simple techniques for linking Fortran and C (or
C++), the most common requirement.
For the full story consult the
description of code generation.
@xref{Debugging and Interfacing}.

When linking Fortran and C, it's usually best to use @command{g77} to do
the linking so that the correct libraries are included (including the
maths one).
If you're linking with C++ you will want to add
@option{-lstdc++}, @option{-lg++} or whatever.
If you need to use another
driver program (or @command{ld} directly),
you can find out what linkage
options @command{g77} passes by running @samp{g77 -v}.

@menu
* C Interfacing Tools::
* C Access to Type Information::
* f2c Skeletons and Prototypes::
* C++ Considerations::
* Startup Code::
@end menu

@node C Interfacing Tools
@subsection C Interfacing Tools
@pindex f2c
@cindex cfortran.h
@cindex Netlib
Even if you don't actually use it as a compiler, @command{f2c} from
@uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
interfacing (linking) Fortran and C@.
@xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @command{f2c}}.

To use @command{f2c} for this purpose you only need retrieve and
build the @file{src} directory from the distribution, consult the
@file{README} instructions there for machine-specifics, and install the
@command{f2c} program on your path.

Something else that might be useful is @samp{cfortran.h} from
@uref{ftp://zebra.desy.de/cfortran}.
This is a fairly general tool which
can be used to generate interfaces for calling in both directions
between Fortran and C@.
It can be used in @command{f2c} mode with
@command{g77}---consult its documentation for details.

@node C Access to Type Information
@subsection Accessing Type Information in C

@cindex types, Fortran/C
Generally, C code written to link with
@command{g77} code---calling and/or being
called from Fortran---should @samp{#include <g2c.h>} to define the C
versions of the Fortran types.
Don't assume Fortran @code{INTEGER} types
correspond to C @code{int}s, for instance; instead, declare them as
@code{integer}, a type defined by @file{g2c.h}.
@file{g2c.h} is installed where @command{gcc} will find it by
default, assuming you use a copy of @command{gcc} compatible with
@command{g77}, probably built at the same time as @command{g77}.

@node f2c Skeletons and Prototypes
@subsection Generating Skeletons and Prototypes with @command{f2c}

@pindex f2c
@cindex -fno-second-underscore
A simple and foolproof way to write @command{g77}-callable C routines---e.g.@: to
interface with an existing library---is to write a file (named, for
example, @file{fred.f}) of dummy Fortran
skeletons comprising just the declaration of the routine(s) and dummy
arguments plus @code{END} statements.
Then run @command{f2c} on file @file{fred.f} to produce @file{fred.c}
into which you can edit
useful code, confident the calling sequence is correct, at least.
(There are some errors otherwise commonly made in generating C
interfaces with @command{f2c} conventions,
such as not using @code{doublereal}
as the return type of a @code{REAL} @code{FUNCTION}.)

@pindex ftnchek
@command{f2c} also can help with calling Fortran from C, using its
@option{-P} option to generate C prototypes appropriate for calling the
Fortran.@footnote{The files generated like this can also be used for
inter-unit consistency checking of dummy and actual arguments, although
the @command{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
or @uref{ftp://ftp.dsm.fordham.edu} is
probably better for this purpose.}
If the Fortran code containing any
routines to be called from C is in file @file{joe.f}, use the command
@kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
prototype information.
@code{#include} this in the C which has to call
the Fortran routines to make sure you get it right.

@xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
between the way Fortran (including compilers like @command{g77}) and
C handle arrays.

@node C++ Considerations
@subsection C++ Considerations

@cindex C++
@command{f2c} can be used to generate suitable code for compilation with a
C++ system using the @option{-C++} option.
The important thing about linking @command{g77}-compiled
code with C++ is that the prototypes for the @command{g77}
routines must specify C linkage to avoid name mangling.
So, use an @samp{extern "C"} declaration.
@command{f2c}'s @option{-C++} option will not take care
of this when generating skeletons or prototype files as above, however,
it will avoid clashes with C++ reserved words in addition to those in C@.

@node Startup Code
@subsection Startup Code

@cindex startup code
@cindex run-time, initialization
@cindex initialization, run-time
Unlike with some runtime systems,
it shouldn't be necessary
(unless there are bugs)
to use a Fortran main program unit to ensure the
runtime---specifically the I/O system---is initialized.

However, to use the @command{g77} intrinsics @code{GETARG} and @code{IARGC},
either the @code{main} routine from the @file{libg2c} library must be used,
or the @code{f_setarg} routine
(new as of @code{egcs} version 1.1 and @command{g77} version 0.5.23)
must be called with the appropriate @code{argc} and @code{argv} arguments
prior to the program calling @code{GETARG} or @code{IARGC}.

To provide more flexibility for mixed-language programming
involving @command{g77} while allowing for shared libraries,
as of @code{egcs} version 1.1 and @command{g77} version 0.5.23,
@command{g77}'s @code{main} routine in @code{libg2c}
does the following, in order:

@enumerate
@item
Calls @code{f_setarg}
with the incoming @code{argc} and @code{argv} arguments,
in the same order as for @code{main} itself.

This sets up the command-line environment
for @code{GETARG} and @code{IARGC}.

@item
Calls @code{f_setsig} (with no arguments).

This sets up the signaling and exception environment.

@item
Calls @code{f_init} (with no arguments).

This initializes the I/O environment,
though that should not be necessary,
as all I/O functions in @code{libf2c}
are believed to call @code{f_init} automatically,
if necessary.

(A future version of @command{g77} might skip this explicit step,
to speed up normal exit of a program.)

@item
Arranges for @code{f_exit} to be called (with no arguments)
when the program exits.

This ensures that the I/O environment is properly shut down
before the program exits normally.
Otherwise, output buffers might not be fully flushed,
scratch files might not be deleted, and so on.

The simple way @code{main} does this is
to call @code{f_exit} itself after calling
@code{MAIN__} (in the next step).

However, this does not catch the cases where the program
might call @code{exit} directly,
instead of using the @code{EXIT} intrinsic
(implemented as @code{exit_} in @code{libf2c}).

So, @code{main} attempts to use
the operating environment's @code{onexit} or @code{atexit}
facility, if available,
to cause @code{f_exit} to be called automatically
upon any invocation of @code{exit}.

@item
Calls @code{MAIN__} (with no arguments).

This starts executing the Fortran main program unit for
the application.
(Both @command{g77} and @command{f2c} currently compile a main
program unit so that its global name is @code{MAIN__}.)

@item
If no @code{onexit} or @code{atexit} is provided by the system,
calls @code{f_exit}.

@item
Calls @code{exit} with a zero argument,
to signal a successful program termination.

@item
Returns a zero value to the caller,
to signal a successful program termination,
in case @code{exit} doesn't exit on the system.
@end enumerate

All of the above names are C @code{extern} names,
i.e.@: not mangled.

When using the @code{main} procedure provided by @command{g77}
without a Fortran main program unit,
you need to provide @code{MAIN__}
as the entry point for your C code.
(Make sure you link the object file that defines that
entry point with the rest of your program.)

To provide your own @code{main} procedure
in place of @command{g77}'s,
make sure you specify the object file defining that procedure
@emph{before} @option{-lg2c} on the @command{g77} command line.
Since the @option{-lg2c} option is implicitly provided,
this is usually straightforward.
(Use the @option{--verbose} option to see how and where
@command{g77} implicitly adds @option{-lg2c} in a command line
that will link the program.
Feel free to specify @option{-lg2c} explicitly,
as appropriate.)

However, when providing your own @code{main},
make sure you perform the appropriate tasks in the
appropriate order.
For example, if your @code{main} does not call @code{f_setarg},
make sure the rest of your application does not call
@code{GETARG} or @code{IARGC}.

And, if your @code{main} fails to ensure that @code{f_exit}
is called upon program exit,
some files might end up incompletely written,
some scratch files might be left lying around,
and some existing files being written might be left
with old data not properly truncated at the end.

Note that, generally, the @command{g77} operating environment
does not depend on a procedure named @code{MAIN__} actually
being called prior to any other @command{g77}-compiled code.
That is, @code{MAIN__} does not, itself,
set up any important operating-environment characteristics
upon which other code might depend.
This might change in future versions of @command{g77},
with appropriate notification in the release notes.

For more information, consult the source code for the above routines.
These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
@file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.

Also, the file @file{@value{path-g77}/com.c} contains the code @command{g77}
uses to open-code (inline) references to @code{IARGC}.

@node Debugging and Interfacing
@chapter Debugging and Interfacing
@cindex debugging
@cindex interfacing
@cindex calling C routines
@cindex C routines calling Fortran
@cindex f2c compatibility

GNU Fortran currently generates code that is object-compatible with
the @command{f2c} converter.
Also, it avoids limitations in the current GBE, such as the
inability to generate a procedure with
multiple entry points, by generating code that is structured
differently (in terms of procedure names, scopes, arguments, and
so on) than might be expected.

As a result, writing code in other languages that calls on, is
called by, or shares in-memory data with @command{g77}-compiled code generally
requires some understanding of the way @command{g77} compiles code for
various constructs.

Similarly, using a debugger to debug @command{g77}-compiled
code, even if that debugger supports native Fortran debugging, generally
requires this sort of information.

This section describes some of the basic information on how
@command{g77} compiles code for constructs involving interfaces to other
languages and to debuggers.

@emph{Caution:} Much or all of this information pertains to only the current
release of @command{g77}, sometimes even to using certain compiler options
with @command{g77} (such as @option{-fno-f2c}).
Do not write code that depends on this
information without clearly marking said code as nonportable and
subject to review for every new release of @command{g77}.
This information
is provided primarily to make debugging of code generated by this
particular release of @command{g77} easier for the user, and partly to make
writing (generally nonportable) interface code easier.
Both of these
activities require tracking changes in new version of @command{g77} as they
are installed, because new versions can change the behaviors
described in this section.

@menu
* Main Program Unit::  How @command{g77} compiles a main program unit.
* Procedures::         How @command{g77} constructs parameter lists
                       for procedures.
* Functions::          Functions returning floating-point or character data.
* Names::              Naming of user-defined variables, procedures, etc.
* Common Blocks::      Accessing common variables while debugging.
* Local Equivalence Areas::  Accessing @code{EQUIVALENCE} while debugging.
* Complex Variables::  How @command{g77} performs complex arithmetic.
* Arrays::             Dealing with (possibly multi-dimensional) arrays.
* Adjustable Arrays::  Special consideration for adjustable arrays.
* Alternate Entry Points::  How @command{g77} implements alternate @code{ENTRY}.
* Alternate Returns::  How @command{g77} handles alternate returns.
* Assigned Statement Labels::  How @command{g77} handles @code{ASSIGN}.
* Run-time Library Errors::  Meanings of some @code{IOSTAT=} values.
@end menu

@node Main Program Unit
@section Main Program Unit (PROGRAM)
@cindex PROGRAM statement
@cindex statements, PROGRAM

When @command{g77} compiles a main program unit, it gives it the public
procedure name @code{MAIN__}.
The @code{libg2c} library has the actual @code{main()} procedure
as is typical of C-based environments, and
it is this procedure that performs some initial start-up
activity and then calls @code{MAIN__}.

Generally, @command{g77} and @code{libg2c} are designed so that you need not
include a main program unit written in Fortran in your program---it
can be written in C or some other language.
Especially for I/O handling, this is the case, although @command{g77} version 0.5.16
includes a bug fix for @code{libg2c} that solved a problem with using the
@code{OPEN} statement as the first Fortran I/O activity in a program
without a Fortran main program unit.

However, if you don't intend to use @command{g77} (or @command{f2c}) to compile
your main program unit---that is, if you intend to compile a @code{main()}
procedure using some other language---you should carefully
examine the code for @code{main()} in @code{libg2c}, found in the source
file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
might need to be done by your @code{main()} in order to provide the
Fortran environment your Fortran code is expecting.

@cindex @code{IArgC} intrinsic
@cindex intrinsics, @code{IArgC}
@cindex @code{GetArg} intrinsic
@cindex intrinsics, @code{GetArg}
For example, @code{libg2c}'s @code{main()} sets up the information used by
the @code{IARGC} and @code{GETARG} intrinsics.
Bypassing @code{libg2c}'s @code{main()}
without providing a substitute for this activity would mean
that invoking @code{IARGC} and @code{GETARG} would produce undefined
results.

@cindex debugging
@cindex main program unit, debugging
@cindex main()
@cindex MAIN__()
@cindex .gdbinit
When debugging, one implication of the fact that @code{main()}, which
is the place where the debugged program ``starts'' from the
debugger's point of view, is in @code{libg2c} is that you won't be
starting your Fortran program at a point you recognize as your
Fortran code.

The standard way to get around this problem is to set a break
point (a one-time, or temporary, break point will do) at
the entrance to @code{MAIN__}, and then run the program.
A convenient way to do so is to add the @command{gdb} command

@example
tbreak MAIN__
@end example

@noindent
to the file @file{.gdbinit} in the directory in which you're debugging
(using @command{gdb}).

After doing this, the debugger will see the current execution
point of the program as at the beginning of the main program
unit of your program.

Of course, if you really want to set a break point at some
other place in your program and just start the program
running, without first breaking at @code{MAIN__},
that should work fine.

@node Procedures
@section Procedures (SUBROUTINE and FUNCTION)
@cindex procedures
@cindex SUBROUTINE statement
@cindex statements, SUBROUTINE
@cindex FUNCTION statement
@cindex statements, FUNCTION
@cindex signature of procedures

Currently, @command{g77} passes arguments via reference---specifically,
by passing a pointer to the location in memory of a variable, array,
array element, a temporary location that holds the result of evaluating an
expression, or a temporary or permanent location that holds the value
of a constant.

Procedures that accept @code{CHARACTER} arguments are implemented by
@command{g77} so that each @code{CHARACTER} argument has two actual arguments.

The first argument occupies the expected position in the
argument list and has the user-specified name.
This argument
is a pointer to an array of characters, passed by the caller.

The second argument is appended to the end of the user-specified
calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
is the user-specified name.
This argument is of the C type @code{ftnlen}
(see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
is the number of characters the caller has allocated in the
array pointed to by the first argument.

A procedure will ignore the length argument if @samp{X} is not declared
@code{CHARACTER*(*)}, because for other declarations, it knows the
length.
Not all callers necessarily ``know'' this, however, which
is why they all pass the extra argument.

The contents of the @code{CHARACTER} argument are specified by the
address passed in the first argument (named after it).
The procedure can read or write these contents as appropriate.

When more than one @code{CHARACTER} argument is present in the argument
list, the length arguments are appended in the order
the original arguments appear.
So @samp{CALL FOO('HI','THERE')} is implemented in
C as @samp{foo("hi","there",2,5);}, ignoring the fact that @command{g77}
does not provide the trailing null bytes on the constant
strings (@command{f2c} does provide them, but they are unnecessary in
a Fortran environment, and you should not expect them to be
there).

Note that the above information applies to @code{CHARACTER} variables and
arrays @strong{only}.
It does @strong{not} apply to external @code{CHARACTER}
functions or to intrinsic @code{CHARACTER} functions.
That is, no second length argument is passed to @samp{FOO} in this case:

@example
CHARACTER X
EXTERNAL X
CALL FOO(X)
@end example

@noindent
Nor does @samp{FOO} expect such an argument in this case:

@example
SUBROUTINE FOO(X)
CHARACTER X
EXTERNAL X
@end example

Because of this implementation detail, if a program has a bug
such that there is disagreement as to whether an argument is
a procedure, and the type of the argument is @code{CHARACTER}, subtle
symptoms might appear.

@node Functions
@section Functions (FUNCTION and RETURN)
@cindex functions
@cindex FUNCTION statement
@cindex statements, FUNCTION
@cindex RETURN statement
@cindex statements, RETURN
@cindex return type of functions

@command{g77} handles in a special way functions that return the following
types:

@itemize @bullet
@item
@code{CHARACTER}
@item
@code{COMPLEX}
@item
@code{REAL(KIND=1)}
@end itemize

For @code{CHARACTER}, @command{g77} implements a subroutine (a C function
returning @code{void})
with two arguments prepended: @samp{__g77_result}, which the caller passes
as a pointer to a @code{char} array expected to hold the return value,
and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
specifying the length of the return value as declared in the calling
program.
For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
to determine the size of the array that @samp{__g77_result} points to;
otherwise, it ignores that argument.

For @code{COMPLEX}, when @option{-ff2c} is in
force, @command{g77} implements
a subroutine with one argument prepended: @samp{__g77_result}, which the
caller passes as a pointer to a variable of the type of the function.
The called function writes the return value into this variable instead
of returning it as a function value.
When @option{-fno-f2c} is in force,
@command{g77} implements a @code{COMPLEX} function as @command{gcc}'s
@samp{__complex__ float} or @samp{__complex__ double} function
(or an emulation thereof, when @option{-femulate-complex} is in effect),
returning the result of the function in the same way as @command{gcc} would.

For @code{REAL(KIND=1)}, when @option{-ff2c} is in force, @command{g77} implements
a function that actually returns @code{REAL(KIND=2)} (typically
C's @code{double} type).
When @option{-fno-f2c} is in force, @code{REAL(KIND=1)}
functions return @code{float}.

@node Names
@section Names
@cindex symbol names
@cindex transforming symbol names

Fortran permits each implementation to decide how to represent
names as far as how they're seen in other contexts, such as debuggers
and when interfacing to other languages, and especially as far
as how casing is handled.

External names---names of entities that are public, or ``accessible'',
to all modules in a program---normally have an underscore (@samp{_})
appended by @command{g77},
to generate code that is compatible with @command{f2c}.
External names include names of Fortran things like common blocks,
external procedures (subroutines and functions, but not including
statement functions, which are internal procedures), and entry point
names.

However, use of the @option{-fno-underscoring} option
disables this kind of transformation of external names (though inhibiting
the transformation certainly improves the chances of colliding with
incompatible externals written in other languages---but that
might be intentional.

@cindex -fno-underscoring option
@cindex options, -fno-underscoring
@cindex -fno-second-underscore option
@cindex options, -fno-underscoring
When @option{-funderscoring} is in force, any name (external or local)
that already has at least one underscore in it is
implemented by @command{g77} by appending two underscores.
(This second underscore can be disabled via the
@option{-fno-second-underscore} option.)
External names are changed this way for @command{f2c} compatibility.
Local names are changed this way to avoid collisions with external names
that are different in the source code---@command{f2c} does the same thing, but
there's no compatibility issue there except for user expectations while
debugging.

For example:

@example
Max_Cost = 0
@end example

@cindex debugging
@noindent
Here, a user would, in the debugger, refer to this variable using the
name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
as described below).
(We hope to improve @command{g77} in this regard in the future---don't
write scripts depending on this behavior!
Also, consider experimenting with the @option{-fno-underscoring}
option to try out debugging without having to massage names by
hand like this.)

@command{g77} provides a number of command-line options that allow the user
to control how case mapping is handled for source files.
The default is the traditional UNIX model for Fortran compilers---names
are mapped to lower case.
Other command-line options can be specified to map names to upper
case, or to leave them exactly as written in the source file.

For example:

@example
Foo = 9.436
@end example

@noindent
Here, it is normally the case that the variable assigned will be named
@samp{foo}.
This would be the name to enter when using a debugger to
access the variable.

However, depending on the command-line options specified, the
name implemented by @command{g77} might instead be @samp{FOO} or even
@samp{Foo}, thus affecting how debugging is done.

Also:

@example
Call Foo
@end example

@noindent
This would normally call a procedure that, if it were in a separate C program,
be defined starting with the line:

@example
void foo_()
@end example

@noindent
However, @command{g77} command-line options could be used to change the casing
of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
procedure instead of @samp{foo_}, and the @option{-fno-underscoring} option
could be used to inhibit the appending of the underscore to the name.

@node Common Blocks
@section Common Blocks (COMMON)
@cindex common blocks
@cindex @code{COMMON} statement
@cindex statements, @code{COMMON}

@command{g77} names and lays out @code{COMMON} areas
the same way @command{f2c} does,
for compatibility with @command{f2c}.

@node Local Equivalence Areas
@section Local Equivalence Areas (EQUIVALENCE)
@cindex equivalence areas
@cindex local equivalence areas
@cindex EQUIVALENCE statement
@cindex statements, EQUIVALENCE

@command{g77} treats storage-associated areas involving a @code{COMMON}
block as explained in the section on common blocks.

A local @code{EQUIVALENCE} area is a collection of variables and arrays
connected to each other in any way via @code{EQUIVALENCE}, none of which are
listed in a @code{COMMON} statement.

(@emph{Note:} @command{g77} version 0.5.18 and earlier chose the name
for @var{x} using a different method when more than one name was
in the list of names of entities placed at the beginning of the
array.
Though the documentation specified that the first name listed in
the @code{EQUIVALENCE} statements was chosen for @var{x}, @command{g77}
in fact chose the name using a method that was so complicated,
it seemed easier to change it to an alphabetical sort than to describe the
previous method in the documentation.)

@node Complex Variables
@section Complex Variables (COMPLEX)
@cindex complex variables
@cindex imaginary part
@cindex COMPLEX statement
@cindex statements, COMPLEX

As of 0.5.20, @command{g77} defaults to handling @code{COMPLEX} types
(and related intrinsics, constants, functions, and so on)
in a manner that
makes direct debugging involving these types in Fortran
language mode difficult.

Essentially, @command{g77} implements these types using an
internal construct similar to C's @code{struct}, at least
as seen by the @command{gcc} back end.

Currently, the back end, when outputting debugging info with
the compiled code for the assembler to digest, does not detect
these @code{struct} types as being substitutes for Fortran
complex.
As a result, the Fortran language modes of debuggers such as
@command{gdb} see these types as C @code{struct} types, which
they might or might not support.

Until this is fixed, switch to C language mode to work with
entities of @code{COMPLEX} type and then switch back to Fortran language
mode afterward.
(In @command{gdb}, this is accomplished via @samp{set lang c} and
either @samp{set lang fortran} or @samp{set lang auto}.)

@node Arrays
@section Arrays (DIMENSION)
@cindex DIMENSION statement
@cindex statements, DIMENSION
@cindex array ordering
@cindex ordering, array
@cindex column-major ordering
@cindex row-major ordering
@cindex arrays

Fortran uses ``column-major ordering'' in its arrays.
This differs from other languages, such as C, which use ``row-major ordering''.
The difference is that, with Fortran, array elements adjacent to
each other in memory differ in the @emph{first} subscript instead of
the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
whereas with row-major ordering it would follow @samp{A(5,10,19)}.

This consideration
affects not only interfacing with and debugging Fortran code,
it can greatly affect how code is designed and written, especially
when code speed and size is a concern.

Fortran also differs from C, a popular language for interfacing and
to support directly in debuggers, in the way arrays are treated.
In C, arrays are single-dimensional and have interesting relationships
to pointers, neither of which is true for Fortran.
As a result, dealing with Fortran arrays from within
an environment limited to C concepts can be challenging.

For example, accessing the array element @samp{A(5,10,20)} is easy enough
in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
are needed.
First, C would treat the A array as a single-dimension array.
Second, C does not understand low bounds for arrays as does Fortran.
Third, C assumes a low bound of zero (0), while Fortran defaults to a
low bound of one (1) and can supports an arbitrary low bound.
Therefore, calculations must be done
to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
calculations require knowing the dimensions of @samp{A}.

For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
@samp{A(5,10,20)} would be:

@example
  (5-2)
+ (10-1)*(11-2+1)
+ (20-0)*(11-2+1)*(21-1+1)
= 4293
@end example

@noindent
So the C equivalent in this case would be @samp{a[4293]}.

When using a debugger directly on Fortran code, the C equivalent
might not work, because some debuggers cannot understand the notion
of low bounds other than zero.  However, unlike @command{f2c}, @command{g77}
does inform the GBE that a multi-dimensional array (like @samp{A}
in the above example) is really multi-dimensional, rather than a
single-dimensional array, so at least the dimensionality of the array
is preserved.

Debuggers that understand Fortran should have no trouble with
nonzero low bounds, but for non-Fortran debuggers, especially
C debuggers, the above example might have a C equivalent of
@samp{a[4305]}.
This calculation is arrived at by eliminating the subtraction
of the lower bound in the first parenthesized expression on each
line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
Actually, the implication of
this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
but that @samp{a[20][10][5]} produces the equivalent of
@samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.

Come to think of it, perhaps
the behavior is due to the debugger internally compensating for
the lower bounds by offsetting the base address of @samp{a}, leaving
@samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
its first element as identified by subscripts equal to the
corresponding lower bounds).

You know, maybe nobody really needs to use arrays.

@node Adjustable Arrays
@section Adjustable Arrays (DIMENSION)
@cindex arrays, adjustable
@cindex adjustable arrays
@cindex arrays, automatic
@cindex automatic arrays
@cindex DIMENSION statement
@cindex statements, DIMENSION
@cindex dimensioning arrays
@cindex arrays, dimensioning

Adjustable and automatic arrays in Fortran require the implementation
(in this
case, the @command{g77} compiler) to ``memorize'' the expressions that
dimension the arrays each time the procedure is invoked.
This is so that subsequent changes to variables used in those
expressions, made during execution of the procedure, do not
have any effect on the dimensions of those arrays.

For example:

@example
REAL ARRAY(5)
DATA ARRAY/5*2/
CALL X(ARRAY, 5)
END
SUBROUTINE X(A, N)
DIMENSION A(N)
N = 20
PRINT *, N, A
END
@end example

@noindent
Here, the implementation should, when running the program, print something
like:

@example
20   2.  2.  2.  2.  2.
@end example

@noindent
Note that this shows that while the value of @samp{N} was successfully
changed, the size of the @samp{A} array remained at 5 elements.

To support this, @command{g77} generates code that executes before any user
code (and before the internally generated computed @code{GOTO} to handle
alternate entry points, as described below) that evaluates each
(nonconstant) expression in the list of subscripts for an
array, and saves the result of each such evaluation to be used when
determining the size of the array (instead of re-evaluating the
expressions).

So, in the above example, when @samp{X} is first invoked, code is
executed that copies the value of @samp{N} to a temporary.
And that same temporary serves as the actual high bound for the single
dimension of the @samp{A} array (the low bound being the constant 1).
Since the user program cannot (legitimately) change the value
of the temporary during execution of the procedure, the size
of the array remains constant during each invocation.

For alternate entry points, the code @command{g77} generates takes into
account the possibility that a dummy adjustable array is not actually
passed to the actual entry point being invoked at that time.
In that case, the public procedure implementing the entry point
passes to the master private procedure implementing all the
code for the entry points a @code{NULL} pointer where a pointer to that
adjustable array would be expected.
The @command{g77}-generated code
doesn't attempt to evaluate any of the expressions in the subscripts
for an array if the pointer to that array is @code{NULL} at run time in
such cases.
(Don't depend on this particular implementation
by writing code that purposely passes @code{NULL} pointers where the
callee expects adjustable arrays, even if you know the callee
won't reference the arrays---nor should you pass @code{NULL} pointers
for any dummy arguments used in calculating the bounds of such
arrays or leave undefined any values used for that purpose in
COMMON---because the way @command{g77} implements these things might
change in the future!)

@node Alternate Entry Points
@section Alternate Entry Points (ENTRY)
@cindex alternate entry points
@cindex entry points
@cindex ENTRY statement
@cindex statements, ENTRY

The GBE does not understand the general concept of
alternate entry points as Fortran provides via the ENTRY statement.
@command{g77} gets around this by using an approach to compiling procedures
having at least one @code{ENTRY} statement that is almost identical to the
approach used by @command{f2c}.
(An alternate approach could be used that
would probably generate faster, but larger, code that would also
be a bit easier to debug.)

Information on how @command{g77} implements @code{ENTRY} is provided for those
trying to debug such code.
The choice of implementation seems
unlikely to affect code (compiled in other languages) that interfaces
to such code.

@command{g77} compiles exactly one public procedure for the primary entry
point of a procedure plus each @code{ENTRY} point it specifies, as usual.
That is, in terms of the public interface, there is no difference
between

@example
SUBROUTINE X
END
SUBROUTINE Y
END
@end example

@noindent
and:

@example
SUBROUTINE X
ENTRY Y
END
@end example

The difference between the above two cases lies in the code compiled
for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
for the second case, an extra internal procedure is compiled.

For every Fortran procedure with at least one @code{ENTRY}
statement, @command{g77} compiles an extra procedure
named @samp{__g77_masterfun_@var{x}}, where @var{x} is
the name of the primary entry point (which, in the above case,
using the standard compiler options, would be @samp{x_} in C).

This extra procedure is compiled as a private procedure---that is,
a procedure not accessible by name to separately compiled modules.
It contains all the code in the program unit, including the code
for the primary entry point plus for every entry point.
(The code for each public procedure is quite short, and explained later.)

The extra procedure has some other interesting characteristics.

The argument list for this procedure is invented by @command{g77}.
It contains
a single integer argument named @samp{__g77_which_entrypoint},
passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
entry point index---0 for the primary entry point, 1 for the
first entry point (the first @code{ENTRY} statement encountered), 2 for
the second entry point, and so on.

It also contains, for functions returning @code{CHARACTER} and
(when @option{-ff2c} is in effect) @code{COMPLEX} functions,
and for functions returning different types among the
@code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
is expected at run time to contain a pointer to where to store
the result of the entry point.
For @code{CHARACTER} functions, this
storage area is an array of the appropriate number of characters;
for @code{COMPLEX} functions, it is the appropriate area for the return
type; for multiple-return-type functions, it is a union of all the supported return
types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
is not supported by @command{g77}).

For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
by yet another argument named @samp{__g77_length} that, at run time,
specifies the caller's expected length of the returned value.
Note that only @code{CHARACTER*(*)} functions and entry points actually
make use of this argument, even though it is always passed by
all callers of public @code{CHARACTER} functions (since the caller does not
generally know whether such a function is @code{CHARACTER*(*)} or whether
there are any other callers that don't have that information).

The rest of the argument list is the union of all the arguments
specified for all the entry points (in their usual forms, e.g.
@code{CHARACTER} arguments have extra length arguments, all appended at
the end of this list).
This is considered the ``master list'' of
arguments.

The code for this procedure has, before the code for the first
executable statement, code much like that for the following Fortran
statement:

@smallexample
       GOTO (100000,100001,100002), __g77_which_entrypoint
100000 @dots{}code for primary entry point@dots{}
100001 @dots{}code immediately following first ENTRY statement@dots{}
100002 @dots{}code immediately following second ENTRY statement@dots{}
@end smallexample

@noindent
(Note that invalid Fortran statement labels and variable names
are used in the above example to highlight the fact that it
represents code generated by the @command{g77} internals, not code to be
written by the user.)

It is this code that, when the procedure is called, picks which
entry point to start executing.

Getting back to the public procedures (@samp{x} and @samp{Y} in the original
example), those procedures are fairly simple.
Their interfaces
are just like they would be if they were self-contained procedures
(without @code{ENTRY}), of course, since that is what the callers
expect.
Their code consists of simply calling the private
procedure, described above, with the appropriate extra arguments
(the entry point index, and perhaps a pointer to a multiple-type-
return variable, local to the public procedure, that contains
all the supported returnable non-character types).
For arguments
that are not listed for a given entry point that are listed for
other entry points, and therefore that are in the ``master list''
for the private procedure, null pointers (in C, the @code{NULL} macro)
are passed.
Also, for entry points that are part of a multiple-type-
returning function, code is compiled after the call of the private
procedure to extract from the multi-type union the appropriate result,
depending on the type of the entry point in question, returning
that result to the original caller.

When debugging a procedure containing alternate entry points, you
can either set a break point on the public procedure itself (e.g.
a break point on @samp{X} or @samp{Y}) or on the private procedure that
contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
If you do the former, you should use the debugger's command to
``step into'' the called procedure to get to the actual code; with
the latter approach, the break point leaves you right at the
actual code, skipping over the public entry point and its call
to the private procedure (unless you have set a break point there
as well, of course).

Further, the list of dummy arguments that is visible when the
private procedure is active is going to be the expanded version
of the list for whichever particular entry point is active,
as explained above, and the way in which return values are
handled might well be different from how they would be handled
for an equivalent single-entry function.

@node Alternate Returns
@section Alternate Returns (SUBROUTINE and RETURN)
@cindex subroutines
@cindex alternate returns
@cindex SUBROUTINE statement
@cindex statements, SUBROUTINE
@cindex RETURN statement
@cindex statements, RETURN

Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
@samp{CALL X(*50)}) are implemented by @command{g77} as functions returning
the C @code{int} type.
The actual alternate-return arguments are omitted from the calling sequence.
Instead, the caller uses
the return value to do a rough equivalent of the Fortran
computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
function), and the callee just returns whatever integer
is specified in the @code{RETURN} statement for the subroutine
For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
by @samp{RETURN}
in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).

@node Assigned Statement Labels
@section Assigned Statement Labels (ASSIGN and GOTO)
@cindex assigned statement labels
@cindex statement labels, assigned
@cindex ASSIGN statement
@cindex statements, ASSIGN
@cindex GOTO statement
@cindex statements, GOTO

For portability to machines where a pointer (such as to a label,
which is how @command{g77} implements @code{ASSIGN} and its relatives,
the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
is wider (bitwise) than an @code{INTEGER(KIND=1)}, @command{g77}
uses a different memory location to hold the @code{ASSIGN}ed value of a variable
than it does the numerical value in that variable, unless the
variable is wide enough (can hold enough bits).

In particular, while @command{g77} implements

@example
I = 10
@end example

@noindent
as, in C notation, @samp{i = 10;}, it implements

@example
ASSIGN 10 TO I
@end example

@noindent
as, in GNU's extended C notation (for the label syntax),
@samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
of the Fortran label @samp{10} to make the syntax C-like; @command{g77} doesn't
actually generate the name @samp{L10} or any other name like that,
since debuggers cannot access labels anyway).

While this currently means that an @code{ASSIGN} statement does not
overwrite the numeric contents of its target variable, @emph{do not}
write any code depending on this feature.
@command{g77} has already changed this implementation across
versions and might do so in the future.
This information is provided only to make debugging Fortran programs
compiled with the current version of @command{g77} somewhat easier.
If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
in a program unit that does @samp{ASSIGN 10 TO I}, that probably
means @command{g77} has decided it can store the pointer to the label directly
into @samp{I} itself.

@xref{Ugly Assigned Labels}, for information on a command-line option
to force @command{g77} to use the same storage for both normal and
assigned-label uses of a variable.

@node Run-time Library Errors
@section Run-time Library Errors
@cindex IOSTAT=
@cindex error values
@cindex error messages
@cindex messages, run-time
@cindex I/O, errors

The @code{libg2c} library currently has the following table to relate
error code numbers, returned in @code{IOSTAT=} variables, to messages.
This information should, in future versions of this document, be
expanded upon to include detailed descriptions of each message.

In line with good coding practices, any of the numbers in the
list below should @emph{not} be directly written into Fortran
code you write.
Instead, make a separate @code{INCLUDE} file that defines
@code{PARAMETER} names for them, and use those in your code,
so you can more easily change the actual numbers in the future.

The information below is culled from the definition
of @code{F_err} in @file{f/runtime/libI77/err.c} in the
@command{g77} source tree.

@smallexample
100: "error in format"
101: "illegal unit number"
102: "formatted io not allowed"
103: "unformatted io not allowed"
104: "direct io not allowed"
105: "sequential io not allowed"
106: "can't backspace file"
107: "null file name"
108: "can't stat file"
109: "unit not connected"
110: "off end of record"
111: "truncation failed in endfile"
112: "incomprehensible list input"
113: "out of free space"
114: "unit not connected"
115: "read unexpected character"
116: "bad logical input field"
117: "bad variable type"
118: "bad namelist name"
119: "variable not in namelist"
120: "no end record"
121: "variable count incorrect"
122: "subscript for scalar variable"
123: "invalid array section"
124: "substring out of bounds"
125: "subscript out of bounds"
126: "can't read file"
127: "can't write file"
128: "'new' file exists"
129: "can't append to file"
130: "non-positive record number"
131: "I/O started while already doing I/O"
@end smallexample

@node Collected Fortran Wisdom
@chapter Collected Fortran Wisdom
@cindex wisdom
@cindex legacy code
@cindex code, legacy
@cindex writing code
@cindex code, writing

Most users of @command{g77} can be divided into two camps:

@itemize @bullet
@item
Those writing new Fortran code to be compiled by @command{g77}.

@item
Those using @command{g77} to compile existing, ``legacy'' code.
@end itemize

Users writing new code generally understand most of the necessary
aspects of Fortran to write ``mainstream'' code, but often need
help deciding how to handle problems, such as the construction
of libraries containing @code{BLOCK DATA}.

Users dealing with ``legacy'' code sometimes don't have much
experience with Fortran, but believe that the code they're compiling
already works when compiled by other compilers (and might
not understand why, as is sometimes the case, it doesn't work
when compiled by @command{g77}).

The following information is designed to help users do a better job
coping with existing, ``legacy'' Fortran code, and with writing
new code as well.

@menu
* Advantages Over f2c::        If @command{f2c} is so great, why @command{g77}?
* Block Data and Libraries::   How @command{g77} solves a common problem.
* Loops::                      Fortran @code{DO} loops surprise many people.
* Working Programs::           Getting programs to work should be done first.
* Overly Convenient Options::  Temptations to avoid, habits to not form.
* Faster Programs::            Everybody wants these, but at what cost?
@end menu

@node Advantages Over f2c
@section Advantages Over f2c

Without @command{f2c}, @command{g77} would have taken much longer to
do and probably not been as good for quite a while.
Sometimes people who notice how much @command{g77} depends on, and
documents encouragement to use, @command{f2c} ask why @command{g77}
was created if @command{f2c} already existed.

This section gives some basic answers to these questions, though it
is not intended to be comprehensive.

@menu
* Language Extensions::  Features used by Fortran code.
* Diagnostic Abilities:: Abilities to spot problems early.
* Compiler Options::     Features helpful to accommodate legacy code, etc.
* Compiler Speed::       Speed of the compilation process.
* Program Speed::        Speed of the generated, optimized code.
* Ease of Debugging::    Debugging ease-of-use at the source level.
* Character and Hollerith Constants::  A byte saved is a byte earned.
@end menu

@node Language Extensions
@subsection Language Extensions

@command{g77} offers several extensions to FORTRAN 77 language that @command{f2c}
doesn't:

@itemize @bullet
@item
Automatic arrays

@item
@code{CYCLE} and @code{EXIT}

@item
Construct names

@item
@code{SELECT CASE}

@item
@code{KIND=} and @code{LEN=} notation

@item
Semicolon as statement separator

@item
Constant expressions in @code{FORMAT} statements
(such as @samp{FORMAT(I<J>)},
where @samp{J} is a @code{PARAMETER} named constant)

@item
@code{MvBits} intrinsic

@item
@code{libU77} (Unix-compatibility) library,
with routines known to compiler as intrinsics
(so they work even when compiler options are used
to change the interfaces used by Fortran routines)
@end itemize

@command{g77} also implements iterative @code{DO} loops
so that they work even in the presence of certain ``extreme'' inputs,
unlike @command{f2c}.
@xref{Loops}.

However, @command{f2c} offers a few that @command{g77} doesn't, such as:

@itemize @bullet
@item
Intrinsics in @code{PARAMETER} statements

@item
Array bounds expressions (such as @samp{REAL M(N(2))})

@item
@code{AUTOMATIC} statement
@end itemize

It is expected that @command{g77} will offer some or all of these missing
features at some time in the future.

@node Diagnostic Abilities
@subsection Diagnostic Abilities

@command{g77} offers better diagnosis of problems in @code{FORMAT} statements.
@command{f2c} doesn't, for example, emit any diagnostic for
@samp{FORMAT(XZFAJG10324)},
leaving that to be diagnosed, at run time, by
the @code{libf2c} run-time library.

@node Compiler Options
@subsection Compiler Options

@command{g77} offers compiler options that @command{f2c} doesn't,
most of which are designed to more easily accommodate
legacy code:

@itemize @bullet
@item
Two that control the automatic appending of extra
underscores to external names

@item
One that allows dollar signs (@samp{$}) in symbol names

@item
A variety that control acceptance of various
``ugly'' constructs

@item
Several that specify acceptable use of upper and lower case
in the source code

@item
Many that enable, disable, delete, or hide
groups of intrinsics

@item
One to specify the length of fixed-form source lines
(normally 72)

@item
One to specify the the source code is written in
Fortran-90-style free-form
@end itemize

However, @command{f2c} offers a few that @command{g77} doesn't,
like an option to have @code{REAL} default to @code{REAL*8}.
It is expected that @command{g77} will offer all of the
missing options pertinent to being a Fortran compiler
at some time in the future.

@node Compiler Speed
@subsection Compiler Speed

Saving the steps of writing and then rereading C code is a big reason
why @command{g77} should be able to compile code much faster than using
@command{f2c} in conjunction with the equivalent invocation of @command{gcc}.

However, due to @command{g77}'s youth, lots of self-checking is still being
performed.
As a result, this improvement is as yet unrealized
(though the potential seems to be there for quite a big speedup
in the future).
It is possible that, as of version 0.5.18, @command{g77}
is noticeably faster compiling many Fortran source files than using
@command{f2c} in conjunction with @command{gcc}.

@node Program Speed
@subsection Program Speed

@command{g77} has the potential to better optimize code than @command{f2c},
even when @command{gcc} is used to compile the output of @command{f2c},
because @command{f2c} must necessarily
translate Fortran into a somewhat lower-level language (C) that cannot
preserve all the information that is potentially useful for optimization,
while @command{g77} can gather, preserve, and transmit that information directly
to the GBE.

For example, @command{g77} implements @code{ASSIGN} and assigned
@code{GOTO} using direct assignment of pointers to labels and direct
jumps to labels, whereas @command{f2c} maps the assigned labels to
integer values and then uses a C @code{switch} statement to encode
the assigned @code{GOTO} statements.

However, as is typical, theory and reality don't quite match, at least
not in all cases, so it is still the case that @command{f2c} plus @command{gcc}
can generate code that is faster than @command{g77}.

Version 0.5.18 of @command{g77} offered default
settings and options, via patches to the @command{gcc}
back end, that allow for better program speed, though
some of these improvements also affected the performance
of programs translated by @command{f2c} and then compiled
by @command{g77}'s version of @command{gcc}.

Version 0.5.20 of @command{g77} offers further performance
improvements, at least one of which (alias analysis) is
not generally applicable to @command{f2c} (though @command{f2c}
could presumably be changed to also take advantage of
this new capability of the @command{gcc} back end, assuming
this is made available in an upcoming release of @command{gcc}).

@node Ease of Debugging
@subsection Ease of Debugging

Because @command{g77} compiles directly to assembler code like @command{gcc},
instead of translating to an intermediate language (C) as does @command{f2c},
support for debugging can be better for @command{g77} than @command{f2c}.

However, although @command{g77} might be somewhat more ``native'' in terms of
debugging support than @command{f2c} plus @command{gcc}, there still are a lot
of things ``not quite right''.
Many of the important ones should be resolved in the near future.

For example, @command{g77} doesn't have to worry about reserved names
like @command{f2c} does.
Given @samp{FOR = WHILE}, @command{f2c} must necessarily
translate this to something @emph{other} than
@samp{for = while;}, because C reserves those words.

However, @command{g77} does still uses things like an extra level of indirection
for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
yet support multiple entry points.

Another example is that, given

@smallexample
COMMON A, B
EQUIVALENCE (B, C)
@end smallexample

@noindent
the @command{g77} user should be able to access the variables directly, by name,
without having to traverse C-like structures and unions, while @command{f2c}
is unlikely to ever offer this ability (due to limitations in the
C language).

Yet another example is arrays.
@command{g77} represents them to the debugger
using the same ``dimensionality'' as in the source code, while @command{f2c}
must necessarily convert them all to one-dimensional arrays to fit
into the confines of the C language.
However, the level of support
offered by debuggers for interactive Fortran-style access to arrays
as compiled by @command{g77} can vary widely.
In some cases, it can actually
be an advantage that @command{f2c} converts everything to widely supported
C semantics.

In fairness, @command{g77} could do many of the things @command{f2c} does
to get things working at least as well as @command{f2c}---for now,
the developers prefer making @command{g77} work the
way they think it is supposed to, and finding help improving the
other products (the back end of @command{gcc}; @command{gdb}; and so on)
to get things working properly.

@node Character and Hollerith Constants
@subsection Character and Hollerith Constants
@cindex character constants
@cindex constants, character
@cindex Hollerith constants
@cindex constants, Hollerith
@cindex trailing null byte
@cindex null byte, trailing
@cindex zero byte, trailing

To avoid the extensive hassle that would be needed to avoid this,
@command{f2c} uses C character constants to encode character and Hollerith
constants.
That means a constant like @samp{'HELLO'} is translated to
@samp{"hello"} in C, which further means that an extra null byte is
present at the end of the constant.
This null byte is superfluous.

@command{g77} does not generate such null bytes.
This represents significant
savings of resources, such as on systems where @file{/dev/null} or
@file{/dev/zero} represent bottlenecks in the systems' performance,
because @command{g77} simply asks for fewer zeros from the operating
system than @command{f2c}.
(Avoiding spurious use of zero bytes, each byte typically have
eight zero bits, also reduces the liabilities in case
Microsoft's rumored patent on the digits 0 and 1 is upheld.)

@node Block Data and Libraries
@section Block Data and Libraries
@cindex block data and libraries
@cindex BLOCK DATA statement
@cindex statements, BLOCK DATA
@cindex libraries, containing BLOCK DATA
@cindex f2c compatibility
@cindex compatibility, f2c

To ensure that block data program units are linked, especially a concern
when they are put into libraries, give each one a name (as in
@samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
statement in every program unit that uses any common block
initialized by the corresponding @code{BLOCK DATA}.
@command{g77} currently compiles a @code{BLOCK DATA} as if it were a
@code{SUBROUTINE},
that is, it generates an actual procedure having the appropriate name.
The procedure does nothing but return immediately if it happens to be
called.
For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
same program unit, @command{g77} assumes there exists a @samp{BLOCK DATA FOO}
in the program and ensures that by generating a
reference to it so the linker will make sure it is present.
(Specifically, @command{g77} outputs in the data section a static pointer to the
external name @samp{FOO}.)

The implementation @command{g77} currently uses to make this work is
one of the few things not compatible with @command{f2c} as currently
shipped.
@command{f2c} currently does nothing with @samp{EXTERNAL FOO} except
issue a warning that @samp{FOO} is not otherwise referenced,
and, for @samp{BLOCK DATA FOO},
@command{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
The upshot is that you shouldn't mix @command{f2c} and @command{g77} in
this particular case.
If you use @command{f2c} to compile @samp{BLOCK DATA FOO},
then any @command{g77}-compiled program unit that says @samp{EXTERNAL FOO}
will result in an unresolved reference when linked.
If you do the
opposite, then @samp{FOO} might not be linked in under various
circumstances (such as when @samp{FOO} is in a library, or you're
using a ``clever'' linker---so clever, it produces a broken program
with little or no warning by omitting initializations of global data
because they are contained in unreferenced procedures).

The changes you make to your code to make @command{g77} handle this situation,
however, appear to be a widely portable way to handle it.
That is, many systems permit it (as they should, since the
FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
is a block data program unit), and of the ones
that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
program units.

Here is the recommended approach to modifying a program containing
a program unit such as the following:

@smallexample
BLOCK DATA FOO
COMMON /VARS/ X, Y, Z
DATA X, Y, Z / 3., 4., 5. /
END
@end smallexample

@noindent
If the above program unit might be placed in a library module, then
ensure that every program unit in every program that references that
particular @code{COMMON} area uses the @code{EXTERNAL} statement
to force the area to be initialized.

For example, change a program unit that starts with

@smallexample
INTEGER FUNCTION CURX()
COMMON /VARS/ X, Y, Z
CURX = X
END
@end smallexample

@noindent
so that it uses the @code{EXTERNAL} statement, as in:

@smallexample
INTEGER FUNCTION CURX()
COMMON /VARS/ X, Y, Z
EXTERNAL FOO
CURX = X
END
@end smallexample

@noindent
That way, @samp{CURX} is compiled by @command{g77} (and many other
compilers) so that the linker knows it must include @samp{FOO},
the @code{BLOCK DATA} program unit that sets the initial values
for the variables in @samp{VAR}, in the executable program.

@node Loops
@section Loops
@cindex DO statement
@cindex statements, DO
@cindex trips, number of
@cindex number of trips

The meaning of a @code{DO} loop in Fortran is precisely specified
in the Fortran standard@dots{}and is quite different from what
many programmers might expect.

In particular, Fortran iterative @code{DO} loops are implemented as if
the number of trips through the loop is calculated @emph{before}
the loop is entered.

The number of trips for a loop is calculated from the @var{start},
@var{end}, and @var{increment} values specified in a statement such as:

@smallexample
DO @var{iter} = @var{start}, @var{end}, @var{increment}
@end smallexample

@noindent
The trip count is evaluated using a fairly simple formula
based on the three values following the @samp{=} in the
statement, and it is that trip count that is effectively
decremented during each iteration of the loop.
If, at the beginning of an iteration of the loop, the
trip count is zero or negative, the loop terminates.
The per-loop-iteration modifications to @var{iter} are not
related to determining whether to terminate the loop.

There are two important things to remember about the trip
count:

@itemize @bullet
@item
It can be @emph{negative}, in which case it is
treated as if it was zero---meaning the loop is
not executed at all.

@item
The type used to @emph{calculate} the trip count
is the same type as @var{iter}, but the final
calculation, and thus the type of the trip
count itself, always is @code{INTEGER(KIND=1)}.
@end itemize

These two items mean that there are loops that cannot
be written in straightforward fashion using the Fortran @code{DO}.

For example, on a system with the canonical 32-bit two's-complement
implementation of @code{INTEGER(KIND=1)}, the following loop will not work:

@smallexample
DO I = -2000000000, 2000000000
@end smallexample

@noindent
Although the @var{start} and @var{end} values are well within
the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
The expected trip count is 40000000001, which is outside
the range of @code{INTEGER(KIND=1)} on many systems.

Instead, the above loop should be constructed this way:

@smallexample
I = -2000000000
DO
  IF (I .GT. 2000000000) EXIT
  @dots{}
  I = I + 1
END DO
@end smallexample

@noindent
The simple @code{DO} construct and the @code{EXIT} statement
(used to leave the innermost loop)
are F90 features that @command{g77} supports.

Some Fortran compilers have buggy implementations of @code{DO},
in that they don't follow the standard.
They implement @code{DO} as a straightforward translation
to what, in C, would be a @code{for} statement.
Instead of creating a temporary variable to hold the trip count
as calculated at run time, these compilers
use the iteration variable @var{iter} to control
whether the loop continues at each iteration.

The bug in such an implementation shows up when the
trip count is within the range of the type of @var{iter},
but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
exceeds that range.  For example:

@smallexample
DO I = 2147483600, 2147483647
@end smallexample

@noindent
A loop started by the above statement will work as implemented
by @command{g77}, but the use, by some compilers, of a
more C-like implementation akin to

@smallexample
for (i = 2147483600; i <= 2147483647; ++i)
@end smallexample

@noindent
produces a loop that does not terminate, because @samp{i}
can never be greater than 2147483647, since incrementing it
beyond that value overflows @samp{i}, setting it to -2147483648.
This is a large, negative number that still is less than 2147483647.

Another example of unexpected behavior of @code{DO} involves
using a nonintegral iteration variable @var{iter}, that is,
a @code{REAL} variable.
Consider the following program:

@smallexample
      DATA BEGIN, END, STEP /.1, .31, .007/
      DO 10 R = BEGIN, END, STEP
         IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
         PRINT *,R
10    CONTINUE
      PRINT *,'LAST = ',R
      IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
      END
@end smallexample

@noindent
A C-like view of @code{DO} would hold that the two ``exclamatory''
@code{PRINT} statements are never executed.
However, this is the output of running the above program
as compiled by @command{g77} on a GNU/Linux ix86 system:

@smallexample
 .100000001
 .107000001
 .114
 .120999999
 @dots{}
 .289000005
 .296000004
 .303000003
LAST =   .310000002
 .310000002 .LE.   .310000002!!
@end smallexample

Note that one of the two checks in the program turned up
an apparent violation of the programmer's expectation---yet,
the loop is correctly implemented by @command{g77}, in that
it has 30 iterations.
This trip count of 30 is correct when evaluated using
the floating-point representations for the @var{begin},
@var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
ix86 are used.
On other systems, an apparently more accurate trip count
of 31 might result, but, nevertheless, @command{g77} is
faithfully following the Fortran standard, and the result
is not what the author of the sample program above
apparently expected.
(Such other systems might, for different values in the @code{DATA}
statement, violate the other programmer's expectation,
for example.)

Due to this combination of imprecise representation
of floating-point values and the often-misunderstood
interpretation of @code{DO} by standard-conforming
compilers such as @command{g77}, use of @code{DO} loops
with @code{REAL} iteration
variables is not recommended.
Such use can be caught by specifying @option{-Wsurprising}.
@xref{Warning Options}, for more information on this
option.

@node Working Programs
@section Working Programs

Getting Fortran programs to work in the first place can be
quite a challenge---even when the programs already work on
other systems, or when using other compilers.

@command{g77} offers some facilities that might be useful for
tracking down bugs in such programs.

@menu
* Not My Type::
* Variables Assumed To Be Zero::
* Variables Assumed To Be Saved::
* Unwanted Variables::
* Unused Arguments::
* Surprising Interpretations of Code::
* Aliasing Assumed To Work::
* Output Assumed To Flush::
* Large File Unit Numbers::
* Floating-point precision::
* Inconsistent Calling Sequences::
@end menu

@node Not My Type
@subsection Not My Type
@cindex mistyped variables
@cindex variables, mistyped
@cindex mistyped functions
@cindex functions, mistyped
@cindex implicit typing

A fruitful source of bugs in Fortran source code is use, or
mis-use, of Fortran's implicit-typing feature, whereby the
type of a variable, array, or function is determined by the
first character of its name.

Simple cases of this include statements like @samp{LOGX=9.227},
without a statement such as @samp{REAL LOGX}.
In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
type, with the result of the assignment being that it is given
the value @samp{9}.

More involved cases include a function that is defined starting
with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
Any caller of this function that does not also declare @samp{IPS}
as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
is likely to assume it returns
@code{INTEGER}, or some other type, leading to invalid results
or even program crashes.

The @option{-Wimplicit} option might catch failures to
properly specify the types of
variables, arrays, and functions in the code.

However, in code that makes heavy use of Fortran's
implicit-typing facility, this option might produce so
many warnings about cases that are working, it would be
hard to find the one or two that represent bugs.
This is why so many experienced Fortran programmers strongly
recommend widespread use of the @code{IMPLICIT NONE} statement,
despite it not being standard FORTRAN 77, to completely turn
off implicit typing.
(@command{g77} supports @code{IMPLICIT NONE}, as do almost all
FORTRAN 77 compilers.)

Note that @option{-Wimplicit} catches only implicit typing of
@emph{names}.
It does not catch implicit typing of expressions such
as @samp{X**(2/3)}.
Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
is equivalent to @samp{X**0}, due to the way Fortran expressions
are given types and then evaluated.
(In this particular case, the programmer probably wanted
@samp{X**(2./3.)}.)

@node Variables Assumed To Be Zero
@subsection Variables Assumed To Be Zero
@cindex zero-initialized variables
@cindex variables, assumed to be zero
@cindex uninitialized variables

Many Fortran programs were developed on systems that provided
automatic initialization of all, or some, variables and arrays
to zero.
As a result, many of these programs depend, sometimes
inadvertently, on this behavior, though to do so violates
the Fortran standards.

You can ask @command{g77} for this behavior by specifying the
@option{-finit-local-zero} option when compiling Fortran code.
(You might want to specify @option{-fno-automatic} as well,
to avoid code-size inflation for non-optimized compilations.)

Note that a program that works better when compiled with the
@option{-finit-local-zero} option
is almost certainly depending on a particular system's,
or compiler's, tendency to initialize some variables to zero.
It might be worthwhile finding such cases and fixing them,
using techniques such as compiling with the @option{-O -Wuninitialized}
options using @command{g77}.

@node Variables Assumed To Be Saved
@subsection Variables Assumed To Be Saved
@cindex variables, retaining values across calls
@cindex saved variables
@cindex static variables

Many Fortran programs were developed on systems that
saved the values of all, or some, variables and arrays
across procedure calls.
As a result, many of these programs depend, sometimes
inadvertently, on being able to assign a value to a
variable, perform a @code{RETURN} to a calling procedure,
and, upon subsequent invocation, reference the previously
assigned variable to obtain the value.

They expect this despite not using the @code{SAVE} statement
to specify that the value in a variable is expected to survive
procedure returns and calls.
Depending on variables and arrays to retain values across
procedure calls without using @code{SAVE} to require it violates
the Fortran standards.

You can ask @command{g77} to assume @code{SAVE} is specified for all
relevant (local) variables and arrays by using the
@option{-fno-automatic} option.

Note that a program that works better when compiled with the
@option{-fno-automatic} option
is almost certainly depending on not having to use
the @code{SAVE} statement as required by the Fortran standard.
It might be worthwhile finding such cases and fixing them,
using techniques such as compiling with the @samp{-O -Wuninitialized}
options using @command{g77}.

@node Unwanted Variables
@subsection Unwanted Variables

The @option{-Wunused} option can find bugs involving
implicit typing, sometimes
more easily than using @option{-Wimplicit} in code that makes
heavy use of implicit typing.
An unused variable or array might indicate that the
spelling for its declaration is different from that of
its intended uses.

Other than cases involving typos, unused variables rarely
indicate actual bugs in a program.
However, investigating such cases thoroughly has, on occasion,
led to the discovery of code that had not been completely
written---where the programmer wrote declarations as needed
for the whole algorithm, wrote some or even most of the code
for that algorithm, then got distracted and forgot that the
job was not complete.

@node Unused Arguments
@subsection Unused Arguments
@cindex unused arguments
@cindex arguments, unused

As with unused variables, It is possible that unused arguments
to a procedure might indicate a bug.
Compile with @samp{-W -Wunused} option to catch cases of
unused arguments.

Note that @option{-W} also enables warnings regarding overflow
of floating-point constants under certain circumstances.

@node Surprising Interpretations of Code
@subsection Surprising Interpretations of Code

The @option{-Wsurprising} option can help find bugs involving
expression evaluation or in
the way @code{DO} loops with non-integral iteration variables
are handled.
Cases found by this option might indicate a difference of
interpretation between the author of the code involved, and
a standard-conforming compiler such as @command{g77}.
Such a difference might produce actual bugs.

In any case, changing the code to explicitly do what the
programmer might have expected it to do, so @command{g77} and
other compilers are more likely to follow the programmer's
expectations, might be worthwhile, especially if such changes
make the program work better.

@node Aliasing Assumed To Work
@subsection Aliasing Assumed To Work
@cindex -falias-check option
@cindex options, -falias-check
@cindex -fargument-alias option
@cindex options, -fargument-alias
@cindex -fargument-noalias option
@cindex options, -fargument-noalias
@cindex -fno-argument-noalias-global option
@cindex options, -fno-argument-noalias-global
@cindex aliasing
@cindex anti-aliasing
@cindex overlapping arguments
@cindex overlays
@cindex association, storage
@cindex storage association
@cindex scheduling of reads and writes
@cindex reads and writes, scheduling

The @option{-falias-check}, @option{-fargument-alias},
@option{-fargument-noalias},
and @option{-fno-argument-noalias-global} options,
introduced in version 0.5.20 and
@command{g77}'s version 2.7.2.2.f.2 of @command{gcc},
were withdrawn as of @command{g77} version 0.5.23
due to their not being supported by @command{gcc} version 2.8.

These options control the assumptions regarding aliasing
(overlapping) of writes and reads to main memory (core) made
by the @command{gcc} back end.

The information below still is useful, but applies to
only those versions of @command{g77} that support the
alias analysis implied by support for these options.

These options are effective only when compiling with @option{-O}
(specifying any level other than @option{-O0})
or with @option{-falias-check}.

The default for Fortran code is @option{-fargument-noalias-global}.
(The default for C code and code written in other C-based languages
is @option{-fargument-alias}.
These defaults apply regardless of whether you use @command{g77} or
@command{gcc} to compile your code.)

Note that, on some systems, compiling with @option{-fforce-addr} in
effect can produce more optimal code when the default aliasing
options are in effect (and when optimization is enabled).

If your program is not working when compiled with optimization,
it is possible it is violating the Fortran standards (77 and 90)
by relying on the ability to ``safely'' modify variables and
arrays that are aliased, via procedure calls, to other variables
and arrays, without using @code{EQUIVALENCE} to explicitly
set up this kind of aliasing.

(The FORTRAN 77 standard's prohibition of this sort of
overlap, generally referred to therein as ``storage
association'', appears in Sections 15.9.3.6.
This prohibition allows implementations, such as @command{g77},
to, for example, implement the passing of procedures and
even values in @code{COMMON} via copy operations into local,
perhaps more efficiently accessed temporaries at entry to a
procedure, and, where appropriate, via copy operations back
out to their original locations in memory at exit from that
procedure, without having to take into consideration the
order in which the local copies are updated by the code,
among other things.)

To test this hypothesis, try compiling your program with
the @option{-fargument-alias} option, which causes the
compiler to revert to assumptions essentially the same as
made by versions of @command{g77} prior to 0.5.20.

If the program works using this option, that strongly suggests
that the bug is in your program.
Finding and fixing the bug(s) should result in a program that
is more standard-conforming and that can be compiled by @command{g77}
in a way that results in a faster executable.

(You might want to try compiling with @option{-fargument-noalias},
a kind of half-way point, to see if the problem is limited to
aliasing between dummy arguments and @code{COMMON} variables---this
option assumes that such aliasing is not done, while still allowing
aliasing among dummy arguments.)

An example of aliasing that is invalid according to the standards
is shown in the following program, which might @emph{not} produce
the expected results when executed:

@smallexample
I = 1
CALL FOO(I, I)
PRINT *, I
END

SUBROUTINE FOO(J, K)
J = J + K
K = J * K
PRINT *, J, K
END
@end smallexample

The above program attempts to use the temporary aliasing of the
@samp{J} and @samp{K} arguments in @samp{FOO} to effect a
pathological behavior---the simultaneous changing of the values
of @emph{both} @samp{J} and @samp{K} when either one of them
is written.

The programmer likely expects the program to print these values:

@example
2  4
4
@end example

However, since the program is not standard-conforming, an
implementation's behavior when running it is undefined, because
subroutine @samp{FOO} modifies at least one of the arguments,
and they are aliased with each other.
(Even if one of the assignment statements was deleted, the
program would still violate these rules.
This kind of on-the-fly aliasing is permitted by the standard
only when none of the aliased items are defined, or written,
while the aliasing is in effect.)

As a practical example, an optimizing compiler might schedule
the @samp{J =} part of the second line of @samp{FOO} @emph{after}
the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
resulting in the following output:

@example
2  2
2
@end example

Essentially, compilers are promised (by the standard and, therefore,
by programmers who write code they claim to be standard-conforming)
that if they cannot detect aliasing via static analysis of a single
program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
such aliasing exists.
In such cases, compilers are free to assume that an assignment to
one variable will not change the value of another variable, allowing
it to avoid generating code to re-read the value of the other
variable, to re-schedule reads and writes, and so on, to produce
a faster executable.

The same promise holds true for arrays (as seen by the called
procedure)---an element of one dummy array cannot be aliased
with, or overlap, any element of another dummy array or be
in a @code{COMMON} area known to the procedure.

(These restrictions apply only when the procedure defines, or
writes to, one of the aliased variables or arrays.)

Unfortunately, there is no way to find @emph{all} possible cases of
violations of the prohibitions against aliasing in Fortran code.
Static analysis is certainly imperfect, as is run-time analysis,
since neither can catch all violations.
(Static analysis can catch all likely violations, and some that
might never actually happen, while run-time analysis can catch
only those violations that actually happen during a particular run.
Neither approach can cope with programs mixing Fortran code with
routines written in other languages, however.)

Currently, @command{g77} provides neither static nor run-time facilities
to detect any cases of this problem, although other products might.
Run-time facilities are more likely to be offered by future
versions of @command{g77}, though patches improving @command{g77} so that
it provides either form of detection are welcome.

@node Output Assumed To Flush
@subsection Output Assumed To Flush
@cindex ALWAYS_FLUSH
@cindex synchronous write errors
@cindex disk full
@cindex flushing output
@cindex fflush()
@cindex I/O, flushing
@cindex output, flushing
@cindex writes, flushing
@cindex NFS
@cindex network file system

For several versions prior to 0.5.20, @command{g77} configured its
version of the @code{libf2c} run-time library so that one of
its configuration macros, @code{ALWAYS_FLUSH}, was defined.

This was done as a result of a belief that many programs expected
output to be flushed to the operating system (under UNIX, via
the @code{fflush()} library call) with the result that errors,
such as disk full, would be immediately flagged via the
relevant @code{ERR=} and @code{IOSTAT=} mechanism.

Because of the adverse effects this approach had on the performance
of many programs, @command{g77} no longer configures @code{libf2c}
(now named @code{libg2c} in its @command{g77} incarnation)
to always flush output.

If your program depends on this behavior, either insert the
appropriate @samp{CALL FLUSH} statements, or modify the sources
to the @code{libg2c}, rebuild and reinstall @command{g77}, and
relink your programs with the modified library.

(Ideally, @code{libg2c} would offer the choice at run-time, so
that a compile-time option to @command{g77} or @command{f2c} could
result in generating the appropriate calls to flushing or
non-flushing library routines.)

Some Fortran programs require output
(writes) to be flushed to the operating system (under UNIX,
via the @code{fflush()} library call) so that errors,
such as disk full, are immediately flagged via the relevant
@code{ERR=} and @code{IOSTAT=} mechanism, instead of such
errors being flagged later as subsequent writes occur, forcing
the previously written data to disk, or when the file is
closed.

Essentially, the difference can be viewed as synchronous error
reporting (immediate flagging of errors during writes) versus
asynchronous, or, more precisely, buffered error reporting
(detection of errors might be delayed).

@code{libg2c} supports flagging write errors immediately when
it is built with the @code{ALWAYS_FLUSH} macro defined.
This results in a @code{libg2c} that runs slower, sometimes
quite a bit slower, under certain circumstances---for example,
accessing files via the networked file system NFS---but the
effect can be more reliable, robust file I/O.

If you know that Fortran programs requiring this level of precision
of error reporting are to be compiled using the
version of @command{g77} you are building, you might wish to
modify the @command{g77} source tree so that the version of
@code{libg2c} is built with the @code{ALWAYS_FLUSH} macro
defined, enabling this behavior.

To do this, find this line in @file{@value{path-libf2c}/f2c.h} in
your @command{g77} source tree:

@example
/* #define ALWAYS_FLUSH */
@end example

Remove the leading @samp{/*@w{ }},
so the line begins with @samp{#define},
and the trailing @samp{@w{ }*/}.

Then build or rebuild @command{g77} as appropriate.

@node Large File Unit Numbers
@subsection Large File Unit Numbers
@cindex MXUNIT
@cindex unit numbers
@cindex maximum unit number
@cindex illegal unit number
@cindex increasing maximum unit number

If your program crashes at run time with a message including
the text @samp{illegal unit number}, that probably is
a message from the run-time library, @code{libg2c}.

The message means that your program has attempted to use a
file unit number that is out of the range accepted by
@code{libg2c}.
Normally, this range is 0 through 99, and the high end
of the range is controlled by a @code{libg2c} source-file
macro named @code{MXUNIT}.

If you can easily change your program to use unit numbers
in the range 0 through 99, you should do so.

As distributed, whether as part of @command{f2c} or @command{g77},
@code{libf2c} accepts file unit numbers only in the range
0 through 99.
For example, a statement such as @samp{WRITE (UNIT=100)} causes
a run-time crash in @code{libf2c}, because the unit number,
100, is out of range.

If you know that Fortran programs at your installation require
the use of unit numbers higher than 99, you can change the
value of the @code{MXUNIT} macro, which represents the maximum unit
number, to an appropriately higher value.

To do this, edit the file @file{@value{path-libf2c}/libI77/fio.h} in your
@command{g77} source tree, changing the following line:

@example
#define MXUNIT 100
@end example

Change the line so that the value of @code{MXUNIT} is defined to be
at least one @emph{greater} than the maximum unit number used by
the Fortran programs on your system.

(For example, a program that does @samp{WRITE (UNIT=255)} would require
@code{MXUNIT} set to at least 256 to avoid crashing.)

Then build or rebuild @command{g77} as appropriate.

@emph{Note:} Changing this macro has @emph{no} effect on other limits
your system might place on the number of files open at the same time.
That is, the macro might allow a program to do @samp{WRITE (UNIT=100)},
but the library and operating system underlying @code{libf2c} might
disallow it if many other files have already been opened (via @code{OPEN} or
implicitly via @code{READ}, @code{WRITE}, and so on).
Information on how to increase these other limits should be found
in your system's documentation.

@node Floating-point precision
@subsection Floating-point precision

@cindex IEEE 754 conformance
@cindex conformance, IEEE 754
@cindex floating-point, precision
@cindex ix86 floating-point
@cindex x86 floating-point
If your program depends on exact IEEE 754 floating-point handling it may
help on some systems---specifically x86 or m68k hardware---to use
the @option{-ffloat-store} option or to reset the precision flag on the
floating-point unit.
@xref{Optimize Options}.

However, it might be better simply to put the FPU into double precision
mode and not take the performance hit of @option{-ffloat-store}.  On x86
and m68k GNU systems you can do this with a technique similar to that
for turning on floating-point exceptions
(@pxref{Floating-point Exception Handling}).
The control word could be set to double precision by some code like this
one:
@smallexample
#include <fpu_control.h>
@{
  fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE;
  _FPU_SETCW(cw);
@}
@end smallexample
(It is not clear whether this has any effect on the operation of the GNU
maths library, but we have no evidence of it causing trouble.)

Some targets (such as the Alpha) may need special options for full IEEE
conformance.
@xref{Submodel Options,,Hardware Models and Configurations,gcc,Using
the GNU Compiler Collection (GCC)}.

@node Inconsistent Calling Sequences
@subsection Inconsistent Calling Sequences

@pindex ftnchek
@cindex floating-point, errors
@cindex ix86 FPU stack
@cindex x86 FPU stack
Code containing inconsistent calling sequences in the same file is
normally rejected---see @ref{GLOBALS}.
(Use, say, @command{ftnchek} to ensure
consistency across source files.
@xref{f2c Skeletons and Prototypes,,
Generating Skeletons and Prototypes with @command{f2c}}.)

Mysterious errors, which may appear to be code generation problems, can
appear specifically on the x86 architecture with some such
inconsistencies.  On x86 hardware, floating-point return values of
functions are placed on the floating-point unit's register stack, not
the normal stack.  Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
@code{FUNCTION} as some other sort of procedure, or vice versa,
scrambles the floating-point stack.  This may break unrelated code
executed later.  Similarly if, say, external C routines are written
incorrectly.

@node Overly Convenient Options
@section Overly Convenient Command-line Options
@cindex overly convenient options
@cindex options, overly convenient

These options should be used only as a quick-and-dirty way to determine
how well your program will run under different compilation models
without having to change the source.
Some are more problematic
than others, depending on how portable and maintainable you want the
program to be (and, of course, whether you are allowed to change it
at all is crucial).

You should not continue to use these command-line options to compile
a given program, but rather should make changes to the source code:

@table @code
@cindex -finit-local-zero option
@cindex options, -finit-local-zero
@item -finit-local-zero
(This option specifies that any uninitialized local variables
and arrays have default initialization to binary zeros.)

Many other compilers do this automatically, which means lots of
Fortran code developed with those compilers depends on it.

It is safer (and probably
would produce a faster program) to find the variables and arrays that
need such initialization and provide it explicitly via @code{DATA}, so that
@option{-finit-local-zero} is not needed.

Consider using @option{-Wuninitialized} (which requires @option{-O}) to
find likely candidates, but
do not specify @option{-finit-local-zero} or @option{-fno-automatic},
or this technique won't work.

@cindex -fno-automatic option
@cindex options, -fno-automatic
@item -fno-automatic
(This option specifies that all local variables and arrays
are to be treated as if they were named in @code{SAVE} statements.)

Many other compilers do this automatically, which means lots of
Fortran code developed with those compilers depends on it.

The effect of this is that all non-automatic variables and arrays
are made static, that is, not placed on the stack or in heap storage.
This might cause a buggy program to appear to work better.
If so, rather than relying on this command-line option (and hoping all
compilers provide the equivalent one), add @code{SAVE}
statements to some or all program unit sources, as appropriate.
Consider using @option{-Wuninitialized} (which requires @option{-O})
to find likely candidates, but
do not specify @option{-finit-local-zero} or @option{-fno-automatic},
or this technique won't work.

The default is @option{-fautomatic}, which tells @command{g77} to try
and put variables and arrays on the stack (or in fast registers)
where possible and reasonable.
This tends to make programs faster.

@cindex automatic arrays
@cindex arrays, automatic
@emph{Note:} Automatic variables and arrays are not affected
by this option.
These are variables and arrays that are @emph{necessarily} automatic,
either due to explicit statements, or due to the way they are
declared.
Examples include local variables and arrays not given the
@code{SAVE} attribute in procedures declared @code{RECURSIVE},
and local arrays declared with non-constant bounds (automatic
arrays).
Currently, @command{g77} supports only automatic arrays, not
@code{RECURSIVE} procedures or other means of explicitly
specifying that variables or arrays are automatic.

@cindex -f@var{group}-intrinsics-hide option
@cindex options, -f@var{group}-intrinsics-hide
@item -f@var{group}-intrinsics-hide
Change the source code to use @code{EXTERNAL} for any external procedure
that might be the name of an intrinsic.
It is easy to find these using @option{-f@var{group}-intrinsics-disable}.
@end table

@node Faster Programs
@section Faster Programs
@cindex speed, of programs
@cindex programs, speeding up

Aside from the usual @command{gcc} options, such as @option{-O},
@option{-ffast-math}, and so on, consider trying some of the
following approaches to speed up your program (once you get
it working).

@menu
* Aligned Data::
* Prefer Automatic Uninitialized Variables::
* Avoid f2c Compatibility::
* Use Submodel Options::
@end menu

@node Aligned Data
@subsection Aligned Data
@cindex alignment
@cindex data, aligned
@cindex stack, aligned
@cindex aligned data
@cindex aligned stack
@cindex Pentium optimizations
@cindex optimization, for Pentium

On some systems, such as those with Pentium Pro CPUs, programs
that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
might run much slower
than possible due to the compiler not aligning these 64-bit
values to 64-bit boundaries in memory.
(The effect also is present, though
to a lesser extent, on the 586 (Pentium) architecture.)

The Intel x86 architecture generally ensures that these programs will
work on all its implementations,
but particular implementations (such as Pentium Pro)
perform better with more strict alignment.
(Such behavior isn't unique to the Intel x86 architecture.)
Other architectures might @emph{demand} 64-bit alignment
of 64-bit data.

There are a variety of approaches to use to address this problem:

@itemize @bullet
@item
@cindex @code{COMMON} layout
@cindex layout of @code{COMMON} blocks
Order your @code{COMMON} and @code{EQUIVALENCE} areas such
that the variables and arrays with the widest alignment
guidelines come first.

For example, on most systems, this would mean placing
@code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
@code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
@code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
@code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
and @code{INTEGER(KIND=3)} entities.

The reason to use such placement is it makes it more likely
that your data will be aligned properly, without requiring
you to do detailed analysis of each aggregate (@code{COMMON}
and @code{EQUIVALENCE}) area.

Specifically, on systems where the above guidelines are
appropriate, placing @code{CHARACTER} entities before
@code{REAL(KIND=2)} entities can work just as well,
but only if the number of bytes occupied by the @code{CHARACTER}
entities is divisible by the recommended alignment for
@code{REAL(KIND=2)}.

By ordering the placement of entities in aggregate
areas according to the simple guidelines above, you
avoid having to carefully count the number of bytes
occupied by each entity to determine whether the
actual alignment of each subsequent entity meets the
alignment guidelines for the type of that entity.

If you don't ensure correct alignment of @code{COMMON} elements, the
compiler may be forced by some systems to violate the Fortran semantics by
adding padding to get @code{DOUBLE PRECISION} data properly aligned.
If the unfortunate practice is employed of overlaying different types of
data in the @code{COMMON} block, the different variants
of this block may become misaligned with respect to each other.
Even if your platform doesn't require strict alignment,
@code{COMMON} should be laid out as above for portability.
(Unfortunately the FORTRAN 77 standard didn't anticipate this
possible requirement, which is compiler-independent on a given platform.)

@item
@cindex -malign-double option
@cindex options, -malign-double
Use the (x86-specific) @option{-malign-double} option when compiling
programs for the Pentium and Pentium Pro architectures (called 586
and 686 in the @command{gcc} configuration subsystem).
The warning about this in the @command{gcc} manual isn't
generally relevant to Fortran,
but using it will force @code{COMMON} to be padded if necessary to align
@code{DOUBLE PRECISION} data.

When @code{DOUBLE PRECISION} data is forcibly aligned
in @code{COMMON} by @command{g77} due to specifying @option{-malign-double},
@command{g77} issues a warning about the need to
insert padding.

In this case, each and every program unit that uses
the same @code{COMMON} area
must specify the same layout of variables and their types
for that area
and be compiled with @option{-malign-double} as well.
@command{g77} will issue warnings in each case,
but as long as every program unit using that area
is compiled with the same warnings,
the resulting object files should work when linked together
unless the program makes additional assumptions about
@code{COMMON} area layouts that are outside the scope
of the FORTRAN 77 standard,
or uses @code{EQUIVALENCE} or different layouts
in ways that assume no padding is ever inserted by the compiler.

@item
Ensure that @file{crt0.o} or @file{crt1.o}
on your system guarantees a 64-bit
aligned stack for @code{main()}.
The recent one from GNU (@code{glibc2}) will do this on x86 systems,
but we don't know of any other x86 setups where it will be right.
Read your system's documentation to determine if
it is appropriate to upgrade to a more recent version
to obtain the optimal alignment.
@end itemize

Progress is being made on making this work
``out of the box'' on future versions of @command{g77},
@command{gcc}, and some of the relevant operating systems
(such as GNU/Linux).

@node Prefer Automatic Uninitialized Variables
@subsection Prefer Automatic Uninitialized Variables

If you're using @option{-fno-automatic} already, you probably
should change your code to allow compilation with @option{-fautomatic}
(the default), to allow the program to run faster.

Similarly, you should be able to use @option{-fno-init-local-zero}
(the default) instead of @option{-finit-local-zero}.
This is because it is rare that every variable affected by these
options in a given program actually needs to
be so affected.

For example, @option{-fno-automatic}, which effectively @code{SAVE}s
every local non-automatic variable and array, affects even things like
@code{DO} iteration
variables, which rarely need to be @code{SAVE}d, and this often reduces
run-time performances.
Similarly, @option{-fno-init-local-zero} forces such
variables to be initialized to zero---when @code{SAVE}d (such as when
@option{-fno-automatic}), this by itself generally affects only
startup time for a program, but when not @code{SAVE}d,
it can slow down the procedure every time it is called.

@xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
for information on the @option{-fno-automatic} and
@option{-finit-local-zero} options and how to convert
their use into selective changes in your own code.

@node Avoid f2c Compatibility
@subsection Avoid f2c Compatibility
@cindex -fno-f2c option
@cindex options, -fno-f2c
@cindex @command{f2c} compatibility
@cindex compatibility, @command{f2c}

If you aren't linking with any code compiled using
@command{f2c}, try using the @option{-fno-f2c} option when
compiling @emph{all} the code in your program.
(Note that @code{libf2c} is @emph{not} an example of code
that is compiled using @command{f2c}---it is compiled by a C
compiler, typically @command{gcc}.)

@node Use Submodel Options
@subsection Use Submodel Options
@cindex submodels

Using an appropriate @option{-m} option to generate specific code for your
CPU may be worthwhile, though it may mean the executable won't run on
other versions of the CPU that don't support the same instruction set.
@xref{Submodel Options,,Hardware Models and Configurations,gcc,Using the
GNU Compiler Collection (GCC)}.  For instance on an x86 system the
compiler might have
been built---as shown by @samp{g77 -v}---for the target
@samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@.  In that case to
generate code best optimized for a Pentium you could use the option
@option{-march=pentium}.

For recent CPUs that don't have explicit support in the released version
of @command{gcc}, it @emph{might} still be possible to get improvements
with certain @option{-m} options.

@option{-fomit-frame-pointer} can help performance on x86 systems and
others.  It will, however, inhibit debugging on the systems on which it
is not turned on anyway by @option{-O}.

@node Trouble
@chapter Known Causes of Trouble with GNU Fortran
@cindex bugs, known
@cindex installation trouble
@cindex known causes of trouble

This section describes known problems that affect users of GNU Fortran.
Most of these are not GNU Fortran bugs per se---if they were, we would
fix them.
But the result for a user might be like the result of a bug.

Some of these problems are due to bugs in other software, some are
missing features that are too much work to add, and some are places
where people's opinions differ as to what is best.

(Note that some of this portion of the manual is lifted
directly from the @command{gcc} manual, with minor modifications
to tailor it to users of @command{g77}.
Anytime a bug seems to have more to do with the @command{gcc}
portion of @command{g77}, see
@ref{Trouble,,Known Causes of Trouble with GCC,
gcc,Using the GNU Compiler Collection (GCC)}.)

@menu
* But-bugs::         Bugs really in other programs or elsewhere.
* Known Bugs::       Bugs known to be in this version of @command{g77}.
* Missing Features:: Features we already know we want to add later.
* Disappointments::  Regrettable things we can't change.
* Non-bugs::         Things we think are right, but some others disagree.
* Warnings and Errors::  Which problems in your code get warnings,
                        and which get errors.
@end menu

@node But-bugs
@section Bugs Not In GNU Fortran
@cindex but-bugs

These are bugs to which the maintainers often have to reply,
``but that isn't a bug in @command{g77}@dots{}''.
Some of these already are fixed in new versions of other
software; some still need to be fixed; some are problems
with how @command{g77} is installed or is being used;
some are the result of bad hardware that causes software
to misbehave in sometimes bizarre ways;
some just cannot be addressed at this time until more
is known about the problem.

Please don't re-report these bugs to the @command{g77} maintainers---if
you must remind someone how important it is to you that the problem
be fixed, talk to the people responsible for the other products
identified below, but preferably only after you've tried the
latest versions of those products.
The @command{g77} maintainers have their hands full working on
just fixing and improving @command{g77}, without serving as a
clearinghouse for all bugs that happen to affect @command{g77}
users.

@xref{Collected Fortran Wisdom}, for information on behavior
of Fortran programs, and the programs that compile them, that
might be @emph{thought} to indicate bugs.

@menu
* Signal 11 and Friends::  Strange behavior by any software.
* Cannot Link Fortran Programs::  Unresolved references.
* Large Common Blocks::    Problems on older GNU/Linux systems.
* Debugger Problems::      When the debugger crashes.
* NeXTStep Problems::      Misbehaving executables.
* Stack Overflow::         More misbehaving executables.
* Nothing Happens::        Less behaving executables.
* Strange Behavior at Run Time::  Executables misbehaving due to
                            bugs in your program.
* Floating-point Errors::  The results look wrong, but@dots{}.
@end menu

@node Signal 11 and Friends
@subsection Signal 11 and Friends
@cindex signal 11
@cindex hardware errors

A whole variety of strange behaviors can occur when the
software, or the way you are using the software,
stresses the hardware in a way that triggers hardware bugs.
This might seem hard to believe, but it happens frequently
enough that there exist documents explaining in detail
what the various causes of the problems are, what
typical symptoms look like, and so on.

Generally these problems are referred to in this document
as ``signal 11'' crashes, because the Linux kernel, running
on the most popular hardware (the Intel x86 line), often
stresses the hardware more than other popular operating
systems.
When hardware problems do occur under GNU/Linux on x86
systems, these often manifest themselves as ``signal 11''
problems, as illustrated by the following diagnostic:

@smallexample
sh# @kbd{g77 myprog.f}
gcc: Internal compiler error: program f771 got fatal signal 11
sh#
@end smallexample

It is @emph{very} important to remember that the above
message is @emph{not} the only one that indicates a
hardware problem, nor does it always indicate a hardware
problem.

In particular, on systems other than those running the Linux
kernel, the message might appear somewhat or very different,
as it will if the error manifests itself while running a
program other than the @command{g77} compiler.
For example,
it will appear somewhat different when running your program,
when running Emacs, and so on.

How to cope with such problems is well beyond the scope
of this manual.

However, users of Linux-based systems (such as GNU/Linux)
should review @uref{http://www.bitwizard.nl/sig11/}, a source
of detailed information on diagnosing hardware problems,
by recognizing their common symptoms.

Users of other operating systems and hardware might
find this reference useful as well.
If you know of similar material for another hardware/software
combination, please let us know so we can consider including
a reference to it in future versions of this manual.

@node Cannot Link Fortran Programs
@subsection Cannot Link Fortran Programs
@cindex unresolved reference (various)
@cindex linking error for user code
@cindex code, user
@cindex @command{ld}, error linking user code
@cindex @command{ld}, can't find strange names
On some systems, perhaps just those with out-of-date (shared?)
libraries, unresolved-reference errors happen when linking @command{g77}-compiled
programs (which should be done using @command{g77}).

If this happens to you, try appending @option{-lc} to the command you
use to link the program, e.g. @samp{g77 foo.f -lc}.
@command{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
but it cannot also specify @option{-lc} because not all systems have a
file named @file{libc.a}.

It is unclear at this point whether there are legitimately installed
systems where @samp{-lg2c -lm} is insufficient to resolve code produced
by @command{g77}.

@cindex undefined reference (_main)
@cindex linking error, user code
@cindex @command{ld}, error linking user code
@cindex code, user
@cindex @command{ld}, can't find @samp{_main}
If your program doesn't link due to unresolved references to names
like @samp{_main}, make sure you're using the @command{g77} command to do the
link, since this command ensures that the necessary libraries are
loaded by specifying @samp{-lg2c -lm} when it invokes the @command{gcc}
command to do the actual link.
(Use the @option{-v} option to discover
more about what actually happens when you use the @command{g77} and @command{gcc}
commands.)

Also, try specifying @option{-lc} as the last item on the @command{g77}
command line, in case that helps.

@node Large Common Blocks
@subsection Large Common Blocks
@cindex common blocks, large
@cindex large common blocks
@cindex linking, errors
@cindex @command{ld}, errors
@cindex errors, linker
On some older GNU/Linux systems, programs with common blocks larger
than 16MB cannot be linked without some kind of error
message being produced.

This is a bug in older versions of @command{ld}, fixed in
more recent versions of @code{binutils}, such as version 2.6.

@node Debugger Problems
@subsection Debugger Problems
@cindex @command{gdb}, support
@cindex support, @command{gdb}
There are some known problems when using @command{gdb} on code
compiled by @command{g77}.
Inadequate investigation as of the release of 0.5.16 results in not
knowing which products are the culprit, but @file{gdb-4.14} definitely
crashes when, for example, an attempt is made to print the contents
of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
machines, plus some others.
Attempts to access assumed-size arrays are
also known to crash recent versions of @command{gdb}.
(@command{gdb}'s Fortran support was done for a different compiler
and isn't properly compatible with @command{g77}.)

@node NeXTStep Problems
@subsection NeXTStep Problems
@cindex NeXTStep problems
@cindex bus error
@cindex segmentation violation
Developers of Fortran code on NeXTStep (all architectures) have to
watch out for the following problem when writing programs with
large, statically allocated (i.e. non-stack based) data structures
(common blocks, saved arrays).

Due to the way the native loader (@file{/bin/ld}) lays out
data structures in virtual memory, it is very easy to create an
executable wherein the @samp{__DATA} segment overlaps (has addresses in
common) with the @samp{UNIX STACK} segment.

This leads to all sorts of trouble, from the executable simply not
executing, to bus errors.
The NeXTStep command line tool @command{ebadexec} points to
the problem as follows:

@smallexample
% @kbd{/bin/ebadexec a.out}
/bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
STACK segment (truncated address = 0x400000 rounded size =
0x3c00000) of executable file: a.out
@end smallexample

(In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
stack segment.)

This can be cured by assigning the @samp{__DATA} segment
(virtual) addresses beyond the stack segment.
A conservative
estimate for this is from address 6000000 (hexadecimal) onwards---this
has always worked for me [Toon Moene]:

@smallexample
% @kbd{g77 -segaddr __DATA 6000000 test.f}
% @kbd{ebadexec a.out}
ebadexec: file: a.out appears to be executable
%
@end smallexample

Browsing through @file{@value{path-g77}/Makefile.in},
you will find that the @code{f771} program itself also has to be
linked with these flags---it has large statically allocated
data structures.
(Version 0.5.18 reduces this somewhat, but probably
not enough.)

(The above item was contributed by Toon Moene
(@email{toon@@moene.indiv.nluug.nl}).)

@node Stack Overflow
@subsection Stack Overflow
@cindex stack, overflow
@cindex segmentation violation
@command{g77} code might fail at runtime (probably with a ``segmentation
violation'') due to overflowing the stack.
This happens most often on systems with an environment
that provides substantially more heap space (for use
when arbitrarily allocating and freeing memory) than stack
space.

Often this can be cured by
increasing or removing your shell's limit on stack usage, typically
using @kbd{limit stacksize} (in @command{csh} and derivatives) or
@kbd{ulimit -s} (in @command{sh} and derivatives).

Increasing the allowed stack size might, however, require
changing some operating system or system configuration parameters.

You might be able to work around the problem by compiling with the
@option{-fno-automatic} option to reduce stack usage, probably at the
expense of speed.

@command{g77}, on most machines, puts many variables and arrays on the stack
where possible, and can be configured (by changing
@code{FFECOM_sizeMAXSTACKITEM} in @file{@value{path-g77}/com.c}) to force
smaller-sized entities into static storage (saving
on stack space) or permit larger-sized entities to be put on the
stack (which can improve run-time performance, as it presents
more opportunities for the GBE to optimize the generated code).

@emph{Note:} Putting more variables and arrays on the stack
might cause problems due to system-dependent limits on stack size.
Also, the value of @code{FFECOM_sizeMAXSTACKITEM} has no
effect on automatic variables and arrays.
@xref{But-bugs}, for more information.
@emph{Note:} While @code{libg2c} places a limit on the range
of Fortran file-unit numbers, the underlying library and operating
system might impose different kinds of limits.
For example, some systems limit the number of files simultaneously
open by a running program.
Information on how to increase these limits should be found
in your system's documentation.

@cindex automatic arrays
@cindex arrays, automatic
However, if your program uses large automatic arrays
(for example, has declarations like @samp{REAL A(N)} where
@samp{A} is a local array and @samp{N} is a dummy or
@code{COMMON} variable that can have a large value),
neither use of @option{-fno-automatic},
nor changing the cut-off point for @command{g77} for using the stack,
will solve the problem by changing the placement of these
large arrays, as they are @emph{necessarily} automatic.

@command{g77} currently provides no means to specify that
automatic arrays are to be allocated on the heap instead
of the stack.
So, other than increasing the stack size, your best bet is to
change your source code to avoid large automatic arrays.
Methods for doing this currently are outside the scope of
this document.

(@emph{Note:} If your system puts stack and heap space in the
same memory area, such that they are effectively combined, then
a stack overflow probably indicates a program that is either
simply too large for the system, or buggy.)

@node Nothing Happens
@subsection Nothing Happens
@cindex nothing happens
@cindex naming programs
@cindex @command{test} programs
@cindex programs, @command{test}
It is occasionally reported that a ``simple'' program,
such as a ``Hello, World!'' program, does nothing when
it is run, even though the compiler reported no errors,
despite the program containing nothing other than a
simple @code{PRINT} statement.

This most often happens because the program has been
compiled and linked on a UNIX system and named @command{test},
though other names can lead to similarly unexpected
run-time behavior on various systems.

Essentially this problem boils down to giving
your program a name that is already known to
the shell you are using to identify some other program,
which the shell continues to execute instead of your
program when you invoke it via, for example:

@smallexample
sh# @kbd{test}
sh#
@end smallexample

Under UNIX and many other system, a simple command name
invokes a searching mechanism that might well not choose
the program located in the current working directory if
there is another alternative (such as the @command{test}
command commonly installed on UNIX systems).

The reliable way to invoke a program you just linked in
the current directory under UNIX is to specify it using
an explicit pathname, as in:

@smallexample
sh# @kbd{./test}
 Hello, World!
sh#
@end smallexample

Users who encounter this problem should take the time to
read up on how their shell searches for commands, how to
set their search path, and so on.
The relevant UNIX commands to learn about include
@command{man}, @command{info} (on GNU systems), @command{setenv} (or
@command{set} and @command{env}), @command{which}, and @command{find}.

@node Strange Behavior at Run Time
@subsection Strange Behavior at Run Time
@cindex segmentation violation
@cindex bus error
@cindex overwritten data
@cindex data, overwritten
@command{g77} code might fail at runtime with ``segmentation violation'',
``bus error'', or even something as subtle as a procedure call
overwriting a variable or array element that it is not supposed
to touch.

These can be symptoms of a wide variety of actual bugs that
occurred earlier during the program's run, but manifested
themselves as @emph{visible} problems some time later.

Overflowing the bounds of an array---usually by writing beyond
the end of it---is one of two kinds of bug that often occurs
in Fortran code.
(Compile your code with the @option{-fbounds-check} option
to catch many of these kinds of errors at program run time.)

The other kind of bug is a mismatch between the actual arguments
passed to a procedure and the dummy arguments as declared by that
procedure.

Both of these kinds of bugs, and some others as well, can be
difficult to track down, because the bug can change its behavior,
or even appear to not occur, when using a debugger.

That is, these bugs can be quite sensitive to data, including
data representing the placement of other data in memory (that is,
pointers, such as the placement of stack frames in memory).

@command{g77} now offers the
ability to catch and report some of these problems at compile, link, or
run time, such as by generating code to detect references to
beyond the bounds of most arrays (except assumed-size arrays),
and checking for agreement between calling and called procedures.
Future improvements are likely to be made in the procedure-mismatch area,
at least.

In the meantime, finding and fixing the programming
bugs that lead to these behaviors is, ultimately, the user's
responsibility, as difficult as that task can sometimes be.

@cindex infinite spaces printed
@cindex space, endless printing of
@cindex libc, non-ANSI or non-default
@cindex C library
@cindex linking against non-standard library
@cindex Solaris
One runtime problem that has been observed might have a simple solution.
If a formatted @code{WRITE} produces an endless stream of spaces, check
that your program is linked against the correct version of the C library.
The configuration process takes care to account for your
system's normal @file{libc} not being ANSI-standard, which will
otherwise cause this behavior.
If your system's default library is
ANSI-standard and you subsequently link against a non-ANSI one, there
might be problems such as this one.

Specifically, on Solaris2 systems,
avoid picking up the @code{BSD} library from @file{/usr/ucblib}.

@node Floating-point Errors
@subsection Floating-point Errors
@cindex floating-point errors
@cindex rounding errors
@cindex inconsistent floating-point results
@cindex results, inconsistent
Some programs appear to produce inconsistent floating-point
results compiled by @command{g77} versus by other compilers.

Often the reason for this behavior is the fact that floating-point
values are represented on almost all Fortran systems by
@emph{approximations}, and these approximations are inexact
even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
0.7, 0.8, 0.9, 1.1, and so on.
Most Fortran systems, including all current ports of @command{g77},
use binary arithmetic to represent these approximations.

Therefore, the exact value of any floating-point approximation
as manipulated by @command{g77}-compiled code is representable by
adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
so on (just keep dividing by two) through the precision of the
fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
@code{REAL(KIND=2)}), then multiplying the sum by a integral
power of two (in Fortran, by @samp{2**N}) that typically is between
-127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
@code{REAL(KIND=2)}, then multiplying by -1 if the number
is negative.

So, a value like 0.2 is exactly represented in decimal---since
it is a fraction, @samp{2/10}, with a denominator that is compatible
with the base of the number system (base 10).
However, @samp{2/10} cannot be represented by any finite number
of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
be exactly represented in binary notation.

(On the other hand, decimal notation can represent any binary
number in a finite number of digits.
Decimal notation cannot do so with ternary, or base-3,
notation, which would represent floating-point numbers as
sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
After all, no finite number of decimal digits can exactly
represent @samp{1/3}.
Fortunately, few systems use ternary notation.)

Moreover, differences in the way run-time I/O libraries convert
between these approximations and the decimal representation often
used by programmers and the programs they write can result in
apparent differences between results that do not actually exist,
or exist to such a small degree that they usually are not worth
worrying about.

For example, consider the following program:

@smallexample
PRINT *, 0.2
END
@end smallexample

When compiled by @command{g77}, the above program might output
@samp{0.20000003}, while another compiler might produce a
executable that outputs @samp{0.2}.

This particular difference is due to the fact that, currently,
conversion of floating-point values by the @code{libg2c} library,
used by @command{g77}, handles only double-precision values.

Since @samp{0.2} in the program is a single-precision value, it
is converted to double precision (still in binary notation)
before being converted back to decimal.
The conversion to binary appends @emph{binary} zero digits to the
original value---which, again, is an inexact approximation of
0.2---resulting in an approximation that is much less exact
than is connoted by the use of double precision.

(The appending of binary zero digits has essentially the same
effect as taking a particular decimal approximation of
@samp{1/3}, such as @samp{0.3333333}, and appending decimal
zeros to it, producing @samp{0.33333330000000000}.
Treating the resulting decimal approximation as if it really
had 18 or so digits of valid precision would make it seem
a very poor approximation of @samp{1/3}.)

As a result of converting the single-precision approximation
to double precision by appending binary zeros, the conversion
of the resulting double-precision
value to decimal produces what looks like an incorrect
result, when in fact the result is @emph{inexact}, and
is probably no less inaccurate or imprecise an approximation
of 0.2 than is produced by other compilers that happen to output
the converted value as ``exactly'' @samp{0.2}.
(Some compilers behave in a way that can make them appear
to retain more accuracy across a conversion of a single-precision
constant to double precision.
@xref{Context-Sensitive Constants}, to see why
this practice is illusory and even dangerous.)

Note that a more exact approximation of the constant is
computed when the program is changed to specify a
double-precision constant:

@smallexample
PRINT *, 0.2D0
END
@end smallexample

Future versions of @command{g77} and/or @code{libg2c} might convert
single-precision values directly to decimal,
instead of converting them to double precision first.
This would tend to result in output that is more consistent
with that produced by some other Fortran implementations.

A useful source of information on floating-point computation is David
Goldberg, `What Every Computer Scientist Should Know About
Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
5-48.
An online version is available at
@uref{http://docs.sun.com/}.

Information related to the IEEE 754 floating-point standard can be found
at @uref{http://grouper.ieee.org/groups/754/} and
@uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
see also slides from the short course referenced from
@uref{http://http.cs.berkeley.edu/%7Efateman/}.

The supplement to the PostScript-formatted Goldberg document,
referenced above, is available in HTML format.
See `Differences Among IEEE 754 Implementations' by Doug Priest.
This document explores some of the issues surrounding computing
of extended (80-bit) results on processors such as the x86,
especially when those results are arbitrarily truncated
to 32-bit or 64-bit values by the compiler
as ``spills''.

@cindex spills of floating-point results
@cindex 80-bit spills
@cindex truncation, of floating-point values
(@emph{Note:} @command{g77} specifically, and @command{gcc} generally,
does arbitrarily truncate 80-bit results during spills
as of this writing.
It is not yet clear whether a future version of
the GNU compiler suite will offer 80-bit spills
as an option, or perhaps even as the default behavior.)

@c xref would be different between editions:
The GNU C library provides routines for controlling the FPU, and other
documentation about this.

@xref{Floating-point precision}, regarding IEEE 754 conformance.

@include bugs.texi

@node Missing Features
@section Missing Features

This section lists features we know are missing from @command{g77},
and which we want to add someday.
(There is no priority implied in the ordering below.)

@menu
GNU Fortran language:
* Better Source Model::
* Fortran 90 Support::
* Intrinsics in PARAMETER Statements::
* Arbitrary Concatenation::
* SELECT CASE on CHARACTER Type::
* RECURSIVE Keyword::
* Popular Non-standard Types::
* Full Support for Compiler Types::
* Array Bounds Expressions::
* POINTER Statements::
* Sensible Non-standard Constructs::
* READONLY Keyword::
* FLUSH Statement::
* Expressions in FORMAT Statements::
* Explicit Assembler Code::
* Q Edit Descriptor::

GNU Fortran dialects:
* Old-style PARAMETER Statements::
* TYPE and ACCEPT I/O Statements::
* STRUCTURE UNION RECORD MAP::
* OPEN CLOSE and INQUIRE Keywords::
* ENCODE and DECODE::
* AUTOMATIC Statement::
* Suppressing Space Padding::
* Fortran Preprocessor::
* Bit Operations on Floating-point Data::
* Really Ugly Character Assignments::

New facilities:
* POSIX Standard::
* Floating-point Exception Handling::
* Nonportable Conversions::
* Large Automatic Arrays::
* Support for Threads::
* Increasing Precision/Range::
* Enabling Debug Lines::

Better diagnostics:
* Better Warnings::
* Gracefully Handle Sensible Bad Code::
* Non-standard Conversions::
* Non-standard Intrinsics::
* Modifying DO Variable::
* Better Pedantic Compilation::
* Warn About Implicit Conversions::
* Invalid Use of Hollerith Constant::
* Dummy Array Without Dimensioning Dummy::
* Invalid FORMAT Specifiers::
* Ambiguous Dialects::
* Unused Labels::
* Informational Messages::

Run-time facilities:
* Uninitialized Variables at Run Time::
* Portable Unformatted Files::
* Better List-directed I/O::
* Default to Console I/O::

Debugging:
* Labels Visible to Debugger::
@end menu

@node Better Source Model
@subsection Better Source Model

@command{g77} needs to provide, as the default source-line model,
a ``pure visual'' mode, where
the interpretation of a source program in this mode can be accurately
determined by a user looking at a traditionally displayed rendition
of the program (assuming the user knows whether the program is fixed
or free form).

The design should assume the user cannot tell tabs from spaces
and cannot see trailing spaces on lines, but has canonical tab stops
and, for fixed-form source, has the ability to always know exactly
where column 72 is (since the Fortran standard itself requires
this for fixed-form source).

This would change the default treatment of fixed-form source
to not treat lines with tabs as if they were infinitely long---instead,
they would end at column 72 just as if the tabs were replaced
by spaces in the canonical way.

As part of this, provide common alternate models (Digital, @command{f2c},
and so on) via command-line options.
This includes allowing arbitrarily long
lines for free-form source as well as fixed-form source and providing
various limits and diagnostics as appropriate.

@cindex sequence numbers
@cindex columns 73 through 80
Also, @command{g77} should offer, perhaps even default to, warnings
when characters beyond the last valid column are anything other
than spaces.
This would mean code with ``sequence numbers'' in columns 73 through 80
would be rejected, and there's a lot of that kind of code around,
but one of the most frequent bugs encountered by new users is
accidentally writing fixed-form source code into and beyond
column 73.
So, maybe the users of old code would be able to more easily handle
having to specify, say, a @option{-Wno-col73to80} option.

@node Fortran 90 Support
@subsection Fortran 90 Support
@cindex Fortran 90, support
@cindex support, Fortran 90

@command{g77} does not support many of the features that
distinguish Fortran 90 (and, now, Fortran 95) from
ANSI FORTRAN 77.

Some Fortran 90 features are supported, because they
make sense to offer even to die-hard users of F77.
For example, many of them codify various ways F77 has
been extended to meet users' needs during its tenure,
so @command{g77} might as well offer them as the primary
way to meet those same needs, even if it offers compatibility
with one or more of the ways those needs were met
by other F77 compilers in the industry.

Still, many important F90 features are not supported,
because no attempt has been made to research each and
every feature and assess its viability in @command{g77}.
In the meantime, users who need those features must
use Fortran 90 compilers anyway, and the best approach
to adding some F90 features to GNU Fortran might well be
to fund a comprehensive project to create GNU Fortran 95.

@node Intrinsics in PARAMETER Statements
@subsection Intrinsics in @code{PARAMETER} Statements
@cindex PARAMETER statement
@cindex statements, PARAMETER

@command{g77} doesn't allow intrinsics in @code{PARAMETER} statements.

Related to this, @command{g77} doesn't allow non-integral
exponentiation in @code{PARAMETER} statements, such as
@samp{PARAMETER (R=2**.25)}.
It is unlikely @command{g77} will ever support this feature,
as doing it properly requires complete emulation of
a target computer's floating-point facilities when
building @command{g77} as a cross-compiler.
But, if the @command{gcc} back end is enhanced to provide
such a facility, @command{g77} will likely use that facility
in implementing this feature soon afterwards.

@node Arbitrary Concatenation
@subsection Arbitrary Concatenation
@cindex concatenation
@cindex CHARACTER*(*)
@cindex run-time, dynamic allocation

@command{g77} doesn't support arbitrary operands for concatenation
in contexts where run-time allocation is required.
For example:

@smallexample
SUBROUTINE X(A)
CHARACTER*(*) A
CALL FOO(A // 'suffix')
@end smallexample

@node SELECT CASE on CHARACTER Type
@subsection @code{SELECT CASE} on @code{CHARACTER} Type

Character-type selector/cases for @code{SELECT CASE} currently
are not supported.

@node RECURSIVE Keyword
@subsection @code{RECURSIVE} Keyword
@cindex RECURSIVE keyword
@cindex keywords, RECURSIVE
@cindex recursion, lack of
@cindex lack of recursion

@command{g77} doesn't support the @code{RECURSIVE} keyword that
F90 compilers do.
Nor does it provide any means for compiling procedures
designed to do recursion.

All recursive code can be rewritten to not use recursion,
but the result is not pretty.

@node Increasing Precision/Range
@subsection Increasing Precision/Range
@cindex -r8
@cindex -qrealsize=8
@cindex -i8
@cindex f2c
@cindex increasing precision
@cindex precision, increasing
@cindex increasing range
@cindex range, increasing
@cindex Toolpack
@cindex Netlib

Some compilers, such as @command{f2c}, have an option (@option{-r8},
@option{-qrealsize=8} or
similar) that provides automatic treatment of @code{REAL}
entities such that they have twice the storage size, and
a corresponding increase in the range and precision, of what
would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
(This affects @code{COMPLEX} the same way.)

They also typically offer another option (@option{-i8}) to increase
@code{INTEGER} entities so they are twice as large
(with roughly twice as much range).

(There are potential pitfalls in using these options.)

@command{g77} does not yet offer any option that performs these
kinds of transformations.
Part of the problem is the lack of detailed specifications regarding
exactly how these options affect the interpretation of constants,
intrinsics, and so on.

Until @command{g77} addresses this need, programmers could improve
the portability of their code by modifying it to not require
compile-time options to produce correct results.
Some free tools are available which may help, specifically
in Toolpack (which one would expect to be sound) and the @file{fortran}
section of the Netlib repository.

Use of preprocessors can provide a fairly portable means
to work around the lack of widely portable methods in the Fortran
language itself (though increasing acceptance of Fortran 90 would
alleviate this problem).

@node Popular Non-standard Types
@subsection Popular Non-standard Types
@cindex @code{INTEGER*2} support
@cindex types, @code{INTEGER*2}
@cindex @code{LOGICAL*1} support
@cindex types, @code{LOGICAL*1}

@command{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
and similar.
In the meantime, version 0.5.18 provides rudimentary support
for them.

@node Full Support for Compiler Types
@subsection Full Support for Compiler Types

@cindex @code{REAL*16} support
@cindex types, @code{REAL*16}
@cindex @code{INTEGER*8} support
@cindex types, @code{INTEGER*8}
@command{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
@code{int}, @code{long int}, @code{long long int}, and @code{long double}).
This means providing intrinsic support, and maybe constant
support (using F90 syntax) as well, and, for most
machines will result in automatic support of @code{INTEGER*1},
@code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
and so on.

@node Array Bounds Expressions
@subsection Array Bounds Expressions
@cindex array elements, in adjustable array bounds
@cindex function references, in adjustable array bounds
@cindex array bounds, adjustable
@cindex @code{DIMENSION} statement
@cindex statements, @code{DIMENSION}

@command{g77} doesn't support more general expressions to dimension
arrays, such as array element references, function
references, etc.

For example, @command{g77} currently does not accept the following:

@smallexample
SUBROUTINE X(M, N)
INTEGER N(10), M(N(2), N(1))
@end smallexample

@node POINTER Statements
@subsection POINTER Statements
@cindex POINTER statement
@cindex statements, POINTER
@cindex Cray pointers

@command{g77} doesn't support pointers or allocatable objects
(other than automatic arrays).
This set of features is
probably considered just behind intrinsics
in @code{PARAMETER} statements on the list of large,
important things to add to @command{g77}.

In the meantime, consider using the @code{INTEGER(KIND=7)}
declaration to specify that a variable must be
able to hold a pointer.
This construct is not portable to other non-GNU compilers,
but it is portable to all machines GNU Fortran supports
when @command{g77} is used.

@xref{Functions and Subroutines}, for information on
@code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
constructs, which are useful for passing pointers to
procedures written in languages other than Fortran.

@node Sensible Non-standard Constructs
@subsection Sensible Non-standard Constructs

@command{g77} rejects things other compilers accept,
like @samp{INTRINSIC SQRT,SQRT}.
As time permits in the future, some of these things that are easy for
humans to read and write and unlikely to be intended to mean something
else will be accepted by @command{g77} (though @option{-fpedantic} should
trigger warnings about such non-standard constructs).

Until @command{g77} no longer gratuitously rejects sensible code,
you might as well fix your code
to be more standard-conforming and portable.

The kind of case that is important to except from the
recommendation to change your code is one where following
good coding rules would force you to write non-standard
code that nevertheless has a clear meaning.

For example, when writing an @code{INCLUDE} file that
defines a common block, it might be appropriate to
include a @code{SAVE} statement for the common block
(such as @samp{SAVE /CBLOCK/}), so that variables
defined in the common block retain their values even
when all procedures declaring the common block become
inactive (return to their callers).

However, putting @code{SAVE} statements in an @code{INCLUDE}
file would prevent otherwise standard-conforming code
from also specifying the @code{SAVE} statement, by itself,
to indicate that all local variables and arrays are to
have the @code{SAVE} attribute.

For this reason, @command{g77} already has been changed to
allow this combination, because although the general
problem of gratuitously rejecting unambiguous and
``safe'' constructs still exists in @command{g77}, this
particular construct was deemed useful enough that
it was worth fixing @command{g77} for just this case.

So, while there is no need to change your code
to avoid using this particular construct, there
might be other, equally appropriate but non-standard
constructs, that you shouldn't have to stop using
just because @command{g77} (or any other compiler)
gratuitously rejects it.

Until the general problem is solved, if you have
any such construct you believe is worthwhile
using (e.g. not just an arbitrary, redundant
specification of an attribute), please submit a
bug report with an explanation, so we can consider
fixing @command{g77} just for cases like yours.

@node READONLY Keyword
@subsection @code{READONLY} Keyword
@cindex READONLY

Support for @code{READONLY}, in @code{OPEN} statements,
requires @code{libg2c} support,
to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')}
does not delete a file opened on a unit
with the @code{READONLY} keyword,
and perhaps to trigger a fatal diagnostic
if a @code{WRITE} or @code{PRINT}
to such a unit is attempted.

@emph{Note:} It is not sufficient for @command{g77} and @code{libg2c}
(its version of @code{libf2c})
to assume that @code{READONLY} does not need some kind of explicit support
at run time,
due to UNIX systems not (generally) needing it.
@command{g77} is not just a UNIX-based compiler!

Further, mounting of non-UNIX filesystems on UNIX systems
(such as via NFS)
might require proper @code{READONLY} support.

@cindex SHARED
(Similar issues might be involved with supporting the @code{SHARED}
keyword.)

@node FLUSH Statement
@subsection @code{FLUSH} Statement

@command{g77} could perhaps use a @code{FLUSH} statement that
does what @samp{CALL FLUSH} does,
but that supports @samp{*} as the unit designator (same unit as for
@code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
specifiers.

@node Expressions in FORMAT Statements
@subsection Expressions in @code{FORMAT} Statements
@cindex FORMAT statement
@cindex statements, FORMAT

@command{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
Supporting this requires a significant redesign or replacement
of @code{libg2c}.

However, @command{g77} does support
this construct when the expression is constant
(as of version 0.5.22).
For example:

@smallexample
      PARAMETER (IWIDTH = 12)
10    FORMAT (I<IWIDTH>)
@end smallexample

Otherwise, at least for output (@code{PRINT} and
@code{WRITE}), Fortran code making use of this feature can
be rewritten to avoid it by constructing the @code{FORMAT}
string in a @code{CHARACTER} variable or array, then
using that variable or array in place of the @code{FORMAT}
statement label to do the original @code{PRINT} or @code{WRITE}.

Many uses of this feature on input can be rewritten this way
as well, but not all can.
For example, this can be rewritten:

@smallexample
      READ 20, I
20    FORMAT (I<J>)
@end smallexample

However, this cannot, in general, be rewritten, especially
when @code{ERR=} and @code{END=} constructs are employed:

@smallexample
      READ 30, J, I
30    FORMAT (I<J>)
@end smallexample

@node Explicit Assembler Code
@subsection Explicit Assembler Code

@command{g77} needs to provide some way, a la @command{gcc}, for @command{g77}
code to specify explicit assembler code.

@node Q Edit Descriptor
@subsection Q Edit Descriptor
@cindex FORMAT statement
@cindex Q edit descriptor
@cindex edit descriptor, Q

The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
(This is meant to get the number of characters remaining in an input record.)
Supporting this requires a significant redesign or replacement
of @code{libg2c}.

A workaround might be using internal I/O or the stream-based intrinsics.
@xref{FGetC Intrinsic (subroutine)}.

@node Old-style PARAMETER Statements
@subsection Old-style PARAMETER Statements
@cindex PARAMETER statement
@cindex statements, PARAMETER

@command{g77} doesn't accept @samp{PARAMETER I=1}.
Supporting this obsolete form of
the @code{PARAMETER} statement would not be particularly hard, as most of the
parsing code is already in place and working.

Until time/money is
spent implementing it, you might as well fix your code to use the
standard form, @samp{PARAMETER (I=1)} (possibly needing
@samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
otherwise, in the obsolete form of @code{PARAMETER}, the
type of the variable is set from the type of the constant being
assigned to it).

@node TYPE and ACCEPT I/O Statements
@subsection @code{TYPE} and @code{ACCEPT} I/O Statements
@cindex TYPE statement
@cindex statements, TYPE
@cindex ACCEPT statement
@cindex statements, ACCEPT

@command{g77} doesn't support the I/O statements @code{TYPE} and
@code{ACCEPT}.
These are common extensions that should be easy to support,
but also are fairly easy to work around in user code.

Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
by @samp{PRINT fmt,list}.
And, any @samp{ACCEPT fmt,list} statement can be
replaced by @samp{READ fmt,list}.

@node STRUCTURE UNION RECORD MAP
@subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
@cindex STRUCTURE statement
@cindex statements, STRUCTURE
@cindex UNION statement
@cindex statements, UNION
@cindex RECORD statement
@cindex statements, RECORD
@cindex MAP statement
@cindex statements, MAP

@command{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
@code{MAP}.
This set of extensions is quite a bit
lower on the list of large, important things to add to @command{g77}, partly
because it requires a great deal of work either upgrading or
replacing @code{libg2c}.

@node OPEN CLOSE and INQUIRE Keywords
@subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
@cindex disposition of files
@cindex OPEN statement
@cindex statements, OPEN
@cindex CLOSE statement
@cindex statements, CLOSE
@cindex INQUIRE statement
@cindex statements, INQUIRE

@command{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
These extensions are easy to add to @command{g77} itself, but
require much more work on @code{libg2c}.

@cindex FORM='PRINT'
@cindex ANS carriage control
@cindex carriage control
@pindex asa
@pindex fpr
@command{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
translate the traditional `carriage control' characters in column 1 of
output to use backspaces, carriage returns and the like.  However
programs exist to translate them in output files (or standard output).
These are typically called either @command{fpr} or @command{asa}.  You can get
a version of @command{asa} from
@uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
systems which will probably build easily on other systems.
Alternatively, @command{fpr} is in BSD distributions in various archive
sites.

@c (Can both programs can be used in a pipeline,
@c with a named input file,
@c and/or with a named output file???)

@node ENCODE and DECODE
@subsection @code{ENCODE} and @code{DECODE}
@cindex ENCODE statement
@cindex statements, ENCODE
@cindex DECODE statement
@cindex statements, DECODE

@command{g77} doesn't support @code{ENCODE} or @code{DECODE}.

These statements are best replaced by READ and WRITE statements
involving internal files (CHARACTER variables and arrays).

For example, replace a code fragment like

@smallexample
      INTEGER*1 LINE(80)
@dots{}
      DECODE (80, 9000, LINE) A, B, C
@dots{}
9000  FORMAT (1X, 3(F10.5))
@end smallexample

@noindent
with:

@smallexample
      CHARACTER*80 LINE
@dots{}
      READ (UNIT=LINE, FMT=9000) A, B, C
@dots{}
9000  FORMAT (1X, 3(F10.5))
@end smallexample

Similarly, replace a code fragment like

@smallexample
      INTEGER*1 LINE(80)
@dots{}
      ENCODE (80, 9000, LINE) A, B, C
@dots{}
9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
@end smallexample

@noindent
with:

@smallexample
      CHARACTER*80 LINE
@dots{}
      WRITE (UNIT=LINE, FMT=9000) A, B, C
@dots{}
9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
@end smallexample

It is entirely possible that @code{ENCODE} and @code{DECODE} will
be supported by a future version of @command{g77}.

@node AUTOMATIC Statement
@subsection @code{AUTOMATIC} Statement
@cindex @code{AUTOMATIC} statement
@cindex statements, @code{AUTOMATIC}
@cindex automatic variables
@cindex variables, automatic

@command{g77} doesn't support the @code{AUTOMATIC} statement that
@command{f2c} does.

@code{AUTOMATIC} would identify a variable or array
as not being @code{SAVE}'d, which is normally the default,
but which would be especially useful for code that, @emph{generally},
needed to be compiled with the @option{-fno-automatic} option.

@code{AUTOMATIC} also would serve as a hint to the compiler that placing
the variable or array---even a very large array--on the stack is acceptable.

@code{AUTOMATIC} would not, by itself, designate the containing procedure
as recursive.

@code{AUTOMATIC} should work syntactically like @code{SAVE},
in that @code{AUTOMATIC} with no variables listed should apply to
all pertinent variables and arrays
(which would not include common blocks or their members).

Variables and arrays denoted as @code{AUTOMATIC}
would not be permitted to be initialized via @code{DATA}
or other specification of any initial values,
requiring explicit initialization,
such as via assignment statements.

@cindex UNSAVE
@cindex STATIC
Perhaps @code{UNSAVE} and @code{STATIC},
as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
should be provided as well.

@node Suppressing Space Padding
@subsection Suppressing Space Padding of Source Lines

@command{g77} should offer VXT-Fortran-style suppression of virtual
spaces at the end of a source line
if an appropriate command-line option is specified.

This affects cases where
a character constant is continued onto the next line in a fixed-form
source file, as in the following example:

@smallexample
10    PRINT *,'HOW MANY
     1 SPACES?'
@end smallexample

@noindent
@command{g77}, and many other compilers, virtually extend
the continued line through column 72 with spaces that become part
of the character constant, but Digital Fortran normally didn't,
leaving only one space between @samp{MANY} and @samp{SPACES?}
in the output of the above statement.

Fairly recently, at least one version of Digital Fortran
was enhanced to provide the other behavior when a
command-line option is specified, apparently due to demand
from readers of the USENET group @file{comp.lang.fortran}
to offer conformance to this widespread practice in the
industry.
@command{g77} should return the favor by offering conformance
to Digital's approach to handling the above example.

@node Fortran Preprocessor
@subsection Fortran Preprocessor

@command{g77} should offer a preprocessor designed specifically
for Fortran to replace @samp{cpp -traditional}.
There are several out there worth evaluating, at least.

Such a preprocessor would recognize Hollerith constants,
properly parse comments and character constants, and so on.
It might also recognize, process, and thus preprocess
files included via the @code{INCLUDE} directive.

@node Bit Operations on Floating-point Data
@subsection Bit Operations on Floating-point Data
@cindex @code{And} intrinsic
@cindex intrinsics, @code{And}
@cindex @code{Or} intrinsic
@cindex intrinsics, @code{Or}
@cindex @code{Shift} intrinsic
@cindex intrinsics, @code{Shift}

@command{g77} does not allow @code{REAL} and other non-integral types for
arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.

For example, this program is rejected by @command{g77}, because
the intrinsic @code{Iand} does not accept @code{REAL} arguments:

@smallexample
DATA A/7.54/, B/9.112/
PRINT *, IAND(A, B)
END
@end smallexample

@node Really Ugly Character Assignments
@subsection Really Ugly Character Assignments

An option such as @option{-fugly-char} should be provided
to allow

@smallexample
REAL*8 A1
DATA A1 / '12345678' /
@end smallexample

and:

@smallexample
REAL*8 A1
A1 = 'ABCDEFGH'
@end smallexample

@node POSIX Standard
@subsection @code{POSIX} Standard

@command{g77} should support the POSIX standard for Fortran.

@node Floating-point Exception Handling
@subsection Floating-point Exception Handling
@cindex floating-point, exceptions
@cindex exceptions, floating-point
@cindex FPE handling
@cindex NaN values

The @command{gcc} backend and, consequently, @command{g77}, currently provides no
general control over whether or not floating-point exceptions are trapped or
ignored.
(Ignoring them typically results in NaN values being
propagated in systems that conform to IEEE 754.)
The behavior is normally inherited from the system-dependent startup
code, though some targets, such as the Alpha, have code generation
options which change the behavior.

Most systems provide some C-callable mechanism to change this; this can
be invoked at startup using @command{gcc}'s @code{constructor} attribute.
For example, just compiling and linking the following C code with your
program will turn on exception trapping for the ``common'' exceptions
on a GNU system using glibc 2.2 or newer:

@smallexample
#define _GNU_SOURCE 1
#include <fenv.h>
static void __attribute__ ((constructor))
trapfpe ()
@{
  /* Enable some exceptions.  At startup all exceptions are masked.  */
  
  feenableexcept (FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
@}
@end smallexample

Assuming the above source is in file @file{trapfpe.c},
then compile this routine as follows:
@smallexample
gcc -c trapfpe.c
@end smallexample
and subsequently use it by adding @file{trapfpe.o} to the @command{g77}
command line when linking.

@node Nonportable Conversions
@subsection Nonportable Conversions
@cindex nonportable conversions
@cindex conversions, nonportable

@command{g77} doesn't accept some particularly nonportable,
silent data-type conversions such as @code{LOGICAL}
to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
is type @code{REAL}), that other compilers might
quietly accept.

Some of these conversions are accepted by @command{g77}
when the @option{-fugly-logint} option is specified.
Perhaps it should accept more or all of them.

@node Large Automatic Arrays
@subsection Large Automatic Arrays
@cindex automatic arrays
@cindex arrays, automatic

Currently, automatic arrays always are allocated on the stack.
For situations where the stack cannot be made large enough,
@command{g77} should offer a compiler option that specifies
allocation of automatic arrays in heap storage.

@node Support for Threads
@subsection Support for Threads
@cindex threads
@cindex parallel processing

Neither the code produced by @command{g77} nor the @code{libg2c} library
are thread-safe, nor does @command{g77} have support for parallel processing
(other than the instruction-level parallelism available on some
processors).
A package such as PVM might help here.

@node Enabling Debug Lines
@subsection Enabling Debug Lines
@cindex debug line
@cindex comment line, debug

An option such as @option{-fdebug-lines} should be provided
to turn fixed-form lines beginning with @samp{D}
to be treated as if they began with a space,
instead of as if they began with a @samp{C}
(as comment lines).

@node Better Warnings
@subsection Better Warnings

Because of how @command{g77} generates code via the back end,
it doesn't always provide warnings the user wants.
Consider:

@smallexample
PROGRAM X
PRINT *, A
END
@end smallexample

Currently, the above is not flagged as a case of
using an uninitialized variable,
because @command{g77} generates a run-time library call that looks,
to the GBE, like it might actually @emph{modify} @samp{A} at run time.
(And, in fact, depending on the previous run-time library call,
it would!)

Fixing this requires one of the following:

@itemize @bullet
@item
Switch to new library, @code{libg77}, that provides
a more ``clean'' interface,
vis-a-vis input, output, and modified arguments,
so the GBE can tell what's going on.

This would provide a pretty big performance improvement,
at least theoretically, and, ultimately, in practice,
for some types of code.

@item
Have @command{g77} pass a pointer to a temporary
containing a copy of @samp{A},
instead of to @samp{A} itself.
The GBE would then complain about the copy operation
involving a potentially uninitialized variable.

This might also provide a performance boost for some code,
because @samp{A} might then end up living in a register,
which could help with inner loops.

@item
Have @command{g77} use a GBE construct similar to @code{ADDR_EXPR}
but with extra information on the fact that the
item pointed to won't be modified
(a la @code{const} in C).

Probably the best solution for now, but not quite trivial
to implement in the general case.
@end itemize

@node Gracefully Handle Sensible Bad Code
@subsection Gracefully Handle Sensible Bad Code

@command{g77} generally should continue processing for
warnings and recoverable (user) errors whenever possible---that
is, it shouldn't gratuitously make bad or useless code.

For example:

@smallexample
INTRINSIC ZABS
CALL FOO(ZABS)
END
@end smallexample

@noindent
When compiling the above with @option{-ff2c-intrinsics-disable},
@command{g77} should indeed complain about passing @code{ZABS},
but it still should compile, instead of rejecting
the entire @code{CALL} statement.
(Some of this is related to improving
the compiler internals to improve how statements are analyzed.)

@node Non-standard Conversions
@subsection Non-standard Conversions

@option{-Wconversion} and related should flag places where non-standard
conversions are found.
Perhaps much of this would be part of @option{-Wugly*}.

@node Non-standard Intrinsics
@subsection Non-standard Intrinsics

@command{g77} needs a new option, like @option{-Wintrinsics}, to warn about use of
non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
This would help find code that might fail silently when ported to another
compiler.

@node Modifying DO Variable
@subsection Modifying @code{DO} Variable

@command{g77} should warn about modifying @code{DO} variables
via @code{EQUIVALENCE}.
(The internal information gathered to produce this warning
might also be useful in setting the
internal ``doiter'' flag for a variable or even array
reference within a loop, since that might produce faster code someday.)

For example, this code is invalid, so @command{g77} should warn about
the invalid assignment to @samp{NOTHER}:

@smallexample
EQUIVALENCE (I, NOTHER)
DO I = 1, 100
   IF (I.EQ. 10) NOTHER = 20
END DO
@end smallexample

@node Better Pedantic Compilation
@subsection Better Pedantic Compilation

@command{g77} needs to support @option{-fpedantic} more thoroughly,
and use it only to generate
warnings instead of rejecting constructs outright.
Have it warn:
if a variable that dimensions an array is not a dummy or placed
explicitly in @code{COMMON} (F77 does not allow it to be
placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
follow statement-function-definition statements; about all sorts of
syntactic extensions.

@node Warn About Implicit Conversions
@subsection Warn About Implicit Conversions

@command{g77} needs a @option{-Wpromotions} option to warn if source code appears
to expect automatic, silent, and
somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
constants to @code{REAL(KIND=2)} based on context.

For example, it would warn about cases like this:

@smallexample
DOUBLE PRECISION FOO
PARAMETER (TZPHI = 9.435784839284958)
FOO = TZPHI * 3D0
@end smallexample

@node Invalid Use of Hollerith Constant
@subsection Invalid Use of Hollerith Constant

@command{g77} should disallow statements like @samp{RETURN 2HAB},
which are invalid in both source forms
(unlike @samp{RETURN (2HAB)},
which probably still makes no sense but at least can
be reliably parsed).
Fixed-form processing rejects it, but not free-form, except
in a way that is a bit difficult to understand.

@node Dummy Array Without Dimensioning Dummy
@subsection Dummy Array Without Dimensioning Dummy

@command{g77} should complain when a list of dummy arguments containing an
adjustable dummy array does
not also contain every variable listed in the dimension list of the
adjustable array.

Currently, @command{g77} does complain about a variable that
dimensions an array but doesn't appear in any dummy list or @code{COMMON}
area, but this needs to be extended to catch cases where it doesn't appear in
every dummy list that also lists any arrays it dimensions.

For example, @command{g77} should warn about the entry point @samp{ALT}
below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
list of arguments:

@smallexample
SUBROUTINE PRIMARY(ARRAY, ISIZE)
REAL ARRAY(ISIZE)
ENTRY ALT(ARRAY)
@end smallexample

@node Invalid FORMAT Specifiers
@subsection Invalid FORMAT Specifiers

@command{g77} should check @code{FORMAT} specifiers for validity
as it does @code{FORMAT} statements.

For example, a diagnostic would be produced for:

@smallexample
PRINT 'HI THERE!'  !User meant PRINT *, 'HI THERE!'
@end smallexample

@node Ambiguous Dialects
@subsection Ambiguous Dialects

@command{g77} needs a set of options such as @option{-Wugly*}, @option{-Wautomatic},
@option{-Wvxt}, @option{-Wf90}, and so on.
These would warn about places in the user's source where ambiguities
are found, helpful in resolving ambiguities in the program's
dialect or dialects.

@node Unused Labels
@subsection Unused Labels

@command{g77} should warn about unused labels when @option{-Wunused} is in effect.

@node Informational Messages
@subsection Informational Messages

@command{g77} needs an option to suppress information messages (notes).
@option{-w} does this but also suppresses warnings.
The default should be to suppress info messages.

Perhaps info messages should simply be eliminated.

@node Uninitialized Variables at Run Time
@subsection Uninitialized Variables at Run Time

@command{g77} needs an option to initialize everything (not otherwise
explicitly initialized) to ``weird''
(machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
largest-magnitude integers, would help track down references to
some kinds of uninitialized variables at run time.

Note that use of the options @samp{-O -Wuninitialized} can catch
many such bugs at compile time.

@node Portable Unformatted Files
@subsection Portable Unformatted Files

@cindex unformatted files
@cindex file formats
@cindex binary data
@cindex byte ordering
@command{g77} has no facility for exchanging unformatted files with systems
using different number formats---even differing only in endianness (byte
order)---or written by other compilers.  Some compilers provide
facilities at least for doing byte-swapping during unformatted I/O.

It is unrealistic to expect to cope with exchanging unformatted files
with arbitrary other compiler runtimes, but the @command{g77} runtime
should at least be able to read files written by @command{g77} on systems
with different number formats, particularly if they differ only in byte
order.

In case you do need to write a program to translate to or from
@command{g77} (@code{libf2c}) unformatted files, they are written as
follows:
@table @asis
@item Sequential
Unformatted sequential records consist of
@enumerate
@item
A number giving the length of the record contents;
@item
the length of record contents again (for backspace).
@end enumerate

The record length is of C type
@code{long}; this means that it is 8 bytes on 64-bit systems such as
Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
Consequently such files cannot be exchanged between 64-bit and 32-bit
systems, even with the same basic number format.
@item Direct access
Unformatted direct access files form a byte stream of length
@var{records}*@var{recl} bytes, where @var{records} is the maximum
record number (@code{REC=@var{records}}) written and @var{recl} is the
record length in bytes specified in the @code{OPEN} statement
(@code{RECL=@var{recl}}).  Data appear in the records as determined by
the relevant @code{WRITE} statement.  Dummy records with arbitrary
contents appear in the file in place of records which haven't been
written.
@end table

Thus for exchanging a sequential or direct access unformatted file
between big- and little-endian 32-bit systems using IEEE 754 floating
point it would be sufficient to reverse the bytes in consecutive words
in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
@code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
@command{g77}.

If necessary, it is possible to do byte-oriented i/o with @command{g77}'s
@code{FGETC} and @code{FPUTC} intrinsics.  Byte-swapping can be done in
Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
array or a set of scalars.

@cindex HDF
@cindex PDB
If you need to exchange binary data between arbitrary system and
compiler variations, we recommend using a portable binary format with
Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
or PACT's PDB@footnote{No, not @emph{that} one.}
(@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}).  (Unlike,
say, CDF or XDR, HDF-like systems write in the native number formats and
only incur overhead when they are read on a system with a different
format.)  A future @command{g77} runtime library should use such
techniques.

@node Better List-directed I/O
@subsection Better List-directed I/O

Values output using list-directed I/O
(@samp{PRINT *, R, D})
should be written with a field width, precision, and so on
appropriate for the type (precision) of each value.

(Currently, no distinction is made between single-precision
and double-precision values
by @code{libf2c}.)

It is likely this item will require the @code{libg77} project
to be undertaken.

In the meantime, use of formatted I/O is recommended.
While it might be of little consolation,
@command{g77} does support @samp{FORMAT(F<WIDTH>.4)}, for example,
as long as @samp{WIDTH} is defined as a named constant
(via @code{PARAMETER}).
That at least allows some compile-time specification
of the precision of a data type,
perhaps controlled by preprocessing directives.

@node Default to Console I/O
@subsection Default to Console I/O

The default I/O units,
specified by @samp{READ @var{fmt}},
@samp{READ (UNIT=*)},
@samp{WRITE (UNIT=*)}, and
@samp{PRINT @var{fmt}},
should not be units 5 (input) and 6 (output),
but, rather, unit numbers not normally available
for use in statements such as @code{OPEN} and @code{CLOSE}.

Changing this would allow a program to connect units 5 and 6
to files via @code{OPEN},
but still use @samp{READ (UNIT=*)} and @samp{PRINT}
to do I/O to the ``console''.

This change probably requires the @code{libg77} project.

@node Labels Visible to Debugger
@subsection Labels Visible to Debugger

@command{g77} should output debugging information for statements labels,
for use by debuggers that know how to support them.
Same with weirder things like construct names.
It is not yet known if any debug formats or debuggers support these.

@node Disappointments
@section Disappointments and Misunderstandings

These problems are perhaps regrettable, but we don't know any practical
way around them for now.

@menu
* Mangling of Names::                       @samp{SUBROUTINE FOO} is given
                                              external name @samp{foo_}.
* Multiple Definitions of External Names::  No doing both @samp{COMMON /FOO/}
                                              and @samp{SUBROUTINE FOO}.
* Limitation on Implicit Declarations::     No @samp{IMPLICIT CHARACTER*(*)}.
@end menu

@node Mangling of Names
@subsection Mangling of Names in Source Code
@cindex naming issues
@cindex external names
@cindex common blocks
@cindex name space
@cindex underscore

The current external-interface design, which includes naming of
external procedures, COMMON blocks, and the library interface,
has various usability problems, including things like adding
underscores where not really necessary (and preventing easier
inter-language operability) and yet not providing complete
namespace freedom for user C code linked with Fortran apps (due
to the naming of functions in the library, among other things).

Project GNU should at least get all this ``right'' for systems
it fully controls, such as the Hurd, and provide defaults and
options for compatibility with existing systems and interoperability
with popular existing compilers.

@node Multiple Definitions of External Names
@subsection Multiple Definitions of External Names
@cindex block data
@cindex BLOCK DATA statement
@cindex statements, BLOCK DATA
@cindex @code{COMMON} statement
@cindex statements, @code{COMMON}
@cindex naming conflicts

@command{g77} doesn't allow a common block and an external procedure or
@code{BLOCK DATA} to have the same name.
Some systems allow this, but @command{g77} does not,
to be compatible with @command{f2c}.

@command{g77} could special-case the way it handles
@code{BLOCK DATA}, since it is not compatible with @command{f2c} in this
particular area (necessarily, since @command{g77} offers an
important feature here), but
it is likely that such special-casing would be very annoying to people
with programs that use @samp{EXTERNAL FOO}, with no other mention of
@samp{FOO} in the same program unit, to refer to external procedures, since
the result would be that @command{g77} would treat these references as requests to
force-load BLOCK DATA program units.

In that case, if @command{g77} modified
names of @code{BLOCK DATA} so they could have the same names as
@code{COMMON}, users
would find that their programs wouldn't link because the @samp{FOO} procedure
didn't have its name translated the same way.

(Strictly speaking,
@command{g77} could emit a null-but-externally-satisfying definition of
@samp{FOO} with its name transformed as if it had been a
@code{BLOCK DATA}, but that probably invites more trouble than it's
worth.)

@node Limitation on Implicit Declarations
@subsection Limitation on Implicit Declarations
@cindex IMPLICIT CHARACTER*(*) statement
@cindex statements, IMPLICIT CHARACTER*(*)

@command{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
This is not standard-conforming.

@node Non-bugs
@section Certain Changes We Don't Want to Make

This section lists changes that people frequently request, but which
we do not make because we think GNU Fortran is better without them.

@menu
* Backslash in Constants::           Why @samp{'\\'} is a constant that
                                       is one, not two, characters long.
* Initializing Before Specifying::   Why @samp{DATA VAR/1/} can't precede
                                       @samp{COMMON VAR}.
* Context-Sensitive Intrinsicness::  Why @samp{CALL SQRT} won't work.
* Context-Sensitive Constants::      Why @samp{9.435784839284958} is a
                                       single-precision constant,
                                       and might be interpreted as
                                       @samp{9.435785} or similar.
* Equivalence Versus Equality::      Why @samp{.TRUE. .EQ. .TRUE.} won't work.
* Order of Side Effects::            Why @samp{J = IFUNC() - IFUNC()} might
                                       not behave as expected.
@end menu

@node Backslash in Constants
@subsection Backslash in Constants
@cindex backslash
@cindex @command{f77} support
@cindex support, @command{f77}

In the opinion of many experienced Fortran users,
@option{-fno-backslash} should be the default, not @option{-fbackslash},
as currently set by @command{g77}.

First of all, you can always specify
@option{-fno-backslash} to turn off this processing.

Despite not being within the spirit (though apparently within the
letter) of the ANSI FORTRAN 77 standard, @command{g77} defaults to
@option{-fbackslash} because that is what most UNIX @command{f77} commands
default to, and apparently lots of code depends on this feature.

This is a particularly troubling issue.
The use of a C construct in the midst of Fortran code
is bad enough, worse when it makes existing Fortran
programs stop working (as happens when programs written
for non-UNIX systems are ported to UNIX systems with
compilers that provide the @option{-fbackslash} feature
as the default---sometimes with no option to turn it off).

The author of GNU Fortran wished, for reasons of linguistic
purity, to make @option{-fno-backslash} the default for GNU
Fortran and thus require users of UNIX @command{f77} and @command{f2c}
to specify @option{-fbackslash} to get the UNIX behavior.

However, the realization that @command{g77} is intended as
a replacement for @emph{UNIX} @command{f77}, caused the author
to choose to make @command{g77} as compatible with
@command{f77} as feasible, which meant making @option{-fbackslash}
the default.

The primary focus on compatibility is at the source-code
level, and the question became ``What will users expect
a replacement for @command{f77} to do, by default?''
Although at least one UNIX @command{f77} does not provide
@option{-fbackslash} as a default, it appears that
the majority of them do, which suggests that
the majority of code that is compiled by UNIX @command{f77}
compilers expects @option{-fbackslash} to be the default.

It is probably the case that more code exists
that would @emph{not} work with @option{-fbackslash}
in force than code that requires it be in force.

However, most of @emph{that} code is not being compiled
with @command{f77},
and when it is, new build procedures (shell scripts,
makefiles, and so on) must be set up anyway so that
they work under UNIX.
That makes a much more natural and safe opportunity for
non-UNIX users to adapt their build procedures for
@command{g77}'s default of @option{-fbackslash} than would
exist for the majority of UNIX @command{f77} users who
would have to modify existing, working build procedures
to explicitly specify @option{-fbackslash} if that was
not the default.

One suggestion has been to configure the default for
@option{-fbackslash} (and perhaps other options as well)
based on the configuration of @command{g77}.

This is technically quite straightforward, but will be avoided
even in cases where not configuring defaults to be
dependent on a particular configuration greatly inconveniences
some users of legacy code.

Many users appreciate the GNU compilers because they provide an
environment that is uniform across machines.
These users would be
inconvenienced if the compiler treated things like the
format of the source code differently on certain machines.

Occasionally users write programs intended only for a particular machine
type.
On these occasions, the users would benefit if the GNU Fortran compiler
were to support by default the same dialect as the other compilers on
that machine.
But such applications are rare.
And users writing a
program to run on more than one type of machine cannot possibly benefit
from this kind of compatibility.
(This is consistent with the design goals for @command{gcc}.
To change them for @command{g77}, you must first change them
for @command{gcc}.
Do not ask the maintainers of @command{g77} to do this for you,
or to disassociate @command{g77} from the widely understood, if
not widely agreed-upon, goals for GNU compilers in general.)

This is why GNU Fortran does and will treat backslashes in the same
fashion on all types of machines (by default).
@xref{Direction of Language Development}, for more information on
this overall philosophy guiding the development of the GNU Fortran
language.

Of course, users strongly concerned about portability should indicate
explicitly in their build procedures which options are expected
by their source code, or write source code that has as few such
expectations as possible.

For example, avoid writing code that depends on backslash (@samp{\})
being interpreted either way in particular, such as by
starting a program unit with:

@smallexample
CHARACTER BACKSL
PARAMETER (BACKSL = '\\')
@end smallexample

@noindent
Then, use concatenation of @samp{BACKSL} anyplace a backslash
is desired.
In this way, users can write programs which have the same meaning
in many Fortran dialects.

(However, this technique does not work for Hollerith constants---which
is just as well, since the only generally portable uses for Hollerith
constants are in places where character constants can and should
be used instead, for readability.)

@node Initializing Before Specifying
@subsection Initializing Before Specifying
@cindex initialization, statement placement
@cindex placing initialization statements

@command{g77} does not allow @samp{DATA VAR/1/} to appear in the
source code before @samp{COMMON VAR},
@samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
In general, @command{g77} requires initialization of a variable
or array to be specified @emph{after} all other specifications
of attributes (type, size, placement, and so on) of that variable
or array are specified (though @emph{confirmation} of data type is
permitted).

It is @emph{possible} @command{g77} will someday allow all of this,
even though it is not allowed by the FORTRAN 77 standard.

Then again, maybe it is better to have
@command{g77} always require placement of @code{DATA}
so that it can possibly immediately write constants
to the output file, thus saving time and space.

That is, @samp{DATA A/1000000*1/} should perhaps always
be immediately writable to canonical assembler, unless it's already known
to be in a @code{COMMON} area following as-yet-uninitialized stuff,
and to do this it cannot be followed by @samp{COMMON A}.

@node Context-Sensitive Intrinsicness
@subsection Context-Sensitive Intrinsicness
@cindex intrinsics, context-sensitive
@cindex context-sensitive intrinsics

@command{g77} treats procedure references to @emph{possible} intrinsic
names as always enabling their intrinsic nature, regardless of
whether the @emph{form} of the reference is valid for that
intrinsic.

For example, @samp{CALL SQRT} is interpreted by @command{g77} as
an invalid reference to the @code{SQRT} intrinsic function,
because the reference is a subroutine invocation.

First, @command{g77} recognizes the statement @samp{CALL SQRT}
as a reference to a @emph{procedure} named @samp{SQRT}, not
to a @emph{variable} with that name (as it would for a statement
such as @samp{V = SQRT}).

Next, @command{g77} establishes that, in the program unit being compiled,
@code{SQRT} is an intrinsic---not a subroutine that
happens to have the same name as an intrinsic (as would be
the case if, for example, @samp{EXTERNAL SQRT} was present).

Finally, @command{g77} recognizes that the @emph{form} of the
reference is invalid for that particular intrinsic.
That is, it recognizes that it is invalid for an intrinsic
@emph{function}, such as @code{SQRT}, to be invoked as
a @emph{subroutine}.

At that point, @command{g77} issues a diagnostic.

Some users claim that it is ``obvious'' that @samp{CALL SQRT}
references an external subroutine of their own, not an
intrinsic function.

However, @command{g77} knows about intrinsic
subroutines, not just functions, and is able to support both having
the same names, for example.

As a result of this, @command{g77} rejects calls
to intrinsics that are not subroutines, and function invocations
of intrinsics that are not functions, just as it (and most compilers)
rejects invocations of intrinsics with the wrong number (or types)
of arguments.

So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
a user-written subroutine named @samp{SQRT}.

@node Context-Sensitive Constants
@subsection Context-Sensitive Constants
@cindex constants, context-sensitive
@cindex context-sensitive constants

@command{g77} does not use context to determine the types of
constants or named constants (@code{PARAMETER}), except
for (non-standard) typeless constants such as @samp{'123'O}.

For example, consider the following statement:

@smallexample
PRINT *, 9.435784839284958 * 2D0
@end smallexample

@noindent
@command{g77} will interpret the (truncated) constant
@samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
constant, because the suffix @code{D0} is not specified.

As a result, the output of the above statement when
compiled by @command{g77} will appear to have ``less precision''
than when compiled by other compilers.

In these and other cases, some compilers detect the
fact that a single-precision constant is used in
a double-precision context and therefore interpret the
single-precision constant as if it was @emph{explicitly}
specified as a double-precision constant.
(This has the effect of appending @emph{decimal}, not
@emph{binary}, zeros to the fractional part of the
number---producing different computational results.)

The reason this misfeature is dangerous is that a slight,
apparently innocuous change to the source code can change
the computational results.
Consider:

@smallexample
REAL ALMOST, CLOSE
DOUBLE PRECISION FIVE
PARAMETER (ALMOST = 5.000000000001)
FIVE = 5
CLOSE = 5.000000000001
PRINT *, 5.000000000001 - FIVE
PRINT *, ALMOST - FIVE
PRINT *, CLOSE - FIVE
END
@end smallexample

@noindent
Running the above program should
result in the same value being
printed three times.
With @command{g77} as the compiler,
it does.

However, compiled by many other compilers,
running the above program would print
two or three distinct values, because
in two or three of the statements, the
constant @samp{5.000000000001}, which
on most systems is exactly equal to @samp{5.}
when interpreted as a single-precision constant,
is instead interpreted as a double-precision
constant, preserving the represented
precision.
However, this ``clever'' promotion of
type does not extend to variables or,
in some compilers, to named constants.

Since programmers often are encouraged to replace manifest
constants or permanently-assigned variables with named
constants (@code{PARAMETER} in Fortran), and might need
to replace some constants with variables having the same
values for pertinent portions of code,
it is important that compilers treat code so modified in the
same way so that the results of such programs are the same.
@command{g77} helps in this regard by treating constants just
the same as variables in terms of determining their types
in a context-independent way.

Still, there is a lot of existing Fortran code that has
been written to depend on the way other compilers freely
interpret constants' types based on context, so anything
@command{g77} can do to help flag cases of this in such code
could be very helpful.

@node Equivalence Versus Equality
@subsection Equivalence Versus Equality
@cindex .EQV., with integer operands
@cindex comparing logical expressions
@cindex logical expressions, comparing

Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
is not supported, except via @option{-fugly-logint}, which is not
recommended except for legacy code (where the behavior expected
by the @emph{code} is assumed).

Legacy code should be changed, as resources permit, to use @code{.EQV.}
and @code{.NEQV.} instead, as these are permitted by the various
Fortran standards.

New code should never be written expecting @code{.EQ.} or @code{.NE.}
to work if either of its operands is @code{LOGICAL}.

The problem with supporting this ``feature'' is that there is
unlikely to be consensus on how it works, as illustrated by the
following sample program:

@smallexample
LOGICAL L,M,N
DATA L,M,N /3*.FALSE./
IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
END
@end smallexample

The issue raised by the above sample program is: what is the
precedence of @code{.EQ.} (and @code{.NE.}) when applied to
@code{LOGICAL} operands?

Some programmers will argue that it is the same as the precedence
for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
operands.
By this interpretation, the subexpression @samp{M.EQ.N} must be
evaluated first in the above program, resulting in a program that,
when run, does not execute the @code{PRINT} statement.

Other programmers will argue that the precedence is the same as
the precedence for @code{.EQV.}, which is restricted by the standards
to @code{LOGICAL} operands.
By this interpretation, the subexpression @samp{L.AND.M} must be
evaluated first, resulting in a program that @emph{does} execute
the @code{PRINT} statement.

Assigning arbitrary semantic interpretations to syntactic expressions
that might legitimately have more than one ``obvious'' interpretation
is generally unwise.

The creators of the various Fortran standards have done a good job
in this case, requiring a distinct set of operators (which have their
own distinct precedence) to compare @code{LOGICAL} operands.
This requirement results in expression syntax with more certain
precedence (without requiring substantial context), making it easier
for programmers to read existing code.
@command{g77} will avoid muddying up elements of the Fortran language
that were well-designed in the first place.

(Ask C programmers about the precedence of expressions such as
@samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
you, without knowing more context, whether the @samp{&} and @samp{-}
operators are infix (binary) or unary!)

Most dangerous of all is the fact that,
even assuming consensus on its meaning,
an expression like @samp{L.AND.M.EQ.N},
if it is the result of a typographical error,
doesn't @emph{look} like it has such a typo.
Even experienced Fortran programmers would not likely notice that
@samp{L.AND.M.EQV.N} was, in fact, intended.

So, this is a prime example of a circumstance in which
a quality compiler diagnoses the code,
instead of leaving it up to someone debugging it
to know to turn on special compiler options
that might diagnose it.

@node Order of Side Effects
@subsection Order of Side Effects
@cindex side effects, order of evaluation
@cindex order of evaluation, side effects

@command{g77} does not necessarily produce code that, when run, performs
side effects (such as those performed by function invocations)
in the same order as in some other compiler---or even in the same
order as another version, port, or invocation (using different
command-line options) of @command{g77}.

It is never safe to depend on the order of evaluation of side effects.
For example, an expression like this may very well behave differently
from one compiler to another:

@smallexample
J = IFUNC() - IFUNC()
@end smallexample

@noindent
There is no guarantee that @samp{IFUNC} will be evaluated in any particular
order.
Either invocation might happen first.
If @samp{IFUNC} returns 5 the first time it is invoked, and
returns 12 the second time, @samp{J} might end up with the
value @samp{7}, or it might end up with @samp{-7}.

Generally, in Fortran, procedures with side-effects intended to
be visible to the caller are best designed as @emph{subroutines},
not functions.
Examples of such side-effects include:

@itemize @bullet
@item
The generation of random numbers
that are intended to influence return values.

@item
Performing I/O
(other than internal I/O to local variables).

@item
Updating information in common blocks.
@end itemize

An example of a side-effect that is not intended to be visible
to the caller is a function that maintains a cache of recently
calculated results, intended solely to speed repeated invocations
of the function with identical arguments.
Such a function can be safely used in expressions, because
if the compiler optimizes away one or more calls to the
function, operation of the program is unaffected (aside
from being speeded up).

@node Warnings and Errors
@section Warning Messages and Error Messages

@cindex error messages
@cindex warnings vs errors
@cindex messages, warning and error
The GNU compiler can produce two kinds of diagnostics: errors and
warnings.
Each kind has a different purpose:

@itemize @w{}
@item
@emph{Errors} report problems that make it impossible to compile your
program.
GNU Fortran reports errors with the source file name, line
number, and column within the line where the problem is apparent.

@item
@emph{Warnings} report other unusual conditions in your code that
@emph{might} indicate a problem, although compilation can (and does)
proceed.
Warning messages also report the source file name, line number,
and column information,
but include the text @samp{warning:} to distinguish them
from error messages.
@end itemize

Warnings might indicate danger points where you should check to make sure
that your program really does what you intend; or the use of obsolete
features; or the use of nonstandard features of GNU Fortran.
Many warnings are issued only if you ask for them, with one of the
@option{-W} options (for instance, @option{-Wall} requests a variety of
useful warnings).

@emph{Note:} Currently, the text of the line and a pointer to the column
is printed in most @command{g77} diagnostics.

@xref{Warning Options,,Options to Request or Suppress Warnings}, for
more detail on these and related command-line options.

@node Open Questions
@chapter Open Questions

Please consider offering useful answers to these questions!

@itemize @bullet
@item
@code{LOC()} and other intrinsics are probably somewhat misclassified.
Is the a need for more precise classification of intrinsics, and if so,
what are the appropriate groupings?
Is there a need to individually
enable/disable/delete/hide intrinsics from the command line?
@end itemize

@node Bugs
@chapter Reporting Bugs
@cindex bugs
@cindex reporting bugs

Your bug reports play an essential role in making GNU Fortran reliable.

When you encounter a problem, the first thing to do is to see if it is
already known.  @xref{Trouble}.  If it isn't known, then you should
report the problem.

@menu
* Criteria: Bug Criteria.    Have you really found a bug?
* Reporting: Bug Reporting.  How to report a bug effectively.
@end menu

@xref{Trouble,,Known Causes of Trouble with GNU Fortran},
for information on problems we already know about.

@xref{Service,,How To Get Help with GNU Fortran},
for information on where to ask for help.

@node Bug Criteria
@section Have You Found a Bug?
@cindex bug criteria

If you are not sure whether you have found a bug, here are some guidelines:

@itemize @bullet
@cindex fatal signal
@cindex core dump
@item
If the compiler gets a fatal signal, for any input whatever, that is a
compiler bug.
Reliable compilers never crash---they just remain obsolete.

@cindex invalid assembly code
@cindex assembly code, invalid
@item
If the compiler produces invalid assembly code, for any input whatever,
@c (except an @code{asm} statement),
that is a compiler bug, unless the
compiler reports errors (not just warnings) which would ordinarily
prevent the assembler from being run.

@cindex undefined behavior
@cindex undefined function value
@item
If the compiler produces valid assembly code that does not correctly
execute the input source code, that is a compiler bug.

However, you must double-check to make sure, because you might have run
into an incompatibility between GNU Fortran and traditional Fortran.
@c (@pxref{Incompatibilities}).
These incompatibilities might be considered
bugs, but they are inescapable consequences of valuable features.

Or you might have a program whose behavior is undefined, which happened
by chance to give the desired results with another Fortran compiler.
It is best to check the relevant Fortran standard thoroughly if
it is possible that the program indeed does something undefined.

After you have localized the error to a single source line, it should
be easy to check for these things.
If your program is correct and well defined, you have found
a compiler bug.

It might help if, in your submission, you identified the specific
language in the relevant Fortran standard that specifies the
desired behavior, if it isn't likely to be obvious and agreed-upon
by all Fortran users.

@item
If the compiler produces an error message for valid input, that is a
compiler bug.

@cindex invalid input
@item
If the compiler does not produce an error message for invalid input,
that is a compiler bug.
However, you should note that your idea of
``invalid input'' might be someone else's idea
of ``an extension'' or ``support for traditional practice''.

@item
If you are an experienced user of Fortran compilers, your suggestions
for improvement of GNU Fortran are welcome in any case.
@end itemize

Many, perhaps most, bug reports against @command{g77} turn out to
be bugs in the user's code.
While we find such bug reports educational, they sometimes take
a considerable amount of time to track down or at least respond
to---time we could be spending making @command{g77}, not some user's
code, better.

Some steps you can take to verify that the bug is not certainly
in the code you're compiling with @command{g77}:

@itemize @bullet
@item
Compile your code using the @command{g77} options @samp{-W -Wall -O}.
These options enable many useful warning; the @option{-O} option
enables flow analysis that enables the uninitialized-variable
warning.

If you investigate the warnings and find evidence of possible bugs
in your code, fix them first and retry @command{g77}.

@item
Compile your code using the @command{g77} options @option{-finit-local-zero},
@option{-fno-automatic}, @option{-ffloat-store}, and various
combinations thereof.

If your code works with any of these combinations, that is not
proof that the bug isn't in @command{g77}---a @command{g77} bug exposed
by your code might simply be avoided, or have a different, more subtle
effect, when different options are used---but it can be a
strong indicator that your code is making unwarranted assumptions
about the Fortran dialect and/or underlying machine it is
being compiled and run on.

@xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
for information on the @option{-fno-automatic} and
@option{-finit-local-zero} options and how to convert
their use into selective changes in your own code.

@item
@pindex ftnchek
Validate your code with @command{ftnchek} or a similar code-checking
tool.
@command{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
or @uref{ftp://ftp.dsm.fordham.edu}.

@pindex make
@cindex Makefile example
Here are some sample @file{Makefile} rules using @command{ftnchek}
``project'' files to do cross-file checking and @command{sfmakedepend}
(from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
to maintain dependencies automatically.
These assume the use of GNU @command{make}.

@smallexample
# Dummy suffix for ftnchek targets:
.SUFFIXES: .chek
.PHONY: chekall

# How to compile .f files (for implicit rule):
FC = g77
# Assume `include' directory:
FFLAGS = -Iinclude -g -O -Wall

# Flags for ftnchek:
CHEK1 = -array=0 -include=includes -noarray
CHEK2 = -nonovice -usage=1 -notruncation
CHEKFLAGS = $(CHEK1) $(CHEK2)

# Run ftnchek with all the .prj files except the one corresponding
# to the target's root:
%.chek : %.f ; \
  ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
    -noextern -library $<

# Derive a project file from a source file:
%.prj : %.f ; \
  ftnchek $(CHEKFLAGS) -noextern -project -library $<

# The list of objects is assumed to be in variable OBJS.
# Sources corresponding to the objects:
SRCS = $(OBJS:%.o=%.f)
# ftnchek project files:
PRJS = $(OBJS:%.o=%.prj)

# Build the program
prog: $(OBJS) ; \
  $(FC) -o $@ $(OBJS)

chekall: $(PRJS) ; \
  ftnchek $(CHEKFLAGS) $(PRJS)

prjs: $(PRJS)

# For Emacs M-x find-tag:
TAGS: $(SRCS) ; \
  etags $(SRCS)

# Rebuild dependencies:
depend: ; \
  sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
@end smallexample

@item
Try your code out using other Fortran compilers, such as @command{f2c}.
If it does not work on at least one other compiler (assuming the
compiler supports the features the code needs), that is a strong
indicator of a bug in the code.

However, even if your code works on many compilers @emph{except}
@command{g77}, that does @emph{not} mean the bug is in @command{g77}.
It might mean the bug is in your code, and that @command{g77} simply
exposes it more readily than other compilers.
@end itemize

@node Bug Reporting
@section How to Report Bugs
@cindex compiler bugs, reporting

Bugs should be reported to our bug database.  Please refer to
@uref{http://gcc.gnu.org/bugs.html} for up-to-date instructions how to
submit bug reports.  Copies of this file in HTML (@file{bugs.html}) and
plain text (@file{BUGS}) are also part of GCC releases.


@node Service
@chapter How To Get Help with GNU Fortran

If you need help installing, using or changing GNU Fortran, there are two
ways to find it:

@itemize @bullet
@item
Look in the service directory for someone who might help you for a fee.
The service directory is found in the file named @file{SERVICE} in the
GCC distribution.

@item
Send a message to @email{@value{email-help}}.
@end itemize

@end ifset
@ifset INTERNALS
@node Adding Options
@chapter Adding Options
@cindex options, adding
@cindex adding options

To add a new command-line option to @command{g77}, first decide
what kind of option you wish to add.
Search the @command{g77} and @command{gcc} documentation for one
or more options that is most closely like the one you want to add
(in terms of what kind of effect it has, and so on) to
help clarify its nature.

@itemize @bullet
@item
@emph{Fortran options} are options that apply only
when compiling Fortran programs.
They are accepted by @command{g77} and @command{gcc}, but
they apply only when compiling Fortran programs.

@item
@emph{Compiler options} are options that apply
when compiling most any kind of program.
@end itemize

@emph{Fortran options} are listed in the file
@file{@value{path-g77}/lang-options.h},
which is used during the build of @command{gcc} to
build a list of all options that are accepted by
at least one language's compiler.
This list goes into the @code{documented_lang_options} array
in @file{gcc/toplev.c}, which uses this array to
determine whether a particular option should be
offered to the linked-in front end for processing
by calling @code{lang_option_decode}, which, for
@command{g77}, is in @file{@value{path-g77}/com.c} and just
calls @code{ffe_decode_option}.

If the linked-in front end ``rejects'' a
particular option passed to it, @file{toplev.c}
just ignores the option, because @emph{some}
language's compiler is willing to accept it.

This allows commands like @samp{gcc -fno-asm foo.c bar.f}
to work, even though Fortran compilation does
not currently support the @option{-fno-asm} option;
even though the @code{f771} version of @code{lang_decode_option}
rejects @option{-fno-asm}, @file{toplev.c} doesn't
produce a diagnostic because some other language (C)
does accept it.

This also means that commands like
@samp{g77 -fno-asm foo.f} yield no diagnostics,
despite the fact that no phase of the command was
able to recognize and process @option{-fno-asm}---perhaps
a warning about this would be helpful if it were
possible.

Code that processes Fortran options is found in
@file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
This code needs to check positive and negative forms
of each option.

The defaults for Fortran options are set in their
global definitions, also found in @file{@value{path-g77}/top.c}.
Many of these defaults are actually macros defined
in @file{@value{path-g77}/target.h}, since they might be
machine-specific.
However, since, in practice, GNU compilers
should behave the same way on all configurations
(especially when it comes to language constructs),
the practice of setting defaults in @file{target.h}
is likely to be deprecated and, ultimately, stopped
in future versions of @command{g77}.

Accessor macros for Fortran options, used by code
in the @command{g77} FFE, are defined in @file{@value{path-g77}/top.h}.

@emph{Compiler options} are listed in @file{gcc/toplev.c}
in the array @code{f_options}.
An option not listed in @code{lang_options} is
looked up in @code{f_options} and handled from there.

The defaults for compiler options are set in the
global definitions for the corresponding variables,
some of which are in @file{gcc/toplev.c}.

You can set different defaults for @emph{Fortran-oriented}
or @emph{Fortran-reticent} compiler options by changing
the source code of @command{g77} and rebuilding.
How to do this depends on the version of @command{g77}:

@table @code
@item G77 0.5.24 (EGCS 1.1)
@itemx G77 0.5.25 (EGCS 1.2 - which became GCC 2.95)
Change the @code{lang_init_options} routine in @file{gcc/gcc/f/com.c}.

(Note that these versions of @command{g77}
perform internal consistency checking automatically
when the @option{-fversion} option is specified.)

@item G77 0.5.23
@itemx G77 0.5.24 (EGCS 1.0)
Change the way @code{f771} handles the @option{-fset-g77-defaults}
option, which is always provided as the first option when
called by @command{g77} or @command{gcc}.

This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
Have it change just the variables that you want to default
to a different setting for Fortran compiles compared to
compiles of other languages.

The @option{-fset-g77-defaults} option is passed to @code{f771}
automatically because of the specification information
kept in @file{@value{path-g77}/lang-specs.h}.
This file tells the @command{gcc} command how to recognize,
in this case, Fortran source files (those to be preprocessed,
and those that are not), and further, how to invoke the
appropriate programs (including @code{f771}) to process
those source files.

It is in @file{@value{path-g77}/lang-specs.h} that @option{-fset-g77-defaults},
@option{-fversion}, and other options are passed, as appropriate,
even when the user has not explicitly specified them.
Other ``internal'' options such as @option{-quiet} also
are passed via this mechanism.
@end table

@node Projects
@chapter Projects
@cindex projects

If you want to contribute to @command{g77} by doing research,
design, specification, documentation, coding, or testing,
the following information should give you some ideas.

@menu
* Efficiency::               Make @command{g77} itself compile code faster.
* Better Optimization::      Teach @command{g77} to generate faster code.
* Simplify Porting::         Make @command{g77} easier to configure, build,
                             and install.
* More Extensions::          Features many users won't know to ask for.
* Machine Model::            @command{g77} should better leverage @command{gcc}.
* Internals Documentation::  Make maintenance easier.
* Internals Improvements::   Make internals more robust.
* Better Diagnostics::       Make using @command{g77} on new code easier.
@end menu

@node Efficiency
@section Improve Efficiency
@cindex efficiency

Don't bother doing any performance analysis until most of the
following items are taken care of, because there's no question
they represent serious space/time problems, although some of
them show up only given certain kinds of (popular) input.

@itemize @bullet
@item
Improve @code{malloc} package and its uses to specify more info about
memory pools and, where feasible, use obstacks to implement them.

@item
Skip over uninitialized portions of aggregate areas (arrays,
@code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
This would reduce memory usage for large initialized aggregate
areas, even ones with only one initialized element.

As of version 0.5.18, a portion of this item has already been
accomplished.

@item
Prescan the statement (in @file{sta.c}) so that the nature of the statement
is determined as much as possible by looking entirely at its form,
and not looking at any context (previous statements, including types
of symbols).
This would allow ripping out of the statement-confirmation,
symbol retraction/confirmation, and diagnostic inhibition
mechanisms.
Plus, it would result in much-improved diagnostics.
For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
is not a subroutine intrinsic, would result actual error instead of the
unimplemented-statement catch-all.

@item
Throughout @command{g77}, don't pass line/column pairs where
a simple @code{ffewhere} type, which points to the error as much as is
desired by the configuration, will do, and don't pass @code{ffelexToken} types
where a simple @code{ffewhere} type will do.
Then, allow new default
configuration of @code{ffewhere} such that the source line text is not
preserved, and leave it to things like Emacs' next-error function
to point to them (now that @samp{next-error} supports column,
or, perhaps, character-offset, numbers).
The change in calling sequences should improve performance somewhat,
as should not having to save source lines.
(Whether this whole
item will improve performance is questionable, but it should
improve maintainability.)

@item
Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
as regards the assembly output.
Some of this might require improving
the back end, but lots of improvement in space/time required in @command{g77}
itself can be fairly easily obtained without touching the back end.
Maybe type-conversion, where necessary, can be speeded up as well in
cases like the one shown (converting the @samp{2} into @samp{2.}).

@item
If analysis shows it to be worthwhile, optimize @file{lex.c}.

@item
Consider redesigning @file{lex.c} to not need any feedback
during tokenization, by keeping track of enough parse state on its
own.
@end itemize

@node Better Optimization
@section Better Optimization
@cindex optimization, better
@cindex code generation, improving

Much of this work should be put off until after @command{g77} has
all the features necessary for its widespread acceptance as a
useful F77 compiler.
However, perhaps this work can be done in parallel during
the feature-adding work.

@itemize @bullet
@item
Do the equivalent of the trick of putting @samp{extern inline} in front
of every function definition in @code{libg2c} and #include'ing the resulting
file in @command{f2c}+@command{gcc}---that is, inline all run-time-library functions
that are at all worth inlining.
(Some of this has already been done, such as for integral exponentiation.)

@item
When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
and it's clear that types line up
and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
make @samp{CHAR_VAR}, not a
temporary, be the receiver for @samp{CHAR_FUNC}.
(This is now done for @code{COMPLEX} variables.)

@item
Design and implement Fortran-specific optimizations that don't
really belong in the back end, or where the front end needs to
give the back end more info than it currently does.

@item
Design and implement a new run-time library interface, with the
code going into @code{libgcc} so no special linking is required to
link Fortran programs using standard language features.
This library
would speed up lots of things, from I/O (using precompiled formats,
doing just one, or, at most, very few, calls for arrays or array sections,
and so on) to general computing (array/section implementations of
various intrinsics, implementation of commonly performed loops that
aren't likely to be optimally compiled otherwise, etc.).

Among the important things the library would do are:

@itemize @bullet
@item
Be a one-stop-shop-type
library, hence shareable and usable by all, in that what are now
library-build-time options in @code{libg2c} would be moved at least to the
@command{g77} compile phase, if not to finer grains (such as choosing how
list-directed I/O formatting is done by default at @code{OPEN} time, for
preconnected units via options or even statements in the main program
unit, maybe even on a per-I/O basis with appropriate pragma-like
devices).
@end itemize

@item
Probably requiring the new library design, change interface to
normally have @code{COMPLEX} functions return their values in the way
@command{gcc} would if they were declared @code{__complex__ float},
rather than using
the mechanism currently used by @code{CHARACTER} functions (whereby the
functions are compiled as returning void and their first arg is
a pointer to where to store the result).
(Don't append underscores to
external names for @code{COMPLEX} functions in some cases once @command{g77} uses
@command{gcc} rather than @command{f2c} calling conventions.)

@item
Do something useful with @code{doiter} references where possible.
For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
a @code{DO} loop that uses @samp{I} as the
iteration variable, and the back end might find that info useful
in determining whether it needs to read @samp{I} back into a register after
the call.
(It normally has to do that, unless it knows @samp{FOO} never
modifies its passed-by-reference argument, which is rarely the case
for Fortran-77 code.)
@end itemize

@node Simplify Porting
@section Simplify Porting
@cindex porting, simplify
@cindex simplify porting

Making @command{g77} easier to configure, port, build, and install, either
as a single-system compiler or as a cross-compiler, would be
very useful.

@itemize @bullet
@item
A new library (replacing @code{libg2c}) should improve portability as well as
produce more optimal code.
Further, @command{g77} and the new library should
conspire to simplify naming of externals, such as by removing unnecessarily
added underscores, and to reduce/eliminate the possibility of naming
conflicts, while making debugger more straightforward.

Also, it should
make multi-language applications more feasible, such as by providing
Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
descriptors.

@item
Possibly related to a new library, @command{g77} should produce the equivalent
of a @command{gcc} @samp{main(argc, argv)} function when it compiles a
main program unit, instead of compiling something that must be
called by a library
implementation of @code{main()}.

This would do many useful things such as
provide more flexibility in terms of setting up exception handling,
not requiring programmers to start their debugging sessions with
@kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.

@item
The GBE needs to understand the difference between alignment
requirements and desires.
For example, on Intel x86 machines, @command{g77} currently imposes
overly strict alignment requirements, due to the back end, but it
would be useful for Fortran and C programmers to be able to override
these @emph{recommendations} as long as they don't violate the actual
processor @emph{requirements}.
@end itemize

@node More Extensions
@section More Extensions
@cindex extensions, more

These extensions are not the sort of things users ask for ``by name'',
but they might improve the usability of @command{g77}, and Fortran in
general, in the long run.
Some of these items really pertain to improving @command{g77} internals
so that some popular extensions can be more easily supported.

@itemize @bullet
@item
Look through all the documentation on the GNU Fortran language,
dialects, compiler, missing features, bugs, and so on.
Many mentions of incomplete or missing features are
sprinkled throughout.
It is not worth repeating them here.

@item
Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
named and unnamed.
The idea is to provide a forward-looking, effective
replacement for things like the old-style @code{PARAMETER} statement
when people
really need typelessness in a maintainable, portable, clearly documented
way.
Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
and whatever else might come along.
(This is not really a call for polymorphism per se, just
an ability to express limited, syntactic polymorphism.)

@item
Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.

@item
Support arbitrary file unit numbers, instead of limiting them
to 0 through @samp{MXUNIT-1}.
(This is a @code{libg2c} issue.)

@item
@samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
@samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
later @code{UNIT=} in the first example is invalid.
Make sure this is what users of this feature would expect.

@item
Currently @command{g77} disallows @samp{READ(1'10)} since
it is an obnoxious syntax, but
supporting it might be pretty easy if needed.
More details are needed, such
as whether general expressions separated by an apostrophe are supported,
or maybe the record number can be a general expression, and so on.

@item
Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
fully.
Currently there is no support at all
for @code{%FILL} in @code{STRUCTURE} and related syntax,
whereas the rest of the
stuff has at least some parsing support.
This requires either major
changes to @code{libg2c} or its replacement.

@item
F90 and @command{g77} probably disagree about label scoping relative to
@code{INTERFACE} and @code{END INTERFACE}, and their contained
procedure interface bodies (blocks?).

@item
@code{ENTRY} doesn't support F90 @code{RESULT()} yet,
since that was added after S8.112.

@item
Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
with the final form of the standard (it was vague at S8.112).

@item
It seems to be an ``open'' question whether a file, immediately after being
@code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
might be nice to offer an option of opening to ``undefined'' status, requiring
an explicit absolute-positioning operation to be performed before any
other (besides @code{CLOSE}) to assist in making applications port to systems
(some IBM?) that @code{OPEN} to the end of a file or some such thing.
@end itemize

@node Machine Model
@section Machine Model

This items pertain to generalizing @command{g77}'s view of
the machine model to more fully accept whatever the GBE
provides it via its configuration.

@itemize @bullet
@item
Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
exclusively so the target float format need not be required.
This
means changing the way @command{g77} handles initialization of aggregate areas
having more than one type, such as @code{REAL} and @code{INTEGER},
because currently
it initializes them as if they were arrays of @code{char} and uses the
bit patterns of the constants of the various types in them to determine
what to stuff in elements of the arrays.

@item
Rely more and more on back-end info and capabilities, especially in the
area of constants (where having the @command{g77} front-end's IL just store
the appropriate tree nodes containing constants might be best).

@item
Suite of C and Fortran programs that a user/administrator can run on a
machine to help determine the configuration for @command{g77} before building
and help determine if the compiler works (especially with whatever
libraries are installed) after building.
@end itemize

@node Internals Documentation
@section Internals Documentation

Better info on how @command{g77} works and how to port it is needed.

@xref{Front End}, which contains some information
on @command{g77} internals.

@node Internals Improvements
@section Internals Improvements

Some more items that would make @command{g77} more reliable
and easier to maintain:

@itemize @bullet
@item
Generally make expression handling focus
more on critical syntax stuff, leaving semantics to callers.
For example,
anything a caller can check, semantically, let it do so, rather
than having @file{expr.c} do it.
(Exceptions might include things like
diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
it seems
important to preserve the left-to-right-in-source order of production
of diagnostics.)

@item
Come up with better naming conventions for @option{-D} to establish requirements
to achieve desired implementation dialect via @file{proj.h}.

@item
Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.

@item
Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.

@item
Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
(after determining if there is indeed no real need for it).

@item
Utility to read and check @file{bad.def} messages and their references in the
code, to make sure calls are consistent with message templates.

@item
Search and fix @samp{&ffe@dots{}} and similar so that
@samp{ffe@dots{}ptr@dots{}} macros are
available instead (a good argument for wishing this could have written all
this stuff in C++, perhaps).
On the other hand, it's questionable whether this sort of
improvement is really necessary, given the availability of
tools such as Emacs and Perl, which make finding any
address-taking of structure members easy enough?

@item
Some modules truly export the member names of their structures (and the
structures themselves), maybe fix this, and fix other modules that just
appear to as well (by appending @samp{_}, though it'd be ugly and probably
not worth the time).

@item
Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
in @file{proj.h}
and use them throughout @command{g77} source code (especially in the definitions
of access macros in @samp{.h} files) so they can be tailored
to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.

@item
Decorate throughout with @code{const} and other such stuff.

@item
All F90 notational derivations in the source code are still based
on the S8.112 version of the draft standard.
Probably should update
to the official standard, or put documentation of the rules as used
in the code@dots{}uh@dots{}in the code.

@item
Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
inside but invoked via paths not involving @code{ffeexpr_lhs} or
@code{ffeexpr_rhs}) might be creating things
in improper pools, leading to such things staying around too long or
(doubtful, but possible and dangerous) not long enough.

@item
Some @code{ffebld_list_new} (or whatever) calls might not be matched by
@code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
(It definitely is not a problem just yet.)

@item
Probably not doing clean things when we fail to @code{EQUIVALENCE} something
due to alignment/mismatch or other problems---they end up without
@code{ffestorag} objects, so maybe the backend (and other parts of the front
end) can notice that and handle like an @code{opANY} (do what it wants, just
don't complain or crash).
Most of this seems to have been addressed
by now, but a code review wouldn't hurt.
@end itemize

@node Better Diagnostics
@section Better Diagnostics

These are things users might not ask about, or that need to
be looked into, before worrying about.
Also here are items that involve reducing unnecessary diagnostic
clutter.

@itemize @bullet
@item
When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
lengths, type classes, and so on),
@code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
it specifies.

@item
Speed up and improve error handling for data when repeat-count is
specified.
For example, don't output 20 unnecessary messages after the
first necessary one for:

@smallexample
INTEGER X(20)
CONTINUE
DATA (X(I), J= 1, 20) /20*5/
END
@end smallexample

@noindent
(The @code{CONTINUE} statement ensures the @code{DATA} statement
is processed in the context of executable, not specification,
statements.)
@end itemize

@include ffe.texi

@end ifset

@ifset USING
@node Diagnostics
@chapter Diagnostics
@cindex diagnostics

Some diagnostics produced by @command{g77} require sufficient explanation
that the explanations are given below, and the diagnostics themselves
identify the appropriate explanation.

Identification uses the GNU Info format---specifically, the @command{info}
command that displays the explanation is given within square
brackets in the diagnostic.
For example:

@smallexample
foo.f:5: Invalid statement [info -f g77 M FOOEY]
@end smallexample

More details about the above diagnostic is found in the @command{g77} Info
documentation, menu item @samp{M}, submenu item @samp{FOOEY},
which is displayed by typing the UNIX command
@samp{info -f g77 M FOOEY}.

Other Info readers, such as EMACS, may be just as easily used to display
the pertinent node.
In the above example, @samp{g77} is the Info document name,
@samp{M} is the top-level menu item to select,
and, in that node (named @samp{Diagnostics}, the name of
this chapter, which is the very text you're reading now),
@samp{FOOEY} is the menu item to select.

@iftex
In this printed version of the @command{g77} manual, the above example
points to a section, below, entitled @samp{FOOEY}---though, of course,
as the above is just a sample, no such section exists.
@end iftex

@menu
* CMPAMBIG::    Ambiguous use of intrinsic.
* EXPIMP::      Intrinsic used explicitly and implicitly.
* INTGLOB::     Intrinsic also used as name of global.
* LEX::         Various lexer messages
* GLOBALS::     Disagreements about globals.
* LINKFAIL::    When linking @code{f771} fails.
* Y2KBAD::      Use of non-Y2K-compliant intrinsic.
@end menu

@node CMPAMBIG
@section @code{CMPAMBIG}

@noindent
@smallexample
Ambiguous use of intrinsic @var{intrinsic} @dots{}
@end smallexample

The type of the argument to the invocation of the @var{intrinsic}
intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
Typically, it is @code{COMPLEX(KIND=2)}, also known as
@code{DOUBLE COMPLEX}.

The interpretation of this invocation depends on the particular
dialect of Fortran for which the code was written.
Some dialects convert the real part of the argument to
@code{REAL(KIND=1)}, thus losing precision; other dialects,
and Fortran 90, do no such conversion.

So, GNU Fortran rejects such invocations except under certain
circumstances, to avoid making an incorrect assumption that results
in generating the wrong code.

To determine the dialect of the program unit, perhaps even whether
that particular invocation is properly coded, determine how the
result of the intrinsic is used.

The result of @var{intrinsic} is expected (by the original programmer)
to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:

@itemize @bullet
@item
It is passed as an argument to a procedure that explicitly or
implicitly declares that argument @code{REAL(KIND=1)}.

For example,
a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
statement specifying the dummy argument corresponding to an
actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
@code{DOUBLE COMPLEX}, strongly suggests that the programmer
expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
of @code{REAL(KIND=2)}.

@item
It is used in a context that would otherwise not include
any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
invocation as @code{REAL(KIND=2)} would result in unnecessary
promotions and (typically) more expensive operations on the
wider type.

For example:

@smallexample
DOUBLE COMPLEX Z
@dots{}
R(1) = T * REAL(Z)
@end smallexample

The above example suggests the programmer expected the real part
of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
multiplied by @samp{T} (presumed, along with @samp{R} above, to
be type @code{REAL(KIND=1)}).

Otherwise, the conversion would have to be delayed until after
the multiplication, requiring not only an extra conversion
(of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
expensive multiplication (a double-precision multiplication instead
of a single-precision one).
@end itemize

The result of @var{intrinsic} is expected (by the original programmer)
to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:

@itemize @bullet
@item
It is passed as an argument to a procedure that explicitly or
implicitly declares that argument @code{REAL(KIND=2)}.

For example, a procedure specifying a @code{DOUBLE PRECISION}
dummy argument corresponding to an
actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
@code{DOUBLE COMPLEX}, strongly suggests that the programmer
expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
of @code{REAL(KIND=1)}.

@item
It is used in an expression context that includes
other @code{REAL(KIND=2)} operands,
or is assigned to a @code{REAL(KIND=2)} variable or array element.

For example:

@smallexample
DOUBLE COMPLEX Z
DOUBLE PRECISION R, T
@dots{}
R(1) = T * REAL(Z)
@end smallexample

The above example suggests the programmer expected the real part
of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
by the @code{REAL()} intrinsic.

Otherwise, the conversion would have to be immediately followed
by a conversion back to @code{REAL(KIND=2)}, losing
the original, full precision of the real part of @code{Z},
before being multiplied by @samp{T}.
@end itemize

Once you have determined whether a particular invocation of @var{intrinsic}
expects the Fortran 90 interpretation, you can:

@itemize @bullet
@item
Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
@code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
is @code{AIMAG})
if it expected the Fortran 90 interpretation.

This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
some other type, such as @code{COMPLEX*32}, you should use the
appropriate intrinsic, such as the one to convert to @code{REAL*16}
(perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
@code{QIMAG()} in place of @code{DIMAG()}).

@item
Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
otherwise.
This converts to @code{REAL(KIND=1)} in all working
Fortran compilers.
@end itemize

If you don't want to change the code, and you are certain that all
ambiguous invocations of @var{intrinsic} in the source file have
the same expectation regarding interpretation, you can:

@itemize @bullet
@item
Compile with the @command{g77} option @option{-ff90}, to enable the
Fortran 90 interpretation.

@item
Compile with the @command{g77} options @samp{-fno-f90 -fugly-complex},
to enable the non-Fortran-90 interpretations.
@end itemize

@xref{REAL() and AIMAG() of Complex}, for more information on this
issue.

Note: If the above suggestions don't produce enough evidence
as to whether a particular program expects the Fortran 90
interpretation of this ambiguous invocation of @var{intrinsic},
there is one more thing you can try.

If you have access to most or all the compilers used on the
program to create successfully tested and deployed executables,
read the documentation for, and @emph{also} test out, each compiler
to determine how it treats the @var{intrinsic} intrinsic in
this case.
(If all the compilers don't agree on an interpretation, there
might be lurking bugs in the deployed versions of the program.)

The following sample program might help:

@cindex JCB003 program
@smallexample
      PROGRAM JCB003
C
C Written by James Craig Burley 1997-02-23.
C
C Determine how compilers handle non-standard REAL
C and AIMAG on DOUBLE COMPLEX operands.
C
      DOUBLE COMPLEX Z
      REAL R
      Z = (3.3D0, 4.4D0)
      R = Z
      CALL DUMDUM(Z, R)
      R = REAL(Z) - R
      IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
      IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
      R = 4.4D0
      CALL DUMDUM(Z, R)
      R = AIMAG(Z) - R
      IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
      IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
      END
C
C Just to make sure compiler doesn't use naive flow
C analysis to optimize away careful work above,
C which might invalidate results....
C
      SUBROUTINE DUMDUM(Z, R)
      DOUBLE COMPLEX Z
      REAL R
      END
@end smallexample

If the above program prints contradictory results on a
particular compiler, run away!

@node EXPIMP
@section @code{EXPIMP}

@noindent
@smallexample
Intrinsic @var{intrinsic} referenced @dots{}
@end smallexample

The @var{intrinsic} is explicitly declared in one program
unit in the source file and implicitly used as an intrinsic
in another program unit in the same source file.

This diagnostic is designed to catch cases where a program
might depend on using the name @var{intrinsic} as an intrinsic
in one program unit and as a global name (such as the name
of a subroutine or function) in another, but @command{g77} recognizes
the name as an intrinsic in both cases.

After verifying that the program unit making implicit use
of the intrinsic is indeed written expecting the intrinsic,
add an @samp{INTRINSIC @var{intrinsic}} statement to that
program unit to prevent this warning.

This and related warnings are disabled by using
the @option{-Wno-globals} option when compiling.

Note that this warning is not issued for standard intrinsics.
Standard intrinsics include those described in the FORTRAN 77
standard and, if @option{-ff90} is specified, those described
in the Fortran 90 standard.
Such intrinsics are not as likely to be confused with user
procedures as intrinsics provided as extensions to the
standard by @command{g77}.

@node INTGLOB
@section @code{INTGLOB}

@noindent
@smallexample
Same name `@var{intrinsic}' given @dots{}
@end smallexample

The name @var{intrinsic} is used for a global entity (a common
block or a program unit) in one program unit and implicitly
used as an intrinsic in another program unit.

This diagnostic is designed to catch cases where a program
intends to use a name entirely as a global name, but @command{g77}
recognizes the name as an intrinsic in the program unit that
references the name, a situation that would likely produce
incorrect code.

For example:

@smallexample
INTEGER FUNCTION TIME()
@dots{}
END
@dots{}
PROGRAM SAMP
INTEGER TIME
PRINT *, 'Time is ', TIME()
END
@end smallexample

The above example defines a program unit named @samp{TIME}, but
the reference to @samp{TIME} in the main program unit @samp{SAMP}
is normally treated by @command{g77} as a reference to the intrinsic
@code{TIME()} (unless a command-line option that prevents such
treatment has been specified).

As a result, the program @samp{SAMP} will @emph{not}
invoke the @samp{TIME} function in the same source file.

Since @command{g77} recognizes @code{libU77} procedures as
intrinsics, and since some existing code uses the same names
for its own procedures as used by some @code{libU77}
procedures, this situation is expected to arise often enough
to make this sort of warning worth issuing.

After verifying that the program unit making implicit use
of the intrinsic is indeed written expecting the intrinsic,
add an @samp{INTRINSIC @var{intrinsic}} statement to that
program unit to prevent this warning.

Or, if you believe the program unit is designed to invoke the
program-defined procedure instead of the intrinsic (as
recognized by @command{g77}), add an @samp{EXTERNAL @var{intrinsic}}
statement to the program unit that references the name to
prevent this warning.

This and related warnings are disabled by using
the @option{-Wno-globals} option when compiling.

Note that this warning is not issued for standard intrinsics.
Standard intrinsics include those described in the FORTRAN 77
standard and, if @option{-ff90} is specified, those described
in the Fortran 90 standard.
Such intrinsics are not as likely to be confused with user
procedures as intrinsics provided as extensions to the
standard by @command{g77}.

@node LEX
@section @code{LEX}

@noindent
@smallexample
Unrecognized character @dots{}
Invalid first character @dots{}
Line too long @dots{}
Non-numeric character @dots{}
Continuation indicator @dots{}
Label at @dots{} invalid with continuation line indicator @dots{}
Character constant @dots{}
Continuation line @dots{}
Statement at @dots{} begins with invalid token
@end smallexample

Although the diagnostics identify specific problems, they can
be produced when general problems such as the following occur:

@itemize @bullet
@item
The source file contains something other than Fortran code.

If the code in the file does not look like many of the examples
elsewhere in this document, it might not be Fortran code.
(Note that Fortran code often is written in lower case letters,
while the examples in this document use upper case letters,
for stylistic reasons.)

For example, if the file contains lots of strange-looking
characters, it might be APL source code; if it contains lots
of parentheses, it might be Lisp source code; if it
contains lots of bugs, it might be C++ source code.

@item
The source file contains free-form Fortran code, but @option{-ffree-form}
was not specified on the command line to compile it.

Free form is a newer form for Fortran code.
The older, classic form is called fixed form.

@cindex continuation character
@cindex characters, continuation
Fixed-form code is visually fairly distinctive, because
numerical labels and comments are all that appear in
the first five columns of a line, the sixth column is
reserved to denote continuation lines,
and actual statements start at or beyond column 7.
Spaces generally are not significant, so if you
see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
you are looking at fixed-form code.
@cindex *
@cindex asterisk
Comment lines are indicated by the letter @samp{C} or the symbol
@samp{*} in column 1.
@cindex trailing comment
@cindex comment
@cindex characters, comment
@cindex !
@cindex exclamation point
(Some code uses @samp{!} or @samp{/*} to begin in-line comments,
which many compilers support.)

Free-form code is distinguished from fixed-form source
primarily by the fact that statements may start anywhere.
(If lots of statements start in columns 1 through 6,
that's a strong indicator of free-form source.)
Consecutive keywords must be separated by spaces, so
@samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
There are no comment lines per se, but @samp{!} starts a
comment anywhere in a line (other than within a character or
Hollerith constant).

@xref{Source Form}, for more information.

@item
The source file is in fixed form and has been edited without
sensitivity to the column requirements.

Statements in fixed-form code must be entirely contained within
columns 7 through 72 on a given line.
Starting them ``early'' is more likely to result in diagnostics
than finishing them ``late'', though both kinds of errors are
often caught at compile time.

For example, if the following code fragment is edited by following
the commented instructions literally, the result, shown afterward,
would produce a diagnostic when compiled:

@smallexample
C On XYZZY systems, remove "C" on next line:
C     CALL XYZZY_RESET
@end smallexample

The result of editing the above line might be:

@smallexample
C On XYZZY systems, remove "C" on next line:
     CALL XYZZY_RESET
@end smallexample

However, that leaves the first @samp{C} in the @code{CALL}
statement in column 6, making it a comment line, which is
not really what the author intended, and which is likely
to result in one of the above-listed diagnostics.

@emph{Replacing} the @samp{C} in column 1 with a space
is the proper change to make, to ensure the @code{CALL}
keyword starts in or after column 7.

Another common mistake like this is to forget that fixed-form
source lines are significant through only column 72, and that,
normally, any text beyond column 72 is ignored or is diagnosed
at compile time.

@xref{Source Form}, for more information.

@item
The source file requires preprocessing, and the preprocessing
is not being specified at compile time.

A source file containing lines beginning with @code{#define},
@code{#include}, @code{#if}, and so on is likely one that
requires preprocessing.

If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
the file normally will be compiled @emph{without} preprocessing
by @command{g77}.

Change the file's suffix from @samp{.f} to @samp{.F}
(or, on systems with case-insensitive file names,
to @samp{.fpp} or @samp{.FPP}),
from @samp{.for} to @samp{.fpp},
or from @samp{.FOR} to @samp{.FPP}.
@command{g77} compiles files with such names @emph{with}
preprocessing.

@pindex cpp
@cindex preprocessor
@cindex cpp program
@cindex programs, cpp
@cindex @option{-x f77-cpp-input} option
@cindex options, @option{-x f77-cpp-input}
Or, learn how to use @command{gcc}'s @option{-x} option to specify
the language @samp{f77-cpp-input} for Fortran files that
require preprocessing.
@xref{Overall Options,,Options Controlling the Kind of
Output,gcc,Using the GNU Compiler Collection (GCC)}.

@item
The source file is preprocessed, and the results of preprocessing
result in syntactic errors that are not necessarily obvious to
someone examining the source file itself.

Examples of errors resulting from preprocessor macro expansion
include exceeding the line-length limit, improperly starting,
terminating, or incorporating the apostrophe or double-quote in
a character constant, improperly forming a Hollerith constant,
and so on.

@xref{Overall Options,,Options Controlling the Kind of Output},
for suggestions about how to use, and not use, preprocessing
for Fortran code.
@end itemize

@node GLOBALS
@section @code{GLOBALS}

@noindent
@smallexample
Global name @var{name} defined at @dots{} already defined@dots{}
Global name @var{name} at @dots{} has different type@dots{}
Too many arguments passed to @var{name} at @dots{}
Too few arguments passed to @var{name} at @dots{}
Argument #@var{n} of @var{name} is @dots{}
@end smallexample

These messages all identify disagreements about the
global procedure named @var{name} among different program units
(usually including @var{name} itself).

Whether a particular disagreement is reported
as a warning or an error
can depend on the relative order
of the disagreeing portions of the source file.

Disagreements between a procedure invocation
and the @emph{subsequent} procedure itself
are, usually, diagnosed as errors
when the procedure itself @emph{precedes} the invocation.
Other disagreements are diagnosed via warnings.

@cindex forward references
@cindex in-line code
@cindex compilation, in-line
This distinction, between warnings and errors,
is due primarily to the present tendency of the @command{gcc} back end
to inline only those procedure invocations that are
@emph{preceded} by the corresponding procedure definitions.
If the @command{gcc} back end is changed
to inline ``forward references'',
in which invocations precede definitions,
the @command{g77} front end will be changed
to treat both orderings as errors, accordingly.

The sorts of disagreements that are diagnosed by @command{g77} include
whether a procedure is a subroutine or function;
if it is a function, the type of the return value of the procedure;
the number of arguments the procedure accepts;
and the type of each argument.

Disagreements regarding global names among program units
in a Fortran program @emph{should} be fixed in the code itself.
However, if that is not immediately practical,
and the code has been working for some time,
it is possible it will work
when compiled with the @option{-fno-globals} option.

The @option{-fno-globals} option
causes these diagnostics to all be warnings
and disables all inlining of references to global procedures
(to avoid subsequent compiler crashes and bad-code generation).
Use of the @option{-Wno-globals} option as well as @option{-fno-globals}
suppresses all of these diagnostics.
(@option{-Wno-globals} by itself disables only the warnings,
not the errors.)

After using @option{-fno-globals} to work around these problems,
it is wise to stop using that option and address them by fixing
the Fortran code, because such problems, while they might not
actually result in bugs on some systems, indicate that the code
is not as portable as it could be.
In particular, the code might appear to work on a particular
system, but have bugs that affect the reliability of the data
without exhibiting any other outward manifestations of the bugs.

@node LINKFAIL
@section @code{LINKFAIL}

@noindent
On AIX 4.1, @command{g77} might not build with the native (non-GNU) tools
due to a linker bug in coping with the @option{-bbigtoc} option which
leads to a @samp{Relocation overflow} error.  The GNU linker is not
recommended on current AIX versions, though; it was developed under a
now-unsupported version.  This bug is said to be fixed by `update PTF
U455193 for APAR IX75823'.

Compiling with @option{-mminimal-toc}
might solve this problem, e.g.@: by adding
@smallexample
BOOT_CFLAGS='-mminimal-toc -O2 -g'
@end smallexample
to the @code{make bootstrap} command line.

@node Y2KBAD
@section @code{Y2KBAD}
@cindex Y2K compliance
@cindex Year 2000 compliance

@noindent
@smallexample
Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
@end smallexample

This diagnostic indicates that
the specific intrinsic invoked by the name @var{name}
is known to have an interface
that is not Year-2000 (Y2K) compliant.

@xref{Year 2000 (Y2K) Problems}.

@end ifset

@node Keyword Index
@unnumbered Keyword Index

@printindex cp
@bye
OpenPOWER on IntegriCloud